From nobody Thu Jan 5 01:54:23 2017 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 435E6128E19 for ; Thu, 5 Jan 2017 01:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1, 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 duda7v3Jwdsy for ; Thu, 5 Jan 2017 01:54:17 -0800 (PST) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3133C1204D9 for ; Thu, 5 Jan 2017 01:54:16 -0800 (PST) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 402907CC004; Thu, 5 Jan 2017 10:54:15 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 22223410247; Thu, 5 Jan 2017 10:54:15 +0100 (CET) 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.319.2; Thu, 5 Jan 2017 10:54:14 +0100 To: "Ali Sajassi (sajassi)" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> From: Thomas Morin Organization: Orange Message-ID: <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> Date: Thu, 5 Jan 2017 10:54:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------786510FA443A178DD99F3F42" 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, 05 Jan 2017 09:54:21 -0000 --------------786510FA443A178DD99F3F42 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, 2016-12-19, Ali Sajassi (sajassi): > I have modified section 2.2 (copied below) to elaborate why coloring > approach for Leaf/Root MAC addresses is used in this draft. Also, the > use of single RT for this scenario is mentioned just as “MAY”. Please > review the text below and let me know if you still have > questions/comments: Thanks for providing text that goes in the right direction. I still have a few comments below. -Thomas > > 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 a Root AC or a Leaf AC > (but not both). > > > +---------+ +---------+ > | 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, just like the previous scenario (in section 2.1), > two Route Targets (one for Root and another for Leaf) can be used. > However, the difference is that on a PE with both Root and Leaf ACs, > all remote MAC routes are imported and thus there needs to be a way > to differentiate remote MAC routes associated with Leaf ACs versus > the ones associated with Root ACs in order to apply the proper > ingress filtering. > > In order to support such ingress filtering on the ingress PE with > both Leaf and Root ACs, one the following two approaches can be used: reverting A and B would be more natural since solution B corresponds to the starting point "what we had before this spec" > > A) Color MAC addresses with Leaf (or Root) color before distributing > them in BGP to other PEs depending on whether it is learned on a Leaf s/it is/they are/ > AC (or a Root AC) I think removing the parenthesis is needed for the 'whether' statement to parse. > > B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs > and another for Leaf ACs. I think "(two bridge tables per VLANs)" is inexact: "two bridge tables per VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a given EVI" ? Similarly, in the following paragraph, I think "per VLAN" should be replaced by "per E-TREE EVI having both Root and Leaf ACs". > > Maintaining two bridge tables per VLAN requires either two lookups be > performed per MAC address in either direction in case of a miss, or > duplicating many MAC addresses between the two bridge tables > belonging to the same VLAN (same E-TREE instance). The duplication of > MAC addresses are need for both locally learned and remotely learned > MAC addresses. Since it is said above "Maintaining two bridge tables per VLAN requires either two lookups [...] or duplicating many MAC addresses [...]", saying "The duplication of MAC addresses is needed for [...]" is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [...]". > Locally learned MAC addresses from Leaf ACs need to be > duplicated onto Root bridge table and locally learned MAC addresses > from Root ACs need to be duplicated onto Leaf bridge table. Remotely > learned MAC addresses from Root ACs need to be copied onto both Root > and Leaf bridge tables. > Neither double lookups nor MAC duplications > are considered viable options; therefore, this draft recommends the > use of MAC address coloring for this scenario as detailed in section > 3.1. I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on router platforms - on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow) - if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?) --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude. > > For this scenario, if for a given EVI, the vast majority of PEs will > have both Leaf and Root sites attached, even though they may start as > Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in > order to alleviate additional configuration overhead associated with "to alleviate additional configuration overhead associated with ..." -> "to alleviate the configuration overhead associated with ..." ? > using two RTs per EVI at the expense of having unwanted MAC addresses > on the Leaf-only PEs. > > > > From: Thomas Morin > > Organization: Orange > Date: Thursday, December 15, 2016 at 4:12 AM > To: Cisco Employee >, Loa > Andersson >, "George Swallow -T (swallow > - MBO PARTNERS INC at Cisco)" >, Eric Rosen >, BESS > > Cc: Martin Vigoureux > > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree > > Hi Ali, > > 2016-12-13, Ali Sajassi (sajassi): >> >> 2016-12-10, Ali Sajassi (sajassi): >>> Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, >>> impacts lot more sections than just section 2.2 for which you >>> suggested some texts. It drastically impacts section 3.1 (known >>> unicast traffic), and it also impacts section 3.2 (BUM traffic) and >>> section 5.1. >> >> Can you detail why ? >> The understanding that leads me to this suggestion is that the >> 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a >> 2.2.1 would not require new procotol procedures nor changes in the >> text that as I understand provides procedures for 2.2(.2) and 2.3. >> 2nd try. As my 1st response got truncated for some reason. >> >> The reason that impacts more sections than just sec. 2, is that the >> proposed 2.2.1 would be an alternative option for section 3.1. In >> section 3.1, the root/leaf indication for MAC addresses are done via >> flag-bit defined in section 5.1 and it only uses a single MAC-VRF >> (single bridge table per VLAN) per RFC 7432. If we go with two >> MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an >> alternative way of doing the same thing described in section 3.1. >> This alternative way has big ramifications on the platform as it >> requires duplicating MACs and managing multiple bridge tables per VLAN. > > Since 2.1 and the proposed 2.2.1 do not require new protocol > procedures (they only require split-horizon locally in Leaf MAC-VRFs), > if you state clearly that the procedures in the document are here to > address 2.2.2 and 2.3, then you don't need to modify the content of > the document after section 2 (more exactly, you will need minor update > like changing the current "This scheme applies to all scenarios > described in section 2." in section 3 into "This scheme applies to > scenarios described in 2.2.2 and 2.3". > > The "big ramifications" above are then not about section 3, but just > the (platform specific-drawbacks) of 2.2.2 that we have already > discussed and that can be covered in 2.2.2. > >> Maybe what you really want is to allow for scenario 2.2 to operate >> with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non >> of the drawbacks. So, maybe we can clarify the current text to make >> sure that this comes out clearly – ie, a PE can have single MAC–VRF >> can have multiple RTs. > > You could mention that, but for me the key things is: > - documenting the motivation for the new procedures > - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document > identified drawbacks) > >> >>> Furthermore, it creates a new paradigm for EVPN that was never >>> intended for because of creating two MAC-VRFs (and two bridge >>> tables) for the same VLAN. >> >> The " created a new paradigm that was never >> intended for" is a not generally valid, or sufficiently detailed, >> argument: if it was, then you might go as far as challenging the >> whole E-Tree spec on the same kind grounds (and many other new things). >> >> So here is where it seems we have a gap to bridge: I still don't >> understand what in RFC7432 describes an intention of "not supporting >> two MAC-VRFs for the same VLAN". >> >> I tried to explain the relationship between EVI, MAC-VRF, bridge >> table, and VLAN in my previous email per RFC 7432. However, lets park >> this discussion for time being as I think it is secondary. > > Ok, feel free to revisit if you think that RFC7432 would preclude > procedures that end up being described in this draft > >> I think you agree that if we have a single solution that has all the >> benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, >> it is much more preferable with having two solutions each with its >> own advantages and draw backs, right? If so, then existing text in >> 2.2 was intended to convey that. However, we can clarify it >> further – e.g, make it clear that for PE with root & leaf in the same >> EVI, we can use a single MAC-VRF with two RTs (one for leaf and >> another for root). > > As said above my key concern is having the document clearly spell out > the motivation for new specs. > If this implies documenting the fact that already existing procedure > can be used, but have drawbacks, then so be it ; there would be no > point in hiding that, right ? > > >> >>> The WG LC was completed on 3/29/16 and I am sure it is not your >>> intention to have major changes to the doc at this stage where >>> multiple vendors have already implemented the draft. >> >> As you know, there are different stages at which people do reviews on >> a doc after WGLC, an which may lead doc editors to introduce >> significant --editorial or technical-- changes in a document. >> Sometimes that leads to documents going back to the working group. >> >> However my root intention as doc shepherd, of course, is not to >> propose a major change, but merely to able to answer the standard >> question of the shepherd review -- on the reviews done, on document >> readiness, and on the document quality -- in a way as positive and >> sincere as possible. In particular questions (3) (4) and (6). >> >> So, hopefully the answers to these three questions are now >> clear. I believe your main concern is to ensure that we can apply >> two-RT approach of sec. 2.1 to sec. 2.2 (and we can still do and >> still have a single MAC-VRF) > > See above. > >> >> >>> This draft talks about two kinds of traffic filtering: a) ingress >>> filtering for known unicast and b) egress filtering for BUM traffic. >>> What you are suggesting is an alternate mechanism for ingress filtering. >> >> (well I'm not suggesting the mechanism itself --which section 2.1 >> already does-- but simply to document that it can still apply without >> the constraint of avoiding the presence of a Root MAC-VRF and a Leaf >> MAC-VRF on a same PE) >> >>> Although having multiple VRFs (and forwarding tables) are fine for >>> IP-VPNs because the unknown traffic is always dropped, multiple VRFs >>> for the same VLAN is not OK for L2 traffic because of flooding of >>> unknown traffic. That’s why in section 6 of RFC 7432, for all >>> service interface types, the draft talks about a single MAC-VRF per >>> EVI per PE and in case of VLAN-aware mode, multiple VLANs per >>> MAC-VRF but only a single bridge table per VLAN. In other words, the >>> bottom line is that there can only be a single bridge table per VLAN >>> in order to avoid unnecessary flooding. >> >> >> >>> When you have two MAC-VRFs per VLAN (one for root ACs and another >>> for Leaf ACs), then you either need to duplicate lots of MAC >>> addresses between these two VRFs, or do lookup on both of these >>> VRFs. Either ways this is not a good option relative to keeping a >>> single VRF table for both root and leaf sites and just have a >>> single-bit indication on whether a MAC is associated with root or >>> leaf (as currently described approach in the draft). I >> >> >> In the above, it seems you agree that it can work, and you are able >> to offer reasons why it is not the preferred option, then why not >> just document that it can work and provides these reasons as the >> motivations that lead to proposing a new specs ? >> >> Sure, I can do that. [...] > > Ok. > I'll be happy to review a new revision and hopefully post the shepherd > review. > > Thanks, > > -Thomas > > >> >> (it seems you have an unfinished last sentence: "I [...]" ) >> >> >>> >>>>> >>>>> (assuming the previous point is resolved:) >>>>> >>>>> With this mechanism above, isn't it possible to have on a given >>>>> PE, for a single E-TREE EVI, both Leaves and Roots, as long as >>>>> distinct MAC-VRFs are used (one for Leaves and one for Roots) ? >>>>> (it seems to me that the 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) >>>>> >>>>> >>>>> That’s 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 something). >>>> And that seems a completely arbitrary restriction. >>>> (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 how many MAC-VRF (and bridge >>>> tables) can be per EVI. >>> >>> This section of RFC7434 discusses many different things for the >>> different variants. >>> Can you provide a specific pointer about "how many MAC-VRFs can be >>> per EVI" ? >>> >>> Ali> Section 6 of RFC7432 spells out the relationship between EVI, >>> MAC-VRF, and bridge tables for all service interfaces very clearly. >>> In all service interfaces, the RFC says there is one MAC-VRF per EVI >>> on a given PE. >>> Now, if the service interface is “vlan-aware”, then there are >>> several bridge tables for that single MAC-VRF – ie, one bridge table >>> per VLAN. In all service interfaces, you can ONLY have one bridge >>> table per VLAN. >> >> This answer is everything but a specific pointer. >> If Section 6 of RFC7432 says all this very clearly, I guess it should >> be possible to extract quotes about "there is one MAC-VRF per EVI on >> a given PE", right ? >> >> >>> >>>> In bridging world, there can only be a single bridge table per VLAN >>>> in a device. >>> >>> I still don't find here anything that would preclude having, on a >>> given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots >>> MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with >>> translation if the external VLANs are constrained). >>> >>> Ali> Lets assume we are using vlan-based service and thus there is >>> only a single bridge table per MAC-VRF, then what you are suggesting >>> is two use two MAC-VRFs (two bridge tables) for the same EVI (same >>> VLAN). This results in some duplications of MAC addresses and would >>> only work if flooding is disabled (more on this later). >> >> "results in some duplications of MAC" is perhaps a drawback, but >> nothing like "just does not work" ? >> >> "would only work if flooding is disabled": why ? (you wrote "(more >> on this later)" but I couldn't identify anything recent from you in >> the rest of the email below) >> >> >> From an helicopter view, I can't see what fundamentally would become >> problematic between "two MAC-VRFs on two distinct PEs" and the same >> "two MAC-VRFs on a same PEs", at worse it is as efficient or as >> inefficient as having them on separate PEs (think logical router >> without anykind of dataplane optimisation), and we can't exclude that >> the PE could have local implementation details to do better than that. >> >> >>>> >>>>> Besides, I don’t 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 replicating all the MAC addresses associated with >>>> the root sites in two bridge tables. >>> >>> Your point above certainly does not sound to me as "it can't be >>> done": some may think that the above is an acceptable cost, some >>> others may find ways to make this "replication" with a low overhead, >>> on some platforms the cost may be negligible, etc. >>> >>> >>>> >>>> >>>>> 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 implement a shortcut not involving >>>> MPLS encap/decap). >>>> >>>> Anything is possible but at what cost. >>> >>> You know, for cost it is not always obvious to reach conclusions >>> that are true for all implementations and all targets. >>> >>>> The current proposal is very efficient in terms of forwarding path >>>> as well as control plane. >>> >>> Sure, but what I question is not the new solution but the lack of >>> discussion on why using the existing specs was not considered good >>> enough. >>> >>> >>> I think that my concern of clearly explaining the scenarios and >>> motivations for this new spec could be addressed by splitting >>> section 2.2 into a 2.2.1 describing the approach from 2.1 and its >>> possible drawbacks, and a 2.2.2 having essentially the content of >>> current section 2.2. >>> >>> Here is a proposal: >>> >>> 2.2 Scenario 2: Leaf of Root site(s) per AC >>> >>> In these scenarii, 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 Root(s) >>> or Leaf(s) (but not both). >>> >>> 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root >>> MAC-VRFs >>> >>> +---------+ +---------+ >>> | PE1 | | PE2 | >>> +---+ | +---+ | +------+ | +---+ | +---+ >>> |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| >>> +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ >>> | |VRF| | | /IP | | '---' | >>> | | | | | | | .---. | >>> | | | | | | | |MAC| | +---+ >>> | | | | | | | |VRF+--+---ES2/AC2--+CE3| >>> | +---+ | +------+ | +---+ | (Root) +---+ >>> +---------+ +---------+ >>> >>> Figure 2: Scenario 2a >>> >>> In this scenario, the RT constraint procedures described in section >>> 2.1 could >>> also be used. The feasibility and efficiency of this approach depends on >>> platforms specifics. >>> >>> This approach will lead toduplication of a large proportion of MAC >>> addresseson >>> PEs having both Leaf and Root sites, and is hence considered less >>> suitable for >>> deployment contexts where the vast majority of PEs are likely to >>> ultimately >>> have both Leaf and Root sites attached to them. >>> >>> 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF >>> >>> +---------+ +---------+ >>> | PE1 | | PE2 | >>> +---+ | +---+ | +------+ | +---+ | +---+ >>> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >>> +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ >>> | |VRF| | | /IP | | |VRF| | >>> | | | | | | | | | | +---+ >>> | | | | | | | | +--+---ES2/AC2--+CE3| >>> | +---+ | +------+ | +---+ | (Root) +---+ >>> +---------+ +---------+ >>> >>> Figure 2: Scenario 2b >>> >>> This scenario will alleviate keys drawbacks from Scenario 2a, in >>> particular >>> by avoiding duplication of MAC addresses on Leaf/Root PEs and >>> avoiding the >>> operational overhead of managing more than one RT. >>> This approach comes at the expense of having routes for unneeded >>> MAC addresses on Leaf-only PEs, and is hence considered less >>> suitable for deployment contexts where the vast majority of PEs >>> would remain Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures >>> provided in this document. >>> >>> >>> (And this last sentence should be added to section 2.3 as well) >>> >>>> >>>>>> 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 “majority” to “vast majority” :-) >>>> >>>> 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 >>>> identified: having useless routes on the fraction of PEs having >>>> only Leaves. >>>> But the gain brought by the recommendation is not even mentioned, >>>> not to say explained. >>>> Hence: why ? >>>> (Why is it a useful tradeoff to have useless routes on some, even >>>> if only one, PE ?) >>>> >>>> Changed the last sentence from: >>>> "then it is recommended to use a single RT per EVI and avoid >>>> additional configuration and operational overhead.” >>>> To >>>> "then it is recommended to use a single RT per EVI and avoid >>>> additional configuration and operational overhead >>>> at the expense of having unwanted MAC addresses on the Leaf PEs." >>> >>> Ok. I adapted and incorporated this addition into my proposed text >>> splitting 2.2 into a 2.2.1 and a 2.2.2. >>> >>> Best, >>> >>> -Thomas >>> >>> >> > --------------786510FA443A178DD99F3F42 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring approach for Leaf/Root MAC addresses is used in this draft. Also, the use of single RT for this scenario is mentioned just as “MAY”. Please review the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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 a Root AC or a Leaf AC
   (but not both). 

                     +---------+            +---------+
                     |   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, just like the previous scenario (in section 2.1),
   two Route Targets (one for Root and another for Leaf) can be used.
   However, the difference is that on a PE with both Root and Leaf ACs,
   all remote MAC routes are imported and thus there needs to be a way
   to differentiate remote MAC routes associated with Leaf ACs versus
   the ones associated with Root ACs in order to apply the proper
   ingress filtering. 
   In order to support such ingress filtering on the ingress PE with
   both Leaf and Root ACs, one the following two approaches can be used:

reverting A and B would be more natural since solution B corresponds to the starting point "what we had before this spec"

   A) Color MAC addresses with Leaf (or Root) color before distributing
   them in BGP to other PEs depending on whether it is learned on a Leaf

s/it is/they are/

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to parse.
   B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "two bridge tables per VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a given EVI" ?

Similarly, in the following paragraph, I think "per VLAN" should be replaced by "per E-TREE EVI having both Root and Leaf ACs".
   Maintaining two bridge tables per VLAN requires either two lookups be
   performed per MAC address in either direction in case of a miss, or
   duplicating many MAC addresses between the two bridge tables
   belonging to the same VLAN (same E-TREE instance). The duplication of
   MAC addresses are need for both locally learned and remotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN requires either two lookups [...] or duplicating many MAC addresses [...]", saying "The duplication of MAC addresses is needed for [...]"  is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [...]".

   Locally learned MAC addresses from Leaf ACs need to be
   duplicated onto Root bridge table and locally learned MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge table. Remotely
   learned MAC addresses from Root ACs need to be copied onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft recommends the
   use of MAC address coloring for this scenario as detailed in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on router platforms
- on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow)
- if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup  (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution

The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude.
   For this scenario, if for a given EVI, the vast majority of PEs will
   have both Leaf and Root sites attached, even though they may start as
   Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
   order to alleviate  additional configuration overhead associated with

"to alleviate  additional configuration overhead associated with ..." -> "to alleviate the configuration overhead associated with ..." ?

   using two RTs per EVI at the expense of having unwanted MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Thursday, December 15, 2016 at 4:12 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of draft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot more sections than just section 2.2 for which you suggested some texts. It drastically  impacts section 3.1 (known unicast traffic), and it also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the proposed 2.2.1 would be an alternative option for section 3.1. In section 3.1, the root/leaf indication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an alternative way of doing the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that the procedures in the document are here to address 2.2.2 and 2.3, then you don't need to modify the content of the document after section 2  (more exactly, you will need minor update like changing the current "This scheme applies to all scenarios described in section 2." in section 3 into "This scheme applies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but just the (platform specific-drawbacks) of 2.2.2 that we have already discussed and that can be covered in 2.2.2.

Maybe what you really want is to allow for scenario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text to make sure that this comes out clearly – ie, a PE can have single MAC–VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified drawbacks)


Furthermore, it creates a new paradigm for EVPN that was never intended for because of creating two MAC-VRFs (and two bridge tables) for the same VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN".

I tried to explain the relationship between EVI, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. However, lets park this discussion for time being as I think it is secondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedures that end up being described in this draft

I think you agree that if we have a single solution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much more preferable with having two solutions each with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. However, we can clarify it further – e.g, make it clear that for PE with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the motivation for new specs.
If this implies documenting the fact that already existing procedure can be used, but have drawbacks, then so be it ; there would be no point in hiding that, right ?



The WG LC was completed on 3/29/16 and I am sure it is not your intention to have major changes to the doc at this stage where multiple vendors have already implemented the draft.

As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three questions are now clear. I believe your main concern is to ensure that we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can still do and still have a single MAC-VRF)

See above.


This draft talks about two kinds of traffic filtering: a) ingress filtering for known unicast and b) egress filtering for BUM traffic. What you are suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE)

Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped, multiple VRFs for the same VLAN is not OK for L2 traffic because of flooding of unknown traffic. That’s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In other words, the bottom line is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf ACs), then you either need to duplicate lots of MAC addresses between these two VRFs, or do lookup on both of these VRFs. Either ways this is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit indication on whether a MAC is associated with root or leaf (as currently described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd review.

Thanks,

-Thomas



(it seems you have an unfinished last sentence: "I [...]" )


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the 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)

That’s 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 something).
And that seems a completely arbitrary restriction.
(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 how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI on a given PE.
Now, if the service interface is “vlan-aware”, then there are several bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. In all service interfaces, you can ONLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?



In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is only a single bridge table per MAC-VRF, then what you are suggesting is two use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below)


From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that.



Besides, I don’t 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 replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




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 implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

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

   In these scenarii, 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 Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 “majority” to “vast majority” :-)

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 identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

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

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------786510FA443A178DD99F3F42-- From nobody Mon Jan 9 17:28:56 2017 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 C6AB11295F1; Mon, 9 Jan 2017 17:28:50 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148401173080.25046.2513424962779854978.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 17:28:50 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-bgp-vpls-control-flags-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: Tue, 10 Jan 2017 01:28:51 -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 : Updated processing of control flags for BGP VPLS Authors : Ravi Singh Kireeti Kompella Senad Palislamovic Filename : draft-ietf-bess-bgp-vpls-control-flags-02.txt Pages : 8 Date : 2017-01-09 Abstract: This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-bgp-vpls-control-flags-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-bgp-vpls-control-flags-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 Tue Jan 10 13:38:03 2017 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 078E31295C1; Tue, 10 Jan 2017 13:38:02 -0800 (PST) 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 qP9bM6ITGiMK; Tue, 10 Jan 2017 13:37:59 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C751295BE; Tue, 10 Jan 2017 13:37:56 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0ALbrv4000441; Tue, 10 Jan 2017 21:37:53 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0ALbogh000419 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2017 21:37:52 GMT From: "Adrian Farrel" To: , Date: Tue, 10 Jan 2017 21:37:49 -0000 Message-ID: <06b901d26b89$ccf3ff80$66dbfe80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJricQq9zcMjzQMSkSpTySYEGP4dg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22816.002 X-TM-AS-Result: No--8.531-10.0-31-10 X-imss-scan-details: No--8.531-10.0-31-10 X-TMASE-MatchedRID: R1xiGq/shpuJ/ollFUOCKeG5dRZCgxC39pLnYtQ99xIGW3hFnC9N1ZWT If+vN5cu4e8y2TDxCW7X+4pjLOgXfGepgZKXIav+xFhT7DBLefByawdArtww58eQfu6iwSfs6Z2 96E0MIULiJ80GM+ooz/Ouevzwt0wjRBZ3QLvUqCRwUSK4/EeOxT9BLgfcJDLqQ+MGgPhHUCYhXF Y4E85YVrgVK28gazGqH2XXM8w5v7pNfs8n85Te8v7E6GNqs6ce3QfwsVk0UbtuRXh7bFKB7nChb F88XI4tHdchCWZvoLlQOnSbMP0Oe8vxF2o4c3l1YDttQUGqHZU= Archived-At: Cc: draft-mackie-bess-nsh-bgp-control-plane@ietf.org Subject: [bess] New revision of draft-mackie-bess-nsh-bgp-control-plane 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: Tue, 10 Jan 2017 21:38:02 -0000 Hi, [Cross-posting to BESS and SFC as requested by the AD] We just posted an update to draft-mackie-bess-nsh-bgp-control-plane You can find it at https://datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/ where the diff function on the History tab may be useful. In summary: - We added some sections to the "Advanced Topics" in Section 7 - Considerations for Stateful Service Functions - Flow Spec for SFC Classifiers - Choice of Data Plane SPI/SI Representation - We added some more examples in Section 8 - Examples of SFPs with Stateful Service Functions - Two new IANA sections at the end of Section 10 - New Generic Transitive Experimental Use Extended Community Sub-Type - SPI/SI Representation (Note that the diff tool makes a pig's ear of the changes around the end of section 7 trying to fold them into section 8.) Other changes are more minor and are mainly slight clarifications As usual, we'd be delighted to discuss this document on either of the mailing lists. It looks as though Eric and I will be in Westford during the SFC interim next week, so we can also talk face-to-face with anyone who is there. Thanks, Adrian From nobody Thu Jan 12 15:16:15 2017 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 E2337128BA2 for ; Thu, 12 Jan 2017 15:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 MnWaNbs1ynm5 for ; Thu, 12 Jan 2017 15:16:06 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64532127071 for ; Thu, 12 Jan 2017 15:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147783; q=dns/txt; s=iport; t=1484262966; x=1485472566; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pqG53Qv09lq0VgnUcqEHvaLplNyp49HYhryh3pCGXAw=; b=E9dE05+s0ptJM1wnWCJZwsotmypx6c7OJDGP+4YfQ+bolGO1HOxEf8A9 2OU+t/ETKatucLw4nPf1k6X543teOpzUeqIvyro5NHyOX/dE87nAmYK0J JQYkaYojh1I6KGoy9Y//QgpBlzj1DGVsADuMjzcHxXQxLg3Gsvdpa498K A=; X-Files: draft-ietf-bess-evpn-etree-08.txt : 42230 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQB4DXhY/4kNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJyOw8BAQEBAR9fgQkHjVCSFJUqgg0mgiEBJIM2AoIIPxQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBBoBDEAFAQQBAQECAxACAQgRAwECIQEGBwIwFAkIAgQBD?= =?us-ascii?q?QMCCQUGB4hlDrJHOiuJYgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4PiiCBBoQNCgE?= =?us-ascii?q?GBQYBLQYJDAwChSoBBIh2hiiGCoYEAYNmgnSDFYMcgg+CO4F3GDmEPYNNhGKBN?= =?us-ascii?q?ogTgh+EHxAjg18BHzhxUxU6gkOBcQUXgV9BMgGGKAEEAggXgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,220,1477958400"; d="txt'?scan'208,217";a="371350777" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2017 23:16:03 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0CNG3Pc011102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2017 23:16:03 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, 12 Jan 2017 18:16:02 -0500 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, 12 Jan 2017 18:16:02 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , 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+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAAgAABy4CAAydaAIAFHy2AgBu7JwCAC1ogAA== Date: Thu, 12 Jan 2017 23:16:02 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> In-Reply-To: <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/mixed; boundary="_004_D49D34031C82F7sajassiciscocom_" 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, 12 Jan 2017 23:16:12 -0000 --_004_D49D34031C82F7sajassiciscocom_ Content-Type: multipart/alternative; boundary="_000_D49D34031C82F7sajassiciscocom_" --_000_D49D34031C82F7sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, I have incorporated your new comments and generated the new text attached h= ere. Please review section 2.2 and let me know if there are any more commen= ts. Please refer below for the comment resolution explanation of some of th= e comments. Regards, Ali From: Thomas Morin = > Organization: Orange Date: Thursday, January 5, 2017 at 1:54 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-19, Ali Sajassi (sajassi): I have modified section 2.2 (copied below) to elaborate why coloring approa= ch for Leaf/Root MAC addresses is used in this draft. Also, the use of sing= le RT for this scenario is mentioned just as =93MAY=94. Please review the t= ext below and let me know if you still have questions/comments: Thanks for providing text that goes in the right direction. I still have a few comments below. -Thomas 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 a Root AC or a Leaf AC (but not both). +---------+ +---------+ | 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, just like the previous scenario (in section 2.1), two Route Targets (one for Root and another for Leaf) can be used. However, the difference is that on a PE with both Root and Leaf ACs, all remote MAC routes are imported and thus there needs to be a way to differentiate remote MAC routes associated with Leaf ACs versus the ones associated with Root ACs in order to apply the proper ingress filtering. In order to support such ingress filtering on the ingress PE with both Leaf and Root ACs, one the following two approaches can be used: reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec" Done. A) Color MAC addresses with Leaf (or Root) color before distributing them in BGP to other PEs depending on whether it is learned on a Leaf s/it is/they are/ Done. AC (or a Root AC) I think removing the parenthesis is needed for the 'whether' statement to p= arse. Done. B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs and another for Leaf ACs. I think "(two bridge tables per VLANs)" is inexact: "two bridge tables per= VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a give= n EVI" ? That=92s fine. Done! Similarly, in the following paragraph, I think "per VLAN" should be replace= d by "per E-TREE EVI having both Root and Leaf ACs". A single EVI can consist of many VLANs (in case of VLAN-aware bundle servic= e), so, =93per VLAN=94 is right. However, to make it more exact as above, I= =92ll change it to =93per VLAN (when both Root and Leafs ACs exist for that= VLAN) requires =85=94. Maintaining two bridge tables per VLAN requires either two lookups be performed per MAC address in either direction in case of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE instance). The duplication of MAC addresses are need for both locally learned and remotely learned MAC addresses. Since it is said above "Maintaining two bridge tables per VLAN requires eit= her two lookups [...] or duplicating many MAC addresses [...]", saying "The= duplication of MAC addresses is needed for [...]" is surprising, so I gue= ss the intent is rather "Unless two lookups are made, duplication of MAC ad= dresses would be needed for [...]". That is correct. I=92ll change it to the sentence that you suggested: =93Un= less two lookups are made, =85" Locally learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC addresses from Root ACs need to be duplicated onto Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Neither double lookups nor MAC duplications are considered viable options; therefore, this draft recommends the use of MAC address coloring for this scenario as detailed in section 3.1. I think that this explanation is too elliptic compared to the strong ("not = viable") conclusion. As soon as we talk about implementation details, a mor= e detailed discussion is required on why, and under which assumptions, some= things are impossible -- there can be many different way to implement a d= ataplane. Without explaining what "two lookups" exactly means in this conte= xt, it's hard to follow why it would be required if duplicating MAC address= es is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on ro= uter platforms - on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow) - if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup (building one table, marking= MAC entries as Leaf entries if they were learned with routes carrying only= the Leaf RT?) --- don't misunderstand me: I'm not claiming that this work= s (I haven't looked closely enough), but simply that the text provided is n= ot sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still,= nothing is explained on why this is "not viable". It seems to be as someth= ing rather belonging to the realm of "having a scalability impact", but eve= n looking in this respect we are not talking about a change of order of mag= nitude. The non-viable conclusion was based on investigation that I did for micro-c= ode and ASIC based platforms; however, I see your point and I am para-phras= ing the sentence as follow to leave room for future investigation. "In order to avoid two MAC-VRFs, this draft introduces the coloring option = (B) as detailed in section 3.1" For this scenario, if for a given EVI, the vast majority of PEs will have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in order to alleviate additional configuration overhead associated with "to alleviate additional configuration overhead associated with ..." -> "t= o alleviate the configuration overhead associated with ..." ? Done. using two RTs per EVI at the expense of having unwanted MAC addresses on the Leaf-only PEs. From: Thomas Morin = > Organization: Orange Date: Thursday, December 15, 2016 at 4:12 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-13, Ali Sajassi (sajassi): 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. 2nd try. As my 1st response got truncated for some reason. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2 (= more exactly, you will need minor update like changing the current "This sc= heme applies to all scenarios described in section 2." in section 3 into "T= his scheme applies to scenarios described in 2.2.2 and 2.3". The "big ramifications" above are then not about section 3, but just the (p= latform specific-drawbacks) of 2.2.2 that we have already discussed and tha= t can be covered in 2.2.2. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. You could mention that, but for me the key things is: - documenting the motivation for the new procedures - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks) Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). As said above my key concern is having the document clearly spell out the m= otivation for new specs. If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ? The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) See above. This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. [...] Ok. I'll be happy to review a new revision and hopefully post the shepherd revi= ew. Thanks, -Thomas (it seems you have an unfinished last sentence: "I [...]" ) (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. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. 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. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. 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. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, 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 Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) 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 addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D49D34031C82F7sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <885CA848E56D5148A57EAD2D52332479@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Thomas,

I have incorporated your new comments and generated the new text attached h= ere. Please review section 2.2 and let me know if there are any more commen= ts. Please refer below for the comment resolution explanation of some of th= e comments.

Regards,
Ali


From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Thursday, January 5, 2017 at = 1:54 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow= - MBO PARTNERS INC at Cisco)" <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

Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring a= pproach for Leaf/Root MAC addresses is used in this draft. Also, the use of= single RT for this scenario is mentioned just as =93MAY=94. Please review = the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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

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


                  &nb= sp;  +---------+            += ;---------+
                  &nb= sp;  |   PE1   |            | =   PE2   |
    +---+           &nb= sp;|  +---+  |  +------+  |  += ---+  |            +---+
    |CE1+-----ES1----+--+   |  | &= nbsp;|      |  |  |   +--+---ES2/AC1-= -+CE2|
    +---+    (Leaf)  |  |MAC= |  |  | MPLS |  |  |MAC|  |   (Leaf)   &= #43;---+
                  &nb= sp;  |  |VRF|  |  |  /IP |  |  |VRF| &nb= sp;|
                  &nb= sp;  |  |   |  |  |      |  | =  |   |  |            +---&= #43;
                  &nb= sp;  |  |   |  |  |      |  | =  |   +--+---ES2/AC2--+CE3|
                  &nb= sp;  |  +---+  |  +------+  | &nbs= p;+---+  |   (Root)   +---+
                  &nb= sp;  +---------+            += ;---------+

   Figure 2: Scenario 2

   In this scenario, just like the previous scenario (in= section 2.1),
   two Route Targets (one for Root and another for Leaf)= can be used.
   However, the difference is that on a PE with both Roo= t and Leaf ACs,
   all remote MAC routes are imported and thus there nee= ds to be a way
   to differentiate remote MAC routes associated with Le= af ACs versus
   the ones associated with Root ACs in order to apply t= he proper
   ingress filtering. 

   In order to support such ingress filtering on the ing= ress PE with
   both Leaf and Root ACs, one the following two approac= hes can be used:

reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec"

Done.

   A) Color MAC addresses with Leaf (or Root) color befo= re distributing
   them in BGP to other PEs depending on whether it is l= earned on a Leaf

s/it is/they are/

Done.

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to p= arse.

Done.

   B) Use two MAC-VRFs (two bridge tables per VLANs) - o= ne for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "t= wo bridge tables per VLAN if a given VLAN exists on the PE for both Leaf an= d Root ACs of a given EVI" ?

That=92s fin= e. Done!


Similarly, in the following paragraph, I think "per VLAN" should = be replaced by "per E-TREE EVI having both Root and Leaf ACs".

A single EVI can consist of many VLANs (in cas= e of VLAN-aware bundle service), so, =93per VLAN=94 is right. However,= to make it more exact as above, I=92ll change it to =93per = VLAN (when both Root and Leafs ACs exist for that VLAN) requires = =85=94.




   Maintaining two bridge tables per VLAN requires eithe= r two lookups be
   performed per MAC address in either direction in case= of a miss, or
   duplicating many MAC addresses between the two bridge= tables
   belonging to the same VLAN (same E-TREE instance). Th= e duplication of
   MAC addresses are need for both locally learned and r= emotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN require= s either two lookups [...] or duplicating many MAC addresses [...]", s= aying "The duplication of MAC addresses is needed for [...]" = ; is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [..= .]".

That is correct. I=92ll change it to the&= nbsp;sentence that you suggested: =93Unless two lookups are made, = ;=85"


   Locally learned MAC addresses from Leaf ACs need to b= e
   duplicated onto Root bridge table and locally learned= MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge = table. Remotely
   learned MAC addresses from Root ACs need to be copied= onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft = recommends the
   use of MAC address coloring for this scenario as deta= iled in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("= ;not viable") conclusion. As soon as we talk about implementation deta= ils, a more detailed discussion is required on why, and under which assumpt= ions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining wha= t "two lookups" exactly means in this context, it's hard to follo= w why it would be required if duplicating MAC addresses is not done, and wh= y it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on ro= uter platforms
- on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow)
- if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup  (building one table, ma= rking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't = misunderstand me: I'm not claiming that this works (I haven't looked closel= y enough), but simply that the text provided is not sufficient to exclude t= his kind of solution

The "duplicating MAC addresses" alternative is explained better, = but still, nothing is explained on why this is "not viable". It s= eems to be as something rather belonging to the realm of "having a sca= lability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investi= gation that I did for micro-code and ASIC based platforms; however, I = see your point and I am para-phrasing the sentence as follow to leave = room for future investigation. 
"In order to avoid two MAC-VRFs, this dra= ft introduces the coloring option (B) as detailed in section 3.1"



   For this scenario, if for a given EVI, the vast major= ity of PEs will
   have both Leaf and Root sites attached, even though t= hey may start as
   Root-only or Leaf-only PEs, then a single RT per EVI = MAY be used in
   order to alleviate  additional configuration ove= rhead associated with

"to alleviate  additional configuration overhead associated with = ..." -> "to alleviate the configuration overhead associated wi= th ..." ?

Done.

   using two RTs per EVI at the expense of having unwant= ed MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange= .com>
Organization: Orange
Date: Thursday, December 15, 2016 a= t 4:12 AM
To: Cisco Employee <sajassi@cisco.com>= , Loa Andersson <l= oa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS = <bess@ietf.org= >
Cc: Martin Vigoureux <martin.vigoure= ux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2  (more exactly, you will need= minor update like changing the current "This scheme applies to all sc= enarios described in section 2." in section 3 into "This scheme a= pplies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but j= ust the (platform specific-drawbacks) of 2.2.2 that we have already discuss= ed and that can be covered in 2.2.2.

=
Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks)

=

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft

=
I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the m= otivation for new specs.
If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ?


=

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF)

See above.
=


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd revi= ew.

Thanks,

-Thomas


=

(it seems you have an unfinished last sentence: "I [...]" )


=


(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.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on = a given PE", right ?


=

In bridging world= , there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

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 logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




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 implement a shortcut not involving MPLS encap/decap)= .

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The cu= rrent proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

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

   In these scenarii, a P= E receives traffic from either Root OR Leaf
   sites (but not both) o= n a given Attachment Circuit (AC) of an EVI. In
   other words, an AC (ES= or ES/VLAN) is either associated with Root(s)
   or Leaf(s) (but not bo= th).

2.2.1 Scenario 2a: Leaf OR Root sit= e(s) per AC, separate Leaf/Root MAC-VRFs

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |VRF|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  '---'&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  .---.  |=
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |MAC|  |      &nbs= p;     +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |VRF+--+---ES2/AC2--+CE3|
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2a<= /tt>

   In this scenario, the = RT constraint procedures described in section 2.1 could
   also be used. The feas= ibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lea= d toduplication of a large proporti= on of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both Leaf and Roo= t sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root sit= e(s) per AC, single MAC-VRF

      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+
      = ;            &n= bsp;  |   PE1   |     &nb= sp;      |   PE2   |
    +---+&nb= sp;           |  = 3;---+  |  +------+  |  +---+ = |            +-= --+
    |CE1+-----ES= 1----+--+   |  |  |    &nbs= p; |  |  |   +--+---ES2/AC1--+CE2|
    +---+&nb= sp;   (Leaf)  |  |MAC|  |  | MPLS |  |&n= bsp; |MAC|  |   (Leaf)   +---+
      = ;            &n= bsp;  |  |VRF|  |  |  /IP |  |  |VRF|&nb= sp; |
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   |  |     =        +---+
      = ;            &n= bsp;  |  |   |  |  |    &= nbsp; |  |  |   +--+---ES2/AC2--+CE3|<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  |  +---+  |  +------+  |&nbs= p; +---+  |   (Root)   +---+<= tt style=3D"color: rgb(0, 0, 0);">
      = ;            &n= bsp;  +---------+       &nb= sp;    +---------+

   Figure 2: Scenario 2b<= /tt>

   This scenario will all= eviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplicatio= n of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead o= f managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 "majority", but was that you should explain w= hy you recommend that.
As the text currently reads, the cost of the recommendation can be identified: having = useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.=
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)<= /font>

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."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas





--_000_D49D34031C82F7sajassiciscocom_-- --_004_D49D34031C82F7sajassiciscocom_ Content-Type: text/plain; name="draft-ietf-bess-evpn-etree-08.txt" Content-Description: draft-ietf-bess-evpn-etree-08.txt Content-Disposition: attachment; filename="draft-ietf-bess-evpn-etree-08.txt"; size=42230; creation-date="Thu, 12 Jan 2017 23:16:02 GMT"; modification-date="Thu, 12 Jan 2017 23:16:02 GMT" Content-ID: <80FCCB73743809409B0C5F9F752CD5AC@emea.cisco.com> Content-Transfer-Encoding: base64 IA0KDQoNCg0KQkVTUyBXb3JrZ3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQS4gU2FqYXNzaSwgRWQuDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUy4gU2FsYW0NCkludGVuZGVkIFN0YXR1 czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNj bw0KVXBkYXRlczogUkZDNzM4NSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEouIERyYWtlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmlwZXINCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEouIFV0dGFybw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQVRUDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFMuIEJvdXRyb3MNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2FyZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBS YWJhZGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTm9raWENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KRXhwaXJlczogTWF5IDIw LCAyMDE3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwLCAyMDE2 DQoNCg0KICAgICAgICAgICAgICAgICAgIEUtVFJFRSBTdXBwb3J0IGluIEVWUE4gJiBQQkItRVZQ Tg0KICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUtMDggDQoN Cg0KQWJzdHJhY3QNCg0KICAgVGhlIE1ldHJvIEV0aGVybmV0IEZvcnVtIChNRUYpIGhhcyBkZWZp bmVkIGEgcm9vdGVkLW11bHRpcG9pbnQNCiAgIEV0aGVybmV0IHNlcnZpY2Uga25vd24gYXMgRXRo ZXJuZXQgVHJlZSAoRS1UcmVlKS4gQSBzb2x1dGlvbg0KICAgZnJhbWV3b3JrIGZvciBzdXBwb3J0 aW5nIHRoaXMgc2VydmljZSBpbiBNUExTIG5ldHdvcmtzIGlzIHByb3Bvc2VkIGluDQogICBhbmQg UkZDIGNhbGxlZCAiQSBGcmFtZXdvcmsgZm9yIEUtVHJlZSBTZXJ2aWNlIG92ZXIgTVBMUyBOZXR3 b3JrIi4NCiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGhvdyB0aG9zZSBmdW5jdGlvbmFsIHJl cXVpcmVtZW50cyBjYW4gYmUNCiAgIGVhc2lseSBtZXQgd2l0aCAoUEJCLSlFVlBOIGFuZCBob3cg KFBCQi0pRVZQTiBvZmZlcnMgYSBtb3JlIGVmZmljaWVudA0KICAgaW1wbGVtZW50YXRpb24gb2Yg dGhlc2UgZnVuY3Rpb25zLiBUaGlzIGRvY3VtZW50IG1ha2VzIHVzZSBvZiB0aGUNCiAgIG1vc3Qg c2lnbmlmaWNhbnQgYml0IG9mIHRoZSBzY29wZSBnb3Zlcm5lZCBieSB0aGUgSUFOQSByZWdpc3Ry eQ0KICAgY3JlYXRlZCBieSBSRkM3Mzg1LCBhbmQgaGVuY2UgdXBkYXRlcyB0aGF0IFJGQyBhY2Nv cmRpbmdseS4NCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgaXMgc3VibWl0dGVkIHRvIElFVEYgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAg cHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sg Rm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRo YXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRz IGFzDQogICBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQg ZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBi ZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh bnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJh ZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KIA0KDQoNClNhamFzc2kgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBNYXkgMjAsIDIwMTcgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSU5URVJO RVQgRFJBRlQgICAgIEUtVFJFRSBTdXBwb3J0IGluIEVWUE4gJiBQQkItRVZQTiAgIERlY2VtYmVy IDIwLCAyMDE2DQoNCg0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJhY3RzLmh0bWwN Cg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBi ZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQoNCkNv cHlyaWdodCBhbmQgTGljZW5zZSBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDE2IElFVEYg VHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRo b3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3Qg dG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5z ZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMg ZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QN CiAgIHRvIHRoaXMgZG9jdW1lbnQuIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlz IGRvY3VtZW50IG11c3QNCiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lv bnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4g dGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuDQoNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQog ICAxICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDQNCiAgICAgMS4xICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMiAgRS1UcmVlIFNjZW5hcmlvcyBh bmQgRVZQTiAvIFBCQi1FVlBOIFN1cHBvcnQgIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIu MSBTY2VuYXJpbyAxOiBMZWFmIE9SIFJvb3Qgc2l0ZShzKSBwZXIgUEUgIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDQNCiAgICAgMi4yIFNjZW5hcmlvIDI6IExlYWYgT1IgUm9vdCBzaXRlKHMpIHBlciBB QyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICAyLjMgU2NlbmFyaW8gMzogTGVhZiBPUiBS b290IHNpdGUocykgcGVyIE1BQyAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAzIE9wZXJhdGlv biBmb3IgRVZQTiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDcNCiAgICAgMy4xIEtub3duIFVuaWNhc3QgVHJhZmZpYyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgICAzLjIgQlVNIFRyYWZmaWMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAgMy4yLjEgQlVNIHRy YWZmaWMgb3JpZ2luYXRlZCBmcm9tIGEgc2luZ2xlLWhvbWVkIHNpdGUgb24gYQ0KICAgICAgICAg ICAgIGxlYWYgQUMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDEwDQogICAgICAgMy4yLjIgQlVNIHRyYWZmaWMgb3JpZ2luYXRlZCBmcm9tIGEgc2luZ2xl LWhvbWVkIHNpdGUgb24gYQ0KICAgICAgICAgICAgIHJvb3QgQUMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgICAgMy4yLjMgQlVNIHRyYWZm aWMgb3JpZ2luYXRlZCBmcm9tIGEgbXVsdGktaG9tZWQgc2l0ZSBvbiBhIA0KICAgICAgICAgICAg IGxlYWYgQUMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwDQogICAgICAgMy4yLjQgQlVNIHRyYWZmaWMgb3JpZ2luYXRlZCBmcm9tIGEgbXVsdGktaG9t ZWQgc2l0ZSBvbiBhIA0KICAgICAgICAgICAgIHJvb3QgQUMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgIDMuMyBFLVRSRUUgVHJhZmZpYyBG bG93cyBmb3IgRVZQTiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgICAgICAz LjMuMSBFLVRyZWUgd2l0aCBNQUMgTGVhcm5pbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMQ0KICAgICAgIDMuMy4yIEUtVHJlZSB3aXRob3V0IE1BQyBMZWFybmluZyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICA0IE9wZXJhdGlvbiBmb3IgUEJCLUVWUE4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgICAgNC4xIEtub3du IFVuaWNhc3QgVHJhZmZpYyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx Mw0KICAgICA0LjIgQlVNIFRyYWZmaWMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDEzDQogDQoNCg0KU2FqYXNzaSBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJTlRFUk5FVCBE UkFGVCAgICAgRS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBCQi1FVlBOICAgRGVjZW1iZXIgMjAs IDIwMTYNCg0KDQogICAgIDQuMyBFLVRyZWUgd2l0aG91dCBNQUMgTGVhcm5pbmcgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgIDUgQkdQIEVuY29kaW5nIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgICA1LjEgRS1U UkVFIEV4dGVuZGVkIENvbW11bml0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE0DQogICAgIDUuMiBQTVNJIFR1bm5lbCBBdHRyaWJ1dGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTUNCiAgIDYgIEFja25vd2xlZGdlbWVudCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgNyAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2DQog ICA4ICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTYNCiAgICAgOC4xIENvbnNpZGVyYXRpb25zIGZvciBQTVNJIFR1bm5lbCBU eXBlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgOSAgUmVmZXJlbmNlcyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgIDku MSAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTcNCiAgICAgOS4yICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNw0KICAgQ29udHJpYnV0b3JzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTgNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQogDQoNCg0KU2FqYXNzaSBldCBhbC4gICAgICAgICAgICBFeHBpcmVz IE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJTlRFUk5FVCBEUkFG VCAgICAgRS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBCQi1FVlBOICAgRGVjZW1iZXIgMjAsIDIw MTYNCg0KDQoxICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIE1ldHJvIEV0aGVybmV0IEZvcnVtIChN RUYpIGhhcyBkZWZpbmVkIGEgcm9vdGVkLW11bHRpcG9pbnQNCiAgIEV0aGVybmV0IHNlcnZpY2Ug a25vd24gYXMgRXRoZXJuZXQgVHJlZSAoRS1UcmVlKS4gSW4gYW4gRS1UcmVlDQogICBzZXJ2aWNl LCBlbmRwb2ludHMgYXJlIGxhYmVsZWQgYXMgZWl0aGVyIFJvb3Qgb3IgTGVhZiBzaXRlcy4gUm9v dA0KICAgc2l0ZXMgY2FuIGNvbW11bmljYXRlIHdpdGggYWxsIG90aGVyIHNpdGVzLiBMZWFmIHNp dGVzIGNhbg0KICAgY29tbXVuaWNhdGUgd2l0aCBSb290IHNpdGVzIGJ1dCBub3Qgd2l0aCBvdGhl ciBMZWFmIHNpdGVzLiANCg0KICAgW1JGQzczODddIHByb3Bvc2VzIHRoZSBzb2x1dGlvbiBmcmFt ZXdvcmsgZm9yIHN1cHBvcnRpbmcgRS1UcmVlDQogICBzZXJ2aWNlIGluIE1QTFMgbmV0d29ya3Mu IFRoZSBkb2N1bWVudCBpZGVudGlmaWVzIHRoZSBmdW5jdGlvbmFsDQogICBjb21wb25lbnRzIG9m IHRoZSBvdmVyYWxsIHNvbHV0aW9uIHRvIGVtdWxhdGUgRS1UcmVlIHNlcnZpY2VzIGluDQogICBh ZGRpdGlvbiB0byBFdGhlcm5ldCBMQU4gKEUtTEFOKSBzZXJ2aWNlcyBvbiBhbiBleGlzdGluZyBN UExTDQogICBuZXR3b3JrLg0KDQogICBbUkZDNzQzMl0gaXMgYSBzb2x1dGlvbiBmb3IgbXVsdGlw b2ludCBMMlZQTiBzZXJ2aWNlcywgd2l0aCBhZHZhbmNlZA0KICAgbXVsdGktaG9taW5nIGNhcGFi aWxpdGllcywgdXNpbmcgQkdQIGZvciBkaXN0cmlidXRpbmcgY3VzdG9tZXIvY2xpZW50DQogICBN QUMgYWRkcmVzcyByZWFjaC1hYmlsaXR5IGluZm9ybWF0aW9uIG92ZXIgdGhlIE1QTFMvSVAgbmV0 d29yay4NCiAgIFtSRkM3NjIzXSBjb21iaW5lcyB0aGUgZnVuY3Rpb25hbGl0eSBvZiBFVlBOIHdp dGggWzgwMi4xYWhdIFByb3ZpZGVyDQogICBCYWNrYm9uZSBCcmlkZ2luZyBmb3IgTUFDIGFkZHJl c3Mgc2NhbGFiaWxpdHkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIGhvdyB0aGUgZnVu Y3Rpb25hbCByZXF1aXJlbWVudHMgZm9yIEUtVHJlZQ0KICAgc2VydmljZSBjYW4gYmUgZWFzaWx5 IG1ldCB3aXRoIChQQkItKUVWUE4gYW5kIGhvdyAoUEJCLSlFVlBOIG9mZmVycyBhDQogICBtb3Jl IGVmZmljaWVudCBpbXBsZW1lbnRhdGlvbiBvZiB0aGVzZSBmdW5jdGlvbnMuIA0KDQoxLjEgIFRl cm1pbm9sb2d5DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJS RUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBh cmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtLRVlXT1JEU10u DQoNCg0KMiAgRS1UcmVlIFNjZW5hcmlvcyBhbmQgRVZQTiAvIFBCQi1FVlBOIFN1cHBvcnQNCg0K ICAgSW4gdGhpcyBzZWN0aW9uLCB3ZSB3aWxsIGNhdGVnb3JpemUgc3VwcG9ydCBmb3IgRS1UcmVl IGludG8gdGhyZWUNCiAgIGRpZmZlcmVudCBzY2VuYXJpb3MsIGRlcGVuZGluZyBvbiB0aGUgbmF0 dXJlIG9mIHRoZSBzaXRlIGFzc29jaWF0aW9uDQogICAoUm9vdC9MZWFmKSBwZXIgUEUgb3IgcGVy IEV0aGVybmV0IFNlZ21lbnQ6DQoNCiAgIC0gTGVhZiBPUiBSb290IHNpdGUocykgcGVyIFBFDQoN CiAgIC0gTGVhZiBPUiBSb290IHNpdGUocykgcGVyIEFDDQoNCiAgIC0gTGVhZiBPUiBSb290IHNp dGUocykgcGVyIE1BQw0KDQoNCjIuMSBTY2VuYXJpbyAxOiBMZWFmIE9SIFJvb3Qgc2l0ZShzKSBw ZXIgUEUNCg0KICAgSW4gdGhpcyBzY2VuYXJpbywgYSBQRSBtYXkgcmVjZWl2ZSB0cmFmZmljIGZy b20gZWl0aGVyIFJvb3Qgc2l0ZXMgT1INCiAgIExlYWYgc2l0ZXMgZm9yIGEgZ2l2ZW4gTUFDLVZS Ri9icmlkZ2UgdGFibGUsIGJ1dCBub3QgYm90aA0KIA0KDQoNClNhamFzc2kgZXQgYWwuICAgICAg ICAgICAgRXhwaXJlcyBNYXkgMjAsIDIwMTcgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0K SU5URVJORVQgRFJBRlQgICAgIEUtVFJFRSBTdXBwb3J0IGluIEVWUE4gJiBQQkItRVZQTiAgIERl Y2VtYmVyIDIwLCAyMDE2DQoNCg0KICAgY29uY3VycmVudGx5LiBJbiBvdGhlciB3b3JkcywgYSBn aXZlbiBFVkkgb24gYSBQRSBpcyBlaXRoZXINCiAgIGFzc29jaWF0ZWQgd2l0aCByb290KHMpIG9y IGxlYWYocykuIFRoZSBQRSBtYXkgaGF2ZSBib3RoIFJvb3QgYW5kDQogICBMZWFmIHNpdGVzIGFs YmVpdCBmb3IgZGlmZmVyZW50IEVWSXMuICANCg0KICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0rICAgICAgICAgICAgKy0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICB8ICAgUEUxICAg fCAgICAgICAgICAgIHwgICBQRTIgICB8DQogICAgKy0tLSsgICAgICAgICAgfCAgKy0tLSsgIHwg ICstLS0tLS0rICB8ICArLS0tKyAgfCAgICAgICAgICAgICstLS0rDQogICAgfENFMSstLS1FUzEt LS0tKy0tKyAgIHwgIHwgIHwgTVBMUyB8ICB8ICB8ICAgKy0tKy0tLS1FUzItLS0tLStDRTJ8DQog ICAgKy0tLSsgIChSb290KSAgfCAgfE1BQ3wgIHwgIHwgIC9JUCB8ICB8ICB8TUFDfCAgfCAgIChM ZWFmKSAgICstLS0rDQogICAgICAgICAgICAgICAgICAgfCAgfFZSRnwgIHwgIHwgICAgICB8ICB8 ICB8VlJGfCAgfA0KICAgICAgICAgICAgICAgICAgIHwgIHwgICB8ICB8ICB8ICAgICAgfCAgfCAg fCAgIHwgIHwgICAgICAgICAgICArLS0tKw0KICAgICAgICAgICAgICAgICAgIHwgIHwgICB8ICB8 ICB8ICAgICAgfCAgfCAgfCAgICstLSstLS0tRVMzLS0tLS0rQ0UzfA0KICAgICAgICAgICAgICAg ICAgIHwgICstLS0rICB8ICArLS0tLS0tKyAgfCAgKy0tLSsgIHwgICAoTGVhZikgICArLS0tKw0K ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLSsNCg0K ICAgRmlndXJlIDE6IFNjZW5hcmlvIDENCg0KICAgSW4gc3VjaCBzY2VuYXJpbywgdXNpbmcgdGFp bG9yZWQgQkdQIFJvdXRlIFRhcmdldCAoUlQpIGltcG9ydC9leHBvcnQNCiAgIHBvbGljaWVzIGFt b25nIHRoZSBQRXMgYmVsb25naW5nIHRvIHRoZSBzYW1lIEVWSSwgY2FuIGJlIHVzZWQgdG8NCiAg IHJlc3RyaWN0IHRoZSBjb21tdW5pY2F0aW9ucyBhbW9uZyBMZWFmIFBFcy4gVG8gcmVzdHJpY3Qg dGhlDQogICBjb21tdW5pY2F0aW9ucyBhbW9uZyBMZWFmIHNpdGVzIGNvbm5lY3RlZCB0byB0aGUg c2FtZSBQRSBhbmQNCiAgIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBFVkksIHNwbGl0LWhvcml6b24g ZmlsdGVyaW5nIGlzIHVzZWQgdG8gYmxvY2sNCiAgIHRyYWZmaWMgZnJvbSBvbmUgTGVhZiBpbnRl cmZhY2UgdG8gYW5vdGhlciBMZWFmIGludGVyZmFjZSBvZiBhIGdpdmVuDQogICBFLVRSRUUgRVZJ LiBUaGUgcHVycG9zZSBvZiB0aGlzIHRvcG9sb2d5IGNvbnN0cmFpbnQgaXMgdG8gYXZvaWQNCiAg IGhhdmluZyBQRXMgd2l0aCBvbmx5ICBMZWFmIHNpdGVzIGltcG9ydGluZyBhbmQgcHJvY2Vzc2lu ZyBCR1AgTUFDDQogICByb3V0ZXMgZnJvbSBlYWNoIG90aGVyLiBUbyBzdXBwb3J0IHN1Y2ggdG9w b2xvZ3kgY29uc3RyYWluIGluIEVWUE4sDQogICB0d28gQkdQIFJvdXRlLVRhcmdldHMgKFJUcykg YXJlIHVzZWQgZm9yIGV2ZXJ5IEVWUE4gSW5zdGFuY2UgKEVWSSk6DQogICBvbmUgUlQgaXMgYXNz b2NpYXRlZCB3aXRoIHRoZSBSb290IHNpdGVzIGFuZCB0aGUgb3RoZXIgaXMgYXNzb2NpYXRlZA0K ICAgd2l0aCB0aGUgTGVhZiBzaXRlcy4gT24gYSBwZXIgRVZJIGJhc2lzLCBldmVyeSBQRSBleHBv cnRzIHRoZSBzaW5nbGUNCiAgIFJUIGFzc29jaWF0ZWQgd2l0aCBpdHMgdHlwZSBvZiBzaXRlKHMp LiBGdXJ0aGVybW9yZSwgYSBQRSB3aXRoIFJvb3QNCiAgIHNpdGUocykgaW1wb3J0cyBib3RoIFJv b3QgYW5kIExlYWYgUlRzLCB3aGVyZWFzIGEgUEUgd2l0aCBMZWFmDQogICBzaXRlKHMpIG9ubHkg aW1wb3J0cyB0aGUgUm9vdCBSVC4NCg0KDQoyLjIgU2NlbmFyaW8gMjogTGVhZiBPUiBSb290IHNp dGUocykgcGVyIEFDDQoNCiAgIEluIHRoaXMgc2NlbmFyaW8sIGEgUEUgcmVjZWl2ZXMgdHJhZmZp YyBmcm9tIGVpdGhlciBSb290IE9SIExlYWYNCiAgIHNpdGVzIChidXQgbm90IGJvdGgpIG9uIGEg Z2l2ZW4gQXR0YWNobWVudCBDaXJjdWl0IChBQykgb2YgYW4gRVZJLiBJbg0KICAgb3RoZXIgd29y ZHMsIGFuIEFDIChFUyBvciBFUy9WTEFOKSBpcyBlaXRoZXIgYSBSb290IEFDIG9yIGEgTGVhZiBB Qw0KICAgKGJ1dCBub3QgYm90aCkuIA0KDQoNCg0KDQoNCg0KDQoNCiANCg0KDQpTYWphc3NpIGV0 IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAgICAgICAgICAgICAgW1Bh Z2UgNV0NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBOICYgUEJC LUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgIHwgICBQ RTEgICB8ICAgICAgICAgICAgfCAgIFBFMiAgIHwNCiAgICArLS0tKyAgICAgICAgICAgIHwgICst LS0rICB8ICArLS0tLS0tKyAgfCAgKy0tLSsgIHwgICAgICAgICAgICArLS0tKw0KICAgIHxDRTEr LS0tLS1FUzEtLS0tKy0tKyAgIHwgIHwgIHwgICAgICB8ICB8ICB8ICAgKy0tKy0tLUVTMi9BQzEt LStDRTJ8DQogICAgKy0tLSsgICAgKExlYWYpICB8ICB8TUFDfCAgfCAgfCBNUExTIHwgIHwgIHxN QUN8ICB8ICAgKExlYWYpICAgKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgIHwgIHxWUkZ8ICB8 ICB8ICAvSVAgfCAgfCAgfFZSRnwgIHwNCiAgICAgICAgICAgICAgICAgICAgIHwgIHwgICB8ICB8 ICB8ICAgICAgfCAgfCAgfCAgIHwgIHwgICAgICAgICAgICArLS0tKw0KICAgICAgICAgICAgICAg ICAgICAgfCAgfCAgIHwgIHwgIHwgICAgICB8ICB8ICB8ICAgKy0tKy0tLUVTMi9BQzItLStDRTN8 DQogICAgICAgICAgICAgICAgICAgICB8ICArLS0tKyAgfCAgKy0tLS0tLSsgIHwgICstLS0rICB8 ICAgKFJvb3QpICAgKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAg ICAgICAgKy0tLS0tLS0tLSsNCg0KICAgRmlndXJlIDI6IFNjZW5hcmlvIDINCg0KICAgSW4gdGhp cyBzY2VuYXJpbywganVzdCBsaWtlIHRoZSBwcmV2aW91cyBzY2VuYXJpbyAoaW4gc2VjdGlvbiAy LjEpLA0KICAgdHdvIFJvdXRlIFRhcmdldHMgKG9uZSBmb3IgUm9vdCBhbmQgYW5vdGhlciBmb3Ig TGVhZikgY2FuIGJlIHVzZWQuDQogICBIb3dldmVyLCB0aGUgZGlmZmVyZW5jZSBpcyB0aGF0IG9u IGEgUEUgd2l0aCBib3RoIFJvb3QgYW5kIExlYWYgQUNzLA0KICAgYWxsIHJlbW90ZSBNQUMgcm91 dGVzIGFyZSBpbXBvcnRlZCBhbmQgdGh1cyB0aGVyZSBuZWVkcyB0byBiZSBhIHdheQ0KICAgdG8g ZGlmZmVyZW50aWF0ZSByZW1vdGUgTUFDIHJvdXRlcyBhc3NvY2lhdGVkIHdpdGggTGVhZiBBQ3Mg dmVyc3VzDQogICB0aGUgb25lcyBhc3NvY2lhdGVkIHdpdGggUm9vdCBBQ3MgaW4gb3JkZXIgdG8g YXBwbHkgdGhlIHByb3Blcg0KICAgaW5ncmVzcyBmaWx0ZXJpbmcuIA0KDQogICBJbiBvcmRlciB0 byBzdXBwb3J0IHN1Y2ggaW5ncmVzcyBmaWx0ZXJpbmcgb24gdGhlIGluZ3Jlc3MgUEUgd2l0aA0K ICAgYm90aCBMZWFmIGFuZCBSb290IEFDcywgb25lIHRoZSBmb2xsb3dpbmcgdHdvIGFwcHJvYWNo ZXMgY2FuIGJlIHVzZWQ6DQoNCiAgIEEpIFRvIHVzZSB0d28gTUFDLVZSRnMgKHR3byBicmlkZ2Ug dGFibGVzIHBlciBWTEFOcyBpZiBhIGdpdmVuIFZMQU4NCiAgIGV4aXN0cyBvbiB0aGUgUEUgZm9y IGJvdGggTGVhZiBhbmQgUm9vdCBBQ3Mgb2YgYW4gRVZJKSAtIG9uZSBmb3IgUm9vdA0KICAgQUNz IGFuZCBhbm90aGVyIGZvciBMZWFmIEFDcy4NCg0KICAgQikgVG8gY29sb3IgTUFDIGFkZHJlc3Nl cyB3aXRoIExlYWYgb3IgUm9vdCBjb2xvciBiZWZvcmUgZGlzdHJpYnV0aW5nDQogICB0aGVtIGlu IEJHUCB0byBvdGhlciBQRXMgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhleSBhcmUgbGVhcm5lZCBv biBhDQogICBMZWFmIEFDIG9yIGEgUm9vdCBBQy4gDQoNCiAgIE1haW50YWluaW5nIHR3byBicmlk Z2UgdGFibGVzIHBlciBWTEFOICh3aGVuIGJvdGggTGVhZiBhbmQgUm9vdCBBQ3MNCiAgIGV4aXN0 cyBmb3IgdGhhdCBWTEFOKSByZXF1aXJlcyBlaXRoZXIgdHdvIGxvb2t1cHMgYmUgcGVyZm9ybWVk IHBlcg0KICAgTUFDIGFkZHJlc3MgaW4gZWl0aGVyIGRpcmVjdGlvbiBpbiBjYXNlIG9mIGEgbWlz cywgb3IgZHVwbGljYXRpbmcNCiAgIG1hbnkgTUFDIGFkZHJlc3NlcyBiZXR3ZWVuIHRoZSB0d28g YnJpZGdlIHRhYmxlcyBiZWxvbmdpbmcgdG8gdGhlDQogICBzYW1lIFZMQU4gKHNhbWUgRS1UUkVF IGluc3RhbmNlKS4gVW5sZXNzIHR3byBsb29rdXBzIGFyZSBtYWRlLA0KICAgZHVwbGljYXRpb24g b2YgTUFDIGFkZHJlc3NlcyB3b3VsZCBiZSBuZWVkZWQgZm9yIGJvdGggbG9jYWxseSBsZWFybmVk DQogICBhbmQgcmVtb3RlbHkgbGVhcm5lZCBNQUMgYWRkcmVzc2VzLiBMb2NhbGx5IGxlYXJuZWQg TUFDIGFkZHJlc3Nlcw0KICAgZnJvbSBMZWFmIEFDcyBuZWVkIHRvIGJlIGR1cGxpY2F0ZWQgb250 byBSb290IGJyaWRnZSB0YWJsZSBhbmQNCiAgIGxvY2FsbHkgbGVhcm5lZCBNQUMgYWRkcmVzc2Vz IGZyb20gUm9vdCBBQ3MgbmVlZCB0byBiZSBkdXBsaWNhdGVkDQogICBvbnRvIExlYWYgYnJpZGdl IHRhYmxlLiBSZW1vdGVseSBsZWFybmVkIE1BQyBhZGRyZXNzZXMgZnJvbSBSb290IEFDcw0KICAg bmVlZCB0byBiZSBjb3BpZWQgb250byBib3RoIFJvb3QgYW5kIExlYWYgYnJpZGdlIHRhYmxlcy4g SW4gb3JkZXIgdG8NCiAgIGF2b2lkIHR3byBNQUMtVlJGcywgdGhpcyBkcmFmdCBpbnRyb2R1Y2Vz IHRoZSBjb2xvcmluZyBvcHRpb24gKEIpIGFzDQogICBkZXRhaWxlZCBpbiBzZWN0aW9uIDMuMS4g IA0KDQogICBGb3IgdGhpcyBzY2VuYXJpbywgaWYgZm9yIGEgZ2l2ZW4gRVZJLCB0aGUgdmFzdCBt YWpvcml0eSBvZiBQRXMgd2lsbA0KICAgaGF2ZSBib3RoIExlYWYgYW5kIFJvb3Qgc2l0ZXMgYXR0 YWNoZWQsIGV2ZW4gdGhvdWdoIHRoZXkgbWF5IHN0YXJ0IGFzDQogDQoNCg0KU2FqYXNzaSBldCBh bC4gICAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgIFtQYWdl IDZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgRS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBCQi1F VlBOICAgRGVjZW1iZXIgMjAsIDIwMTYNCg0KDQogICBSb290LW9ubHkgb3IgTGVhZi1vbmx5IFBF cywgdGhlbiBhIHNpbmdsZSBSVCBwZXIgRVZJIE1BWSBiZSB1c2VkIGluDQogICBvcmRlciB0byBh bGxldmlhdGUgdGhlIGNvbmZpZ3VyYXRpb24gb3ZlcmhlYWQgYXNzb2NpYXRlZCB3aXRoIHVzaW5n DQogICB0d28gUlRzIHBlciBFVkkgYXQgdGhlIGV4cGVuc2Ugb2YgaGF2aW5nIHVud2FudGVkIE1B QyBhZGRyZXNzZXMgb24NCiAgIHRoZSBMZWFmLW9ubHkgUEVzLiANCg0KDQoyLjMgU2NlbmFyaW8g MzogTGVhZiBPUiBSb290IHNpdGUocykgcGVyIE1BQw0KDQogICBJbiB0aGlzIHNjZW5hcmlvLCBh IFBFIG1heSByZWNlaXZlIHRyYWZmaWMgZnJvbSBib3RoIFJvb3QgQU5EIExlYWYNCiAgIHNpdGVz IG9uIGEgc2luZ2xlIEF0dGFjaG1lbnQgQ2lyY3VpdCAoQUMpIG9mIGFuIEVWSS4gU2luY2UgYW4N CiAgIEF0dGFjaG1lbnQgQ2lyY3VpdCAoRVMgb3IgRVMvVkxBTikgY2FycmllcyB0cmFmZmljIGZy b20gYm90aCBSb290IGFuZA0KICAgTGVhZiBzaXRlcywgdGhlIGdyYW51bGFyaXR5IGF0IHdoaWNo IFJvb3Qgb3IgTGVhZiBzaXRlcyBhcmUNCiAgIGlkZW50aWZpZWQgaXMgb24gYSBwZXIgTUFDIGFk ZHJlc3MuIFRoaXMgc2NlbmFyaW8gaXMgY29uc2lkZXJlZCBpbg0KICAgdGhpcyBkcmFmdCBmb3Ig RVZQTiBzZXJ2aWNlIHdpdGggb25seSBrbm93biB1bmljYXN0IHRyYWZmaWMgYmVjYXVzZQ0KICAg dGhlIERGIGZpbHRlcmluZyBwZXIgW1JGQzc0MzJdIHdvdWxkIG5vdCBiZSBjb21wYXRpYmxlIHdp dGggdGhlDQogICByZXF1aXJlZCBlZ3Jlc3MgZmlsdGVyaW5nIC0gaS5lLiwgQlVNIHRyYWZmaWMg aXMgbm90IHN1cHBvcnRlZCBpbg0KICAgdGhpcyBzY2VuYXJpbyBhbmQgaXQgaXMgZHJvcHBlZCBi eSB0aGUgaW5ncmVzcyBQRS4NCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0r ICAgICAgICAgICAgKy0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgIHwgICBQRTEgICB8 ICAgICAgICAgICAgfCAgIFBFMiAgIHwNCiAgICArLS0tKyAgICAgICAgICAgIHwgICstLS0rICB8 ICArLS0tLS0tKyAgfCAgKy0tLSsgIHwgICAgICAgICAgICArLS0tKw0KICAgIHxDRTErLS0tLS1F UzEtLS0tKy0tKyAgIHwgIHwgIHwgICAgICB8ICB8ICB8ICAgKy0tKy0tLUVTMi9BQzEtLStDRTJ8 DQogICAgKy0tLSsgICAgKFJvb3QpICB8ICB8IEUgfCAgfCAgfCBNUExTIHwgIHwgIHwgRSB8ICB8 IChMZWFmL1Jvb3QpKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgIHwgIHwgViB8ICB8ICB8ICAv SVAgfCAgfCAgfCBWIHwgIHwNCiAgICAgICAgICAgICAgICAgICAgIHwgIHwgSSB8ICB8ICB8ICAg ICAgfCAgfCAgfCBJIHwgIHwgICAgICAgICAgICArLS0tKw0KICAgICAgICAgICAgICAgICAgICAg fCAgfCAgIHwgIHwgIHwgICAgICB8ICB8ICB8ICAgKy0tKy0tLUVTMi9BQzItLStDRTN8DQogICAg ICAgICAgICAgICAgICAgICB8ICArLS0tKyAgfCAgKy0tLS0tLSsgIHwgICstLS0rICB8ICAgKExl YWYpICAgKy0tLSsNCiAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAg Ky0tLS0tLS0tLSsNCg0KICAgRmlndXJlIDM6IFNjZW5hcmlvIDMNCg0KDQozIE9wZXJhdGlvbiBm b3IgRVZQTg0KDQogICBbUkZDNzQzMl0gZGVmaW5lcyB0aGUgbm90aW9uIG9mIEVTSSBNUExTIGxh YmVsIHVzZWQgZm9yIHNwbGl0LWhvcml6b24NCiAgIGZpbHRlcmluZyBvZiBCVU0gdHJhZmZpYyBh dCB0aGUgZWdyZXNzIFBFLiBTdWNoIGVncmVzcyBmaWx0ZXJpbmcNCiAgIGNhcGFiaWxpdGllcyBj YW4gYmUgbGV2ZXJhZ2VkIGluIHByb3Zpc2lvbiBvZiBFLVRSRUUgc2VydmljZXMgYXMgc2Vlbg0K ICAgc2hvcnRseS4gSW4gb3RoZXIgd29yZHMsIFtSRkM3NDMyXSBoYXMgaW5oZXJlbnQgY2FwYWJp bGl0eSB0byBzdXBwb3J0DQogICBFLVRSRUUgc2VydmljZXMgd2l0aG91dCBkZWZpbmluZyBhbnkg bmV3IEJHUCByb3V0ZXMgYnV0IGJ5IGp1c3QNCiAgIGRlZmluaW5nIGEgbmV3IEJHUCBFeHRlbmRl ZCBDb21tdW5pdHkgZm9yIGxlYWYgaW5kaWNhdGlvbiBhcyBzaG93bg0KICAgbGF0ZXIgaW4gdGhp cyBkb2N1bWVudC4NCg0KDQozLjEgS25vd24gVW5pY2FzdCBUcmFmZmljDQoNCiAgIFNpbmNlIGlu IEVWUE4sIE1BQyBsZWFybmluZyBpcyBwZXJmb3JtZWQgaW4gY29udHJvbCBwbGFuZSB2aWENCiAN Cg0KDQpTYWphc3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAg ICAgICAgICAgICAgW1BhZ2UgN10NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9y dCBpbiBFVlBOICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIGFkdmVydGlz ZW1lbnQgb2YgQkdQIHJvdXRlcywgdGhlIGZpbHRlcmluZyBuZWVkZWQgYnkgRS1UUkVFIHNlcnZp Y2UNCiAgIGZvciBrbm93biB1bmljYXN0IHRyYWZmaWMgY2FuIGJlIHBlcmZvcm1lZCBhdCB0aGUg aW5ncmVzcyBQRSwgdGh1cw0KICAgcHJvdmlkaW5nIHZlcnkgZWZmaWNpZW50IGZpbHRlcmluZyBh bmQgYXZvaWRpbmcgc2VuZGluZyBrbm93biB1bmljYXN0DQogICB0cmFmZmljIG92ZXIgTVBMUy9J UCBjb3JlIHRvIGJlIGZpbHRlcmVkIGF0IHRoZSBlZ3Jlc3MgUEUgYXMgZG9uZSBpbg0KICAgdHJh ZGl0aW9uYWwgRS1UUkVFIHNvbHV0aW9ucyAoZS5nLiwgRS1UUkVFIGZvciBWUExTKS4gDQoNCiAg IFRvIHByb3ZpZGUgc3VjaCBpbmdyZXNzIGZpbHRlcmluZyBmb3Iga25vd24gdW5pY2FzdCB0cmFm ZmljLCBhIFBFDQogICBNVVNUIGluZGljYXRlIHRvIG90aGVyIFBFcyB3aGF0IGtpbmQgb2Ygc2l0 ZXMgKHJvb3Qgb3IgbGVhZikgaXRzIE1BQw0KICAgYWRkcmVzc2VzIGFyZSBhc3NvY2lhdGVkIHdp dGggYnkgYWR2ZXJ0aXNpbmcgYSBsZWFmIGluZGljYXRpb24gZmxhZw0KICAgKHZpYSBhbiBFeHRl bmRlZCBDb21tdW5pdHkpIGFsb25nIHdpdGggZWFjaCBvZiBpdHMgTUFDL0lQDQogICBBZHZlcnRp c2VtZW50IHJvdXRlLiBUaGUgbGFjayBvZiBzdWNoIGZsYWcgaW5kaWNhdGVzIHRoYXQgdGhlIE1B Qw0KICAgYWRkcmVzcyBpcyBhc3NvY2lhdGVkIHdpdGggYSByb290IHNpdGUuIFRoaXMgc2NoZW1l IGFwcGxpZXMgdG8gYWxsDQogICBzY2VuYXJpb3MgZGVzY3JpYmVkIGluIHNlY3Rpb24gMi4gDQoN CiAgIEZ1cnRoZXJtb3JlLCBmb3IgbXVsdGktaG9taW5nIHNjZW5hcmlvIG9mIHNlY3Rpb24gMi4y LCB3aGVyZSBhbiBBQyBpcw0KICAgZWl0aGVyIHJvb3Qgb3IgbGVhZiAoYnV0IG5vdCBib3RoKSwg dGhlIFBFIE1BWSBhZHZlcnRpc2UgbGVhZg0KICAgaW5kaWNhdGlvbiBhbG9uZyB3aXRoIHRoZSBF dGhlcm5ldCBBLUQgcGVyIEVWSSByb3V0ZS4gVGhpcw0KICAgYWR2ZXJ0aXNlbWVudCBpcyB1c2Vk IGZvciBzYW5pdHkgY2hlY2tpbmcgaW4gY29udHJvbC1wbGFuZSB0byBlbnN1cmUNCiAgIHRoYXQg dGhlcmUgaXMgbm8gZGlzY3JlcGFuY3kgaW4gY29uZmlndXJhdGlvbiBhbW9uZyBkaWZmZXJlbnQg UEVzIG9mDQogICB0aGUgc2FtZSByZWR1bmRhbmN5IGdyb3VwLiBGb3IgZXhhbXBsZSwgaWYgYSBs ZWFmIHNpdGUgaXMgbXVsdGktaG9tZWQNCiAgIHRvIFBFMSBhbiBQRTIsIGFuZCBQRTEgYWR2ZXJ0 aXNlcyB0aGUgRXRoZXJuZXQgQS1EIHBlciBFVkkNCiAgIGNvcnJlc3BvbmRpbmcgdG8gdGhpcyBs ZWFmIHNpdGUgd2l0aCB0aGUgbGVhZi1pbmRpY2F0aW9uIGZsYWcgYnV0IFBFMg0KICAgZG9lcyBu b3QsIHRoZW4gdGhlIHJlY2VpdmluZyBQRSBub3RpZmllcyB0aGUgb3BlcmF0b3Igb2Ygc3VjaA0K ICAgZGlzY3JlcGFuY3kgYW5kIGlnbm9yZSB0aGUgbGVhZi1pbmRpY2F0aW9uIGZsYWcgb24gUEUx LiBJbiBvdGhlcg0KICAgd29yZHMsIGluIGNhc2Ugb2YgZGlzY3JlcGFuY3ksIHRoZSBtdWx0aS1o b21pbmcgZm9yIHRoYXQgcGFpciBvZiBQRXMNCiAgIGlzIGFzc3VtZWQgdG8gYmUgaW4gZGVmYXVs dCAicm9vdCIgbW9kZSBmb3IgdGhhdCA8RVNJLCBFVkk+IG9yIDxFU0ksDQogICBFVkkvVkxBTj4u IFRoZSBsZWFmIGluZGljYXRpb24gZmxhZyBvbiBFdGhlcm5ldCBBLUQgcGVyIEVWSSByb3V0ZQ0K ICAgdGVsbHMgdGhlIHJlY2VpdmluZyBQRXMgdGhhdCBhbGwgTUFDIGFkZHJlc3NlcyBhc3NvY2lh dGVkIHdpdGggdGhpcw0KICAgPEVTSSwgRVZJPiBvciA8RVNJLCBFVkkvVkxBTj4gYXJlIGZyb20g YSBsZWFmIHNpdGUuIFRoZXJlZm9yZSwgaWYgYQ0KICAgUEUgcmVjZWl2ZXMgYSBsZWFmIGluZGlj YXRpb24gZm9yIGFuIEFDIHZpYSB0aGUgRXRoZXJuZXQgQS1EIHBlciBFVkkNCiAgIHJvdXRlIGJ1 dCBkb2Vzbid0IHJlY2VpdmUgYSBsZWFmIGluZGljYXRpb24gaW4gdGhlIGNvcnJlc3BvbmRpbmcN CiAgIE1BQy9JUCBBZHZlcnRpc2VtZW50IHJvdXRlLCB0aGVuIGl0IG5vdGlmaWVzIHRoZSBvcGVy YXRvciBhbmQgaWdub3JlDQogICB0aGUgbGVhZiBpbmRpY2F0aW9uIG9uIHRoZSBFdGhlcm5ldCBB LUQgcGVyIEVWSSByb3V0ZS4gIA0KDQogICBUYWdnaW5nIE1BQyBhZGRyZXNzZXMgd2l0aCBhIGxl YWYgaW5kaWNhdGlvbiBlbmFibGVzIHJlbW90ZSBQRXMgdG8NCiAgIHBlcmZvcm0gaW5ncmVzcyBm aWx0ZXJpbmcgZm9yIGtub3duIHVuaWNhc3QgdHJhZmZpYyAtIGkuZS4sIG9uIHRoZQ0KICAgaW5n cmVzcyBQRSwgdGhlIE1BQyBkZXN0aW5hdGlvbiBhZGRyZXNzIGxvb2t1cCB5aWVsZHMsIGluIGFk ZGl0aW9uIHRvDQogICB0aGUgZm9yd2FyZGluZyBhZGphY2VuY3ksIGEgZmxhZyB3aGljaCBpbmRp Y2F0ZXMgd2hldGhlciB0aGUgdGFyZ2V0DQogICBNQUMgaXMgYXNzb2NpYXRlZCB3aXRoIGEgTGVh ZiBzaXRlIG9yIG5vdC4gVGhlIGluZ3Jlc3MgUEUgY3Jvc3MtDQogICBjaGVja3MgdGhpcyBmbGFn IHdpdGggdGhlIHN0YXR1cyBvZiB0aGUgb3JpZ2luYXRpbmcgQUMsIGFuZCBpZiBib3RoDQogICBh cmUgTGVhZnMsIHRoZW4gdGhlIHBhY2tldCBpcyBub3QgZm9yd2FyZGVkLg0KDQogICBJbiBzaXR1 YXRpb24gd2hlcmUgTUFDIG1vdmVzIGFyZSBhbGxvd2VkIGFtb25nIExlYWYgYW5kIFJvb3Qgc2l0 ZXMNCiAgIChlLmcuLCBub24tc3RhdGljIE1BQyksIFBFcyBjYW4gcmVjZWl2ZSBtdWx0aXBsZSBN QUMvSVANCiAgIGFkdmVydGlzZW1lbnRzIHJvdXRlcyBmb3IgdGhlIHNhbWUgTUFDIGFkZHJlc3Mg d2l0aCBkaWZmZXJlbnQNCiAgIExlYWYvUm9vdCBpbmRpY2F0aW9ucyAoYW5kIHBvc3NpYmx5IGRp ZmZlcmVudCBFU0lzIGZvciBtdWx0aS1ob21pbmcNCiAgIHNjZW5hcmlvcykuIEluIHN1Y2ggc2l0 dWF0aW9ucywgTUFDIG1vYmlsaXR5IHByb2NlZHVyZXMgdGFrZQ0KICAgcHJlY2VkZW5jZSB0byBm aXJzdCBpZGVudGlmeSB0aGUgbG9jYXRpb24gb2YgdGhlIE1BQyBiZWZvcmUNCiANCg0KDQpTYWph c3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAgICAgICAgICAg ICAgW1BhZ2UgOF0NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBO ICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIGFzc29jaWF0aW5nIHRoYXQg TUFDIHdpdGggYSBSb290IG9yIGEgTGVhZiBzaXRlLiANCg0KICAgVG8gc3VwcG9ydCB0aGUgYWJv dmUgaW5ncmVzcyBmaWx0ZXJpbmcgZnVuY3Rpb25hbGl0eSwgYSBuZXcgRS1UUkVFDQogICBFeHRl bmRlZCBDb21tdW5pdHkgd2l0aCBhIExlYWYgaW5kaWNhdGlvbiBmbGFnIGlzIGludHJvZHVjZWQg W3NlY3Rpb24NCiAgIDUuMl0uIFRoaXMgbmV3IEV4dGVuZGVkIENvbW11bml0eSBNVVNUIGJlIGFk dmVydGlzZWQgd2l0aCBNQUMvSVANCiAgIEFkdmVydGlzZW1lbnQgcm91dGUgYW5kIE1BWSBiZSBh ZHZlcnRpc2VkIHdpdGggYW4gRXRoZXJuZXQgQS1EIHBlcg0KICAgRVZJIHJvdXRlIGFzIGRlc2Ny aWJlZCBhYm92ZS4gDQoNCjMuMiBCVU0gVHJhZmZpYw0KDQogICBUaGlzIHNwZWNpZmljYXRpb24g ZG9lcyBub3QgcHJvdmlkZSBzdXBwb3J0IGZvciBmaWx0ZXJpbmcgQlVNIHRyYWZmaWMNCiAgIG9u IHRoZSBpbmdyZXNzIFBFIGJlY2F1c2UgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHBlcmZvcm0gZmls dGVyaW5nIG9mDQogICBCVU0gdHJhZmZpYyBvbiB0aGUgaW5ncmVzcyBQRSwgYXMgaXMgdGhlIGNh c2Ugd2l0aCBrbm93biB1bmljYXN0DQogICBkZXNjcmliZWQgYWJvdmUsIGR1ZSB0byB0aGUgbXVs dGktZGVzdGluYXRpb24gbmF0dXJlIG9mIEJVTSB0cmFmZmljLg0KICAgQXMgc3VjaCwgdGhlIHNv bHV0aW9uIHJlbGllcyBvbiBlZ3Jlc3MgZmlsdGVyaW5nLiBJbiBvcmRlciB0byBhcHBseQ0KICAg dGhlIHByb3BlciBlZ3Jlc3MgZmlsdGVyaW5nLCB3aGljaCB2YXJpZXMgYmFzZWQgb24gd2hldGhl ciBhIHBhY2tldA0KICAgaXMgc2VudCBmcm9tIGEgTGVhZiBBQyBvciBhIHJvb3QgQUMsIHRoZSBN UExTLWVuY2Fwc3VsYXRlZCBmcmFtZXMNCiAgIE1VU1QgYmUgdGFnZ2VkIHdpdGggYW4gaW5kaWNh dGlvbiB3aGVuIHRoZXkgb3JpZ2luYXRlZCBmcm9tIGEgTGVhZg0KICAgQUMuIEluIG90aGVyIHdv cmRzLCBsZWFmIGluZGljYXRpb24gZm9yIEJVTSB0cmFmZmljIGlzIGRvbmUgYXQgdGhlDQogICBn cmFudWxhcml0eSBvZiBBQy4gVGhpcyBjYW4gYmUgYWNoaWV2ZWQgaW4gRVZQTiB0aHJvdWdoIHRo ZSB1c2Ugb2YgYQ0KICAgTVBMUyBsYWJlbCB3aGVyZSBpdCBjYW4gYmUgdXNlZCB0byBlaXRoZXIg aWRlbnRpZnkgdGhlIEV0aGVybmV0DQogICBzZWdtZW50IG9mIG9yaWdpbiBwZXIgW1JGQzc0MzJd IChpLmUuLCBFU0kgbGFiZWwpIG9yIGl0IGNhbiBiZSB1c2VkDQogICB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBwYWNrZXQgaXMgb3JpZ2luYXRlZCBmcm9tIGEgbGVhZiBzaXRlIChMZWFmDQogICBsYWJl bCkuDQoNCiAgIEJVTSB0cmFmZmljIHNlbnQgb3ZlciBhIFAyTVAgTFNQIG9yIGluZ3Jlc3MgcmVw bGljYXRpb24sIG1heSBuZWVkIHRvDQogICBjYXJyeSBhbiB1cHN0cmVhbSBhc3NpZ25lZCBvciBk b3duc3RyZWFtIGFzc2lnbmVkIE1QTFMgbGFiZWwNCiAgIChyZXNwZWN0aXZlbHkpIGZvciB0aGUg cHVycG9zZSBvZiBlZ3Jlc3MgZmlsdGVyaW5nIHRvIGluZGljYXRlIHRvIHRoZQ0KICAgZWdyZXNz IFBFcyB3aGV0aGVyIHRoaXMgcGFja2V0IGlzIG9yaWdpbmF0ZWQgZnJvbSBhIGxlYWYgQUMuDQoN CiAgIFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiBkb3duc3RyZWFtIGFuZCB1cHN0cmVhbSBh c3NpZ25lZCBNUExTDQogICBsYWJlbCBpcyB0aGF0IGluIGNhc2Ugb2YgZG93bnN0cmVhbSBhc3Np Z25lZCBub3QgYWxsIGVncmVzcyBQRQ0KICAgZGV2aWNlcyBuZWVkIHRvIHJlY2VpdmUgdGhlIGxh YmVsIGp1c3QgbGlrZSBpbmdyZXNzIHJlcGxpY2F0aW9uDQogICBwcm9jZWR1cmVzIGRlZmluZWQg aW4gW1JGQzc0MzJdLg0KDQogICBUaGUgUEUgcGxhY2VzIGFsbCBMZWFmIEV0aGVybmV0IFNlZ21l bnRzIG9mIGEgZ2l2ZW4gYnJpZGdlIGRvbWFpbiBpbg0KICAgYSBzaW5nbGUgc3BsaXQtaG9yaXpv biBncm91cCBpbiBvcmRlciB0byBwcmV2ZW50IGludHJhLVBFIGZvcndhcmRpbmcNCiAgIGFtb25n IExlYWYgc2VnbWVudHMuIFRoaXMgc3BsaXQtaG9yaXpvbiBmdW5jdGlvbiBhcHBsaWVzIHRvIEJV TQ0KICAgdHJhZmZpYyBhcyB3ZWxsIGFzIGtub3duLXVuaWNhc3QgdHJhZmZpYy4NCg0KICAgVGhl cmUgYXJlIGZvdXIgc2NlbmFyaW9zIHRvIGNvbnNpZGVyIGFzIGZvbGxvd3MuIEluIGFsbCB0aGVz ZQ0KICAgc2NlbmFyaW9zLCB0aGUgaW5ncmVzcyBQRSBpbXBvc2VzIHRoZSByaWdodCBNUExTIGxh YmVsIGFzc29jaWF0ZWQNCiAgIHdpdGggdGhlIG9yaWdpbmF0ZWQgRXRoZXJuZXQgU2VnbWVudCAo RVMpIGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZQ0KICAgRXRoZXJuZXQgZnJhbWUgb3JpZ2luYXRl ZCBmcm9tIGEgUm9vdCBvciBhIExlYWYgc2l0ZSBvbiB0aGF0IEV0aGVybmV0DQogICBTZWdtZW50 IChFU0kgbGFiZWwgb3IgTGVhZiBsYWJlbCkuIFRoZSBtZWNoYW5pc20gYnkgd2hpY2ggdGhlIFBF DQogICBpZGVudGlmaWVzIHdoZXRoZXIgYSBnaXZlbiBmcmFtZSBvcmlnaW5hdGVkIGZyb20gYSBS b290IG9yIGEgTGVhZg0KICAgc2l0ZSBvbiB0aGUgc2VnbWVudCBpcyBiYXNlZCBvbiB0aGUgQUMg aWRlbnRpZmllciBmb3IgdGhhdCBzZWdtZW50DQogICAoZS5nLiwgRXRoZXJuZXQgVGFnIG9mIHRo ZSBmcmFtZSBmb3IgODAyLjFRIGZyYW1lcykuIE90aGVyIG1lY2hhbmlzbXMNCiANCg0KDQpTYWph c3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAgICAgICAgICAg ICAgW1BhZ2UgOV0NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBO ICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIGZvciBpZGVudGlmeWluZyBy b290IG9yIGxlYWYgKGUuZy4sIG9uIGEgcGVyIE1BQyBhZGRyZXNzIGJhc2lzKSBpcw0KICAgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQozLjIuMSBCVU0gdHJhZmZpYyBvcmln aW5hdGVkIGZyb20gYSBzaW5nbGUtaG9tZWQgc2l0ZSBvbiBhIGxlYWYgQUMNCg0KICAgSW4gdGhp cyBzY2VuYXJpbywgdGhlIGluZ3Jlc3MgUEUgYWRkcyBhIHNwZWNpYWwgTVBMUyBsYWJlbCBpbmRp Y2F0aW5nDQogICBhIExlYWYgc2l0ZS4gVGhpcyBzcGVjaWFsIExlYWYgTVBMUyBsYWJlbCwgdXNl ZCBmb3Igc2luZ2xlLWhvbWluZw0KICAgc2NlbmFyaW9zLCBpcyBub3Qgb24gYSBwZXIgRVMgYmFz aXMgYnV0IHJhdGhlciBvbiBhIHBlciBQRSBiYXNpcyAtDQogICBpLmUuLCBhIHNpbmdsZSBMZWFm IE1QTFMgbGFiZWwgaXMgdXNlZCBmb3IgYWxsIHNpbmdsZS1ob21lZCBFUydzIG9uDQogICB0aGF0 IFBFLiBUaGlzIExlYWYgbGFiZWwgaXMgYWR2ZXJ0aXNlZCB0byBvdGhlciBQRSBkZXZpY2VzLCB1 c2luZyBhDQogICBuZXcgRVZQTiBFeHRlbmRlZCBDb21tdW5pdHkgY2FsbGVkIEUtVFJFRSBFeHRl bmRlZCBDb21tdW5pdHkgKHNlY3Rpb24NCiAgIDUuMSkgYWxvbmcgd2l0aCBhbiBFdGhlcm5ldCBB LUQgcGVyIEVTIHJvdXRlIHdpdGggRVNJIG9mIHplcm8gYW5kIGENCiAgIHNldCBvZiBSb3V0ZSBU YXJnZXRzIChSVHMpIGNvcnJlc3BvbmRpbmcgdG8gYWxsIEVWSXMgb24gdGhlIFBFIHdpdGgNCiAg IGF0IGxlYXN0IG9uZSBsZWFmIHNpdGUgcGVyIEVWSS4gVGhlIHNldCBvZiBFdGhlcm5ldCBBLUQg cGVyIEVTIHJvdXRlcw0KICAgbWF5IGJlIG5lZWRlZCBpZiB0aGUgbnVtYmVyIG9mIFJvdXRlIFRh cmdldHMgKFJUcykgdGhhdCBuZWVkIHRvIGJlDQogICBzZW50IGV4Y2VlZCB0aGUgbGltaXQgb24g YSBzaW5nbGUgcm91dGUgcGVyIFtSRkM3NDMyXS4gVGhlIEVTSSBmb3INCiAgIHRoZSBFdGhlcm5l dCBBLUQgcGVyIEVTIHJvdXRlIGlzIHNldCB0byB6ZXJvIHRvIGluZGljYXRlIHNpbmdsZS1ob21l ZA0KICAgc2l0ZXMuDQoNCiAgIFdoZW4gYSBQRSByZWNlaXZlcyB0aGlzIHNwZWNpYWwgTGVhZiBs YWJlbCBpbiB0aGUgZGF0YSBwYXRoLCBpdA0KICAgYmxvY2tzIHRoZSBwYWNrZXQgaWYgdGhlIGRl c3RpbmF0aW9uIEFDIGlzIG9mIHR5cGUgTGVhZjsgb3RoZXJ3aXNlLA0KICAgaXQgZm9yd2FyZHMg dGhlIHBhY2tldC4gIA0KDQozLjIuMiBCVU0gdHJhZmZpYyBvcmlnaW5hdGVkIGZyb20gYSBzaW5n bGUtaG9tZWQgc2l0ZSBvbiBhIHJvb3QgQUMNCg0KICAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIGlu Z3Jlc3MgUEUgZG9lcyBub3QgYWRkIGFueSBFU0kgbGFiZWwgb3IgTGVhZg0KICAgbGFiZWwgYW5k IGl0IG9wZXJhdGVzIHBlciBbUkZDNzQzMl0gcHJvY2VkdXJlcy4gDQoNCjMuMi4zIEJVTSB0cmFm ZmljIG9yaWdpbmF0ZWQgZnJvbSBhIG11bHRpLWhvbWVkIHNpdGUgb24gYSBsZWFmIEFDDQoNCiAg IEluIHRoaXMgc2NlbmFyaW8sIGl0IGlzIGFzc3VtZWQgdGhhdCB3aGlsZSBkaWZmZXJlbnQgQUNz IChWTEFOcykgb24NCiAgIHRoZSBzYW1lIEVTIGNvdWxkIGhhdmUgZGlmZmVyZW50IHJvb3QvbGVh ZiBkZXNpZ25hdGlvbiAoc29tZSBiZWluZw0KICAgcm9vdHMgYW5kIHNvbWUgYmVpbmcgbGVhZnMp LCB0aGUgc2FtZSBBQyAoZS5nLiwgVkxBTikgZG9lcyBoYXZlIHRoZQ0KICAgc2FtZSByb290L2xl YWYgZGVzaWduYXRpb24gb24gYWxsIFBFcyBvbiB0aGUgc2FtZSBFUy4gRnVydGhlcm1vcmUsIGl0 DQogICBpcyBhc3N1bWVkIHRoYXQgdGhlcmUgaXMgbm8gZm9yd2FyZGluZyBhbW9uZyBzdWJuZXRz IC0gaWUsIHRoZQ0KICAgc2VydmljZSBpcyBFVlBOIEwyIGFuZCBub3QgRVZQTiBJUkIuIElSQiB1 c2UgY2FzZSBpcyBvdXRzaWRlIHRoZQ0KICAgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIA0KDQog ICBJbiBzdWNoIHNjZW5hcmlvcywgIElmIGEgbXVsdGljYXN0IG9yIGJyb2FkY2FzdCBwYWNrZXQg aXMgb3JpZ2luYXRlZA0KICAgZnJvbSBhIGxlYWYgQUMsIHRoZW4gaXQgb25seSBuZWVkcyB0byBj YXJyeSBMZWFmIGxhYmVsIGRlc2NyaWJlZCBpbg0KICAgc2VjdGlvbiAzLjIuMS4gVGhpcyBsYWJl bCBpcyBzdWZmaWNpZW50IGluIHByb3ZpZGluZyB0aGUgbmVjZXNzYXJ5DQogICBlZ3Jlc3MgZmls dGVyaW5nIG9mIEJVTSB0cmFmZmljIGZyb20gZ2V0dGluZyBzZW50IHRvIGxlYWYgQUNzDQogICBp bmNsdWRpbmcgdGhlIGxlYWYgQUMgb24gdGhlIHNhbWUgRXRoZXJuZXQgU2VnbWVudC4gIA0KDQoz LjIuNCBCVU0gdHJhZmZpYyBvcmlnaW5hdGVkIGZyb20gYSBtdWx0aS1ob21lZCBzaXRlIG9uIGEg cm9vdCBBQw0KDQogICBJbiB0aGlzIHNjZW5hcmlvLCBib3RoIHRoZSBpbmdyZXNzIGFuZCBlZ3Jl c3MgUEUgZGV2aWNlcyBmb2xsb3dzIHRoZQ0KICAgcHJvY2VkdXJlIGRlZmluZWQgaW4gW1JGQzc0 MzJdIGZvciBhZGRpbmcgYW5kL29yIHByb2Nlc3NpbmcgYW4gRVNJDQogDQoNCg0KU2FqYXNzaSBl dCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgW1Bh Z2UgMTBdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgRS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBC Qi1FVlBOICAgRGVjZW1iZXIgMjAsIDIwMTYNCg0KDQogICBNUExTIGxhYmVsLg0KDQoNCjMuMyBF LVRSRUUgVHJhZmZpYyBGbG93cyBmb3IgRVZQTg0KDQogICBQZXIgW1JGQzczODddLCBhIGdlbmVy aWMgRS1UcmVlIHNlcnZpY2Ugc3VwcG9ydHMgYWxsIG9mIHRoZSBmb2xsb3dpbmcNCiAgIHRyYWZm aWMgZmxvd3M6DQoNCiAgICAgICAgLSBFdGhlcm5ldCBVbmljYXN0IGZyb20gUm9vdCB0byBSb290 cyAmIExlYWYNCiAgICAgICAgLSBFdGhlcm5ldCBVbmljYXN0IGZyb20gTGVhZiB0byBSb290DQog ICAgICAgIC0gRXRoZXJuZXQgQnJvYWRjYXN0L011bHRpY2FzdCBmcm9tIFJvb3QgdG8gUm9vdHMg JiBMZWFmcw0KICAgICAgICAtIEV0aGVybmV0IEJyb2FkY2FzdC9NdWx0aWNhc3QgZnJvbSBMZWFm IHRvIFJvb3RzDQoNCiAgIEEgcGFydGljdWxhciBFLVRyZWUgc2VydmljZSBtYXkgbmVlZCB0byBz dXBwb3J0IGFsbCBvZiB0aGUgYWJvdmUNCiAgIHR5cGVzIG9mIGZsb3dzIG9yIG9ubHkgYSBzZWxl Y3Qgc3Vic2V0LCBkZXBlbmRpbmcgb24gdGhlIHRhcmdldA0KICAgYXBwbGljYXRpb24uIEluIHRo ZSBjYXNlIHdoZXJlIHVuaWNhc3QgZmxvd3MgbmVlZCBub3QgYmUgc3VwcG9ydGVkLA0KICAgdGhl IEwyVlBOIFBFcyBjYW4gYXZvaWQgcGVyZm9ybWluZyBhbnkgTUFDIGxlYXJuaW5nIGZ1bmN0aW9u LiANCg0KICAgSW4gdGhlIHN1YnNlY3Rpb25zIHRoYXQgZm9sbG93LCB3ZSB3aWxsIGRlc2NyaWJl IHRoZSBvcGVyYXRpb24gb2YNCiAgIEVWUE4gdG8gc3VwcG9ydCBFLVRyZWUgc2VydmljZSB3aXRo IGFuZCB3aXRob3V0IE1BQyBsZWFybmluZy4NCg0KDQozLjMuMSBFLVRyZWUgd2l0aCBNQUMgTGVh cm5pbmcNCg0KICAgVGhlIFBFcyBpbXBsZW1lbnRpbmcgYW4gRS1UcmVlIHNlcnZpY2UgbXVzdCBw ZXJmb3JtIE1BQyBsZWFybmluZyB3aGVuDQogICB1bmljYXN0IHRyYWZmaWMgZmxvd3MgbXVzdCBi ZSBzdXBwb3J0ZWQgYW1vbmcgUm9vdCBhbmQgTGVhZiBzaXRlcy4gSW4NCiAgIHRoaXMgY2FzZSwg dGhlIFBFKHMpIHdpdGggUm9vdCBzaXRlcyBwZXJmb3JtcyBNQUMgbGVhcm5pbmcgaW4gdGhlDQog ICBkYXRhLXBhdGggb3ZlciB0aGUgRXRoZXJuZXQgU2VnbWVudHMsIGFuZCBhZHZlcnRpc2VzIHJl YWNoYWJpbGl0eSBpbg0KICAgRVZQTiBNQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZXMuIFRoZXNlIHJv dXRlcyB3aWxsIGJlIGltcG9ydGVkIGJ5IGFsbA0KICAgUEVzIGZvciB0aGF0IEVWSSAoaS5lLiwg UEVzIHRoYXQgaGF2ZSBMZWFmIHNpdGVzIGFzIHdlbGwgYXMgUEVzIHRoYXQNCiAgIGhhdmUgUm9v dCBzaXRlcykuIFNpbWlsYXJseSwgdGhlIFBFcyB3aXRoIExlYWYgc2l0ZXMgcGVyZm9ybSBNQUMN CiAgIGxlYXJuaW5nIGluIHRoZSBkYXRhLXBhdGggb3ZlciB0aGVpciBFdGhlcm5ldCBTZWdtZW50 cywgYW5kIGFkdmVydGlzZQ0KICAgcmVhY2hhYmlsaXR5IGluIEVWUE4gTUFDIEFkdmVydGlzZW1l bnQgcm91dGVzLiBGb3IgdGhlIHNjZW5hcmlvDQogICBkZXNjcmliZWQgaW4gc2VjdGlvbiAyLjEg KG9yIHBvc3NpYmx5IHNlY3Rpb24gMi4yKSwgdGhlc2Ugcm91dGVzIGFyZQ0KICAgaW1wb3J0ZWQg b25seSBieSBQRXMgd2l0aCBhdCBsZWFzdCBvbmUgUm9vdCBzaXRlIGluIHRoZSBFVkkgLSBpLmUu LCBhDQogICBQRSB3aXRoIG9ubHkgTGVhZiBzaXRlcyB3aWxsIG5vdCBpbXBvcnQgdGhlc2Ugcm91 dGVzLiBQRXMgd2l0aCBSb290DQogICBhbmQvb3IgTGVhZiBzaXRlcyBtYXkgdXNlIHRoZSBFdGhl cm5ldCBBLUQgcm91dGVzIGZvciBhbGlhc2luZyAoaW4NCiAgIHRoZSBjYXNlIG9mIG11bHRpLWhv bWVkIHNlZ21lbnRzKSBhbmQgZm9yIG1hc3MgTUFDIHdpdGhkcmF3YWwgcGVyDQogICBbUkZDNzQz Ml0uDQoNCiAgIFRvIHN1cHBvcnQgbXVsdGljYXN0L2Jyb2FkY2FzdCBmcm9tIFJvb3QgdG8gTGVh ZiBzaXRlcywgZWl0aGVyIGEgUDJNUA0KICAgdHJlZSByb290ZWQgYXQgdGhlIFBFKHMpIHdpdGgg dGhlIFJvb3Qgc2l0ZShzKSBvciBpbmdyZXNzIHJlcGxpY2F0aW9uDQogICBjYW4gYmUgdXNlZC4g VGhlIG11bHRpY2FzdCB0dW5uZWxzIGFyZSBzZXQgdXAgdGhyb3VnaCB0aGUgZXhjaGFuZ2Ugb2YN CiAgIHRoZSBFVlBOIEluY2x1c2l2ZSBNdWx0aWNhc3Qgcm91dGUsIGFzIGRlZmluZWQgaW4gW1JG Qzc0MzJdLiANCg0KICAgVG8gc3VwcG9ydCBtdWx0aWNhc3QvYnJvYWRjYXN0IGZyb20gTGVhZiB0 byBSb290IHNpdGVzLCBpbmdyZXNzDQogICByZXBsaWNhdGlvbiBzaG91bGQgYmUgc3VmZmljaWVu dCBmb3IgbW9zdCBzY2VuYXJpb3Mgd2hlcmUgdGhlcmUgYXJlDQogICBvbmx5IGEgZmV3IFJvb3Rz ICh0eXBpY2FsbHkgdHdvKS4gVGhlcmVmb3JlLCBpbiBhIHR5cGljYWwgc2NlbmFyaW8sIGENCiAN Cg0KDQpTYWphc3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAg ICAgICAgICAgICBbUGFnZSAxMV0NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9y dCBpbiBFVlBOICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIHJvb3QgUEUg bmVlZHMgdG8gc3VwcG9ydCBib3RoIGEgUDJNUCB0dW5uZWwgaW4gdHJhbnNtaXQgZGlyZWN0aW9u DQogICBmcm9tIGl0c2VsZiB0byBsZWFmIFBFcyBhbmQgYXQgdGhlIHNhbWUgdGltZSBpdCBuZWVk cyB0byBzdXBwb3J0DQogICBpbmdyZXNzLXJlcGxpY2F0aW9uIHR1bm5lbHMgaW4gcmVjZWl2ZSBk aXJlY3Rpb24gZnJvbSBsZWFmIFBFcyB0bw0KICAgaXRzZWxmLiBJbiBvcmRlciB0byBzaWduYWwg dGhpcyBlZmZpY2llbnRseSBmcm9tIHRoZSByb290IFBFLCBhIG5ldw0KICAgY29tcG9zaXRlIHR1 bm5lbCB0eXBlIGlzIGRlZmluZWQgcGVyIHNlY3Rpb24gNS4zLiAgVGhpcyBuZXcgY29tcG9zaXRl DQogICB0dW5uZWwgdHlwZSBpcyBhZHZlcnRpc2VkIGJ5IHRoZSByb290IFBFIHRvIHNpbXVsdGFu ZW91c2x5IGluZGljYXRlIGENCiAgIFAyTVAgdHVubmVsIGluIHRyYW5zbWl0IGRpcmVjdGlvbiBh bmQgYW4gaW5ncmVzcy1yZXBsaWNhdGlvbiB0dW5uZWwNCiAgIGluIHRoZSByZWNlaXZlIGRpcmVj dGlvbiBmb3IgdGhlIEJVTSB0cmFmZmljLiAgIA0KDQogICBJZiB0aGUgbnVtYmVyIG9mIFJvb3Rz IGlzIGxhcmdlLCBQMk1QIHR1bm5lbHMgb3JpZ2luYXRlZCBhdCB0aGUgUEVzDQogICB3aXRoIExl YWYgc2l0ZXMgbWF5IGJlIHVzZWQgYW5kIHRodXMgdGhlcmUgd2lsbCBiZSBubyBuZWVkIHRvIHVz ZSB0aGUNCiAgIG1vZGlmaWVkIFBNU0kgdHVubmVsIGF0dHJpYnV0ZSBpbiBzZWN0aW9uIDUuMiBm b3IgY29tcG9zaXRlIHR1bm5lbA0KICAgdHlwZS4NCg0KMy4zLjIgRS1UcmVlIHdpdGhvdXQgTUFD IExlYXJuaW5nDQoNCiAgIFRoZSBQRXMgaW1wbGVtZW50aW5nIGFuIEUtVHJlZSBzZXJ2aWNlIG5l ZWQgbm90IHBlcmZvcm0gTUFDIGxlYXJuaW5nDQogICB3aGVuIHRoZSB0cmFmZmljIGZsb3dzIGJl dHdlZW4gUm9vdCBhbmQgTGVhZiBzaXRlcyBhcmUgb25seSBtdWx0aWNhc3QNCiAgIG9yIGJyb2Fk Y2FzdC4gSW4gdGhpcyBjYXNlLCB0aGUgUEVzIGRvIG5vdCBleGNoYW5nZSBFVlBOIE1BQw0KICAg QWR2ZXJ0aXNlbWVudCByb3V0ZXMuIEluc3RlYWQsIHRoZSBJbmNsdXNpdmUgTXVsdGljYXN0IEV0 aGVybmV0IFRhZyANCiAgIHJvdXRlIGlzIHVzZWQgdG8gc3VwcG9ydCBCVU0gdHJhZmZpYy4gDQoN CiAgIFRoZSBmaWVsZHMgb2YgdGhpcyByb3V0ZSBhcmUgcG9wdWxhdGVkIHBlciB0aGUgcHJvY2Vk dXJlcyBkZWZpbmVkIGluDQogICBbUkZDNzQzMl0sIGFuZCB0aGUgbXVsdGljYXN0IHR1bm5lbCBz ZXR1cCBjcml0ZXJpYSBhcmUgYXMgZGVzY3JpYmVkDQogICBpbiB0aGUgcHJldmlvdXMgc2VjdGlv bi4gDQoNCiAgIEp1c3QgYXMgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24sIGlmIHRoZSBudW1iZXIg b2YgUEVzIHdpdGggcm9vdCBzaXRlcw0KICAgYXJlIG9ubHkgYSBmZXcgYW5kIHRodXMgaW5ncmVz cyByZXBsaWNhdGlvbiBpcyBkZXNpcmVkIGZyb20gbGVhZiBQRXMNCiAgIHRvIHRoZXNlIHJvb3Qg UEVzLCB0aGVuIHRoZSBtb2RpZmllZCBQTVNJIGF0dHJpYnV0ZSBhcyBkZWZpbmVkIGluDQogICBz ZWN0aW9uIDUuMyBzaG91bGQgYmUgdXNlZC4NCg0KNCBPcGVyYXRpb24gZm9yIFBCQi1FVlBODQoN CiAgIEluIFBCQi1FVlBOLCB0aGUgUEUgYWR2ZXJ0aXNlcyBhIFJvb3QvTGVhZiBpbmRpY2F0aW9u IGFsb25nIHdpdGggZWFjaA0KICAgQi1NQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZSwgdG8gaW5kaWNh dGUgd2hldGhlciB0aGUgYXNzb2NpYXRlZCBCLU1BQw0KICAgYWRkcmVzcyBjb3JyZXNwb25kcyB0 byBhIFJvb3Qgb3IgYSBMZWFmIHNpdGUuIEp1c3QgbGlrZSB0aGUgRVZQTg0KICAgY2FzZSwgdGhl IG5ldyBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5IGRlZmluZWQgaW4gc2VjdGlvbiBbNS4xXSBp cw0KICAgYWR2ZXJ0aXNlZCB3aXRoIGVhY2ggTUFDIEFkdmVydGlzZW1lbnQgcm91dGUuDQoNCiAg IEluIHRoZSBjYXNlIHdoZXJlIGEgbXVsdGktaG9tZWQgRXRoZXJuZXQgU2VnbWVudCBoYXMgYm90 aCBSb290IGFuZA0KICAgTGVhZiBzaXRlcyBhdHRhY2hlZCwgdHdvIEItTUFDIGFkZHJlc3NlcyBh cmUgYWR2ZXJ0aXNlZDogb25lIEItTUFDDQogICBhZGRyZXNzIGlzIHBlciBFUyBhcyBzcGVjaWZp ZWQgaW4gW1JGQzc2MjNdIGFuZCBpbXBsaWNpdGx5IGRlbm90aW5nIA0KICAgUm9vdCwgYW5kIHRo ZSBvdGhlciBCLU1BQyBhZGRyZXNzIGlzIHBlciBQRSBhbmQgZXhwbGljaXRseSBkZW5vdGluZw0K ICAgTGVhZi4gVGhlIGZvcm1lciBCLU1BQyBhZGRyZXNzIGlzIG5vdCBhZHZlcnRpc2VkIHdpdGgg dGhlIEUtVFJFRQ0KICAgZXh0ZW5kZWQgY29tbXVuaXR5IGJ1dCB0aGUgbGF0dGVyIEItTUFDIGRl bm90aW5nIExlYWYgaXMgYWR2ZXJ0aXNlZA0KICAgd2l0aCB0aGUgbmV3IEUtVFJFRSBleHRlbmRl ZCBjb21tdW5pdHkgd2hlcmUgIkxlYWYtaW5kaWNhdGlvbiIgZmxhZw0KICAgaXMgc2V0LiBJbiBz dWNoIG11bHRpLWhvbWluZyBzY2VuYXJpb3Mgd2hlcmUgYW5kIEV0aGVybmV0IFNlZ21lbnQgaGFz DQogICBib3RoIFJvb3QgYW5kIExlYWYgQUNzLCBpdCBpcyBhc3N1bWVkIHRoYXQgV2hpbGUgZGlm ZmVyZW50IEFDcw0KIA0KDQoNClNhamFzc2kgZXQgYWwuICAgICAgICAgICAgRXhwaXJlcyBNYXkg MjAsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSU5URVJORVQgRFJBRlQgICAg IEUtVFJFRSBTdXBwb3J0IGluIEVWUE4gJiBQQkItRVZQTiAgIERlY2VtYmVyIDIwLCAyMDE2DQoN Cg0KICAgKFZMQU5zKSBvbiB0aGUgc2FtZSBFUyBjb3VsZCBoYXZlIGRpZmZlcmVudCByb290L2xl YWYgZGVzaWduYXRpb24NCiAgIChzb21lIGJlaW5nIHJvb3RzIGFuZCBzb21lIGJlaW5nIGxlYWZz KSwgdGhlIHNhbWUgVkxBTiBkb2VzIGhhdmUgdGhlDQogICBzYW1lIHJvb3QvbGVhZiBkZXNpZ25h dGlvbiBvbiBhbGwgUEVzIG9uIHRoZSBzYW1lIEVTLiBGdXJ0aGVybW9yZSwgaXQNCiAgIGlzIGFz c3VtZWQgdGhhdCB0aGVyZSBpcyBubyBmb3J3YXJkaW5nIGFtb25nIHN1Ym5ldHMgLSBpZSwgdGhl DQogICBzZXJ2aWNlIGlzIEwyIGFuZCBub3QgSVJCLiBJUkIgdXNlIGNhc2UgaXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgdGhpcw0KICAgZG9jdW1lbnQuDQoNCiAgIFRoZSBpbmdyZXNzIFBFIHVzZXMg dGhlIHJpZ2h0IEItTUFDIHNvdXJjZSBhZGRyZXNzIGRlcGVuZGluZyBvbg0KICAgd2hldGhlciB0 aGUgRXRoZXJuZXQgZnJhbWUgb3JpZ2luYXRlZCBmcm9tIHRoZSBSb290IG9yIExlYWYgQUMgb24N CiAgIHRoYXQgRXRoZXJuZXQgU2VnbWVudC4gVGhlIG1lY2hhbmlzbSBieSB3aGljaCB0aGUgUEUg aWRlbnRpZmllcw0KICAgd2hldGhlciBhIGdpdmVuIGZyYW1lIG9yaWdpbmF0ZWQgZnJvbSBhIFJv b3Qgb3IgTGVhZiBzaXRlIG9uIHRoZQ0KICAgc2VnbWVudCBpcyBiYXNlZCBvbiB0aGUgRXRoZXJu ZXQgVGFnIGFzc29jaWF0ZWQgd2l0aCB0aGUgZnJhbWUuIE90aGVyDQogICBtZWNoYW5pc21zIG9m IGlkZW50aWZpY2F0aW9uLCBiZXlvbmQgdGhlIEV0aGVybmV0IFRhZywgYXJlIG91dHNpZGUNCiAg IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgDQoNCiAgIEZ1cnRoZXJtb3JlLCBhIFBFIGFk dmVydGlzZXMgdHdvIHNwZWNpYWwgZ2xvYmFsIEItTUFDIGFkZHJlc3Nlczogb25lDQogICBmb3Ig Um9vdCBhbmQgYW5vdGhlciBmb3IgTGVhZiwgYW5kIHRhZ3MgdGhlIExlYWYgb25lIGFzIHN1Y2gg aW4gdGhlDQogICBNQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZS4gVGhlc2UgQi1NQUMgYWRkcmVzc2Vz IGFyZSB1c2VkIGFzIHNvdXJjZQ0KICAgYWRkcmVzc2VzIGZvciB0cmFmZmljIG9yaWdpbmF0aW5n IGZyb20gc2luZ2xlLWhvbWVkIHNlZ21lbnRzLiBUaGUgQi0NCiAgIE1BQyBhZGRyZXNzIHVzZWQg Zm9yIGluZGljYXRpbmcgTGVhZiBzaXRlcyBjYW4gYmUgdGhlIHNhbWUgZm9yIGJvdGgNCiAgIHNp bmdsZS1ob21lZCBhbmQgbXVsdGktaG9tZWQgc2VnbWVudHMuDQoNCjQuMSBLbm93biBVbmljYXN0 IFRyYWZmaWMNCg0KICAgRm9yIGtub3duIHVuaWNhc3QgdHJhZmZpYywgdGhlIFBFcyBwZXJmb3Jt IGluZ3Jlc3MgZmlsdGVyaW5nOiBPbiB0aGUNCiAgIGluZ3Jlc3MgUEUsIHRoZSBDLU1BQyBkZXN0 aW5hdGlvbiBhZGRyZXNzIGxvb2t1cCB5aWVsZHMsIGluIGFkZGl0aW9uDQogICB0byB0aGUgdGFy Z2V0IEItTUFDIGFkZHJlc3MgYW5kIGZvcndhcmRpbmcgYWRqYWNlbmN5LCBhIGZsYWcgd2hpY2gN CiAgIGluZGljYXRlcyB3aGV0aGVyIHRoZSB0YXJnZXQgQi1NQUMgaXMgYXNzb2NpYXRlZCB3aXRo IGEgUm9vdCBvciBhDQogICBMZWFmIHNpdGUuIFRoZSBpbmdyZXNzIFBFIGNyb3NzLWNoZWNrcyB0 aGlzIGZsYWcgd2l0aCB0aGUgc3RhdHVzIG9mDQogICB0aGUgb3JpZ2luYXRpbmcgc2l0ZSwgYW5k IGlmIGJvdGggYXJlIGEgTGVhZiwgdGhlbiB0aGUgcGFja2V0IGlzIG5vdA0KICAgZm9yd2FyZGVk Lg0KDQoNCjQuMiBCVU0gVHJhZmZpYw0KDQogICBGb3IgQlVNIHRyYWZmaWMsIHRoZSBQRXMgbXVz dCBwZXJmb3JtIGVncmVzcyBmaWx0ZXJpbmcuIFdoZW4gYSBQRQ0KICAgcmVjZWl2ZXMgYSBNQUMg YWR2ZXJ0aXNlbWVudCByb3V0ZSAod2hpY2ggd2lsbCBiZSB1c2VkIGFzIGEgc291cmNlIEItDQog ICBNQUMgZm9yIEJVTSB0cmFmZmljKSwgaXQgdXBkYXRlcyBpdHMgZWdyZXNzIGZpbHRlcmluZyAo YmFzZWQgb24gdGhlDQogICBzb3VyY2UgQi1NQUMgYWRkcmVzcyksIGFzIGZvbGxvd3M6DQoNCiAg IC0gSWYgdGhlIE1BQyBBZHZlcnRpc2VtZW50IHJvdXRlIGluZGljYXRlcyB0aGF0IHRoZSBhZHZl cnRpc2VkIEItTUFDDQogICBpcyBhIExlYWYsIGFuZCB0aGUgbG9jYWwgRXRoZXJuZXQgU2VnbWVu dCBpcyBhIExlYWYgYXMgd2VsbCwgdGhlbiB0aGUNCiAgIHNvdXJjZSBCLU1BQyBhZGRyZXNzIGlz IGFkZGVkIHRvIGl0cyBCLU1BQyBsaXN0IHVzZWQgZm9yIGVncmVzcw0KICAgZmlsdGVyaW5nIC0g aS5lLiwgdG8gYmxvY2sgdHJhZmZpYyBmcm9tIHRoYXQgQi1NQUMgYWRkcmVzcy4NCg0KICAgLSBP dGhlcndpc2UsIHRoZSBCLU1BQyBmaWx0ZXJpbmcgbGlzdCBpcyBub3QgdXBkYXRlZC4NCg0KICAg V2hlbiB0aGUgZWdyZXNzIFBFIHJlY2VpdmVzIHRoZSBwYWNrZXQsIGl0IGV4YW1pbmVzIHRoZSBC LU1BQyBzb3VyY2UNCiANCg0KDQpTYWphc3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5 IDIwLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCklOVEVSTkVUIERSQUZUICAg ICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBOICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0K DQoNCiAgIGFkZHJlc3MgdG8gY2hlY2sgd2hldGhlciBpdCBzaG91bGQgZmlsdGVyIG9yIGZvcndh cmQgdGhlIGZyYW1lLiBOb3RlDQogICB0aGF0IHRoaXMgdXNlcyB0aGUgc2FtZSBmaWx0ZXJpbmcg bG9naWMgYXMgYmFzZWxpbmUgW1JGQzc2MjNdIGFuZA0KICAgZG9lcyBub3QgcmVxdWlyZSBhbnkg YWRkaXRpb25hbCBmbGFncyBpbiB0aGUgZGF0YS1wbGFuZS4NCg0KICAgSnVzdCBhcyBpbiBzZWN0 aW9uIDMuMiwgdGhlIFBFIHBsYWNlcyBhbGwgTGVhZiBFdGhlcm5ldCBTZWdtZW50cyBvZiBhDQog ICBnaXZlbiBicmlkZ2UgZG9tYWluIGluIGEgc2luZ2xlIHNwbGl0LWhvcml6b24gZ3JvdXAgaW4g b3JkZXIgdG8NCiAgIHByZXZlbnQgaW50cmEtUEUgZm9yd2FyZGluZyBhbW9uZyBMZWFmIHNlZ21l bnRzLiBUaGlzIHNwbGl0LWhvcml6b24NCiAgIGZ1bmN0aW9uIGFwcGxpZXMgdG8gQlVNIHRyYWZm aWMgYXMgd2VsbCBhcyBrbm93bi11bmljYXN0IHRyYWZmaWMuDQoNCjQuMyBFLVRyZWUgd2l0aG91 dCBNQUMgTGVhcm5pbmcNCg0KICAgSW4gc2NlbmFyaW9zIHdoZXJlIHRoZSB0cmFmZmljIG9mIGlu dGVyZXN0IGlzIG9ubHkgTXVsdGljYXN0IGFuZC9vcg0KICAgYnJvYWRjYXN0LCB0aGUgUEVzIGlt cGxlbWVudGluZyBhbiBFLVRyZWUgc2VydmljZSBkbyBub3QgbmVlZCB0byBkbw0KICAgYW55IE1B QyBsZWFybmluZy4gSW4gc3VjaCBzY2VuYXJpb3MgdGhlIGZpbHRlcmluZyBtdXN0IGJlIHBlcmZv cm1lZA0KICAgb24gZWdyZXNzIFBFcy4gRm9yIFBCQi1FVlBOLCB0aGUgaGFuZGxpbmcgb2Ygc3Vj aCB0cmFmZmljIGlzIHBlcg0KICAgc2VjdGlvbiA0LjIgd2l0aG91dCBDLU1BQyBsZWFybmluZyBw YXJ0IG9mIGl0IGF0IGJvdGggaW5ncmVzcyBhbmQNCiAgIGVncmVzcyBQRXMuICANCg0KDQo1IEJH UCBFbmNvZGluZw0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldyBCR1AgRXh0ZW5k ZWQgQ29tbXVuaXR5IGZvciBFVlBOLg0KDQo1LjEgRS1UUkVFIEV4dGVuZGVkIENvbW11bml0eQ0K DQogICBUaGlzIEV4dGVuZGVkIENvbW11bml0eSBpcyBhIG5ldyB0cmFuc2l0aXZlIEV4dGVuZGVk IENvbW11bml0eSBoYXZpbmcNCiAgIGEgVHlwZSBmaWVsZCB2YWx1ZSBvZiAweDA2IChFVlBOKSBh bmQgdGhlIFN1Yi1UeXBlIDB4MDUuIEl0IGlzIHVzZWQNCiAgIGZvciBsZWFmIGluZGljYXRpb24g b2Yga25vd24gdW5pY2FzdCBhbmQgQlVNIHRyYWZmaWMuIEZvciBCVU0NCiAgIHRyYWZmaWMsIHRo ZSBMZWFmIExhYmVsIGZpZWxkIGlzIHNldCB0byBhIHZhbGlkIE1QTFMgbGFiZWwgYW5kIHRoaXMN CiAgIEVDIGlzIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBFdGhlcm5ldCBBLUQgcGVyIEVTIHJvdXRl IHdpdGggYW4gRVNJIG9mDQogICB6ZXJvIHRvIGVuYWJsZSBlZ3Jlc3MgZmlsdGVyaW5nIG9uIGRp c3Bvc2l0aW9uIFBFcyBwZXIgc2VjdGlvbiAzLjIuMQ0KICAgYW5kIDMuMi4zLiBUaGVyZSBpcyBu byBuZWVkIHRvIHNlbmQgRVNJIExhYmVsIEV4dGVuZGVkIENvbW11bml0eSB3aGVuDQogICBzZW5k aW5nIEV0aGVybmV0IEEtRCBwZXIgRVMgcm91dGUgd2l0aCBhbiBFU0kgb2YgemVyby4gRm9yIGtu b3duDQogICB1bmljYXN0IHRyYWZmaWMsIHRoZSBMZWFmIGZsYWcgYml0IGlzIHNldCB0byBvbmUg YW5kIHRoaXMgRUMgaXMNCiAgIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBNQUMvSVAgQWR2ZXJ0aXNl bWVudCByb3V0ZSBwZXIgc2VjdGlvbiAzLjEuICAgDQoNCiAgIFRoZSBFLVRSRUUgRXh0ZW5kZWQg Q29tbXVuaXR5IGlzIGVuY29kZWQgYXMgYW4gOC1vY3RldCB2YWx1ZSBhcw0KICAgZm9sbG93czoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KIA0KDQoNClNhamFzc2kgZXQgYWwuICAgICAgICAgICAgRXhw aXJlcyBNYXkgMjAsIDIwMTcgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSU5URVJORVQg RFJBRlQgICAgIEUtVFJFRSBTdXBwb3J0IGluIEVWUE4gJiBQQkItRVZQTiAgIERlY2VtYmVyIDIw LCAyMDE2DQoNCg0KICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAg ICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgICAgfCBUeXBlPTB4MDYgICAgIHwgU3ViLVR5cGU9MHgwNSB8IEZsYWdzKDEgT2N0ZXQp fCAgUmVzZXJ2ZWQ9MCAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgIFJlc2VydmVkPTAg ICB8ICAgICAgICAgICBMZWFmIExhYmVsICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCg0KDQoNCiAgIFRoZSBsb3ctb3JkZXIgYml0IG9mIHRoZSBGbGFncyBvY3Rl dCBpcyBkZWZpbmVkIGFzIHRoZSAiTGVhZi0NCiAgIEluZGljYXRpb24iIGJpdC4gQSB2YWx1ZSBv ZiBvbmUgaW5kaWNhdGVzIGEgTGVhZiBBQy9TaXRlLiANCg0KICAgV2hlbiB0aGlzIEVDIGlzIGFk dmVydGlzZWQgYWxvbmcgd2l0aCBNQUMvSVAgQWR2ZXJ0aXNlbWVudCByb3V0ZSAoZm9yDQogICBr bm93biB1bmljYXN0IHRyYWZmaWMpLCB0aGUgTGVhZi1JbmRpY2F0aW9uIGZsYWcgTVVTVCBiZSBz ZXQgdG8gb25lDQogICBhbmQgTGVhZiBMYWJlbCBpcyBzZXQgdG8gemVyby4gVGhlIHJlY2VpdmVk IFBFIHNob3VsZCBpZ25vcmUgTGVhZg0KICAgTGFiZWwgYW5kIG9ubHkgcHJvY2Vzc2VzIExlYWYt SW5kaWNhdGlvbiBmbGFnLiBBIHZhbHVlIG9mIHplcm8gZm9yDQogICBMZWFmLUluZGljYXRpb24g ZmxhZyBpcyBpbnZhbGlkIHdoZW4gc2VudCBhbG9uZyB3aXRoIE1BQy9JUA0KICAgYWR2ZXJ0aXNl bWVudCByb3V0ZSBhbmQgYW4gZXJyb3Igc2hvdWxkIGJlIGxvZ2dlZC4NCg0KICAgV2hlbiB0aGlz IEVDIGlzIGFkdmVydGlzZWQgYWxvbmcgd2l0aCBFdGhlcm5ldCBBLUQgcGVyIEVTIHJvdXRlICh3 aXRoDQogICBFU0kgb2YgemVybykgZm9yIEJVTSB0cmFmZmljLCB0aGUgTGVhZiBMYWJlbCBNVVNU IGJlIHNldCB0byBhIHZhbGlkDQogICBNUExTIGxhYmVsIGFuZCB0aGUgTGVhZi1JbmRpY2F0aW9u IGZsYWcgc2hvdWxkIGJlIHNldCB0byB6ZXJvLiBUaGUNCiAgIHJlY2VpdmVkIFBFIHNob3VsZCBp Z25vcmUgdGhlIExlYWYtSW5kaWNhdGlvbiBmbGFnLiBBIG5vbi12YWxpZCBNUExTDQogICBsYWJl bCB3aGVuIHNlbnQgYWxvbmcgd2l0aCB0aGUgRXRoZXJuZXQgQS1EIHBlciBFUyByb3V0ZSwgc2hv dWxkIGJlDQogICBsb2dnZWQgYXMgYW4gZXJyb3IuIA0KDQoNCjUuMiBQTVNJIFR1bm5lbCBBdHRy aWJ1dGUNCg0KICAgW1JGQzY1MTRdIGRlZmluZXMgUE1TSSBUdW5uZWwgYXR0cmlidXRlIHdoaWNo IGlzIGFuIG9wdGlvbmFsDQogICB0cmFuc2l0aXZlIGF0dHJpYnV0ZSB3aXRoIHRoZSBmb2xsb3dp bmcgZm9ybWF0Og0KDQoNCiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQogICAgICAgICB8ICBGbGFncyAoMSBvY3RldCkgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgIHwgIFR1bm5l bCBUeXBlICgxIG9jdGV0cykgICAgICAgICB8DQogICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgfCAgTVBMUyBMYWJlbCAoMyBvY3RldHMpICAgICAg ICAgIHwNCiAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAg ICAgICB8ICBUdW5uZWwgSWRlbnRpZmllciAodmFyaWFibGUpICAgfA0KICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQogICBUaGlzIGRyYWZ0IHVzZXMgYWxs IHRoZSBmaWVsZHMgcGVyIGV4aXN0aW5nIGRlZmluaXRpb24gZXhjZXB0IGZvciB0aGUNCiAgIGZv bGxvd2luZyBtb2RpZmljYXRpb25zIHRvIHRoZSBUdW5uZWwgVHlwZSBhbmQgVHVubmVsIElkZW50 aWZpZXI6IA0KDQogDQoNCg0KU2FqYXNzaSBldCBhbC4gICAgICAgICAgICBFeHBpcmVzIE1heSAy MCwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAg RS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBCQi1FVlBOICAgRGVjZW1iZXIgMjAsIDIwMTYNCg0K DQogICBXaGVuIHJlY2VpdmVyIGluZ3Jlc3MtcmVwbGljYXRpb24gbGFiZWwgaXMgbmVlZGVkLCB0 aGUgaGlnaC1vcmRlciBiaXQNCiAgIG9mIHRoZSB0dW5uZWwgdHlwZSBmaWVsZCAoQyBiaXQgLSBD b21wb3NpdGUgdHVubmVsIGJpdCkgaXMgc2V0IHdoaWxlDQogICB0aGUgcmVtYWluaW5nIGxvdy1v cmRlciBzZXZlbiBiaXRzIGluZGljYXRlIHRoZSB0dW5uZWwgdHlwZSBhcw0KICAgYmVmb3JlLiBX aGVuIHRoaXMgQyBiaXQgaXMgc2V0LCB0aGUgInR1bm5lbCBpZGVudGlmaWVyIiBmaWVsZCB3b3Vs ZA0KICAgYmVnaW4gd2l0aCBhIHRocmVlLW9jdGV0IGxhYmVsLCBmb2xsb3dlZCBieSB0aGUgYWN0 dWFsIHR1bm5lbA0KICAgaWRlbnRpZmllciBmb3IgdGhlIHRyYW5zbWl0IHR1bm5lbC4gIFBFcyB0 aGF0IGRvbid0IHVuZGVyc3RhbmQgdGhlDQogICBuZXcgbWVhbmluZyBvZiB0aGUgaGlnaC1vcmRl ciBiaXQgd291bGQgdHJlYXQgdGhlIHR1bm5lbCB0eXBlIGFzIGFuDQogICBpbnZhbGlkIHR1bm5l bCB0eXBlLiBGb3IgdGhlIFBFcyB0aGF0IGRvIHVuZGVyc3RhbmQgdGhlIG5ldyBtZWFuaW5nDQog ICBvZiB0aGUgaGlnaC1vcmRlciwgaWYgaW5ncmVzcyByZXBsaWNhdGlvbiBpcyBkZXNpcmVkIHdo ZW4gc2VuZGluZyBCVU0NCiAgIHRyYWZmaWMsIHRoZSBQRSB3aWxsIHVzZSB0aGUgdGhlIGxhYmVs IGluIHRoZSBUdW5uZWwgSWRlbnRpZmllciBmaWVsZA0KICAgd2hlbiBzZW5kaW5nIGl0cyBCVU0g dHJhZmZpYy4gDQoNCiAgIFVzaW5nIHRoZSBDb21wb3NpdGUgZmxhZyBmb3IgVHVubmVsIFR5cGVz IDB4MDAgJ25vIHR1bm5lbCBpbmZvcm1hdGlvbg0KICAgcHJlc2VudCcgYW5kIDB4MDYgJ0luZ3Jl c3MgUmVwbGljYXRpb24nIGlzIGludmFsaWQsIGFuZCBzaG91bGQgYmUNCiAgIHRyZWF0ZWQgYXMg YW4gaW52YWxpZCB0dW5uZWwgdHlwZSBvbiByZWNlcHRpb24uICANCg0KDQo2ICBBY2tub3dsZWRn ZW1lbnQNCg0KICAgV2Ugd291bGQgbGlrZSB0byB0aGFuayBEZW5uaXMgQ2FpLCBBbnRvbmkgUHJ6 eWdpZW5kYSwgYW5kIEplZmZyZXkNCiAgIFpoYW5nIGZvciB0aGVpciB2YWx1YWJsZSBjb21tZW50 cy4gDQoNCg0KNyAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgU2luY2UgdGhpcyBkcmFm dCB1c2VzIHRoZSBFVlBOIGNvbnN0cnVjdHMgb2YgW1JGQzc0MzJdIGFuZCBbUkZDNzYyM10sDQog ICB0aGUgc2FtZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGVzZSBkcmFmdHMgYXJlIGFs c28gYXBwbGljYWJsZQ0KICAgaGVyZS4gRnVydGhlcm1vcmUsIHRoaXMgZHJhZnQgcHJvdmlkZXMg YWRkaXRpb25hbCBzZWN1cml0eSBjaGVjayBieQ0KICAgYWxsb3dpbmcgc2l0ZXMgKG9yIEFDcykg b2YgYW4gRVZQTiBpbnN0YW5jZSB0byBiZSBkZXNpZ25hdGVkIGFzDQogICAiUm9vdCIgb3IgIkxl YWYiIGFuZCBwcmV2ZW50aW5nIGFueSB0cmFmZmljIGV4Y2hhbmdlIGFtb25nICJMZWFmIg0KICAg c2l0ZXMgb2YgdGhhdCBWUE4gdGhyb3VnaCBpbmdyZXNzIGZpbHRlcmluZyBmb3Iga25vd24gdW5p Y2FzdCB0cmFmZmljDQogICBhbmQgZWdyZXNzIGZpbHRlcmluZyBmb3IgQlVNIHRyYWZmaWMuICAg DQoNCg0KOCAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBJQU5BIGhhcyBhbGxvY2F0ZWQgdmFs dWUgNSBpbiB0aGUgIkVWUE4gRXh0ZW5kZWQgQ29tbXVuaXR5IFN1Yi1UeXBlcyINCiAgIHJlZ2lz dHJ5IGRlZmluZWQgaW4gW1JGQzcxNTNdIGFzIGZvbGxvdzoNCg0KICAgICAgICAgU1VCLVRZUEUg VkFMVUUgICAgIE5BTUUgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UNCg0KICAgICAg ICAgMHgwNSAgICAgICAgICAgICAgIEUtVFJFRSBFeHRlbmRlZCBDb21tdW5pdHkgICBUaGlzIGRv Y3VtZW50DQoNCg0KOC4xIENvbnNpZGVyYXRpb25zIGZvciBQTVNJIFR1bm5lbCBUeXBlcw0KDQog ICBUaGUgIlAtTXVsdGljYXN0IFNlcnZpY2UgSW50ZXJmYWNlIFR1bm5lbCAoUE1TSSBUdW5uZWwp IFR1bm5lbCBUeXBlcyINCiAgIHJlZ2lzdHJ5IGluIHRoZSAiQm9yZGVyIEdhdGV3YXkgUHJvdG9j b2wgKEJHUCkgUGFyYW1ldGVycyIgcmVnaXN0cnkNCiANCg0KDQpTYWphc3NpIGV0IGFsLiAgICAg ICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwN CklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBOICYgUEJCLUVWUE4gICBE ZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gcmVmbGVjdCB0 aGUgdXNlIG9mIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCB0bw0KICAgYWR2ZXJ0aXNlIHRoZSB1 c2Ugb2YgImNvbXBvc2l0ZSB0dW5uZWxzIiAoc2VjdGlvbiA1LjIpLg0KDQogICBGb3IgdGhpcyBw dXJwb3NlLCB0aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNzM4NS4NCg0KICAgVGhlIHJlZ2lzdHJ5 IGlzIHRvIGJlIHVwZGF0ZWQsIGJ5IHJlbW92aW5nIHRoZSBlbnRyaWVzIGZvciAweEZCLTB4RkUN CiAgIGFuZCAweDBGLCBhbmQgcmVwbGFjaW5nIHRoZW0gYnk6DQoNCiAgIC0gMHg3Qi0weDdFIFJl c2VydmVkIGZvciBFeHBlcmltZW50YWwgVXNlIFt0aGlzIGRvY3VtZW50XQ0KICAgLSAweDdGICBS ZXNlcnZlZCBbdGhpcyBkb2N1bWVudF0NCiAgIC0gMHg4MC0weEZGIE5vdCBBbGxvY2F0YWJsZSwg Y29ycmVzcG9uZHMgdG8gQ29tcG9zaXRlIHR1bm5lbCB0eXBlcyANCiAgICAgW3RoaXMgZG9jdW1l bnRdDQoNCiAgIFRoZSBhbGxvY2F0aW9uIHBvbGljeSBmb3IgdmFsdWVzIDB4MDAgdG8gMHg3QSBp cyBJRVRGIFJldmlldw0KICAgW1JGQzUyMjZdLiBUaGUgcmFuZ2UgZm9yIGV4cGVyaW1lbnRhbCB1 c2UgaXMgbm93IDB4N0ItMHg3RSwgYW5kIHZhbHVlDQogICBpbiB0aGlzIHJhbmdlIGFyZSBub3Qg dG8gYmUgYXNzaWduZWQuIFRoZSBzdGF0dXMgb2YgMHg3RiBtYXkgb25seSBiZQ0KICAgY2hhbmdl ZCB0aHJvdWdoIFN0YW5kYXJkcyBBY3Rpb24gW1JGQzUyMjZdLiAgDQoNCjkgIFJlZmVyZW5jZXMN Cg0KOS4xICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbS0VZV09SRFNdIEJyYWRuZXIsIFMu LCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBS ZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoNCiAg IFtSRkM3NDMyXSBTYWphc3NpIGV0IGFsLiwgIkJHUCBNUExTIEJhc2VkIEV0aGVybmV0IFZQTiIs IEZlYnJ1YXJ5LA0KICAgICAgICAgICAgICAyMDE1Lg0KDQogICBbUkZDNzYyM10gU2FqYXNzaSBl dCBhbC4sICJQcm92aWRlciBCYWNrYm9uZSBCcmlkZ2luZyBDb21iaW5lZCB3aXRoDQogICAgICAg ICAgICAgIEV0aGVybmV0IFZQTiAoUEJCLUVWUE4pIiwgU2VwdGVtYmVyLCAyMDE1Lg0KDQogICAg ICAgICAgICAgIFtSRkM3Mzg1XSBBbmRlcnNzb24gZXQgYWwuLCAiSUFOQSBSZWdpc3RyeSBmb3Ig UC1NdWx0aWNhc3QNCiAgICAgICAgICAgICAgU2VydmljZSBJbnRlcmZhY2UgKFBNU0kpIFR1bm5l bCBUeXBlIENvZGUgUG9pbnRzIiwNCiAgICAgICAgICAgICAgT2N0b2JlciwgMjAxNC4NCg0KICAg ICAgICAgICAgICBbUkZDNzE1M10gUm9zZW4gZXQgYWwuLCAiSUFOQSBSZWdpc3RyaWVzIGZvciBC R1AgRXh0ZW5kZWQNCiAgICAgICAgICAgICAgQ29tbXVuaXRpZXMiLCAgTWFyY2gsIDIwMTQuDQoN CiAgICAgICAgICAgICAgW1JGQzY1MTRdIEFnZ2Fyd2FsIGV0IGFsLiwgIkJHUCBFbmNvZGluZ3Mg YW5kIFByb2NlZHVyZXMNCiAgICAgICAgICAgICAgZm9yIE11bHRpY2FzdCBpbiBNUExTL0JHUCBJ UCBWUE5zIiwgIEZlYnJ1YXJ5LCAyMDEyLg0KDQoNCjkuMiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cw0KDQogICBbUkZDNzM4N10gS2V5IGV0IGFsLiwgIkEgRnJhbWV3b3JrIGZvciBFLVRyZWUgU2Vy dmljZSBvdmVyIE1QTFMNCiAgIE5ldHdvcmsiLCBPY3RvYmVyIDIwMTQuDQoNCiANCg0KDQpTYWph c3NpIGV0IGFsLiAgICAgICAgICAgIEV4cGlyZXMgTWF5IDIwLCAyMDE3ICAgICAgICAgICAgICAg ICBbUGFnZSAxN10NCgwNCklOVEVSTkVUIERSQUZUICAgICBFLVRSRUUgU3VwcG9ydCBpbiBFVlBO ICYgUEJCLUVWUE4gICBEZWNlbWJlciAyMCwgMjAxNg0KDQoNCiAgIFtSRkM0MzYwXSBTLiBTYW5n bGkgZXQgYWwsICJCR1AgRXh0ZW5kZWQgQ29tbXVuaXRpZXMgQXR0cmlidXRlIiwgDQogICBGZWJy dWFyeSwgMjAwNi4NCg0KDQpDb250cmlidXRvcnMNCg0KICAgSW4gYWRkaXRpb24gdG8gdGhlIGF1 dGhvcnMgbGlzdGVkIG9uIHRoZSBmcm9udCBwYWdlLCB0aGUgZm9sbG93aW5nDQogICBjby1hdXRo b3JzIGhhdmUgYWxzbyBjb250cmlidXRlZCB0byB0aGlzIGRvY3VtZW50Og0KDQoNCiAgIFdpbSBI ZW5kZXJpY2t4DQogICBOb2tpYQ0KDQogICBBbGRyaW4gSXNhYWMNCiAgIFdlbiBMaW4NCiAgIEp1 bmlwZXINCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0KDQogICBBbGkgU2FqYXNzaQ0KICAgQ2lz Y28NCiAgIEVtYWlsOiBzYWphc3NpQGNpc2NvLmNvbQ0KDQoNCiAgIFNhbWVyIFNhbGFtDQogICBD aXNjbw0KICAgRW1haWw6IHNzYWxhbUBjaXNjby5jb20NCg0KDQogICBKb2huIERyYWtlDQogICBK dW5pcGVyDQogICBFbWFpbDogamRyYWtlQGp1bmlwZXIubmV0IA0KDQoNCiAgIEppbSBVdHRhcm8N CiAgIEFUJlQNCiAgIEVtYWlsOiBqdTE3MzhAYXR0LmNvbSANCg0KDQogICBTYW1pIEJvdXRyb3MN CiAgIFZNd2FyZQ0KICAgRW1haWw6IHNib3V0cm9zQHZtd2FyZS5jb20gIA0KDQoNCiAgIEpvcmdl IFJhYmFkYW4NCiAgIE5va2lhDQogDQoNCg0KU2FqYXNzaSBldCBhbC4gICAgICAgICAgICBFeHBp cmVzIE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJTlRFUk5FVCBE UkFGVCAgICAgRS1UUkVFIFN1cHBvcnQgaW4gRVZQTiAmIFBCQi1FVlBOICAgRGVjZW1iZXIgMjAs IDIwMTYNCg0KDQogICBFbWFpbDogam9yZ2UucmFiYWRhbkBub2tpYS5jb20gDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2FqYXNzaSBldCBhbC4gICAgICAgICAg ICBFeHBpcmVzIE1heSAyMCwgMjAxNyAgICAgICAgICAgICAgICAgW1BhZ2UgMTldDQo= --_004_D49D34031C82F7sajassiciscocom_-- From nobody Fri Jan 13 01:22:45 2017 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 087A1129489 for ; Fri, 13 Jan 2017 01:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 ORbI1zTZybL4 for ; Fri, 13 Jan 2017 01:22:40 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C4A411270B4 for ; Fri, 13 Jan 2017 01:22:38 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 861575D8AF8; Fri, 13 Jan 2017 10:22:37 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 744595D8AC8; Fri, 13 Jan 2017 10:22:37 +0100 (CET) Received: from [172.31.0.98] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Fri, 13 Jan 2017 10:22:35 +0100 To: "Ali Sajassi (sajassi)" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> From: Thomas Morin Organization: Orange Message-ID: Date: Fri, 13 Jan 2017 10:22:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C09E83613DCA5C75E63CD82E" 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: Fri, 13 Jan 2017 09:22:44 -0000 --------------C09E83613DCA5C75E63CD82E Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, One comment on what seems to me the last pending issue. Ali: >>Thomas: > I think that this explanation is too elliptic compared to the strong > ("not viable") conclusion. As soon as we talk about implementation > details, a more detailed discussion is required on why, and under > which assumptions, some things are impossible -- there can be many > different way to implement a dataplane. Without explaining what "two > lookups" exactly means in this context, it's hard to follow why it > would be required if duplicating MAC addresses is not done, and why it > is latter concluded as "not viable": > - doing multiple lookups is something that is far from being uncommon > on router platforms > - on software platforms the impact of doing multiple lookups can be > reduced to mostly zero (e.g. with OpenVSwitch that would only impact > the first packets of a flow) > - if the dataplane can leverage the colouring information to avoid > doing two lookups, then perhaps this hardware ability can be leveraged > to support the two MAC-VRFs approach with only one lookup (building > one table, marking MAC entries as Leaf entries if they were learned > with routes carrying only the Leaf RT?) --- don't misunderstand me: > I'm not claiming that this works (I haven't looked closely enough), > but simply that the text provided is not sufficient to exclude this > kind of solution > > The "duplicating MAC addresses" alternative is explained better, but > still, nothing is explained on why this is "not viable". It seems to > be as something rather belonging to the realm of "having a scalability > impact", but even looking in this respect we are not talking about a > change of order of magnitude. > > The non-viable conclusion was based on investigation that I did for > micro-code and ASIC based platforms; however, I see your point and I > am para-phrasing the sentence as follow to leave room for > future investigation. > "In order to avoid two MAC-VRFs, this draft introduces the coloring > option (B) as detailed in section 3.1" > This is better, but: - the text still makes a statement that either two lookups or duplicating MACs is required, without much explanation - the logic is not consolidated: if either X or Y is required, then its illogical to say "In order to avoid X, this drafts introduces Z...." (Z being different than Y) - the text still misses an explanation on why avoiding two MAC-VRFs was desired If we can't (or don't want to spend time on) explaining the details on why something else than "two MAC RVFs" was deemed useful, then perhaps we could simplify the whole paragraph into something like: Because option (A) is not believed to be implementable without dataplane performance inefficiencies some platforms, this drafts introduces the coloring option (B) in section 3.1. Best, -Thomas 2017-01-13, Ali Sajassi (sajassi): > > > > Hi Ali, > > 2016-12-19, Ali Sajassi (sajassi): >> I have modified section 2.2 (copied below) to elaborate why coloring >> approach for Leaf/Root MAC addresses is used in this draft. Also, the >> use of single RT for this scenario is mentioned just as “MAY”. Please >> review the text below and let me know if you still have >> questions/comments: > > Thanks for providing text that goes in the right direction. > I still have a few comments below. > > -Thomas > > >> >> 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 a Root AC or a Leaf AC >> (but not both). >> >> >> +---------+ +---------+ >> | 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, just like the previous scenario (in section 2.1), >> two Route Targets (one for Root and another for Leaf) can be used. >> However, the difference is that on a PE with both Root and Leaf ACs, >> all remote MAC routes are imported and thus there needs to be a way >> to differentiate remote MAC routes associated with Leaf ACs versus >> the ones associated with Root ACs in order to apply the proper >> ingress filtering. >> >> In order to support such ingress filtering on the ingress PE with >> both Leaf and Root ACs, one the following two approaches can be used: > > reverting A and B would be more natural since solution B corresponds > to the starting point "what we had before this spec" > > Done. > >> >> A) Color MAC addresses with Leaf (or Root) color before distributing >> them in BGP to other PEs depending on whether it is learned on a Leaf > > s/it is/they are/ > > Done. > >> AC (or a Root AC) > > I think removing the parenthesis is needed for the 'whether' statement > to parse. > > Done. >> >> B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs >> and another for Leaf ACs. > > I think "(two bridge tables per VLANs)" is inexact: "two bridge > tables per VLAN if a given VLAN exists on the PE for both Leaf and > Root ACs of a given EVI" ? > > That’s fine. Done! > > > Similarly, in the following paragraph, I think "per VLAN" should be > replaced by "per E-TREE EVI having both Root and Leaf ACs". > > A single EVI can consist of many VLANs (in case of VLAN-aware bundle > service), so, “per VLAN” is right. However, to make it more exact as > above, I’ll change it to “per VLAN (when both Root and Leafs ACs exist > for that VLAN) requires …”. > > > >> >> Maintaining two bridge tables per VLAN requires either two lookups be >> performed per MAC address in either direction in case of a miss, or >> duplicating many MAC addresses between the two bridge tables >> belonging to the same VLAN (same E-TREE instance). The duplication of >> MAC addresses are need for both locally learned and remotely learned >> MAC addresses. > > Since it is said above "Maintaining two bridge tables per VLAN > requires either two lookups [...] or duplicating many MAC addresses > [...]", saying "The duplication of MAC addresses is needed for [...]" > is surprising, so I guess the intent is rather "Unless two lookups are > made, duplication of MAC addresses would be needed for [...]". > > That is correct. I’ll change it to the sentence that you > suggested: “Unless two lookups are made, …" > > >> Locally learned MAC addresses from Leaf ACs need to be >> duplicated onto Root bridge table and locally learned MAC addresses >> from Root ACs need to be duplicated onto Leaf bridge table. Remotely >> learned MAC addresses from Root ACs need to be copied onto both Root >> and Leaf bridge tables. >> Neither double lookups nor MAC duplications >> are considered viable options; therefore, this draft recommends the >> use of MAC address coloring for this scenario as detailed in section >> 3.1. > > > I think that this explanation is too elliptic compared to the strong > ("not viable") conclusion. As soon as we talk about implementation > details, a more detailed discussion is required on why, and under > which assumptions, some things are impossible -- there can be many > different way to implement a dataplane. Without explaining what "two > lookups" exactly means in this context, it's hard to follow why it > would be required if duplicating MAC addresses is not done, and why it > is latter concluded as "not viable": > - doing multiple lookups is something that is far from being uncommon > on router platforms > - on software platforms the impact of doing multiple lookups can be > reduced to mostly zero (e.g. with OpenVSwitch that would only impact > the first packets of a flow) > - if the dataplane can leverage the colouring information to avoid > doing two lookups, then perhaps this hardware ability can be leveraged > to support the two MAC-VRFs approach with only one lookup (building > one table, marking MAC entries as Leaf entries if they were learned > with routes carrying only the Leaf RT?) --- don't misunderstand me: > I'm not claiming that this works (I haven't looked closely enough), > but simply that the text provided is not sufficient to exclude this > kind of solution > > The "duplicating MAC addresses" alternative is explained better, but > still, nothing is explained on why this is "not viable". It seems to > be as something rather belonging to the realm of "having a scalability > impact", but even looking in this respect we are not talking about a > change of order of magnitude. > > The non-viable conclusion was based on investigation that I did for > micro-code and ASIC based platforms; however, I see your point and I > am para-phrasing the sentence as follow to leave room for > future investigation. > "In order to avoid two MAC-VRFs, this draft introduces the coloring > option (B) as detailed in section 3.1" > > >> >> For this scenario, if for a given EVI, the vast majority of PEs will >> have both Leaf and Root sites attached, even though they may start as >> Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in >> order to alleviate additional configuration overhead associated with > > "to alleviate additional configuration overhead associated with ..." > -> "to alleviate the configuration overhead associated with ..." ? > > Done. > >> using two RTs per EVI at the expense of having unwanted MAC addresses >> on the Leaf-only PEs. >> >> > > > > >> >> From: Thomas Morin > > >> Organization: Orange >> Date: Thursday, December 15, 2016 at 4:12 AM >> To: Cisco Employee >, >> Loa Andersson >, "George Swallow -T >> (swallow - MBO PARTNERS INC at Cisco)" > >, Eric Rosen > >, BESS > >> Cc: Martin Vigoureux > > >> Subject: Re: shepherd review of draft-ietf-bess-evpn-etree >> >> Hi Ali, >> >> 2016-12-13, Ali Sajassi (sajassi): >>> >>> 2016-12-10, Ali Sajassi (sajassi): >>>> Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, >>>> impacts lot more sections than just section 2.2 for which you >>>> suggested some texts. It drastically impacts section 3.1 (known >>>> unicast traffic), and it also impacts section 3.2 (BUM traffic) and >>>> section 5.1. >>> >>> Can you detail why ? >>> The understanding that leads me to this suggestion is that the >>> 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in >>> a 2.2.1 would not require new procotol procedures nor changes in the >>> text that as I understand provides procedures for 2.2(.2) and 2.3. >>> 2nd try. As my 1st response got truncated for some reason. >>> >>> The reason that impacts more sections than just sec. 2, is that the >>> proposed 2.2.1 would be an alternative option for section 3.1. In >>> section 3.1, the root/leaf indication for MAC addresses are done via >>> flag-bit defined in section 5.1 and it only uses a single MAC-VRF >>> (single bridge table per VLAN) per RFC 7432. If we go with two >>> MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an >>> alternative way of doing the same thing described in section 3.1. >>> This alternative way has big ramifications on the platform as it >>> requires duplicating MACs and managing multiple bridge tables per VLAN. >> >> Since 2.1 and the proposed 2.2.1 do not require new protocol >> procedures (they only require split-horizon locally in Leaf >> MAC-VRFs), if you state clearly that the procedures in the document >> are here to address 2.2.2 and 2.3, then you don't need to modify the >> content of the document after section 2 (more exactly, you will need >> minor update like changing the current "This scheme applies to all >> scenarios described in section 2." in section 3 into "This scheme >> applies to scenarios described in 2.2.2 and 2.3". >> >> The "big ramifications" above are then not about section 3, but just >> the (platform specific-drawbacks) of 2.2.2 that we have already >> discussed and that can be covered in 2.2.2. >> >>> Maybe what you really want is to allow for scenario 2.2 to operate >>> with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non >>> of the drawbacks. So, maybe we can clarify the current text to make >>> sure that this comes out clearly – ie, a PE can have single MAC–VRF >>> can have multiple RTs. >> >> You could mention that, but for me the key things is: >> - documenting the motivation for the new procedures >> - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document >> identified drawbacks) >> >>> >>>> Furthermore, it creates a new paradigm for EVPN that was never >>>> intended for because of creating two MAC-VRFs (and two bridge >>>> tables) for the same VLAN. >>> >>> The " created a new paradigm that was never >>> intended for" is a not generally valid, or sufficiently detailed, >>> argument: if it was, then you might go as far as challenging the >>> whole E-Tree spec on the same kind grounds (and many other new things). >>> >>> So here is where it seems we have a gap to bridge: I still don't >>> understand what in RFC7432 describes an intention of "not supporting >>> two MAC-VRFs for the same VLAN". >>> >>> I tried to explain the relationship between EVI, MAC-VRF, bridge >>> table, and VLAN in my previous email per RFC 7432. However, lets >>> park this discussion for time being as I think it is secondary. >> >> Ok, feel free to revisit if you think that RFC7432 would preclude >> procedures that end up being described in this draft >> >>> I think you agree that if we have a single solution that has all the >>> benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, >>> it is much more preferable with having two solutions each with its >>> own advantages and draw backs, right? If so, then existing text in >>> 2.2 was intended to convey that. However, we can clarify it >>> further – e.g, make it clear that for PE with root & leaf in >>> the same EVI, we can use a single MAC-VRF with two RTs (one for leaf >>> and another for root). >> >> As said above my key concern is having the document clearly spell out >> the motivation for new specs. >> If this implies documenting the fact that already existing procedure >> can be used, but have drawbacks, then so be it ; there would be no >> point in hiding that, right ? >> >> >>> >>>> The WG LC was completed on 3/29/16 and I am sure it is not your >>>> intention to have major changes to the doc at this stage where >>>> multiple vendors have already implemented the draft. >>> >>> As you know, there are different stages at which people do reviews >>> on a doc after WGLC, an which may lead doc editors to introduce >>> significant --editorial or technical-- changes in a document. >>> Sometimes that leads to documents going back to the working group. >>> >>> However my root intention as doc shepherd, of course, is not to >>> propose a major change, but merely to able to answer the standard >>> question of the shepherd review -- on the reviews done, on document >>> readiness, and on the document quality -- in a way as positive and >>> sincere as possible. In particular questions (3) (4) and (6). >>> >>> So, hopefully the answers to these three questions are now >>> clear. I believe your main concern is to ensure that we can apply >>> two-RT approach of sec. 2.1 to sec. 2.2 (and we can still do and >>> still have a single MAC-VRF) >> >> See above. >> >>> >>> >>>> This draft talks about two kinds of traffic filtering: a) ingress >>>> filtering for known unicast and b) egress filtering for BUM >>>> traffic. What you are suggesting is an alternate mechanism for >>>> ingress filtering. >>> >>> (well I'm not suggesting the mechanism itself --which section 2.1 >>> already does-- but simply to document that it can still apply >>> without the constraint of avoiding the presence of a Root MAC-VRF >>> and a Leaf MAC-VRF on a same PE) >>> >>>> Although having multiple VRFs (and forwarding tables) are fine for >>>> IP-VPNs because the unknown traffic is always dropped, multiple >>>> VRFs for the same VLAN is not OK for L2 traffic because of flooding >>>> of unknown traffic. That’s why in section 6 of RFC 7432, for all >>>> service interface types, the draft talks about a single MAC-VRF per >>>> EVI per PE and in case of VLAN-aware mode, multiple VLANs per >>>> MAC-VRF but only a single bridge table per VLAN. In other words, >>>> the bottom line is that there can only be a single bridge table per >>>> VLAN in order to avoid unnecessary flooding. >>> >>> >>> >>>> When you have two MAC-VRFs per VLAN (one for root ACs and another >>>> for Leaf ACs), then you either need to duplicate lots of MAC >>>> addresses between these two VRFs, or do lookup on both of these >>>> VRFs. Either ways this is not a good option relative to keeping a >>>> single VRF table for both root and leaf sites and just have a >>>> single-bit indication on whether a MAC is associated with root or >>>> leaf (as currently described approach in the draft). I >>> >>> >>> In the above, it seems you agree that it can work, and you are able >>> to offer reasons why it is not the preferred option, then why not >>> just document that it can work and provides these reasons as the >>> motivations that lead to proposing a new specs ? >>> >>> Sure, I can do that. [...] >> >> Ok. >> I'll be happy to review a new revision and hopefully post the >> shepherd review. >> >> Thanks, >> >> -Thomas >> >> >>> >>> (it seems you have an unfinished last sentence: "I [...]" ) >>> >>> >>>> >>>>>> >>>>>> (assuming the previous point is resolved:) >>>>>> >>>>>> With this mechanism above, isn't it possible to have on a given >>>>>> PE, for a single E-TREE EVI, both Leaves and Roots, as long as >>>>>> distinct MAC-VRFs are used (one for Leaves and one for Roots) ? >>>>>> (it seems to me that the 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) >>>>>> >>>>>> >>>>>> That’s 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 something). >>>>> And that seems a completely arbitrary restriction. >>>>> (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 how many MAC-VRF (and bridge >>>>> tables) can be per EVI. >>>> >>>> This section of RFC7434 discusses many different things for the >>>> different variants. >>>> Can you provide a specific pointer about "how many MAC-VRFs can be >>>> per EVI" ? >>>> >>>> Ali> Section 6 of RFC7432 spells out the relationship between EVI, >>>> MAC-VRF, and bridge tables for all service interfaces very clearly. >>>> In all service interfaces, the RFC says there is one MAC-VRF per >>>> EVI on a given PE. >>>> Now, if the service interface is “vlan-aware”, then there are >>>> several bridge tables for that single MAC-VRF – ie, one bridge >>>> table per VLAN. In all service interfaces, you can ONLY have one >>>> bridge table per VLAN. >>> >>> This answer is everything but a specific pointer. >>> If Section 6 of RFC7432 says all this very clearly, I guess it >>> should be possible to extract quotes about "there is one MAC-VRF per >>> EVI on a given PE", right ? >>> >>> >>>> >>>>> In bridging world, there can only be a single bridge table per >>>>> VLAN in a device. >>>> >>>> I still don't find here anything that would preclude having, on a >>>> given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots >>>> MAC-VRF: can't these two MAC-VRFs use different internal VLANs >>>> (with translation if the external VLANs are constrained). >>>> >>>> Ali> Lets assume we are using vlan-based service and thus there is >>>> only a single bridge table per MAC-VRF, then what you are >>>> suggesting is two use two MAC-VRFs (two bridge tables) for the same >>>> EVI (same VLAN). This results in some duplications of MAC addresses >>>> and would only work if flooding is disabled (more on this later). >>> >>> "results in some duplications of MAC" is perhaps a drawback, but >>> nothing like "just does not work" ? >>> >>> "would only work if flooding is disabled": why ? (you wrote "(more >>> on this later)" but I couldn't identify anything recent from you in >>> the rest of the email below) >>> >>> >>> From an helicopter view, I can't see what fundamentally would become >>> problematic between "two MAC-VRFs on two distinct PEs" and the same >>> "two MAC-VRFs on a same PEs", at worse it is as efficient or as >>> inefficient as having them on separate PEs (think logical router >>> without anykind of dataplane optimisation), and we can't exclude >>> that the PE could have local implementation details to do better >>> than that. >>> >>> >>>>> >>>>>> Besides, I don’t 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 replicating all the MAC addresses associated with >>>>> the root sites in two bridge tables. >>>> >>>> Your point above certainly does not sound to me as "it can't be >>>> done": some may think that the above is an acceptable cost, some >>>> others may find ways to make this "replication" with a low >>>> overhead, on some platforms the cost may be negligible, etc. >>>> >>>> >>>>> >>>>> >>>>>> 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 implement a shortcut not >>>>> involving MPLS encap/decap). >>>>> >>>>> Anything is possible but at what cost. >>>> >>>> You know, for cost it is not always obvious to reach conclusions >>>> that are true for all implementations and all targets. >>>> >>>>> The current proposal is very efficient in terms of forwarding path >>>>> as well as control plane. >>>> >>>> Sure, but what I question is not the new solution but the lack of >>>> discussion on why using the existing specs was not considered good >>>> enough. >>>> >>>> >>>> I think that my concern of clearly explaining the scenarios and >>>> motivations for this new spec could be addressed by splitting >>>> section 2.2 into a 2.2.1 describing the approach from 2.1 and its >>>> possible drawbacks, and a 2.2.2 having essentially the content of >>>> current section 2.2. >>>> >>>> Here is a proposal: >>>> >>>> 2.2 Scenario 2: Leaf of Root site(s) per AC >>>> >>>> In these scenarii, 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 Root(s) >>>> or Leaf(s) (but not both). >>>> >>>> 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root >>>> MAC-VRFs >>>> >>>> +---------+ +---------+ >>>> | PE1 | | PE2 | >>>> +---+ | +---+ | +------+ | +---+ | +---+ >>>> |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| >>>> +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ >>>> | |VRF| | | /IP | | '---' | >>>> | | | | | | | .---. | >>>> | | | | | | | |MAC| | +---+ >>>> | | | | | | | |VRF+--+---ES2/AC2--+CE3| >>>> | +---+ | +------+ | +---+ | (Root) +---+ >>>> +---------+ +---------+ >>>> >>>> Figure 2: Scenario 2a >>>> >>>> In this scenario, the RT constraint procedures described in >>>> section 2.1 could >>>> also be used. The feasibility and efficiency of this approach >>>> depends on >>>> platforms specifics. >>>> >>>> This approach will lead toduplication of a large proportion of >>>> MAC addresseson >>>> PEs having both Leaf and Root sites, and is hence considered >>>> less suitable for >>>> deployment contexts where the vast majority of PEs are likely to >>>> ultimately >>>> have both Leaf and Root sites attached to them. >>>> >>>> 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF >>>> >>>> +---------+ +---------+ >>>> | PE1 | | PE2 | >>>> +---+ | +---+ | +------+ | +---+ | +---+ >>>> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >>>> +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ >>>> | |VRF| | | /IP | | |VRF| | >>>> | | | | | | | | | | +---+ >>>> | | | | | | | | +--+---ES2/AC2--+CE3| >>>> | +---+ | +------+ | +---+ | (Root) +---+ >>>> +---------+ +---------+ >>>> >>>> Figure 2: Scenario 2b >>>> >>>> This scenario will alleviate keys drawbacks from Scenario 2a, in >>>> particular >>>> by avoiding duplication of MAC addresses on Leaf/Root PEs and >>>> avoiding the >>>> operational overhead of managing more than one RT. >>>> This approach comes at the expense of having routes for unneeded >>>> MAC addresses on Leaf-only PEs, and is hence considered less >>>> suitable for deployment contexts where the vast majority of PEs >>>> would remain Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures >>>> provided in this document. >>>> >>>> >>>> (And this last sentence should be added to section 2.3 as well) >>>> >>>>> >>>>>>> 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 “majority” to “vast majority” :-) >>>>> >>>>> 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 >>>>> identified: having useless routes on the fraction of PEs having >>>>> only Leaves. >>>>> But the gain brought by the recommendation is not even mentioned, >>>>> not to say explained. >>>>> Hence: why ? >>>>> (Why is it a useful tradeoff to have useless routes on some, even >>>>> if only one, PE ?) >>>>> >>>>> Changed the last sentence from: >>>>> "then it is recommended to use a single RT per EVI and avoid >>>>> additional configuration and operational overhead.” >>>>> To >>>>> "then it is recommended to use a single RT per EVI and avoid >>>>> additional configuration and operational overhead >>>>> at the expense of having unwanted MAC addresses on the Leaf PEs." >>>> >>>> Ok. I adapted and incorporated this addition into my proposed text >>>> splitting 2.2 into a 2.2.1 and a 2.2.2. >>>> >>>> Best, >>>> >>>> -Thomas >>>> >>>> >>> >> > --------------C09E83613DCA5C75E63CD82E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

One comment on what seems to me the last pending issue.

Ali:
>>Thomas:
I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on router platforms
- on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow)
- if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup  (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution

The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investigation that I did for micro-code and ASIC based platforms; however, I see your point and I am para-phrasing the sentence as follow to leave room for future investigation. 
"In order to avoid two MAC-VRFs, this draft introduces the coloring option (B) as detailed in section 3.1"


This is better, but:
- the text still makes a statement that either two lookups or duplicating MACs is required, without much explanation
- the logic is not consolidated: if either X or Y is required, then its illogical to say "In order to avoid X, this drafts introduces Z...."  (Z being different than Y)
- the text still misses an explanation on why avoiding two MAC-VRFs was desired

If we can't (or don't want to spend time on) explaining the details on why something else than "two MAC RVFs" was deemed useful, then perhaps we could simplify the whole paragraph into something like:

      Because option (A) is not believed to be implementable without dataplane performance inefficiencies some platforms, this drafts introduces the coloring option (B) in section 3.1.

Best,

-Thomas



2017-01-13, Ali Sajassi (sajassi):



Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring approach for Leaf/Root MAC addresses is used in this draft. Also, the use of single RT for this scenario is mentioned just as “MAY”. Please review the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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 a Root AC or a Leaf AC
   (but not both). 


                     +---------+            +---------+
                     |   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, just like the previous scenario (in section 2.1),
   two Route Targets (one for Root and another for Leaf) can be used.
   However, the difference is that on a PE with both Root and Leaf ACs,
   all remote MAC routes are imported and thus there needs to be a way
   to differentiate remote MAC routes associated with Leaf ACs versus
   the ones associated with Root ACs in order to apply the proper
   ingress filtering. 

   In order to support such ingress filtering on the ingress PE with
   both Leaf and Root ACs, one the following two approaches can be used:

reverting A and B would be more natural since solution B corresponds to the starting point "what we had before this spec"

Done.

   A) Color MAC addresses with Leaf (or Root) color before distributing
   them in BGP to other PEs depending on whether it is learned on a Leaf

s/it is/they are/

Done.

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to parse.

Done.

   B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "two bridge tables per VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a given EVI" ?

That’s fine. Done!


Similarly, in the following paragraph, I think "per VLAN" should be replaced by "per E-TREE EVI having both Root and Leaf ACs".

A single EVI can consist of many VLANs (in case of VLAN-aware bundle service), so, “per VLAN” is right. However, to make it more exact as above, I’ll change it to “per VLAN (when both Root and Leafs ACs exist for that VLAN) requires …”.




   Maintaining two bridge tables per VLAN requires either two lookups be
   performed per MAC address in either direction in case of a miss, or
   duplicating many MAC addresses between the two bridge tables
   belonging to the same VLAN (same E-TREE instance). The duplication of
   MAC addresses are need for both locally learned and remotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN requires either two lookups [...] or duplicating many MAC addresses [...]", saying "The duplication of MAC addresses is needed for [...]"  is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [...]".

That is correct. I’ll change it to the sentence that you suggested: “Unless two lookups are made, …"


   Locally learned MAC addresses from Leaf ACs need to be
   duplicated onto Root bridge table and locally learned MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge table. Remotely
   learned MAC addresses from Root ACs need to be copied onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft recommends the
   use of MAC address coloring for this scenario as detailed in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on router platforms
- on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow)
- if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup  (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution

The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investigation that I did for micro-code and ASIC based platforms; however, I see your point and I am para-phrasing the sentence as follow to leave room for future investigation. 
"In order to avoid two MAC-VRFs, this draft introduces the coloring option (B) as detailed in section 3.1"



   For this scenario, if for a given EVI, the vast majority of PEs will
   have both Leaf and Root sites attached, even though they may start as
   Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
   order to alleviate  additional configuration overhead associated with

"to alleviate  additional configuration overhead associated with ..." -> "to alleviate the configuration overhead associated with ..." ?

Done.

   using two RTs per EVI at the expense of having unwanted MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Thursday, December 15, 2016 at 4:12 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of draft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot more sections than just section 2.2 for which you suggested some texts. It drastically  impacts section 3.1 (known unicast traffic), and it also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the proposed 2.2.1 would be an alternative option for section 3.1. In section 3.1, the root/leaf indication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an alternative way of doing the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that the procedures in the document are here to address 2.2.2 and 2.3, then you don't need to modify the content of the document after section 2  (more exactly, you will need minor update like changing the current "This scheme applies to all scenarios described in section 2." in section 3 into "This scheme applies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but just the (platform specific-drawbacks) of 2.2.2 that we have already discussed and that can be covered in 2.2.2.

Maybe what you really want is to allow for scenario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text to make sure that this comes out clearly – ie, a PE can have single MAC–VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified drawbacks)


Furthermore, it creates a new paradigm for EVPN that was never intended for because of creating two MAC-VRFs (and two bridge tables) for the same VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN".

I tried to explain the relationship between EVI, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. However, lets park this discussion for time being as I think it is secondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedures that end up being described in this draft

I think you agree that if we have a single solution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much more preferable with having two solutions each with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. However, we can clarify it further – e.g, make it clear that for PE with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the motivation for new specs.
If this implies documenting the fact that already existing procedure can be used, but have drawbacks, then so be it ; there would be no point in hiding that, right ?



The WG LC was completed on 3/29/16 and I am sure it is not your intention to have major changes to the doc at this stage where multiple vendors have already implemented the draft.

As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three questions are now clear. I believe your main concern is to ensure that we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can still do and still have a single MAC-VRF)

See above.


This draft talks about two kinds of traffic filtering: a) ingress filtering for known unicast and b) egress filtering for BUM traffic. What you are suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE)

Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped, multiple VRFs for the same VLAN is not OK for L2 traffic because of flooding of unknown traffic. That’s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In other words, the bottom line is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf ACs), then you either need to duplicate lots of MAC addresses between these two VRFs, or do lookup on both of these VRFs. Either ways this is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit indication on whether a MAC is associated with root or leaf (as currently described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd review.

Thanks,

-Thomas



(it seems you have an unfinished last sentence: "I [...]" )


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the 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)

That’s 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 something).
And that seems a completely arbitrary restriction.
(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 how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI on a given PE.
Now, if the service interface is “vlan-aware”, then there are several bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. In all service interfaces, you can ONLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?



In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is only a single bridge table per MAC-VRF, then what you are suggesting is two use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below)


From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that.



Besides, I don’t 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 replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




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 implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

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

   In these scenarii, 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 Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 “majority” to “vast majority” :-)

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 identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

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

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------C09E83613DCA5C75E63CD82E-- From nobody Fri Jan 13 10:41:34 2017 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 08EFA129D3E for ; Fri, 13 Jan 2017 10:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 kv62u6gal1kX for ; Fri, 13 Jan 2017 10:41:28 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632D1129C73 for ; Fri, 13 Jan 2017 10:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105032; q=dns/txt; s=iport; t=1484332888; x=1485542488; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=g33A0jj81g/a+YLJNv66jWqZqq7fawU4paPOz3oP70Y=; b=jueVjaD3TW1t3sDPsbxYWrhXYM3VU4DPN6EEdtKRHcg3nUBBkJT5j1Vl mnmrELv8LQ1GqhxmfDvT2sSLsNg7tpX1NjVTKgbFIhohfJdQT10gRecBX 25bFulXW1LqY4egYgLyBShiKzfKEZBYQDgbnlxCUvXWBHPWIsavKG6JRt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDiHnlY/4kNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ1Ow8BAQEBAR+BaAeNUZIWlSqCDYJHASSDNgKCFD8UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQQaAQxFBQEBAQIDEAIBCBEDAQIhAQYHMhQJCAIEAQ0FG4hos?= =?us-ascii?q?n46K4lcAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYoggQaEFwEGCwE8GIUsBZUqhgg?= =?us-ascii?q?BiXCHaIF3hQ6DTYRjgTiIFIY+hBIBHzhxUxWEbxyBX3OGOIEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,222,1477958400"; d="scan'208,217";a="192728736" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2017 18:41:26 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0DIfP7O000859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 18:41:25 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; Fri, 13 Jan 2017 13:41:24 -0500 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, 13 Jan 2017 13:41:24 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , 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+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAAgAABy4CAAydaAIAFHy2AgBu7JwCAC1ogAIABL6yAgAAWB4A= Date: Fri, 13 Jan 2017 18:41:24 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D49E569E1C8463sajassiciscocom_" 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: Fri, 13 Jan 2017 18:41:33 -0000 --_000_D49E569E1C8463sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Please refer to the comment resolution below: From: Thomas Morin = > Organization: Orange Date: Friday, January 13, 2017 at 1:22 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, One comment on what seems to me the last pending issue. Ali: >>Thomas: I think that this explanation is too elliptic compared to the strong ("not = viable") conclusion. As soon as we talk about implementation details, a mor= e detailed discussion is required on why, and under which assumptions, some= things are impossible -- there can be many different way to implement a d= ataplane. Without explaining what "two lookups" exactly means in this conte= xt, it's hard to follow why it would be required if duplicating MAC address= es is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on ro= uter platforms - on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow) - if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup (building one table, marking= MAC entries as Leaf entries if they were learned with routes carrying only= the Leaf RT?) --- don't misunderstand me: I'm not claiming that this work= s (I haven't looked closely enough), but simply that the text provided is n= ot sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still,= nothing is explained on why this is "not viable". It seems to be as someth= ing rather belonging to the realm of "having a scalability impact", but eve= n looking in this respect we are not talking about a change of order of mag= nitude. The non-viable conclusion was based on investigation that I did for micro-c= ode and ASIC based platforms; however, I see your point and I am para-phras= ing the sentence as follow to leave room for future investigation. "In order to avoid two MAC-VRFs, this draft introduces the coloring option = (B) as detailed in section 3.1" This is better, but: - the text still makes a statement that either two lookups or duplicating M= ACs is required, without much explanation - the logic is not consolidated: if either X or Y is required, then its ill= ogical to say "In order to avoid X, this drafts introduces Z...." (Z being= different than Y) - the text still misses an explanation on why avoiding two MAC-VRFs was des= ired If we can't (or don't want to spend time on) explaining the details on why = something else than "two MAC RVFs" was deemed useful, then perhaps we could= simplify the whole paragraph into something like: Because option (A) is not believed to be implementable without datapl= ane performance inefficiencies some platforms, this drafts introduces the c= oloring option (B) in section 3.1. I modified the last sentence as below: "Because of potential inefficiencies associated with data-plane implementat= ion of additional MAC lookup or duplication of MAC entries, option (A) is n= ot believed to be implementable without dataplane performance inefficiencie= s in some platforms and thus this draft introduces the coloring option (B) = as detailed in section 3.1.=94 The logic is as follow: Option A requires either X (two MAC lookup) or Y (d= uplication of MAC entries). Because of potential data-plane inefficiencies = for X or Y (which is needed for option A), we are suggesting option B. The whole paragraph is as below: "Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf and = Root ACs exists for that VLAN) would either require two lookups be performe= d per MAC address in each direction in case of a miss, or duplicating many = MAC addresses between the two bridge tables belonging to the same VLAN (sam= e E-TREE instance). Unless two lookups are made, duplication of MAC address= es would be needed for both locally learned and remotely learned MAC addres= ses. Locally learned MAC addresses from Leaf ACs need to be duplicated onto= Root bridge table and locally learned MAC addresses from Root ACs need to = be duplicated onto Leaf bridge table. Remotely learned MAC addresses from R= oot ACs need to be copied onto both Root and Leaf bridge tables. Because of= potential inefficiencies associated with data-plane implementation of addi= tional MAC lookup or duplication of MAC entries, option (A) is not believed= to be implementable without dataplane performance inefficiencies in some p= latforms and thus this draft introduces the coloring option (B) as detailed= in section 3.1." Cheers, Ali Best, -Thomas 2017-01-13, Ali Sajassi (sajassi): Hi Ali, 2016-12-19, Ali Sajassi (sajassi): I have modified section 2.2 (copied below) to elaborate why coloring approa= ch for Leaf/Root MAC addresses is used in this draft. Also, the use of sing= le RT for this scenario is mentioned just as =93MAY=94. Please review the t= ext below and let me know if you still have questions/comments: Thanks for providing text that goes in the right direction. I still have a few comments below. -Thomas 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 a Root AC or a Leaf AC (but not both). +---------+ +---------+ | 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, just like the previous scenario (in section 2.1), two Route Targets (one for Root and another for Leaf) can be used. However, the difference is that on a PE with both Root and Leaf ACs, all remote MAC routes are imported and thus there needs to be a way to differentiate remote MAC routes associated with Leaf ACs versus the ones associated with Root ACs in order to apply the proper ingress filtering. In order to support such ingress filtering on the ingress PE with both Leaf and Root ACs, one the following two approaches can be used: reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec" Done. A) Color MAC addresses with Leaf (or Root) color before distributing them in BGP to other PEs depending on whether it is learned on a Leaf s/it is/they are/ Done. AC (or a Root AC) I think removing the parenthesis is needed for the 'whether' statement to p= arse. Done. B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs and another for Leaf ACs. I think "(two bridge tables per VLANs)" is inexact: "two bridge tables per= VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a give= n EVI" ? That=92s fine. Done! Similarly, in the following paragraph, I think "per VLAN" should be replace= d by "per E-TREE EVI having both Root and Leaf ACs". A single EVI can consist of many VLANs (in case of VLAN-aware bundle servic= e), so, =93per VLAN=94 is right. However, to make it more exact as above, I= =92ll change it to =93per VLAN (when both Root and Leafs ACs exist for that= VLAN) requires =85=94. Maintaining two bridge tables per VLAN requires either two lookups be performed per MAC address in either direction in case of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE instance). The duplication of MAC addresses are need for both locally learned and remotely learned MAC addresses. Since it is said above "Maintaining two bridge tables per VLAN requires eit= her two lookups [...] or duplicating many MAC addresses [...]", saying "The= duplication of MAC addresses is needed for [...]" is surprising, so I gue= ss the intent is rather "Unless two lookups are made, duplication of MAC ad= dresses would be needed for [...]". That is correct. I=92ll change it to the sentence that you suggested: =93Un= less two lookups are made, =85" Locally learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC addresses from Root ACs need to be duplicated onto Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Neither double lookups nor MAC duplications are considered viable options; therefore, this draft recommends the use of MAC address coloring for this scenario as detailed in section 3.1. I think that this explanation is too elliptic compared to the strong ("not = viable") conclusion. As soon as we talk about implementation details, a mor= e detailed discussion is required on why, and under which assumptions, some= things are impossible -- there can be many different way to implement a d= ataplane. Without explaining what "two lookups" exactly means in this conte= xt, it's hard to follow why it would be required if duplicating MAC address= es is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on ro= uter platforms - on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow) - if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup (building one table, marking= MAC entries as Leaf entries if they were learned with routes carrying only= the Leaf RT?) --- don't misunderstand me: I'm not claiming that this work= s (I haven't looked closely enough), but simply that the text provided is n= ot sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still,= nothing is explained on why this is "not viable". It seems to be as someth= ing rather belonging to the realm of "having a scalability impact", but eve= n looking in this respect we are not talking about a change of order of mag= nitude. The non-viable conclusion was based on investigation that I did for micro-c= ode and ASIC based platforms; however, I see your point and I am para-phras= ing the sentence as follow to leave room for future investigation. "In order to avoid two MAC-VRFs, this draft introduces the coloring option = (B) as detailed in section 3.1" For this scenario, if for a given EVI, the vast majority of PEs will have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in order to alleviate additional configuration overhead associated with "to alleviate additional configuration overhead associated with ..." -> "t= o alleviate the configuration overhead associated with ..." ? Done. using two RTs per EVI at the expense of having unwanted MAC addresses on the Leaf-only PEs. From: Thomas Morin = > Organization: Orange Date: Thursday, December 15, 2016 at 4:12 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-13, Ali Sajassi (sajassi): 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. 2nd try. As my 1st response got truncated for some reason. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2 (= more exactly, you will need minor update like changing the current "This sc= heme applies to all scenarios described in section 2." in section 3 into "T= his scheme applies to scenarios described in 2.2.2 and 2.3". The "big ramifications" above are then not about section 3, but just the (p= latform specific-drawbacks) of 2.2.2 that we have already discussed and tha= t can be covered in 2.2.2. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. You could mention that, but for me the key things is: - documenting the motivation for the new procedures - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks) Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). As said above my key concern is having the document clearly spell out the m= otivation for new specs. If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ? The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) See above. This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. [...] Ok. I'll be happy to review a new revision and hopefully post the shepherd revi= ew. Thanks, -Thomas (it seems you have an unfinished last sentence: "I [...]" ) (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. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. 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. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. 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. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, 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 Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) 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 addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D49E569E1C8463sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <473B2F204C495142B1A6C27F99781043@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Please refer to the comment resolution below:

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Friday, January 13, 2017 at 1= :22 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow= - MBO PARTNERS INC at Cisco)" <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

Hi Ali,

One comment on what seems to me the last pending issue.

Ali:
>>Thomas:
I think that this explanation is = too elliptic compared to the strong ("not viable") conclusion. As= soon as we talk about implementation details, a more detailed discussion i= s required on why, and under which assumptions, some things are impossible  -- there can be many different way to imp= lement a dataplane. Without explaining what "two lookups" exactly= means in this context, it's hard to follow why it would be required if dup= licating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on ro= uter platforms
- on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow)
- if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup  (building one table, ma= rking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't = misunderstand me: I'm not claiming that this works (I haven't looked closel= y enough), but simply that the text provided is not sufficient to exclude t= his kind of solution

The "duplicating MAC addresses" alternative is explained better, = but still, nothing is explained on why this is "not viable". It s= eems to be as something rather belonging to the realm of "having a sca= lability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investi= gation that I did for micro-code and ASIC based platforms; however, I = see your point and I am para-phrasing the sentence as follow to leave = room for future investigation. 
"In order to avoid two MAC-VRFs, this dra= ft introduces the coloring option (B) as detailed in section 3.1"


This is better, but:
- the text still makes a statement that either two lookups or duplicating M= ACs is required, without much explanation
- the logic is not consolidated: if either X or Y is required, then its ill= ogical to say "In order to avoid X, this drafts introduces Z...."=   (Z being different than Y)
- the text still misses an explanation on why avoiding two MAC-VRFs was des= ired

If we can't (or don't want to spend time on) explaining the details on why = something else than "two MAC RVFs" was deemed useful, then perhap= s we could simplify the whole paragraph into something like:

      Because option (A) is not believed to be imp= lementable without dataplane performance inefficiencies some platforms, thi= s drafts introduces the coloring option (B) in section 3.1.

I modified the last sentence as below:<= /div>
"Because of potential inefficiencies asso= ciated with data-plane implementation of additional MAC lookup or duplicati= on of MAC entries, option (A) is not believed to be implementable without d= ataplane performance inefficiencies in some platforms and thus this draft introduces the coloring option (B) as d= etailed in section 3.1.=94

The logic is as follow: Option A requires= either X (two MAC lookup) or Y (duplication of MAC entries). Because = of potential data-plane inefficiencies for X or Y (which is needed for=  option A), we are suggesting option B.

The whole paragraph is as below:
"Maintaining two MAC-VRFs (two bridge tab= les) per VLAN (when both Leaf and Root ACs exists for that VLAN) would eith= er require two lookups be performed per MAC address in each direction in ca= se of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE inst= ance). Unless two lookups are made, duplication of MAC addresses would be n= eeded for both locally learned and remotely learned MAC addresses. Locally = learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC a= ddresses from Root ACs need to be duplicated onto Leaf bridge table. Remote= ly learned MAC addresses from Root ACs need to be copied onto both Root and= Leaf bridge tables. Because of potential inefficiencies associated with data-plane implementation of addi= tional MAC lookup or duplication of MAC entries, option (A) is not believed= to be implementable without dataplane performance inefficiencies in some p= latforms and thus this draft introduces the coloring option (B) as detailed in section 3.1."

Cheers,
Ali


Best,

-Thomas



2017-01-13, Ali Sajassi (sajassi):



Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring a= pproach for Leaf/Root MAC addresses is used in this draft. Also, the use of= single RT for this scenario is mentioned just as =93MAY=94. Please review = the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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

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


                  &nb= sp;  +---------+            += ;---------+
                  &nb= sp;  |   PE1   |            | =   PE2   |
    +---+           &nb= sp;|  +---+  |  +------+  |  += ---+  |            +---+
    |CE1+-----ES1----+--+   |  | &= nbsp;|      |  |  |   +--+---ES2/AC1-= -+CE2|
    +---+    (Leaf)  |  |MAC= |  |  | MPLS |  |  |MAC|  |   (Leaf)   &= #43;---+
                  &nb= sp;  |  |VRF|  |  |  /IP |  |  |VRF| &nb= sp;|
                  &nb= sp;  |  |   |  |  |      |  | =  |   |  |            +---&= #43;
                  &nb= sp;  |  |   |  |  |      |  | =  |   +--+---ES2/AC2--+CE3|
                  &nb= sp;  |  +---+  |  +------+  | &nbs= p;+---+  |   (Root)   +---+
                  &nb= sp;  +---------+            += ;---------+

   Figure 2: Scenario 2

   In this scenario, just like the previous scenario (in= section 2.1),
   two Route Targets (one for Root and another for Leaf)= can be used.
   However, the difference is that on a PE with both Roo= t and Leaf ACs,
   all remote MAC routes are imported and thus there nee= ds to be a way
   to differentiate remote MAC routes associated with Le= af ACs versus
   the ones associated with Root ACs in order to apply t= he proper
   ingress filtering. 

   In order to support such ingress filtering on the ing= ress PE with
   both Leaf and Root ACs, one the following two approac= hes can be used:

reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec"

Done.

   A) Color MAC addresses with Leaf (or Root) color befo= re distributing
   them in BGP to other PEs depending on whether it is l= earned on a Leaf

s/it is/they are/

Done.

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to p= arse.

Done.

   B) Use two MAC-VRFs (two bridge tables per VLANs) - o= ne for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "t= wo bridge tables per VLAN if a given VLAN exists on the PE for both Leaf an= d Root ACs of a given EVI" ?

That=92s fin= e. Done!


Similarly, in the following paragraph, I think "per VLAN" should = be replaced by "per E-TREE EVI having both Root and Leaf ACs".

A single EVI can consist of many VLANs (in cas= e of VLAN-aware bundle service), so, =93per VLAN=94 is right. However,= to make it more exact as above, I=92ll change it to =93per = VLAN (when both Root and Leafs ACs exist for that VLAN) requires = =85=94.




   Maintaining two bridge tables per VLAN requires eithe= r two lookups be
   performed per MAC address in either direction in case= of a miss, or
   duplicating many MAC addresses between the two bridge= tables
   belonging to the same VLAN (same E-TREE instance). Th= e duplication of
   MAC addresses are need for both locally learned and r= emotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN require= s either two lookups [...] or duplicating many MAC addresses [...]", s= aying "The duplication of MAC addresses is needed for [...]" = ; is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [..= .]".

That is correct. I=92ll change it to the&= nbsp;sentence that you suggested: =93Unless two lookups are made, = ;=85"


   Locally learned MAC addresses from Leaf ACs need to b= e
   duplicated onto Root bridge table and locally learned= MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge = table. Remotely
   learned MAC addresses from Root ACs need to be copied= onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft = recommends the
   use of MAC address coloring for this scenario as deta= iled in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("= ;not viable") conclusion. As soon as we talk about implementation deta= ils, a more detailed discussion is required on why, and under which assumpt= ions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining wha= t "two lookups" exactly means in this context, it's hard to follo= w why it would be required if duplicating MAC addresses is not done, and wh= y it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on ro= uter platforms
- on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow)
- if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup  (building one table, ma= rking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't = misunderstand me: I'm not claiming that this works (I haven't looked closel= y enough), but simply that the text provided is not sufficient to exclude t= his kind of solution

The "duplicating MAC addresses" alternative is explained better, = but still, nothing is explained on why this is "not viable". It s= eems to be as something rather belonging to the realm of "having a sca= lability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investi= gation that I did for micro-code and ASIC based platforms; however, I = see your point and I am para-phrasing the sentence as follow to leave = room for future investigation. 
"In order to avoid two MAC-VRFs, this dra= ft introduces the coloring option (B) as detailed in section 3.1"



   For this scenario, if for a given EVI, the vast major= ity of PEs will
   have both Leaf and Root sites attached, even though t= hey may start as
   Root-only or Leaf-only PEs, then a single RT per EVI = MAY be used in
   order to alleviate  additional configuration ove= rhead associated with

"to alleviate  additional configuration overhead associated with = ..." -> "to alleviate the configuration overhead associated wi= th ..." ?

Done.

   using two RTs per EVI at the expense of having unwant= ed MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange= .com>
Organization: Orange
Date: Thursday, December 15, 2016 a= t 4:12 AM
To: Cisco Employee <sajassi@cisco.com>= , Loa Andersson <l= oa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS = <bess@ietf.org= >
Cc: Martin Vigoureux <martin.vigoure= ux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2  (more exactly, you will need= minor update like changing the current "This scheme applies to all sc= enarios described in section 2." in section 3 into "This scheme a= pplies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but j= ust the (platform specific-drawbacks) of 2.2.2 that we have already discuss= ed and that can be covered in 2.2.2.

=
Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks)

=

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft

=
I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the m= otivation for new specs.
If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ?


=

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF)

See above.
=


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd revi= ew.

Thanks,

-Thomas


=

(it seems you have an unfinished last sentence: "I [...]" )


=


(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.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?


=

In bridging world, there can only b= e a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

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 logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




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 th= ey *have* to be in the same MAC-VRF, you can rely on the local MPLS datapla= ne inside the PE to carry the traffic between Roots and Leaves can be passe= d between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implement a shortcut not involving MPLS enca= p/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

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

   In these s= cenarii, a PE receives traffic from either Root OR Leaf
   sites (but= not both) on a given Attachment Circuit (AC) of an EVI. In
   other word= s, an AC (ES or ES/VLAN) is either associated with Root(s)
   or Leaf(s)= (but not both).

2.2.1 Scenario 2a: Leaf= OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

    = ;            &n= bsp;    +---------+     &nb= sp;      +---------+
    = ;            &n= bsp;    |   PE1   |   &nb= sp;        |   PE2  = |
    += ;---+           = |  +---+  |  +------+  |  +--= -+  |          &= nbsp; +---+
    |CE1= +-----ES1----+--+   |  |  |  &nbs= p;   |  |  |MAC+--+---ES2/AC1--+CE2|
    += ;---+    (Leaf)  |  |MAC|  |  | MPLS= |  |  |VRF|  |   (Leaf)   +---+=
    = ;            &n= bsp;    |  |VRF|  |  |  /IP |  |&nb= sp; '---'  |
    = ;            &n= bsp;    |  |   |  |  |  &= nbsp;   |  |  .---.  |
    = ;            &n= bsp;    |  |   |  |  |  &= nbsp;   |  |  |MAC|  |    &nbs= p;       +---+
    = ;            &n= bsp;    |  |   |  |  |  &= nbsp;   |  |  |VRF+--+---ES2/AC2--+CE3|
    = ;            &n= bsp;    |  +---+  |  +------+=   |  +---+  |   (Root)   +--= -+
    = ;            &n= bsp;    +---------+     &nb= sp;      +---------+

   Figure 2: = Scenario 2a

   In this sc= enario, the RT constraint procedures described in section 2.1 could
   also be us= ed. The feasibility and efficiency of this approach depends on
   platforms = specifics.

   This appro= ach will lead toduplication of a la= rge proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
   have both = Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf= OR Root site(s) per AC, single MAC-VRF

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

   Figure 2: = Scenario 2b

   This scena= rio will alleviate keys drawbacks from Scenario 2a, in particular
   by avoidin= g duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead o= f managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 "majority", but was that you should= explain why you recommend that.
As the text currently reads, the cost of the recommendation can be identified= : having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to say e= xplained.
Hence: why ?
(Why is it a useful tradeoff to have 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."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas






 --_000_D49E569E1C8463sajassiciscocom_-- From nobody Fri Jan 13 12:33:21 2017 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 4B9EF129E17 for ; Fri, 13 Jan 2017 12:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 IMPE0eMWROdq for ; Fri, 13 Jan 2017 12:33:15 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D168129E13 for ; Fri, 13 Jan 2017 12:33:13 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 38A7C5D8B22; Fri, 13 Jan 2017 21:33:12 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 263BD5D8B20; Fri, 13 Jan 2017 21:33:12 +0100 (CET) Received: from [172.31.0.98] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Fri, 13 Jan 2017 21:33:09 +0100 To: "Ali Sajassi (sajassi)" , Loa Andersson , "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> From: Thomas Morin Organization: Orange Message-ID: <6ba88792-47ca-8008-d848-95b469ea8a5c@orange.com> Date: Fri, 13 Jan 2017 21:33:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------18DCC66B8039D19356E63979" 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: Fri, 13 Jan 2017 20:33:20 -0000 --------------18DCC66B8039D19356E63979 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, I'm fine with the new text, thanks for the work on addressing my comments. You can post a revision and I will wrap-up the shepherd review in parallel. Best, -Thomas 2017-01-13, Ali Sajassi (sajassi): > Hi Thomas, > > Please refer to the comment resolution below: > > From: Thomas Morin > > Organization: Orange > Date: Friday, January 13, 2017 at 1:22 AM > To: Cisco Employee >, Loa > Andersson >, "George Swallow -T (swallow > - MBO PARTNERS INC at Cisco)" >, Eric Rosen >, BESS > > Cc: Martin Vigoureux > > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree > > Hi Ali, > > One comment on what seems to me the last pending issue. > > Ali: > >>Thomas: >> I think that this explanation is too elliptic compared to the strong >> ("not viable") conclusion. As soon as we talk about implementation >> details, a more detailed discussion is required on why, and under >> which assumptions, some things are impossible -- there can be many >> different way to implement a dataplane. Without explaining what "two >> lookups" exactly means in this context, it's hard to follow why it >> would be required if duplicating MAC addresses is not done, and why >> it is latter concluded as "not viable": >> - doing multiple lookups is something that is far from being uncommon >> on router platforms >> - on software platforms the impact of doing multiple lookups can be >> reduced to mostly zero (e.g. with OpenVSwitch that would only impact >> the first packets of a flow) >> - if the dataplane can leverage the colouring information to avoid >> doing two lookups, then perhaps this hardware ability can be >> leveraged to support the two MAC-VRFs approach with only one lookup >> (building one table, marking MAC entries as Leaf entries if they were >> learned with routes carrying only the Leaf RT?) --- don't >> misunderstand me: I'm not claiming that this works (I haven't looked >> closely enough), but simply that the text provided is not sufficient >> to exclude this kind of solution >> >> The "duplicating MAC addresses" alternative is explained better, but >> still, nothing is explained on why this is "not viable". It seems to >> be as something rather belonging to the realm of "having a >> scalability impact", but even looking in this respect we are not >> talking about a change of order of magnitude. >> >> The non-viable conclusion was based on investigation that I did for >> micro-code and ASIC based platforms; however, I see your point and I >> am para-phrasing the sentence as follow to leave room for >> future investigation. >> "In order to avoid two MAC-VRFs, this draft introduces the coloring >> option (B) as detailed in section 3.1" >> > > This is better, but: > - the text still makes a statement that either two lookups or > duplicating MACs is required, without much explanation > - the logic is not consolidated: if either X or Y is required, then > its illogical to say "In order to avoid X, this drafts introduces > Z...." (Z being different than Y) > - the text still misses an explanation on why avoiding two MAC-VRFs > was desired > > If we can't (or don't want to spend time on) explaining the details on > why something else than "two MAC RVFs" was deemed useful, then perhaps > we could simplify the whole paragraph into something like: > > Because option (A) is not believed to be implementable without > dataplane performance inefficiencies some platforms, this drafts > introduces the coloring option (B) in section 3.1. > > I modified the last sentence as below: > "Because of potential inefficiencies associated with data-plane > implementation of additional MAC lookup or duplication of MAC entries, > option (A) is not believed to be implementable without dataplane > performance inefficiencies in some platforms and thus this draft > introduces the coloring option (B) as detailed in section 3.1.” > > The logic is as follow: Option A requires either X (two MAC lookup) or > Y (duplication of MAC entries). Because of potential data-plane > inefficiencies for X or Y (which is needed for option A), we are > suggesting option B. > > The whole paragraph is as below: > "Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf > and Root ACs exists for that VLAN) would either require two lookups be > performed per MAC address in each direction in case of a miss, or > duplicating many MAC addresses between the two bridge tables belonging > to the same VLAN (same E-TREE instance). Unless two lookups are made, > duplication of MAC addresses would be needed for both locally learned > and remotely learned MAC addresses. Locally learned MAC addresses from > Leaf ACs need to be duplicated onto Root bridge table and locally > learned MAC addresses from Root ACs need to be duplicated onto Leaf > bridge table. Remotely learned MAC addresses from Root ACs need to be > copied onto both Root and Leaf bridge tables. Because of potential > inefficiencies associated with data-plane implementation of additional > MAC lookup or duplication of MAC entries, option (A) is not believed > to be implementable without dataplane performance inefficiencies in > some platforms and thus this draft introduces the coloring option (B) > as detailed in section 3.1." > > Cheers, > Ali > > > Best, > > -Thomas > > > > 2017-01-13, Ali Sajassi (sajassi): >> >> >> >> Hi Ali, >> >> 2016-12-19, Ali Sajassi (sajassi): >>> I have modified section 2.2 (copied below) to elaborate why coloring >>> approach for Leaf/Root MAC addresses is used in this draft. Also, >>> the use of single RT for this scenario is mentioned just as “MAY”. >>> Please review the text below and let me know if you still have >>> questions/comments: >> >> Thanks for providing text that goes in the right direction. >> I still have a few comments below. >> >> -Thomas >> >> >>> >>> 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 a Root AC or a Leaf AC >>> (but not both). >>> >>> >>> +---------+ +---------+ >>> | 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, just like the previous scenario (in section 2.1), >>> two Route Targets (one for Root and another for Leaf) can be used. >>> However, the difference is that on a PE with both Root and Leaf ACs, >>> all remote MAC routes are imported and thus there needs to be a way >>> to differentiate remote MAC routes associated with Leaf ACs versus >>> the ones associated with Root ACs in order to apply the proper >>> ingress filtering. >>> >>> In order to support such ingress filtering on the ingress PE with >>> both Leaf and Root ACs, one the following two approaches can be used: >> >> reverting A and B would be more natural since solution B corresponds >> to the starting point "what we had before this spec" >> >> Done. >> >>> >>> A) Color MAC addresses with Leaf (or Root) color before distributing >>> them in BGP to other PEs depending on whether it is learned on a Leaf >> >> s/it is/they are/ >> >> Done. >> >>> AC (or a Root AC) >> >> I think removing the parenthesis is needed for the 'whether' >> statement to parse. >> >> Done. >>> >>> B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs >>> and another for Leaf ACs. >> >> I think "(two bridge tables per VLANs)" is inexact: "two bridge >> tables per VLAN if a given VLAN exists on the PE for both Leaf and >> Root ACs of a given EVI" ? >> >> That’s fine. Done! >> >> >> Similarly, in the following paragraph, I think "per VLAN" should be >> replaced by "per E-TREE EVI having both Root and Leaf ACs". >> >> A single EVI can consist of many VLANs (in case of VLAN-aware bundle >> service), so, “per VLAN” is right. However, to make it more exact as >> above, I’ll change it to “per VLAN (when both Root and Leafs ACs >> exist for that VLAN) requires …”. >> >> >> >>> >>> Maintaining two bridge tables per VLAN requires either two lookups be >>> performed per MAC address in either direction in case of a miss, or >>> duplicating many MAC addresses between the two bridge tables >>> belonging to the same VLAN (same E-TREE instance). The duplication of >>> MAC addresses are need for both locally learned and remotely learned >>> MAC addresses. >> >> Since it is said above "Maintaining two bridge tables per VLAN >> requires either two lookups [...] or duplicating many MAC addresses >> [...]", saying "The duplication of MAC addresses is needed for [...]" >> is surprising, so I guess the intent is rather "Unless two lookups >> are made, duplication of MAC addresses would be needed for [...]". >> >> That is correct. I’ll change it to the sentence that you >> suggested: “Unless two lookups are made, …" >> >> >>> Locally learned MAC addresses from Leaf ACs need to be >>> duplicated onto Root bridge table and locally learned MAC addresses >>> from Root ACs need to be duplicated onto Leaf bridge table. Remotely >>> learned MAC addresses from Root ACs need to be copied onto both Root >>> and Leaf bridge tables. >>> Neither double lookups nor MAC duplications >>> are considered viable options; therefore, this draft recommends the >>> use of MAC address coloring for this scenario as detailed in section >>> 3.1. >> >> >> I think that this explanation is too elliptic compared to the strong >> ("not viable") conclusion. As soon as we talk about implementation >> details, a more detailed discussion is required on why, and under >> which assumptions, some things are impossible -- there can be many >> different way to implement a dataplane. Without explaining what "two >> lookups" exactly means in this context, it's hard to follow why it >> would be required if duplicating MAC addresses is not done, and why >> it is latter concluded as "not viable": >> - doing multiple lookups is something that is far from being uncommon >> on router platforms >> - on software platforms the impact of doing multiple lookups can be >> reduced to mostly zero (e.g. with OpenVSwitch that would only impact >> the first packets of a flow) >> - if the dataplane can leverage the colouring information to avoid >> doing two lookups, then perhaps this hardware ability can be >> leveraged to support the two MAC-VRFs approach with only one lookup >> (building one table, marking MAC entries as Leaf entries if they were >> learned with routes carrying only the Leaf RT?) --- don't >> misunderstand me: I'm not claiming that this works (I haven't looked >> closely enough), but simply that the text provided is not sufficient >> to exclude this kind of solution >> >> The "duplicating MAC addresses" alternative is explained better, but >> still, nothing is explained on why this is "not viable". It seems to >> be as something rather belonging to the realm of "having a >> scalability impact", but even looking in this respect we are not >> talking about a change of order of magnitude. >> >> The non-viable conclusion was based on investigation that I did for >> micro-code and ASIC based platforms; however, I see your point and I >> am para-phrasing the sentence as follow to leave room for >> future investigation. >> "In order to avoid two MAC-VRFs, this draft introduces the coloring >> option (B) as detailed in section 3.1" >> >> >>> >>> For this scenario, if for a given EVI, the vast majority of PEs will >>> have both Leaf and Root sites attached, even though they may start as >>> Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in >>> order to alleviate additional configuration overhead associated with >> >> "to alleviate additional configuration overhead associated with ..." >> -> "to alleviate the configuration overhead associated with ..." ? >> >> Done. >> >>> using two RTs per EVI at the expense of having unwanted MAC addresses >>> on the Leaf-only PEs. >>> >>> >> >> >> >> >>> >>> From: Thomas Morin >> > >>> Organization: Orange >>> Date: Thursday, December 15, 2016 at 4:12 AM >>> To: Cisco Employee >, >>> Loa Andersson >, "George Swallow -T >>> (swallow - MBO PARTNERS INC at Cisco)" >> >, Eric Rosen >> >, BESS >> > >>> Cc: Martin Vigoureux >> > >>> Subject: Re: shepherd review of draft-ietf-bess-evpn-etree >>> >>> Hi Ali, >>> >>> 2016-12-13, Ali Sajassi (sajassi): >>>> >>>> 2016-12-10, Ali Sajassi (sajassi): >>>>> Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, >>>>> impacts lot more sections than just section 2.2 for which you >>>>> suggested some texts. It drastically impacts section 3.1 (known >>>>> unicast traffic), and it also impacts section 3.2 (BUM traffic) >>>>> and section 5.1. >>>> >>>> Can you detail why ? >>>> The understanding that leads me to this suggestion is that the >>>> 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in >>>> a 2.2.1 would not require new procotol procedures nor changes in >>>> the text that as I understand provides procedures for 2.2(.2) and 2.3. >>>> 2nd try. As my 1st response got truncated for some reason. >>>> >>>> The reason that impacts more sections than just sec. 2, is that the >>>> proposed 2.2.1 would be an alternative option for section 3.1. In >>>> section 3.1, the root/leaf indication for MAC addresses are done >>>> via flag-bit defined in section 5.1 and it only uses a single >>>> MAC-VRF (single bridge table per VLAN) per RFC 7432. If we go with >>>> two MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an >>>> alternative way of doing the same thing described in section 3.1. >>>> This alternative way has big ramifications on the platform as it >>>> requires duplicating MACs and managing multiple bridge tables per >>>> VLAN. >>> >>> Since 2.1 and the proposed 2.2.1 do not require new protocol >>> procedures (they only require split-horizon locally in Leaf >>> MAC-VRFs), if you state clearly that the procedures in the document >>> are here to address 2.2.2 and 2.3, then you don't need to modify the >>> content of the document after section 2 (more exactly, you will >>> need minor update like changing the current "This scheme applies to >>> all scenarios described in section 2." in section 3 into "This >>> scheme applies to scenarios described in 2.2.2 and 2.3". >>> >>> The "big ramifications" above are then not about section 3, but just >>> the (platform specific-drawbacks) of 2.2.2 that we have already >>> discussed and that can be covered in 2.2.2. >>> >>>> Maybe what you really want is to allow for scenario 2.2 to operate >>>> with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non >>>> of the drawbacks. So, maybe we can clarify the current text to make >>>> sure that this comes out clearly – ie, a PE can have single MAC–VRF >>>> can have multiple RTs. >>> >>> You could mention that, but for me the key things is: >>> - documenting the motivation for the new procedures >>> - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document >>> identified drawbacks) >>> >>>> >>>>> Furthermore, it creates a new paradigm for EVPN that was never >>>>> intended for because of creating two MAC-VRFs (and two bridge >>>>> tables) for the same VLAN. >>>> >>>> The " created a new paradigm that was never >>>> intended for" is a not generally valid, or sufficiently detailed, >>>> argument: if it was, then you might go as far as challenging the >>>> whole E-Tree spec on the same kind grounds (and many other new things). >>>> >>>> So here is where it seems we have a gap to bridge: I still don't >>>> understand what in RFC7432 describes an intention of "not >>>> supporting two MAC-VRFs for the same VLAN". >>>> >>>> I tried to explain the relationship between EVI, MAC-VRF, bridge >>>> table, and VLAN in my previous email per RFC 7432. However, lets >>>> park this discussion for time being as I think it is secondary. >>> >>> Ok, feel free to revisit if you think that RFC7432 would preclude >>> procedures that end up being described in this draft >>> >>>> I think you agree that if we have a single solution that has all >>>> the benefits of your proposed 2.2.1 and 2.2.2 and none of the >>>> drawbacks, it is much more preferable with having two solutions >>>> each with its own advantages and draw backs, right? If so, then >>>> existing text in 2.2 was intended to convey that. However, we can >>>> clarify it further – e.g, make it clear that for PE with root & >>>> leaf in the same EVI, we can use a single MAC-VRF with two RTs (one >>>> for leaf and another for root). >>> >>> As said above my key concern is having the document clearly spell >>> out the motivation for new specs. >>> If this implies documenting the fact that already existing procedure >>> can be used, but have drawbacks, then so be it ; there would be no >>> point in hiding that, right ? >>> >>> >>>> >>>>> The WG LC was completed on 3/29/16 and I am sure it is not your >>>>> intention to have major changes to the doc at this stage where >>>>> multiple vendors have already implemented the draft. >>>> >>>> As you know, there are different stages at which people do reviews >>>> on a doc after WGLC, an which may lead doc editors to introduce >>>> significant --editorial or technical-- changes in a document. >>>> Sometimes that leads to documents going back to the working group. >>>> >>>> However my root intention as doc shepherd, of course, is not to >>>> propose a major change, but merely to able to answer the standard >>>> question of the shepherd review -- on the reviews done, on document >>>> readiness, and on the document quality -- in a way as positive and >>>> sincere as possible. In particular questions (3) (4) and (6). >>>> >>>> So, hopefully the answers to these three questions are now >>>> clear. I believe your main concern is to ensure that we can apply >>>> two-RT approach of sec. 2.1 to sec. 2.2 (and we can still do and >>>> still have a single MAC-VRF) >>> >>> See above. >>> >>>> >>>> >>>>> This draft talks about two kinds of traffic filtering: a) ingress >>>>> filtering for known unicast and b) egress filtering for BUM >>>>> traffic. What you are suggesting is an alternate mechanism for >>>>> ingress filtering. >>>> >>>> (well I'm not suggesting the mechanism itself --which section 2.1 >>>> already does-- but simply to document that it can still apply >>>> without the constraint of avoiding the presence of a Root MAC-VRF >>>> and a Leaf MAC-VRF on a same PE) >>>> >>>>> Although having multiple VRFs (and forwarding tables) are fine for >>>>> IP-VPNs because the unknown traffic is always dropped, multiple >>>>> VRFs for the same VLAN is not OK for L2 traffic because of >>>>> flooding of unknown traffic. That’s why in section 6 of RFC 7432, >>>>> for all service interface types, the draft talks about a single >>>>> MAC-VRF per EVI per PE and in case of VLAN-aware mode, multiple >>>>> VLANs per MAC-VRF but only a single bridge table per VLAN. In >>>>> other words, the bottom line is that there can only be a single >>>>> bridge table per VLAN in order to avoid unnecessary flooding. >>>> >>>> >>>> >>>>> When you have two MAC-VRFs per VLAN (one for root ACs and another >>>>> for Leaf ACs), then you either need to duplicate lots of MAC >>>>> addresses between these two VRFs, or do lookup on both of these >>>>> VRFs. Either ways this is not a good option relative to keeping a >>>>> single VRF table for both root and leaf sites and just have a >>>>> single-bit indication on whether a MAC is associated with root or >>>>> leaf (as currently described approach in the draft). I >>>> >>>> >>>> In the above, it seems you agree that it can work, and you are able >>>> to offer reasons why it is not the preferred option, then why not >>>> just document that it can work and provides these reasons as the >>>> motivations that lead to proposing a new specs ? >>>> >>>> Sure, I can do that. [...] >>> >>> Ok. >>> I'll be happy to review a new revision and hopefully post the >>> shepherd review. >>> >>> Thanks, >>> >>> -Thomas >>> >>> >>>> >>>> (it seems you have an unfinished last sentence: "I [...]" ) >>>> >>>> >>>>> >>>>>>> >>>>>>> (assuming the previous point is resolved:) >>>>>>> >>>>>>> With this mechanism above, isn't it possible to have on a given >>>>>>> PE, for a single E-TREE EVI, both Leaves and Roots, as long as >>>>>>> distinct MAC-VRFs are used (one for Leaves and one for Roots) ? >>>>>>> (it seems to me that the 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) >>>>>>> >>>>>>> >>>>>>> That’s 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 something). >>>>>> And that seems a completely arbitrary restriction. >>>>>> (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 how many MAC-VRF (and bridge >>>>>> tables) can be per EVI. >>>>> >>>>> This section of RFC7434 discusses many different things for the >>>>> different variants. >>>>> Can you provide a specific pointer about "how many MAC-VRFs can be >>>>> per EVI" ? >>>>> >>>>> Ali> Section 6 of RFC7432 spells out the relationship between EVI, >>>>> MAC-VRF, and bridge tables for all service interfaces very clearly. >>>>> In all service interfaces, the RFC says there is one MAC-VRF per >>>>> EVI on a given PE. >>>>> Now, if the service interface is “vlan-aware”, then there are >>>>> several bridge tables for that single MAC-VRF – ie, one bridge >>>>> table per VLAN. In all service interfaces, you can ONLY have one >>>>> bridge table per VLAN. >>>> >>>> This answer is everything but a specific pointer. >>>> If Section 6 of RFC7432 says all this very clearly, I guess it >>>> should be possible to extract quotes about "there is one MAC-VRF >>>> per EVI on a given PE", right ? >>>> >>>> >>>>> >>>>>> In bridging world, there can only be a single bridge table per >>>>>> VLAN in a device. >>>>> >>>>> I still don't find here anything that would preclude having, on a >>>>> given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots >>>>> MAC-VRF: can't these two MAC-VRFs use different internal VLANs >>>>> (with translation if the external VLANs are constrained). >>>>> >>>>> Ali> Lets assume we are using vlan-based service and thus there >>>>> is only a single bridge table per MAC-VRF, then what you are >>>>> suggesting is two use two MAC-VRFs (two bridge tables) for the >>>>> same EVI (same VLAN). This results in some duplications of MAC >>>>> addresses and would only work if flooding is disabled (more on >>>>> this later). >>>> >>>> "results in some duplications of MAC" is perhaps a drawback, but >>>> nothing like "just does not work" ? >>>> >>>> "would only work if flooding is disabled": why ? (you wrote "(more >>>> on this later)" but I couldn't identify anything recent from you in >>>> the rest of the email below) >>>> >>>> >>>> From an helicopter view, I can't see what fundamentally would >>>> become problematic between "two MAC-VRFs on two distinct PEs" and >>>> the same "two MAC-VRFs on a same PEs", at worse it is as efficient >>>> or as inefficient as having them on separate PEs (think logical >>>> router without anykind of dataplane optimisation), and we can't >>>> exclude that the PE could have local implementation details to do >>>> better than that. >>>> >>>> >>>>>> >>>>>>> Besides, I don’t 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 replicating all the MAC addresses associated with >>>>>> the root sites in two bridge tables. >>>>> >>>>> Your point above certainly does not sound to me as "it can't be >>>>> done": some may think that the above is an acceptable cost, some >>>>> others may find ways to make this "replication" with a low >>>>> overhead, on some platforms the cost may be negligible, etc. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> 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 implement a shortcut not >>>>>> involving MPLS encap/decap). >>>>>> >>>>>> Anything is possible but at what cost. >>>>> >>>>> You know, for cost it is not always obvious to reach conclusions >>>>> that are true for all implementations and all targets. >>>>> >>>>>> The current proposal is very efficient in terms of forwarding >>>>>> path as well as control plane. >>>>> >>>>> Sure, but what I question is not the new solution but the lack of >>>>> discussion on why using the existing specs was not considered good >>>>> enough. >>>>> >>>>> >>>>> I think that my concern of clearly explaining the scenarios and >>>>> motivations for this new spec could be addressed by splitting >>>>> section 2.2 into a 2.2.1 describing the approach from 2.1 and its >>>>> possible drawbacks, and a 2.2.2 having essentially the content of >>>>> current section 2.2. >>>>> >>>>> Here is a proposal: >>>>> >>>>> 2.2 Scenario 2: Leaf of Root site(s) per AC >>>>> >>>>> In these scenarii, 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 Root(s) >>>>> or Leaf(s) (but not both). >>>>> >>>>> 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root >>>>> MAC-VRFs >>>>> >>>>> +---------+ +---------+ >>>>> | PE1 | | PE2 | >>>>> +---+ | +---+ | +------+ | +---+ | +---+ >>>>> |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| >>>>> +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ >>>>> | |VRF| | | /IP | | '---' | >>>>> | | | | | | | .---. | >>>>> | | | | | | | |MAC| | +---+ >>>>> | | | | | | | |VRF+--+---ES2/AC2--+CE3| >>>>> | +---+ | +------+ | +---+ | (Root) +---+ >>>>> +---------+ +---------+ >>>>> >>>>> Figure 2: Scenario 2a >>>>> >>>>> In this scenario, the RT constraint procedures described in >>>>> section 2.1 could >>>>> also be used. The feasibility and efficiency of this approach >>>>> depends on >>>>> platforms specifics. >>>>> >>>>> This approach will lead toduplication of a large proportion of MAC >>>>> addresseson >>>>> PEs having both Leaf and Root sites, and is hence considered >>>>> less suitable for >>>>> deployment contexts where the vast majority of PEs are likely >>>>> to ultimately >>>>> have both Leaf and Root sites attached to them. >>>>> >>>>> 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF >>>>> >>>>> +---------+ +---------+ >>>>> | PE1 | | PE2 | >>>>> +---+ | +---+ | +------+ | +---+ | +---+ >>>>> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >>>>> +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ >>>>> | |VRF| | | /IP | | |VRF| | >>>>> | | | | | | | | | | +---+ >>>>> | | | | | | | | +--+---ES2/AC2--+CE3| >>>>> | +---+ | +------+ | +---+ | (Root) +---+ >>>>> +---------+ +---------+ >>>>> >>>>> Figure 2: Scenario 2b >>>>> >>>>> This scenario will alleviate keys drawbacks from Scenario 2a, in >>>>> particular >>>>> by avoiding duplication of MAC addresses on Leaf/Root PEs and >>>>> avoiding the >>>>> operational overhead of managing more than one RT. >>>>> This approach comes at the expense of having routes for >>>>> unneeded MAC addresses on Leaf-only PEs, and is hence considered >>>>> less suitable for deployment contexts where the vast majority of >>>>> PEs would remain Leaf-only. Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures >>>>> provided in this document. >>>>> >>>>> >>>>> (And this last sentence should be added to section 2.3 as well) >>>>> >>>>>> >>>>>>>> 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 “majority” to “vast majority” :-) >>>>>> >>>>>> 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 identified: having useless routes on the fraction of PEs >>>>>> having only Leaves. >>>>>> But the gain brought by the recommendation is not even mentioned, >>>>>> not to say explained. >>>>>> Hence: why ? >>>>>> (Why is it a useful tradeoff to have useless routes on some, even >>>>>> if only one, PE ?) >>>>>> >>>>>> Changed the last sentence from: >>>>>> "then it is recommended to use a single RT per EVI and avoid >>>>>> additional configuration and operational overhead.” >>>>>> To >>>>>> "then it is recommended to use a single RT per EVI and avoid >>>>>> additional configuration and operational overhead >>>>>> at the expense of having unwanted MAC addresses on the Leaf PEs." >>>>> >>>>> Ok. I adapted and incorporated this addition into my proposed text >>>>> splitting 2.2 into a 2.2.1 and a 2.2.2. >>>>> >>>>> Best, >>>>> >>>>> -Thomas >>>>> >>>>> >>>> >>> >> > --------------18DCC66B8039D19356E63979 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

I'm fine with the new text, thanks for the work on addressing my comments.
You can post a revision and I will wrap-up the shepherd review in parallel.

Best,

-Thomas

2017-01-13, Ali Sajassi (sajassi):
Hi Thomas,

Please refer to the comment resolution below:

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Friday, January 13, 2017 at 1:22 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of draft-ietf-bess-evpn-etree

Hi Ali,

One comment on what seems to me the last pending issue.

Ali:
>>Thomas:
I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on router platforms
- on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow)
- if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup  (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution

The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investigation that I did for micro-code and ASIC based platforms; however, I see your point and I am para-phrasing the sentence as follow to leave room for future investigation. 
"In order to avoid two MAC-VRFs, this draft introduces the coloring option (B) as detailed in section 3.1"


This is better, but:
- the text still makes a statement that either two lookups or duplicating MACs is required, without much explanation
- the logic is not consolidated: if either X or Y is required, then its illogical to say "In order to avoid X, this drafts introduces Z...."  (Z being different than Y)
- the text still misses an explanation on why avoiding two MAC-VRFs was desired

If we can't (or don't want to spend time on) explaining the details on why something else than "two MAC RVFs" was deemed useful, then perhaps we could simplify the whole paragraph into something like:

      Because option (A) is not believed to be implementable without dataplane performance inefficiencies some platforms, this drafts introduces the coloring option (B) in section 3.1.

I modified the last sentence as below:
"Because of potential inefficiencies associated with data-plane implementation of additional MAC lookup or duplication of MAC entries, option (A) is not believed to be implementable without dataplane performance inefficiencies in some platforms and thus this draft introduces the coloring option (B) as detailed in section 3.1.”

The logic is as follow: Option A requires either X (two MAC lookup) or Y (duplication of MAC entries). Because of potential data-plane inefficiencies for X or Y (which is needed for option A), we are suggesting option B.

The whole paragraph is as below:
"Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf and Root ACs exists for that VLAN) would either require two lookups be performed per MAC address in each direction in case of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE instance). Unless two lookups are made, duplication of MAC addresses would be needed for both locally learned and remotely learned MAC addresses. Locally learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC addresses from Root ACs need to be duplicated onto Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Because of potential inefficiencies associated with data-plane implementation of additional MAC lookup or duplication of MAC entries, option (A) is not believed to be implementable without dataplane performance inefficiencies in some platforms and thus this draft introduces the coloring option (B) as detailed in section 3.1."

Cheers,
Ali


Best,

-Thomas



2017-01-13, Ali Sajassi (sajassi):



Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring approach for Leaf/Root MAC addresses is used in this draft. Also, the use of single RT for this scenario is mentioned just as “MAY”. Please review the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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 a Root AC or a Leaf AC
   (but not both). 


                     +---------+            +---------+
                     |   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, just like the previous scenario (in section 2.1),
   two Route Targets (one for Root and another for Leaf) can be used.
   However, the difference is that on a PE with both Root and Leaf ACs,
   all remote MAC routes are imported and thus there needs to be a way
   to differentiate remote MAC routes associated with Leaf ACs versus
   the ones associated with Root ACs in order to apply the proper
   ingress filtering. 

   In order to support such ingress filtering on the ingress PE with
   both Leaf and Root ACs, one the following two approaches can be used:

reverting A and B would be more natural since solution B corresponds to the starting point "what we had before this spec"

Done.

   A) Color MAC addresses with Leaf (or Root) color before distributing
   them in BGP to other PEs depending on whether it is learned on a Leaf

s/it is/they are/

Done.

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to parse.

Done.

   B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "two bridge tables per VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a given EVI" ?

That’s fine. Done!


Similarly, in the following paragraph, I think "per VLAN" should be replaced by "per E-TREE EVI having both Root and Leaf ACs".

A single EVI can consist of many VLANs (in case of VLAN-aware bundle service), so, “per VLAN” is right. However, to make it more exact as above, I’ll change it to “per VLAN (when both Root and Leafs ACs exist for that VLAN) requires …”.




   Maintaining two bridge tables per VLAN requires either two lookups be
   performed per MAC address in either direction in case of a miss, or
   duplicating many MAC addresses between the two bridge tables
   belonging to the same VLAN (same E-TREE instance). The duplication of
   MAC addresses are need for both locally learned and remotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN requires either two lookups [...] or duplicating many MAC addresses [...]", saying "The duplication of MAC addresses is needed for [...]"  is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [...]".

That is correct. I’ll change it to the sentence that you suggested: “Unless two lookups are made, …"


   Locally learned MAC addresses from Leaf ACs need to be
   duplicated onto Root bridge table and locally learned MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge table. Remotely
   learned MAC addresses from Root ACs need to be copied onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft recommends the
   use of MAC address coloring for this scenario as detailed in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("not viable") conclusion. As soon as we talk about implementation details, a more detailed discussion is required on why, and under which assumptions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining what "two lookups" exactly means in this context, it's hard to follow why it would be required if duplicating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on router platforms
- on software platforms the impact of doing multiple lookups can be reduced to mostly zero (e.g. with OpenVSwitch that would only impact the first packets of a flow)
- if the dataplane can leverage the colouring information to avoid doing two lookups, then perhaps this hardware ability can be leveraged to support the two MAC-VRFs approach with only one lookup  (building one table, marking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't misunderstand me: I'm not claiming that this works (I haven't looked closely enough), but simply that the text provided is not sufficient to exclude this kind of solution

The "duplicating MAC addresses" alternative is explained better, but still, nothing is explained on why this is "not viable". It seems to be as something rather belonging to the realm of "having a scalability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investigation that I did for micro-code and ASIC based platforms; however, I see your point and I am para-phrasing the sentence as follow to leave room for future investigation. 
"In order to avoid two MAC-VRFs, this draft introduces the coloring option (B) as detailed in section 3.1"



   For this scenario, if for a given EVI, the vast majority of PEs will
   have both Leaf and Root sites attached, even though they may start as
   Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
   order to alleviate  additional configuration overhead associated with

"to alleviate  additional configuration overhead associated with ..." -> "to alleviate the configuration overhead associated with ..." ?

Done.

   using two RTs per EVI at the expense of having unwanted MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Thursday, December 15, 2016 at 4:12 AM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS <bess@ietf.org>
Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: Re: shepherd review of draft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot more sections than just section 2.2 for which you suggested some texts. It drastically  impacts section 3.1 (known unicast traffic), and it also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+split-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not require new procotol procedures nor changes in the text that as I understand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason that impacts more sections than just sec. 2, is that the proposed 2.2.1 would be an alternative option for section 3.1. In section 3.1, the root/leaf indication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN, then that is an alternative way of doing the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (they only require split-horizon locally in Leaf MAC-VRFs), if you state clearly that the procedures in the document are here to address 2.2.2 and 2.3, then you don't need to modify the content of the document after section 2  (more exactly, you will need minor update like changing the current "This scheme applies to all scenarios described in section 2." in section 3 into "This scheme applies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but just the (platform specific-drawbacks) of 2.2.2 that we have already discussed and that can be covered in 2.2.2.

Maybe what you really want is to allow for scenario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text to make sure that this comes out clearly – ie, a PE can have single MAC–VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identified drawbacks)


Furthermore, it creates a new paradigm for EVPN that was never intended for because of creating two MAC-VRFs (and two bridge tables) for the same VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was never intended for" is a not generally valid, or sufficiently detailed, argument: if it was, then you might go as far as challenging the whole E-Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand what in RFC7432 describes an intention of "not supporting two MAC-VRFs for the same VLAN".

I tried to explain the relationship between EVI, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. However, lets park this discussion for time being as I think it is secondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedures that end up being described in this draft

I think you agree that if we have a single solution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much more preferable with having two solutions each with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. However, we can clarify it further – e.g, make it clear that for PE with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the motivation for new specs.
If this implies documenting the fact that already existing procedure can be used, but have drawbacks, then so be it ; there would be no point in hiding that, right ?



The WG LC was completed on 3/29/16 and I am sure it is not your intention to have major changes to the doc at this stage where multiple vendors have already implemented the draft.

As you know, there are different stages at which people do reviews on a doc after WGLC, an which may lead doc editors to introduce significant --editorial or technical-- changes in a document. Sometimes that leads to documents going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a major change, but merely to able to answer the standard question of the shepherd review -- on the reviews done, on document readiness, and on the document quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three questions are now clear. I believe your main concern is to ensure that we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can still do and still have a single MAC-VRF)

See above.


This draft talks about two kinds of traffic filtering: a) ingress filtering for known unicast and b) egress filtering for BUM traffic. What you are suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already does-- but simply to document that it can still apply without the constraint of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE)

Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs because the unknown traffic is always dropped, multiple VRFs for the same VLAN is not OK for L2 traffic because of flooding of unknown traffic. That’s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In other words, the bottom line is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf ACs), then you either need to duplicate lots of MAC addresses between these two VRFs, or do lookup on both of these VRFs. Either ways this is not a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit indication on whether a MAC is associated with root or leaf (as currently described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offer reasons why it is not the preferred option, then why not just document that it can work and provides these reasons as the motivations that lead to proposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd review.

Thanks,

-Thomas



(it seems you have an unfinished last sentence: "I [...]" )


(assuming the previous point is resolved:)

With this mechanism above, isn't it possible to have on a given PE, for a single E-TREE EVI, both Leaves and Roots, as long as distinct MAC-VRFs are used (one for Leaves and one for Roots) ?   (it seems to me that the 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)

That’s 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 something).
And that seems a completely arbitrary restriction.
(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 how many MAC-VRF (and bridge tables) can be per EVI.

This section of RFC7434 discusses many different things for the different variants.
Can you provide a specific pointer about "how many MAC-VRFs can be per EVI" ?

Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF, and bridge tables for all service interfaces very clearly.
In all service interfaces, the RFC says there is one MAC-VRF per EVI on a given PE.
Now, if the service interface is “vlan-aware”, then there are several bridge tables for that single MAC-VRF – ie, one bridge table per VLAN. In all service interfaces, you can ONLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be possible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?



In bridging world, there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE, for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't these two MAC-VRFs use different internal VLANs (with translation if the external VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is only a single bridge table per MAC-VRF, then what you are suggesting is two use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote "(more on this later)" but I couldn't identify anything recent from you in the rest of the email below)


From an helicopter view, I can't see what fundamentally would become problematic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs on a same PEs", at worse it is as efficient or as inefficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude that the PE could have local implementation details to do better than that.



Besides, I don’t 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 replicating all the MAC addresses associated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done": some may think that the above is an acceptable cost, some others may find ways to make this "replication" with a low overhead, on some platforms the cost may be negligible, etc.




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 implement a shortcut not involving MPLS encap/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are true for all implementations and all targets.

The current proposal is very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussion on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations for this new spec could be addressed by splitting section 2.2 into a 2.2.1 describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 having essentially the content of current section 2.2.

Here is a proposal:

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

   In these scenarii, 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 Root(s)
   or Leaf(s) (but not both).

2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |MAC+--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |VRF|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  '---'  |
                     |  |   |  |  |      |  |  .---.  |
                     |  |   |  |  |      |  |  |MAC|  |            +---+
                     |  |   |  |  |      |  |  |VRF+--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2a

   In this scenario, the RT constraint procedures described in section 2.1 could
   also be used. The feasibility and efficiency of this approach depends on
   platforms specifics.

   This approach will lead toduplication of a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered less suitable for
   deployment contexts where the vast majority of PEs are likely to ultimately
   have both Leaf and Root sites attached to them.

2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Leaf)  |  |MAC|  |  | MPLS |  |  |MAC|  |   (Leaf)   +---+
                     |  |VRF|  |  |  /IP |  |  |VRF|  |
                     |  |   |  |  |      |  |  |   |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Root)   +---+
                     +---------+            +---------+

   Figure 2: Scenario 2b

   This scenario will alleviate keys drawbacks from Scenario 2a, in particular
   by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding the
   operational overhead of managing more than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresses
   on Leaf-only PEs, and is hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Scenario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 “majority” to “vast majority” :-)

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 identified: having useless routes on the fraction of PEs having only Leaves.
But the gain brought by the recommendation is not even mentioned, not to say explained.
Hence: why ?
(Why is it a useful tradeoff to have useless routes on some, even if only one, PE ?)

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

Ok. I adapted and incorporated this addition into my proposed text splitting 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas


--------------18DCC66B8039D19356E63979-- From nobody Fri Jan 13 15:40:35 2017 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 15FF0129F57; Fri, 13 Jan 2017 15:40:34 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148435083408.9764.8741371187506813925.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 15:40:34 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-08.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, 13 Jan 2017 23:40:34 -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 : E-TREE Support in EVPN & PBB-EVPN Authors : Ali Sajassi Samer Salam John Drake Jim Uttaro Sami Boutros Jorge Rabadan Filename : draft-ietf-bess-evpn-etree-08.txt Pages : 19 Date : 2017-01-13 Abstract: The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in and RFC called "A Framework for E-Tree Service over MPLS Network". This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates that RFC accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-08 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 Jan 13 15:46:05 2017 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 F0201129F91 for ; Fri, 13 Jan 2017 15:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 dluEhBIuHfb6 for ; Fri, 13 Jan 2017 15:45:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E24129F90 for ; Fri, 13 Jan 2017 15:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=114733; q=dns/txt; s=iport; t=1484351157; x=1485560757; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7anYBn2IRtzPmCIutMYgfpkVBunSlzNWOaGHWWai3ls=; b=iTRlDr14b+dFRUN8fM4kdvFDuVSNS6rZQFeJ61aI5+1ldECtASS2hnps NNLF+o9Yg5MNAWs6FdDTlXK8TUcR1/nXMI0tBRl9oyT6qY6G75Pr8f49q 2R+K7XJsb/DtjPG+B6c54RfqrAldLJw8AO3npacNqDMj9GpZZf4CJMdXl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQDCZHlY/5JdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvOw8BAQEBAR9fgQkHjVGSFZUqggwqgh0BJIM2AoIXPxgBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBBoBDEUFAQEBAgMQAgEIEQMBAiEBBgcyFAkIAgQBDQUbi?= =?us-ascii?q?GgOslY6K4liAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWKIIEGhBcBBgsBPBiFLAW?= =?us-ascii?q?VKoYIAYZbgxWHaIF3hQ6DTYRjgTiIFIY+hBIBHzhxUxWEbxyBX3OGOIEhgQ0BA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.33,224,1477958400"; d="scan'208,217";a="192540528" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2017 23:45:55 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v0DNjtBr020797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 23:45:55 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 18:45:54 -0500 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, 13 Jan 2017 18:45:53 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , 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+oCASmTegIBKoSmAgAU1ewCABIpWAIABYlAAgAABy4CAAydaAIAFHy2AgBu7JwCAC1ogAIABL6yAgAAWB4CAAKVWgP//r7cA Date: Fri, 13 Jan 2017 23:45:53 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> <0b846411-4526-c6d3-3ea4-87ebd90de953@orange.com> <62a4bc51-b9de-4a80-a843-bfa356bc23ea@orange.com> <84953d59-4962-2b5d-1730-7ac1d0d9c982@orange.com> <7cc40566-d985-2cc3-a15d-39e4a45c3ae9@orange.com> <6ba88792-47ca-8008-d848-95b469ea8a5c@orange.com> In-Reply-To: <6ba88792-47ca-8008-d848-95b469ea8a5c@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.52] Content-Type: multipart/alternative; boundary="_000_D49E9B471C84B9sajassiciscocom_" 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: Fri, 13 Jan 2017 23:46:04 -0000 --_000_D49E9B471C84B9sajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks very much for shepherding this draft and providing valuable comments= . I have just posted the new rev with all the edits incorproated. We can now move to the next draft in the queue - draft-ietf-bess-evpn-overl= ay-07. Regards, Ali From: Thomas Morin = > Organization: Orange Date: Friday, January 13, 2017 at 12:33 PM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, I'm fine with the new text, thanks for the work on addressing my comments. You can post a revision and I will wrap-up the shepherd review in parallel. Best, -Thomas 2017-01-13, Ali Sajassi (sajassi): Hi Thomas, Please refer to the comment resolution below: From: Thomas Morin = > Organization: Orange Date: Friday, January 13, 2017 at 1:22 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, One comment on what seems to me the last pending issue. Ali: >>Thomas: I think that this explanation is too elliptic compared to the strong ("not = viable") conclusion. As soon as we talk about implementation details, a mor= e detailed discussion is required on why, and under which assumptions, some= things are impossible -- there can be many different way to implement a d= ataplane. Without explaining what "two lookups" exactly means in this conte= xt, it's hard to follow why it would be required if duplicating MAC address= es is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on ro= uter platforms - on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow) - if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup (building one table, marking= MAC entries as Leaf entries if they were learned with routes carrying only= the Leaf RT?) --- don't misunderstand me: I'm not claiming that this work= s (I haven't looked closely enough), but simply that the text provided is n= ot sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still,= nothing is explained on why this is "not viable". It seems to be as someth= ing rather belonging to the realm of "having a scalability impact", but eve= n looking in this respect we are not talking about a change of order of mag= nitude. The non-viable conclusion was based on investigation that I did for micro-c= ode and ASIC based platforms; however, I see your point and I am para-phras= ing the sentence as follow to leave room for future investigation. "In order to avoid two MAC-VRFs, this draft introduces the coloring option = (B) as detailed in section 3.1" This is better, but: - the text still makes a statement that either two lookups or duplicating M= ACs is required, without much explanation - the logic is not consolidated: if either X or Y is required, then its ill= ogical to say "In order to avoid X, this drafts introduces Z...." (Z being= different than Y) - the text still misses an explanation on why avoiding two MAC-VRFs was des= ired If we can't (or don't want to spend time on) explaining the details on why = something else than "two MAC RVFs" was deemed useful, then perhaps we could= simplify the whole paragraph into something like: Because option (A) is not believed to be implementable without datapl= ane performance inefficiencies some platforms, this drafts introduces the c= oloring option (B) in section 3.1. I modified the last sentence as below: "Because of potential inefficiencies associated with data-plane implementat= ion of additional MAC lookup or duplication of MAC entries, option (A) is n= ot believed to be implementable without dataplane performance inefficiencie= s in some platforms and thus this draft introduces the coloring option (B) = as detailed in section 3.1.=94 The logic is as follow: Option A requires either X (two MAC lookup) or Y (d= uplication of MAC entries). Because of potential data-plane inefficiencies = for X or Y (which is needed for option A), we are suggesting option B. The whole paragraph is as below: "Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf and = Root ACs exists for that VLAN) would either require two lookups be performe= d per MAC address in each direction in case of a miss, or duplicating many = MAC addresses between the two bridge tables belonging to the same VLAN (sam= e E-TREE instance). Unless two lookups are made, duplication of MAC address= es would be needed for both locally learned and remotely learned MAC addres= ses. Locally learned MAC addresses from Leaf ACs need to be duplicated onto= Root bridge table and locally learned MAC addresses from Root ACs need to = be duplicated onto Leaf bridge table. Remotely learned MAC addresses from R= oot ACs need to be copied onto both Root and Leaf bridge tables. Because of= potential inefficiencies associated with data-plane implementation of addi= tional MAC lookup or duplication of MAC entries, option (A) is not believed= to be implementable without dataplane performance inefficiencies in some p= latforms and thus this draft introduces the coloring option (B) as detailed= in section 3.1." Cheers, Ali Best, -Thomas 2017-01-13, Ali Sajassi (sajassi): Hi Ali, 2016-12-19, Ali Sajassi (sajassi): I have modified section 2.2 (copied below) to elaborate why coloring approa= ch for Leaf/Root MAC addresses is used in this draft. Also, the use of sing= le RT for this scenario is mentioned just as =93MAY=94. Please review the t= ext below and let me know if you still have questions/comments: Thanks for providing text that goes in the right direction. I still have a few comments below. -Thomas 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 a Root AC or a Leaf AC (but not both). +---------+ +---------+ | 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, just like the previous scenario (in section 2.1), two Route Targets (one for Root and another for Leaf) can be used. However, the difference is that on a PE with both Root and Leaf ACs, all remote MAC routes are imported and thus there needs to be a way to differentiate remote MAC routes associated with Leaf ACs versus the ones associated with Root ACs in order to apply the proper ingress filtering. In order to support such ingress filtering on the ingress PE with both Leaf and Root ACs, one the following two approaches can be used: reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec" Done. A) Color MAC addresses with Leaf (or Root) color before distributing them in BGP to other PEs depending on whether it is learned on a Leaf s/it is/they are/ Done. AC (or a Root AC) I think removing the parenthesis is needed for the 'whether' statement to p= arse. Done. B) Use two MAC-VRFs (two bridge tables per VLANs) - one for Root ACs and another for Leaf ACs. I think "(two bridge tables per VLANs)" is inexact: "two bridge tables per= VLAN if a given VLAN exists on the PE for both Leaf and Root ACs of a give= n EVI" ? That=92s fine. Done! Similarly, in the following paragraph, I think "per VLAN" should be replace= d by "per E-TREE EVI having both Root and Leaf ACs". A single EVI can consist of many VLANs (in case of VLAN-aware bundle servic= e), so, =93per VLAN=94 is right. However, to make it more exact as above, I= =92ll change it to =93per VLAN (when both Root and Leafs ACs exist for that= VLAN) requires =85=94. Maintaining two bridge tables per VLAN requires either two lookups be performed per MAC address in either direction in case of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE instance). The duplication of MAC addresses are need for both locally learned and remotely learned MAC addresses. Since it is said above "Maintaining two bridge tables per VLAN requires eit= her two lookups [...] or duplicating many MAC addresses [...]", saying "The= duplication of MAC addresses is needed for [...]" is surprising, so I gue= ss the intent is rather "Unless two lookups are made, duplication of MAC ad= dresses would be needed for [...]". That is correct. I=92ll change it to the sentence that you suggested: =93Un= less two lookups are made, =85" Locally learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC addresses from Root ACs need to be duplicated onto Leaf bridge table. Remotely learned MAC addresses from Root ACs need to be copied onto both Root and Leaf bridge tables. Neither double lookups nor MAC duplications are considered viable options; therefore, this draft recommends the use of MAC address coloring for this scenario as detailed in section 3.1. I think that this explanation is too elliptic compared to the strong ("not = viable") conclusion. As soon as we talk about implementation details, a mor= e detailed discussion is required on why, and under which assumptions, some= things are impossible -- there can be many different way to implement a d= ataplane. Without explaining what "two lookups" exactly means in this conte= xt, it's hard to follow why it would be required if duplicating MAC address= es is not done, and why it is latter concluded as "not viable": - doing multiple lookups is something that is far from being uncommon on ro= uter platforms - on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow) - if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup (building one table, marking= MAC entries as Leaf entries if they were learned with routes carrying only= the Leaf RT?) --- don't misunderstand me: I'm not claiming that this work= s (I haven't looked closely enough), but simply that the text provided is n= ot sufficient to exclude this kind of solution The "duplicating MAC addresses" alternative is explained better, but still,= nothing is explained on why this is "not viable". It seems to be as someth= ing rather belonging to the realm of "having a scalability impact", but eve= n looking in this respect we are not talking about a change of order of mag= nitude. The non-viable conclusion was based on investigation that I did for micro-c= ode and ASIC based platforms; however, I see your point and I am para-phras= ing the sentence as follow to leave room for future investigation. "In order to avoid two MAC-VRFs, this draft introduces the coloring option = (B) as detailed in section 3.1" For this scenario, if for a given EVI, the vast majority of PEs will have both Leaf and Root sites attached, even though they may start as Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in order to alleviate additional configuration overhead associated with "to alleviate additional configuration overhead associated with ..." -> "t= o alleviate the configuration overhead associated with ..." ? Done. using two RTs per EVI at the expense of having unwanted MAC addresses on the Leaf-only PEs. From: Thomas Morin = > Organization: Orange Date: Thursday, December 15, 2016 at 4:12 AM To: Cisco Employee >, Loa Ander= sson >, "George Swallow -T (swallow - MBO PARTN= ERS INC at Cisco)" >, Eric Rose= n >, BESS > Cc: Martin Vigoureux > Subject: Re: shepherd review of draft-ietf-bess-evpn-etree Hi Ali, 2016-12-13, Ali Sajassi (sajassi): 2016-12-10, Ali Sajassi (sajassi): Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impacts lot= more sections than just section 2.2 for which you suggested some texts. It= drastically impacts section 3.1 (known unicast traffic), and it also impa= cts section 3.2 (BUM traffic) and section 5.1. Can you detail why ? The understanding that leads me to this suggestion is that the 2-RT+split-h= orizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would not r= equire new procotol procedures nor changes in the text that as I understand= provides procedures for 2.2(.2) and 2.3. 2nd try. As my 1st response got truncated for some reason. The reason that impacts more sections than just sec. 2, is that the propose= d 2.2.1 would be an alternative option for section 3.1. In section 3.1, the= root/leaf indication for MAC addresses are done via flag-bit defined in se= ction 5.1 and it only uses a single MAC-VRF (single bridge table per VLAN) = per RFC 7432. If we go with two MAC-VRFs (e.g., two bridge tables) per VLAN= , then that is an alternative way of doing the same thing described in sect= ion 3.1. This alternative way has big ramifications on the platform as it r= equires duplicating MACs and managing multiple bridge tables per VLAN. Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2 (= more exactly, you will need minor update like changing the current "This sc= heme applies to all scenarios described in section 2." in section 3 into "T= his scheme applies to scenarios described in 2.2.2 and 2.3". The "big ramifications" above are then not about section 3, but just the (p= latform specific-drawbacks) of 2.2.2 that we have already discussed and tha= t can be covered in 2.2.2. Maybe what you really want is to allow for scenario 2.2 to operate with two= RTs which has the benefits of both 2.2.1 and 2.2.2 and non of the drawback= s. So, maybe we can clarify the current text to make sure that this comes o= ut clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs. You could mention that, but for me the key things is: - documenting the motivation for the new procedures - not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks) Furthermore, it creates a new paradigm for EVPN that was never intended for= because of creating two MAC-VRFs (and two bridge tables) for the same VLAN= . The " created a new paradigm that was never intended f= or" is a not generally valid, or sufficiently detailed, argument: if it was= , then you might go as far as challenging the whole E-Tree spec on the same= kind grounds (and many other new things). So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRFs for= the same VLAN". I tried to explain the relationship between EVI, MAC-VRF, bridge table, and= VLAN in my previous email per RFC 7432. However, lets park this discussion= for time being as I think it is secondary. Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft I think you agree that if we have a single solution that has all the benefi= ts of your proposed 2.2.1 and 2.2.2 and none of the drawbacks, it is much m= ore preferable with having two solutions each with its own advantages and d= raw backs, right? If so, then existing text in 2.2 was intended to convey t= hat. However, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with two RTs = (one for leaf and another for root). As said above my key concern is having the document clearly spell out the m= otivation for new specs. If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ? The WG LC was completed on 3/29/16 and I am sure it is not your intention t= o have major changes to the doc at this stage where multiple vendors have a= lready implemented the draft. As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group. However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular = questions (3) (4) and (6). So, hopefully the answers to these three questions are now clear. I believe= your main concern is to ensure that we can apply two-RT approach of sec. 2= .1 to sec. 2.2 (and we can still do and still have a single MAC-VRF) See above. This draft talks about two kinds of traffic filtering: a) ingress filtering= for known unicast and b) egress filtering for BUM traffic. What you are su= ggesting is an alternate mechanism for ingress filtering. (well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= ) Although having multiple VRFs (and forwarding tables) are fine for IP-VPNs = because the unknown traffic is always dropped, multiple VRFs for the same V= LAN is not OK for L2 traffic because of flooding of unknown traffic. That= =92s why in section 6 of RFC 7432, for all service interface types, the dra= ft talks about a single MAC-VRF per EVI per PE and in case of VLAN-aware mo= de, multiple VLANs per MAC-VRF but only a single bridge table per VLAN. In= other words, the bottom line is that there can only be a single bridge tab= le per VLAN in order to avoid unnecessary flooding. When you have two MAC-VRFs per VLAN (one for root ACs and another for Leaf = ACs), then you either need to duplicate lots of MAC addresses between these= two VRFs, or do lookup on both of these VRFs. Either ways this is not a go= od option relative to keeping a single VRF table for both root and leaf sit= es and just have a single-bit indication on whether a MAC is associated wit= h root or leaf (as currently described approach in the draft). I In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ? Sure, I can do that. [...] Ok. I'll be happy to review a new revision and hopefully post the shepherd revi= ew. Thanks, -Thomas (it seems you have an unfinished last sentence: "I [...]" ) (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. This section of RFC7434 discusses many different things for the different v= ariants. Can you provide a specific pointer about "how many MAC-VRFs can be per EVI"= ? Ali> Section 6 of RFC7432 spells out the relationship between EVI, MAC-VRF,= and bridge tables for all service interfaces very clearly. In all service interfaces, the RFC says there is one MAC-VRF per EVI on a g= iven PE. Now, if the service interface is =93vlan-aware=94, then there are several b= ridge tables for that single MAC-VRF =96 ie, one bridge table per VLAN. In = all service interfaces, you can ONLY have one bridge table per VLAN. This answer is everything but a specific pointer. If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE"= , right ? In bridging world, there can only be a single bridge table per VLAN in a de= vice. I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained). Ali> Lets assume we are using vlan-based service and thus there is only a = single bridge table per MAC-VRF, then what you are suggesting is two use tw= o MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This results i= n some duplications of MAC addresses and would only work if flooding is dis= abled (more on this later). "results in some duplications of MAC" is perhaps a drawback, but nothing li= ke "just does not work" ? "would only work if flooding is disabled": why ? (you wrote "(more on this= later)" but I couldn't identify anything recent from you in the rest of th= e email below) >From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same "two MAC-VRFs= on a same PEs", at worse it is as efficient or as inefficient as having th= em on separate PEs (think logical router without anykind of dataplane optim= isation), and we can't exclude that the PE could have local implementation = details to do better than that. 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. Your point above certainly does not sound to me as "it can't be done": some= may think that the above is an acceptable cost, some others may find ways = to make this "replication" with a low overhead, on some platforms the cost = may be negligible, etc. 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. You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets. The current proposal is very efficient in terms of forwarding path as well = as control plane. Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough. I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2. Here is a proposal: 2.2 Scenario 2: Leaf of Root site(s) per AC In these scenarii, 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 Root(s) or Leaf(s) (but not both). 2.2.1 Scenario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | |MAC+--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |VRF| | (Leaf) +---+ | |VRF| | | /IP | | '---' | | | | | | | | .---. | | | | | | | | |MAC| | +---+ | | | | | | | |VRF+--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2a In this scenario, the RT constraint procedures described in section 2.1 = could also be used. The feasibility and efficiency of this approach depends on platforms specifics. This approach will lead toduplication of a large proportion of MAC addre= sses on PEs having both Leaf and Root sites, and is hence considered less suitab= le for deployment contexts where the vast majority of PEs are likely to ultimat= ely have both Leaf and Root sites attached to them. 2.2.2 Scenario 2b: Leaf OR Root site(s) per AC, single MAC-VRF +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2b This scenario will alleviate keys drawbacks from Scenario 2a, in particu= lar by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding t= he operational overhead of managing more than one RT. This approach comes at the expense of having routes for unneeded MAC add= resses on Leaf-only PEs, and is hence considered less suitable for deployment c= ontexts where the vast majority of PEs would remain Leaf-only. Unlike Scenario= 1 and Scenario 2a, this scenario requires additional procedures provided in this document. (And this last sentence should be added to section 2.3 as well) 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 addresses on the Leaf PEs." Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2. Best, -Thomas --_000_D49E9B471C84B9sajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Thomas,

Thanks very much for shepherding this draft and providing valuable com= ments. I have just posted the new rev with all the edits incorproated.

We can now move to the next draft in the queue - draft-ietf-= bess-evpn-overlay-07. 

Regards,
Ali

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Friday, January 13, 2017 at 1= 2:33 PM
To: Cisco Employee <sajassi@cisco.com>, Loa Andersson <loa@pi.nu>, "George Swallow -T (swallow= - MBO PARTNERS INC at Cisco)" <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

Hi Ali,

I'm fine with the new text, thanks for the work on addressing my comments.<= br> You can post a revision and I will wrap-up the shepherd review in parallel.=

Best,

-Thomas

2017-01-13, Ali Sajassi (sajassi):
Hi Thomas,

Please refer to the comment resolution below:

From: Thomas Morin <thomas.morin@orange= .com>
Organization: Orange
Date: Friday, January 13, 2017 at 1= :22 AM
To: Cisco Employee <sajassi@cisco.com>= , Loa Andersson <l= oa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS = <bess@ietf.org= >
Cc: Martin Vigoureux <martin.vigoure= ux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

One comment on what seems to me the last pending issue.

Ali:
>>Thomas:
I think that this explanation is = too elliptic compared to the strong ("not viable") conclusion. As= soon as we talk about implementation details, a more detailed discussion i= s required on why, and under which assumptions, some things are impossible  -- there can be many different way to imp= lement a dataplane. Without explaining what "two lookups" exactly= means in this context, it's hard to follow why it would be required if dup= licating MAC addresses is not done, and why it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on ro= uter platforms
- on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow)
- if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup  (building one table, ma= rking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't = misunderstand me: I'm not claiming that this works (I haven't looked closel= y enough), but simply that the text provided is not sufficient to exclude t= his kind of solution

The "duplicating MAC addresses" alternative is explained better, = but still, nothing is explained on why this is "not viable". It s= eems to be as something rather belonging to the realm of "having a sca= lability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investi= gation that I did for micro-code and ASIC based platforms; however, I = see your point and I am para-phrasing the sentence as follow to leave = room for future investigation. 
"In order to avoid two MAC-VRFs, this dra= ft introduces the coloring option (B) as detailed in section 3.1"


This is better, but:
- the text still makes a statement that either two lookups or duplicating M= ACs is required, without much explanation
- the logic is not consolidated: if either X or Y is required, then its ill= ogical to say "In order to avoid X, this drafts introduces Z...."=   (Z being different than Y)
- the text still misses an explanation on why avoiding two MAC-VRFs was des= ired

If we can't (or don't want to spend time on) explaining the details on why = something else than "two MAC RVFs" was deemed useful, then perhap= s we could simplify the whole paragraph into something like:

      Because option (A) is not believed to be imp= lementable without dataplane performance inefficiencies some platforms, thi= s drafts introduces the coloring option (B) in section 3.1.

I modified the last sentence as below:<= /div>
"Because of potential inefficiencies asso= ciated with data-plane implementation of additional MAC lookup or duplicati= on of MAC entries, option (A) is not believed to be implementable without d= ataplane performance inefficiencies in some platforms and thus this draft introduces the coloring option (B) as d= etailed in section 3.1.=94

The logic is as follow: Option A requires= either X (two MAC lookup) or Y (duplication of MAC entries). Because = of potential data-plane inefficiencies for X or Y (which is needed for=  option A), we are suggesting option B.

The whole paragraph is as below:
"Maintaining two MAC-VRFs (two bridge tab= les) per VLAN (when both Leaf and Root ACs exists for that VLAN) would eith= er require two lookups be performed per MAC address in each direction in ca= se of a miss, or duplicating many MAC addresses between the two bridge tables belonging to the same VLAN (same E-TREE inst= ance). Unless two lookups are made, duplication of MAC addresses would be n= eeded for both locally learned and remotely learned MAC addresses. Locally = learned MAC addresses from Leaf ACs need to be duplicated onto Root bridge table and locally learned MAC a= ddresses from Root ACs need to be duplicated onto Leaf bridge table. Remote= ly learned MAC addresses from Root ACs need to be copied onto both Root and= Leaf bridge tables. Because of potential inefficiencies associated with data-plane implementation of addi= tional MAC lookup or duplication of MAC entries, option (A) is not believed= to be implementable without dataplane performance inefficiencies in some p= latforms and thus this draft introduces the coloring option (B) as detailed in section 3.1."

Cheers,
Ali


Best,

-Thomas



2017-01-13, Ali Sajassi (sajassi):



Hi Ali,

2016-12-19, Ali Sajassi (sajassi):
I have modified section 2.2 (copied below) to elaborate why coloring a= pproach for Leaf/Root MAC addresses is used in this draft. Also, the use of= single RT for this scenario is mentioned just as =93MAY=94. Please review = the text below and let me know if you still have questions/comments:

Thanks for providing text that goes in the right direction.
I still have a few comments below.

-Thomas



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

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


                  &nb= sp;  +---------+            += ;---------+
                  &nb= sp;  |   PE1   |            | =   PE2   |
    +---+           &nb= sp;|  +---+  |  +------+  |  += ---+  |            +---+
    |CE1+-----ES1----+--+   |  | &= nbsp;|      |  |  |   +--+---ES2/AC1-= -+CE2|
    +---+    (Leaf)  |  |MAC= |  |  | MPLS |  |  |MAC|  |   (Leaf)   &= #43;---+
                  &nb= sp;  |  |VRF|  |  |  /IP |  |  |VRF| &nb= sp;|
                  &nb= sp;  |  |   |  |  |      |  | =  |   |  |            +---&= #43;
                  &nb= sp;  |  |   |  |  |      |  | =  |   +--+---ES2/AC2--+CE3|
                  &nb= sp;  |  +---+  |  +------+  | &nbs= p;+---+  |   (Root)   +---+
                  &nb= sp;  +---------+            += ;---------+

   Figure 2: Scenario 2

   In this scenario, just like the previous scenario (in= section 2.1),
   two Route Targets (one for Root and another for Leaf)= can be used.
   However, the difference is that on a PE with both Roo= t and Leaf ACs,
   all remote MAC routes are imported and thus there nee= ds to be a way
   to differentiate remote MAC routes associated with Le= af ACs versus
   the ones associated with Root ACs in order to apply t= he proper
   ingress filtering. 

   In order to support such ingress filtering on the ing= ress PE with
   both Leaf and Root ACs, one the following two approac= hes can be used:

reverting A and B would be more natural since solution B corresponds to the= starting point "what we had before this spec"

Done.

   A) Color MAC addresses with Leaf (or Root) color befo= re distributing
   them in BGP to other PEs depending on whether it is l= earned on a Leaf

s/it is/they are/

Done.

   AC (or a Root AC)

I think removing the parenthesis is needed for the 'whether' statement to p= arse.

Done.

   B) Use two MAC-VRFs (two bridge tables per VLANs) - o= ne for Root ACs
   and another for Leaf ACs.

I think "(two bridge tables per VLANs)" is inexact:  "t= wo bridge tables per VLAN if a given VLAN exists on the PE for both Leaf an= d Root ACs of a given EVI" ?

That=92s fin= e. Done!


Similarly, in the following paragraph, I think "per VLAN" should = be replaced by "per E-TREE EVI having both Root and Leaf ACs".

A single EVI can consist of many VLANs (in cas= e of VLAN-aware bundle service), so, =93per VLAN=94 is right. However,= to make it more exact as above, I=92ll change it to =93per = VLAN (when both Root and Leafs ACs exist for that VLAN) requires = =85=94.




   Maintaining two bridge tables per VLAN requires eithe= r two lookups be
   performed per MAC address in either direction in case= of a miss, or
   duplicating many MAC addresses between the two bridge= tables
   belonging to the same VLAN (same E-TREE instance). Th= e duplication of
   MAC addresses are need for both locally learned and r= emotely learned
   MAC addresses.

Since it is said above "Maintaining two bridge tables per VLAN require= s either two lookups [...] or duplicating many MAC addresses [...]", s= aying "The duplication of MAC addresses is needed for [...]" = ; is surprising, so I guess the intent is rather "Unless two lookups are made, duplication of MAC addresses would be needed for [..= .]".

That is correct. I=92ll change it to the&= nbsp;sentence that you suggested: =93Unless two lookups are made, = ;=85"


   Locally learned MAC addresses from Leaf ACs need to b= e
   duplicated onto Root bridge table and locally learned= MAC addresses
   from Root ACs need to be duplicated onto Leaf bridge = table. Remotely
   learned MAC addresses from Root ACs need to be copied= onto both Root
   and Leaf bridge tables.
   Neither double lookups nor MAC duplications
   are considered viable options; therefore, this draft = recommends the
   use of MAC address coloring for this scenario as deta= iled in section
   3.1.   


I think that this explanation is too elliptic compared to the strong ("= ;not viable") conclusion. As soon as we talk about implementation deta= ils, a more detailed discussion is required on why, and under which assumpt= ions, some things are impossible  -- there can be many different way to implement a dataplane. Without explaining wha= t "two lookups" exactly means in this context, it's hard to follo= w why it would be required if duplicating MAC addresses is not done, and wh= y it is latter concluded as "not viable":
- doing multiple lookups is something that is far from being uncommon on ro= uter platforms
- on software platforms the impact of doing multiple lookups can be reduced= to mostly zero (e.g. with OpenVSwitch that would only impact the first pac= kets of a flow)
- if the dataplane can leverage the colouring information to avoid doing tw= o lookups, then perhaps this hardware ability can be leveraged to support t= he two MAC-VRFs approach with only one lookup  (building one table, ma= rking MAC entries as Leaf entries if they were learned with routes carrying only the Leaf RT?)  --- don't = misunderstand me: I'm not claiming that this works (I haven't looked closel= y enough), but simply that the text provided is not sufficient to exclude t= his kind of solution

The "duplicating MAC addresses" alternative is explained better, = but still, nothing is explained on why this is "not viable". It s= eems to be as something rather belonging to the realm of "having a sca= lability impact", but even looking in this respect we are not talking about a change of order of magnitude.

The non-viable conclusion was based on investi= gation that I did for micro-code and ASIC based platforms; however, I = see your point and I am para-phrasing the sentence as follow to leave = room for future investigation. 
"In order to avoid two MAC-VRFs, this dra= ft introduces the coloring option (B) as detailed in section 3.1"



   For this scenario, if for a given EVI, the vast major= ity of PEs will
   have both Leaf and Root sites attached, even though t= hey may start as
   Root-only or Leaf-only PEs, then a single RT per EVI = MAY be used in
   order to alleviate  additional configuration ove= rhead associated with

"to alleviate  additional configuration overhead associated with = ..." -> "to alleviate the configuration overhead associated wi= th ..." ?

Done.

   using two RTs per EVI at the expense of having unwant= ed MAC addresses
   on the Leaf-only PEs. 







From: Thomas Morin <thomas.morin@orange= .com>
Organization: Orange
Date: Thursday, December 15, 2016 a= t 4:12 AM
To: Cisco Employee <sajassi@cisco.com>= , Loa Andersson <l= oa@pi.nu>, "George Swallow -T (swallow - MBO PARTNERS INC at Cisco)" <swallow@cisco.com>, Eric Rosen <erosen@juniper.net>, BESS = <bess@ietf.org= >
Cc: Martin Vigoureux <martin.vigoure= ux@nokia.com>
Subject: Re: shepherd review of dra= ft-ietf-bess-evpn-etree

Hi Ali,

2016-12-13, Ali Sajassi (sajassi):

2016-12-10, Ali Sajassi (sajassi):
Your suggestion regarding multiple MAC-VRFs per EVI for E-TREE, impact= s lot more sections than just section 2.2 for which you suggested some text= s. It drastically  impacts section 3.1 (known unicast traffic), and it= also impacts section 3.2 (BUM traffic) and section 5.1.

Can you detail why ?
The understanding that leads me to this suggestion is that the 2-RT+spl= it-horizon scenario in 2.1, then applied to Root/Leaf PE in a 2.2.1 would n= ot require new procotol procedures nor changes in the text that as I unders= tand provides procedures for 2.2(.2) and 2.3.
2nd try. As my 1st response got truncated for some reason.

The reason t= hat impacts more sections than just sec. 2, is that the proposed 2.2.1 woul= d be an alternative option for section 3.1. In section 3.1, the root/leaf i= ndication for MAC addresses are done via flag-bit defined in section 5.1 and it only uses a single MAC-VRF (sin= gle bridge table per VLAN) per RFC 7432. If we go with two MAC-VRFs (e.g., = two bridge tables) per VLAN, then that is an alternative way of doing = the same thing described in section 3.1. This alternative way has big ramifications on the platform as it requires = duplicating MACs and managing multiple bridge tables per VLAN.

Since 2.1 and the proposed 2.2.1 do not require new protocol procedures (th= ey only require split-horizon locally in Leaf MAC-VRFs), if you state clear= ly that the procedures in the document are here to address 2.2.2 and 2.3, t= hen you don't need to modify the content of the document after section 2  (more exactly, you will need= minor update like changing the current "This scheme applies to all sc= enarios described in section 2." in section 3 into "This scheme a= pplies to scenarios described in 2.2.2 and 2.3".
 
The "big ramifications" above are then not about section 3, but j= ust the (platform specific-drawbacks) of 2.2.2 that we have already discuss= ed and that can be covered in 2.2.2.

=
Maybe what you really want is to allow for sce= nario 2.2 to operate with two RTs which has the benefits of both 2.2.1 and = 2.2.2 and non of the drawbacks. So, maybe we can clarify the current text t= o make sure that this comes out clearly =96 ie, a PE can have single MAC=96VRF can have multiple RTs.

You could mention that, but for me the key things is:
- documenting the motivation for the new procedures
- not arbitrarily /restrict/ 2.2.2 to one RT (but why not document identifi= ed drawbacks)

=

Furthermore, it creates a new paradigm for EVPN that was never intende= d for because of creating two MAC-VRFs (and two bridge tables) for the same= VLAN.

The "<new thing> created a new paradigm that <RFX xyz> was= never intended for" is a not generally valid, or sufficiently detaile= d, argument: if it was, then you might go as far as challenging the whole E= -Tree spec on the same kind grounds (and many other new things).

So here is where it seems we have a gap to bridge: I still don't understand= what in RFC7432 describes an intention of "not supporting two MAC-VRF= s for the same VLAN".

I tried to explain the relationship between EV= I, MAC-VRF, bridge table, and VLAN in my previous email per RFC 7432. = However, lets park this discussion for time being as I think it is sec= ondary.

Ok, feel free to revisit if you think that RFC7432 would preclude procedure= s that end up being described in this draft

=
I think you agree that if we have a single sol= ution that has all the benefits of your proposed 2.2.1 and 2.2.2 and none o= f the drawbacks, it is much more preferable with having two solutions each = with its own advantages and draw backs, right? If so, then existing text in 2.2 was intended to convey that. Howev= er, we can clarify it further =96 e.g, make it clear that for PE = with root & leaf in the same EVI, we can use a single MAC-VRF with= two RTs (one for leaf and another for root).

As said above my key concern is having the document clearly spell out the m= otivation for new specs.
If this implies documenting the fact that already existing procedure can be= used, but have drawbacks, then so be it ; there would be no point in hidin= g that, right ?


=

The WG LC was completed on 3/29/16 and I am sure it is not your intent= ion to have major changes to the doc at this stage where multiple vendors h= ave already implemented the draft.

As you know, there are different stages at which people do reviews on a doc= after WGLC, an which may lead doc editors to introduce significant --edito= rial or technical-- changes in a document. Sometimes that leads to document= s going back to the working group.

However my root intention as doc shepherd, of course, is not to propose a m= ajor change, but merely to able to answer the standard question of the shep= herd review -- on the reviews done, on document readiness, and on the docum= ent quality -- in a way as positive and sincere as possible. In particular questions (3) (4) and (6).

So, hopefully the answers to these three quest= ions are now clear. I believe your main concern is to ensure that= we can apply two-RT approach of sec. 2.1  to sec. 2.2 (and we can sti= ll do and still have a single MAC-VRF)

See above.
=


This draft talks about two kinds of traffic filtering: a) ingress filt= ering for known unicast and b) egress filtering for BUM traffic. What you a= re suggesting is an alternate mechanism for ingress filtering.

(well I'm not suggesting the mechanism itself --which section 2.1 already d= oes-- but simply to document that it can still apply without the constraint= of avoiding the presence of a Root MAC-VRF and a Leaf MAC-VRF on a same PE= )

Although having multiple VRFs (and forwarding tables) are fine for IP-= VPNs because the unknown traffic is always dropped, multiple VRFs for the s= ame VLAN is not OK for L2 traffic because of flooding of unknown traffic. T= hat=92s why in section 6 of RFC 7432, for all service interface types, the draft talks about a single MAC-VRF pe= r EVI per PE and in case of VLAN-aware mode,  multiple VLANs per MAC-V= RF but only a single bridge table per VLAN. In other words, the bottom line= is that there can only be a single bridge table per VLAN in order to avoid unnecessary flooding.



When you have two MAC-VRFs per VLAN (one for root ACs and another for = Leaf ACs), then you either need to duplicate lots of MAC addresses between = these two VRFs, or do lookup on both of these VRFs. Either ways this is not= a good option relative to keeping a single VRF table for both root and leaf sites and just have a single-bit= indication on whether a MAC is associated with root or leaf (as currently = described approach in the draft).  I


In the above, it seems you agree that it can work, and you are able to offe= r reasons why it is not the preferred option, then why not just document th= at it can work and provides these reasons as the motivations that lead to p= roposing a new specs ?

Sure, I can do that. [...]

Ok.
I'll be happy to review a new revision and hopefully post the shepherd revi= ew.

Thanks,

-Thomas


=

(it seems you have an unfinished last sentence: "I [...]" )


=


(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.

This section of RFC7434 discusses many different things for the different v= ariants.
Can you provide a specific pointer about "how many MAC-VRFs can be per= EVI" ?

Ali> Section 6 of RFC7432 spel= ls out the relationship between EVI, MAC-VRF, and bridge tables for all ser= vice interfaces very clearly.
=
In all service interfaces, the RF= C says there is one MAC-VRF per EVI on a given PE.
=
Now, if the service interface is = =93vlan-aware=94, then there are several bridge tables for that single MAC-= VRF =96 ie, one bridge table per VLAN. In all service interfaces, you can O= NLY have one bridge table per VLAN.

This answer is everything but a specific pointer.
If Section 6 of RFC7432 says all this very clearly, I guess it should be po= ssible to extract quotes about "there is one MAC-VRF per EVI on a given PE", right ?


=

In bridging world= , there can only be a single bridge table per VLAN in a device.

I still don't find here anything that would preclude having, on a given PE,= for a given E-TREE EVI, one Leaves MAC-VRF and one Roots MAC-VRF: can't th= ese two MAC-VRFs use different internal VLANs (with translation if the exte= rnal VLANs are constrained).

Ali>  Lets assume we are using vlan-based service and thus there is= only a single bridge table per MAC-VRF, then what you are suggesting is tw= o use two MAC-VRFs (two bridge tables) for the same EVI (same VLAN). This r= esults in some duplications of MAC addresses and would only work if flooding is disabled (more on this later).

"results in some duplications of MAC" is perhaps a drawback, but = nothing like "just does not work" ?

"would only work if flooding is disabled": why ?  (you wrote= "(more on this later)" but I couldn't identify anything recent f= rom you in the rest of the email below)


>From an helicopter view, I can't see what fundamentally would become proble= matic between "two MAC-VRFs on two distinct PEs" and the same &qu= ot;two MAC-VRFs on a same PEs", at worse it is as efficient or as inef= ficient as having them on separate PEs (think logical router without anykind of dataplane optimisation), and we can't exclude th= at the PE could have local implementation details to do better than that.

=

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 logical PEs in single physical PE, you end up replicating all the MAC addresses associ= ated with the root sites in two bridge tables.

Your point above certainly does not sound to me as "it can't be done&q= uot;: some may think that the above is an acceptable cost, some others may = find ways to make this "replication" with a low overhead, on some= platforms the cost may be negligible, etc.




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 th= ey *have* to be in the same MAC-VRF, you can rely on the local MPLS datapla= ne inside the PE to carry the traffic between Roots and Leaves can be passe= d between a Leaf MAC-VRF and a Root MAC-VRF (and you can possibly implement a shortcut not involving MPLS enca= p/decap).

Anything is possible but at what cost.

You know, for cost it is not always obvious to reach conclusions that are t= rue for all implementations and all targets.

The current proposal is= very efficient in terms of forwarding path as well as control plane.

Sure, but what I question is not the new solution but the lack of discussio= n on why using the existing specs was not considered good enough.


I think that my concern of clearly explaining the scenarios and motivations= for this new spec could be addressed by splitting section 2.2 into a 2.2.1= describing the approach from 2.1 and its possible drawbacks, and a 2.2.2 h= aving essentially the content of current section 2.2.

Here is a proposal:

2.2 Scen= ario 2: Leaf of Root site(s) per AC

 &n= bsp; In these scenarii, a PE receives traffic from either Root OR Leaf=
 &n= bsp; sites (but not both) on a given Attachment Circuit (AC) of an EVI. In<= /tt>
 &n= bsp; other words, an AC (ES or ES/VLAN) is either associated with Root(s)
 &n= bsp; or Leaf(s) (but not both).

2.2.1 Sc= enario 2a: Leaf OR Root site(s) per AC, separate Leaf/Root MAC-VRFs

 &n= bsp;            = ;       +---------+   =          +---------+
 &n= bsp;            = ;       |   PE1   | =            |   = PE2   |
 &n= bsp;  +---+        &nb= sp;   |  +---+  |  +------+  = |  +---+  |       &nbs= p;    +---+
 &n= bsp;  |CE1+-----ES1----+--+   |  |  |&= nbsp;     |  |  |MAC+--+---ES2/AC1--&= #43;CE2|
 &n= bsp;  +---+    (Leaf)  |  |MAC| = |  | MPLS |  |  |VRF|  |   (Leaf)  = ; +---+
 &n= bsp;            = ;       |  |VRF|  |  |  /= IP |  |  '---'  |
 &n= bsp;            = ;       |  |   |  | = |      |  |  .---.  |
 &n= bsp;            = ;       |  |   |  | = |      |  |  |MAC|  |  &= nbsp;         +---+
 &n= bsp;            = ;       |  |   |  | = |      |  |  |VRF+--+---ES2/AC2= --+CE3|
 &n= bsp;            = ;       |  +---+  |  &= #43;------+  |  +---+  |   (Root) = ;  +---+
 &n= bsp;            = ;       +---------+   =          +---------+

 &n= bsp; Figure 2: Scenario 2a

 &n= bsp; In this scenario, the RT constraint procedures described in section 2.= 1 could
 &n= bsp; also be used. The feasibility and efficiency of this approach depends = on
 &n= bsp; platforms specifics.

 &n= bsp; This approach will lead toduplication of = a large proportion of MAC addresses on
   PEs having both Leaf and Root sites, and is hence considered l= ess suitable for
   deployment contexts where the vast majority of PEs are likely = to ultimately
 &n= bsp; have both Leaf and Root sites attached to them.

2.2.2 Sc= enario 2b: Leaf OR Root site(s) per AC, single MAC-VRF

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

 &n= bsp; Figure 2: Scenario 2b

 &n= bsp; This scenario will alleviate keys drawbacks from Scenario 2a, in parti= cular
 &n= bsp; by avoiding duplication of MAC addresses on Leaf/Root PEs and avoiding= the
   operational overhead of managing mor= e than one RT.
   This approach comes at the expense of having routes for unneeded MAC addresse=
s
   on Leaf-only PEs, and is =
hence considered less suitable for deployment contexts
   where the vast majority of PEs would remain Leaf-only.   Unlike Sce=
nario 1 and Scenario 2a, this scenario requires additional procedures
   provided in this document.
(And this last sentence should be added to section 2.3 as well)


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 "majority", but was that you should= explain why you recommend that.
As the text currently reads, the cost of the recommendation can be identified= : having useless routes on the fraction of PEs having only Leaves. But the gain brought by the recommendation is not even mentioned, not to say e= xplained.
Hence: why ?
(Why is it a useful tradeoff to have 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."

Ok. I adapted and incorporated this addition into my proposed text splittin= g 2.2 into a 2.2.1 and a 2.2.2.

Best,

-Thomas







--_000_D49E9B471C84B9sajassiciscocom_-- From nobody Fri Jan 13 15:56:41 2017 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 82665129FA5; Fri, 13 Jan 2017 15:56:36 -0800 (PST) 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.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148435179652.9704.16832234610729801733.idtracker@ietfa.amsl.com> Date: Fri, 13 Jan 2017 15:56:36 -0800 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-09.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, 13 Jan 2017 23:56:36 -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 : E-TREE Support in EVPN & PBB-EVPN Authors : Ali Sajassi Samer Salam John Drake Jim Uttaro Sami Boutros Jorge Rabadan Filename : draft-ietf-bess-evpn-etree-09.txt Pages : 19 Date : 2017-01-13 Abstract: The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in and RFC called "A Framework for E-Tree Service over MPLS Network". This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates that RFC accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-09 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 Sun Jan 15 21:24:49 2017 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 E0C6B129513 for ; Sun, 15 Jan 2017 21:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 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=-1.156, 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 3Uf2UORV7qrQ for ; Sun, 15 Jan 2017 21:24:45 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.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 71FB512950C for ; Sun, 15 Jan 2017 21:24:45 -0800 (PST) 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=3Kk41Dlbys/IQ6oudswHioEpZ3wsTlH2KN8FolgUBzk=; b=TJZr0Ko/oheng5oMjYVOpZyjv0ZTOtgAbsebZDz/oyG7kITJP3QMNiB9wZazDac5ZZXIXkgVltIi0wWcHV+sYKfJ8NnGzoYF8aws3CYXMZ4bjjiFYS2QPwbQLIQs3yJR3hihtKP1LuvuUCFj735W7l8R4VzkXJdmfkGYPgMJVOo= Received: from CY4PR05MB2854.namprd05.prod.outlook.com (10.169.183.12) by CY4PR05MB2856.namprd05.prod.outlook.com (10.169.183.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Mon, 16 Jan 2017 05:24:41 +0000 Received: from CY4PR05MB2854.namprd05.prod.outlook.com ([10.169.183.12]) by CY4PR05MB2854.namprd05.prod.outlook.com ([10.169.183.12]) with mapi id 15.01.0860.008; Mon, 16 Jan 2017 05:24:41 +0000 From: Suraj Kumar To: "bess@ietf.org" Thread-Topic: New Version Notification for draft-surajk-evpn-access-security-00.txt Thread-Index: AQHSbMxwyDeBM5VHdkyMc4C5gq11jaE6lekQ Date: Mon, 16 Jan 2017 05:24:41 +0000 Message-ID: References: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.com> In-Reply-To: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.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=surajk@juniper.net; x-originating-ip: [116.197.184.10] x-ms-office365-filtering-correlation-id: a79ab27a-6e8f-4222-ec84-08d43dcff97c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB2856; x-microsoft-exchange-diagnostics: 1; CY4PR05MB2856; 7:Hahw25y3Wf3IyhcryXN9DqzVIyomDMFpq3N6BY2wVnduHn0KFSWC4iqUxHiuKHU031O5bR2arVQWAoy68iLv4MpU9Ve5Jyog8LLPf2LHjDWL01hu3MpMvYhGxsAxX/F+k7f6F7XOjJ7icusdXcBNHompiuWPSchG3b8zD8aM6yET7Uz34c2gCQNEQI0tvl+/dUfcEFN9sTiqDXsgNYV38+tt32qDLVAL8J8THns0pL4hYz4qqjRTQi2bbsIi+D3O/GObUqCsXl94O2m15g+EpeQAjxJON9ueB1RYe8QqZfAixvwXnuMOaE+mqSQrNmot8/F+xXbaYQqsRBdN6qt7vkIboD+rpdPnz4IhXlASJM4Dq4BvprLB9NefOHvlWCuehHtk/dUO9QMV/MuKNWyAVbA8xk2nrQM21S82b2iDfl2SaDv6qTJtEv7g0mR5dExnwDKwvDa7L72ZDRmnQZ3O6g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR05MB2856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2856; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(377424004)(377454003)(13464003)(199003)(189002)(15650500001)(81156014)(81166006)(3280700002)(8936002)(74316002)(77096006)(6506006)(38730400001)(8676002)(27001)(1730700003)(66066001)(54356999)(230783001)(50986999)(76176999)(55016002)(25786008)(2473003)(229853002)(305945005)(6306002)(2351001)(5640700003)(7736002)(2906002)(3660700001)(99286003)(2501003)(9686003)(6436002)(7696004)(97736004)(189998001)(33656002)(107886002)(110136003)(2900100001)(68736007)(122556002)(86362001)(101416001)(450100001)(106356001)(106116001)(5660300001)(3846002)(6116002)(102836003)(105586002)(92566002)(6916009)(2950100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2856; H:CY4PR05MB2854.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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: 16 Jan 2017 05:24:41.2755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2856 Archived-At: Subject: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.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, 16 Jan 2017 05:24:48 -0000 SGksDQpJIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgDQogICAiVGhlIGRyYWZ0IGRlZmluZXMgYSBu ZXcgQkdQIEVWUE4gcm91dGUgbWVzc2FnZSBmb3Igc3luY2luZyBESENQDQogICAgIHBhY2tldCBj b250ZW50cyBhcyB3ZWxsIGFzIHNub29wIGVudHJ5IGFtb25nIFBFcyBpbiBhbiBFdGhlcm5ldA0K ICAgICBTZWdtZW50IChFUykuICBUaGUgc25vb3AgZW50cnkgaXMgcmVxdWlyZWQgdG8gaW1wbGVt ZW50IER5bmFtaWMgQVJQDQogICAgIGluc3BlY3Rpb24gKERBSSksIElQIFNvdXJjZSBHdWFyZCAo SVBTRy9JUFNHdjYpIGFuZCBJUHY2IE5laWdoYm9yLg0KICAgICBEaXNjb3ZlcnkgSW5zcGVjdGlv biAoTkRJKSBhY2Nlc3Mgc2VjdXJpdHkgZmVhdHVyZXMuIg0KDQpQbGVhc2UgcmV2aWV3IHRoaXMg YW5kIHByb3ZpZGUgeW91ciBjb21tZW50cy4NCg0KLVRoYW5rcywNClN1cmFqDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTIs IDIwMTcgNTozNyBQTQ0KVG86IERlZXBhayBLYWtyYW5pYSA8ZGtha3JhbmlhQGp1bmlwZXIubmV0 PjsgU3VyYWogS3VtYXIgPHN1cmFqa0BqdW5pcGVyLm5ldD47IFZpamF5IEt1bWFyIER1bm5hIDxk dmlqYXlAanVuaXBlci5uZXQ+OyBWaWpheSBLdW1hciBEdW5uYSA8ZHZpamF5QGp1bmlwZXIubmV0 Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zdXJhamstZXZw bi1hY2Nlc3Mtc2VjdXJpdHktMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LXN1cmFqay1ldnBuLWFjY2Vzcy1zZWN1cml0eS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgU3VyYWogS3VtYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtc3VyYWprLWV2cG4tYWNjZXNzLXNlY3VyaXR5DQpSZXZpc2lv bjoJMDANClRpdGxlOgkJRVZQTiBBQ0NFU1MgU0VDVVJJVFkNCkRvY3VtZW50IGRhdGU6CTIwMTct MDEtMTINCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEyDQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXN1cmFq ay1ldnBuLWFjY2Vzcy1zZWN1cml0eS0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdXJhamstZXZwbi1hY2Nlc3Mtc2VjdXJpdHkv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN1cmFq ay1ldnBuLWFjY2Vzcy1zZWN1cml0eS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIGRyYWZ0IGRl ZmluZXMgYSBuZXcgQkdQIEVWUE4gcm91dGUgbWVzc2FnZSBmb3Igc3luY2luZyBESENQDQogICBw YWNrZXQgY29udGVudHMgYXMgd2VsbCBhcyBzbm9vcCBlbnRyeSBhbW9uZyBQRXMgaW4gYW4gRXRo ZXJuZXQNCiAgIFNlZ21lbnQgKEVTKS4gIFRoZSBzbm9vcCBlbnRyeSBpcyByZXF1aXJlZCB0byBp bXBsZW1lbnQgRHluYW1pYyBBUlANCiAgIGluc3BlY3Rpb24gKERBSSksIElQIFNvdXJjZSBHdWFy ZCAoSVBTRy9JUFNHdjYpIGFuZCBJUHY2IE5laWdoYm9yDQogICBEaXNjb3ZlcnkgSW5zcGVjdGlv biAoTkRJKSBhY2Nlc3Mgc2VjdXJpdHkgZmVhdHVyZXMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From nobody Sun Jan 15 22:46:01 2017 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 5D7D412951E for ; Sun, 15 Jan 2017 22:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 dSVlTc_hUTD4 for ; Sun, 15 Jan 2017 22:45:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDD2129513 for ; Sun, 15 Jan 2017 22:45:58 -0800 (PST) Received: from xandl ([46.189.28.191]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LikQP-1czJbJ09cr-00cwTA; Mon, 16 Jan 2017 07:45:52 +0100 From: "Alexander Marhold" To: "'Suraj Kumar'" , References: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 16 Jan 2017 07:45:51 +0100 Organization: Alexander Marhold Message-ID: <001701d26fc4$2de6f6b0$89b4e410$@gmx.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEaZeCXgCvtMQuCfnNOcnMBlnVTGgIk0RGMopmVXuA= Content-Language: de X-Provags-ID: V03:K0:V5oyBQQBiE3rfuOHv6OEAlINfhjXHVX/n3oJAg0HRmN9NDDEDqQ QilgK8OIcH7JWftsvKkiCw3VOtDPfFhLb4uAlTHm/SA5RhYuV25KKQyQBeCGbWjLNLhH48w YgoW75KX7hgD10/CLh1u92DuxeMUPmA8NRkbj+G5O31iWsqJVbWWLXXQHgdOfhWmRyo9f3U lvKbMsYw2p2mvZXIhXybA== X-UI-Out-Filterresults: notjunk:1;V01:K0:CKeHCKZFlNM=:I/OJ7Ec4gG8um+WCJ5avOh MKx9GB3wCIDqTwNUZtT/fY0NFz//XjhyzjAbRf9N6S7QmbGOsnnHjjCuns5l/IvrCUxyEz2ZC 5IWaCiWUdujLLw1cFy4lHDB4BBA6X3Uan6SRtJ1NGWHaeXt+tIr/1Emkg/HQ3ifRSbM5bpBjA 5s/q3flsZYUJpsfxg6wYC7fSmZcGMQBPBVlYDfv7NFt1REN7IqD1CVpQKHr7aE9mJ7xenyGW7 /aEzO4pdk64BafE/kY6bV3Ty48vyVhpsIA8uV6s2fwqn0nIx/YF4yFATwiFPqkCV3jgkrlVMO boveUiqzAM2lQ1N6SvLPqmdnhLXkj/mhjSjsp8ik+/3ORJGO3WhQwl3iIzkMxdkQyVdcqsDQ2 E9bOE377qp2m5BprzVB40taGsMVhVaajzUOjVrrsA4tNSpsf0Q/PtBMFkIpoaABmP7qeUCGZ/ YIycn1ArYd3ETvndAFhmTxMHUWHhmbtVH9oi8smULX9gu1jFQCvXN0aUxSVHHAY97HIVSfigU uUCD8G83FYyIy7ixqlpEGhGz230xTMdSPHdg//VLCuDnHicHvNOhaXJ67YQJdZ2FXf5cjG4W8 164kpw6nxBSNXokWbR9vLOXo7z+sEeo0mKmJ2FsF+OThIjkojIq8mCr1kAAqw4L3k6gJodR7e zEZ6corWhrzql9aYCAsovzdQ3nuo7cRqTq7UOU9zHoLawDQDmShfyElY1WKsRK6eR5YB9HSYa QFLj9PMwx71EElqjrD8tHJMz6PzlM21kdaQhhRJ++jDX3KXtIcaCsPlTDKfmeCn7c1GoIZRwe oWhVmOq Archived-At: Subject: Re: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: alexander.marhold@gmx.at List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 06:46:00 -0000 Hi ! By checking your draft I think you missed the original type 5 route = already defined not in the base EVOPN RFC but in other drafts for L3 information when writing, therefore should it not be type 6 ? This draft defines a new route (DHCP Snoop Advertisement route) The PE uses this route message for exchanging DHCP packet contents as well as complete bindings with other PE. ###################################### + 5 - DHCP Snoop Advertisement route ###################################### An DHCP Snoop Advertisement route type specific EVPN NLRI consists of the following: regards Alexander Marhold -----Urspr=FCngliche Nachricht----- Von: BESS [mailto:bess-bounces@ietf.org] Im Auftrag von Suraj Kumar Gesendet: Montag, 16. Januar 2017 06:25 An: bess@ietf.org Betreff: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt Hi, I have submitted a draft=20 "The draft defines a new BGP EVPN route message for syncing DHCP packet contents as well as snoop entry among PEs in an Ethernet Segment (ES). The snoop entry is required to implement Dynamic ARP inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor. Discovery Inspection (NDI) access security features." Please review this and provide your comments. -Thanks, Suraj -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, January 12, 2017 5:37 PM To: Deepak Kakrania ; Suraj Kumar ; Vijay Kumar Dunna ; Vijay = Kumar Dunna Subject: New Version Notification for draft-surajk-evpn-access-security-00.txt A new version of I-D, draft-surajk-evpn-access-security-00.txt has been successfully submitted by Suraj Kumar and posted to the IETF repository. Name: draft-surajk-evpn-access-security Revision: 00 Title: EVPN ACCESS SECURITY Document date: 2017-01-12 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-surajk-evpn-access-security-00= .tx t Status: https://datatracker.ietf.org/doc/draft-surajk-evpn-access-security/ Htmlized: https://tools.ietf.org/html/draft-surajk-evpn-access-security-00 Abstract: The draft defines a new BGP EVPN route message for syncing DHCP packet contents as well as snoop entry among PEs in an Ethernet Segment (ES). The snoop entry is required to implement Dynamic ARP inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor Discovery Inspection (NDI) access security features. =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. The IETF Secretariat _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Sun Jan 15 22:48:28 2017 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 CF93412943A for ; Sun, 15 Jan 2017 22:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fjCOpIb_w5nf for ; Sun, 15 Jan 2017 22:48:26 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0111.outbound.protection.outlook.com [104.47.36.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41CE1293F5 for ; Sun, 15 Jan 2017 22:48:25 -0800 (PST) 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=sNinktbCoznP5dEf7ybkqZb58juybujCI2Q8h0fLuYI=; b=a1aA961JeUAQDEg4AZMCtYXT2ftUChyNZGrLgfCaWLi+mW6TGpy94Fz3fGyWtbsi5pB0AgDmAxFLRJ2nCvfCwm0JtVM/6nUOvV8CzAJzmjTd/TXOgIhsWVscPHUy7wiPrOnjlM+vRCTWa88wCwhQWE+ZAZH7VQC8ZCE7f3Crzjk= Received: from CY4PR05MB2854.namprd05.prod.outlook.com (10.169.183.12) by CY4PR05MB2856.namprd05.prod.outlook.com (10.169.183.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Mon, 16 Jan 2017 06:48:24 +0000 Received: from CY4PR05MB2854.namprd05.prod.outlook.com ([10.169.183.12]) by CY4PR05MB2854.namprd05.prod.outlook.com ([10.169.183.12]) with mapi id 15.01.0860.008; Mon, 16 Jan 2017 06:48:24 +0000 From: Suraj Kumar To: "alexander.marhold@gmx.at" , "bess@ietf.org" Thread-Topic: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt Thread-Index: AQHSbMxwyDeBM5VHdkyMc4C5gq11jaE6lekQgAAY2ICAAABEUA== Date: Mon, 16 Jan 2017 06:48:23 +0000 Message-ID: References: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.com> <001701d26fc4$2de6f6b0$89b4e410$@gmx.at> In-Reply-To: <001701d26fc4$2de6f6b0$89b4e410$@gmx.at> 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=surajk@juniper.net; x-originating-ip: [116.197.184.10] x-ms-office365-filtering-correlation-id: b24ed570-62b6-442b-9133-08d43ddbaaef x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB2856; x-microsoft-exchange-diagnostics: 1; CY4PR05MB2856; 7:BCRW6x4umfILAeLNcvYGQ0Tvf1yVmznuByoQIBhKp7l32eUbyUEPol43wk7e+Ji0CkR06KVnuK6LX1ItGo/BS3IEeHk82XQQS38O0hQATh2HihQmbuJ9oHQFULIfrYL8sY27oIuOquw+77VvS5mOOcF54GBtKzOVPCJHWUUM9t2tMmJrJe24Ri2g0oJAXtt2YMwwo9AuP8RPVuYeaIpbgBr+IXbVEeX7VqPiWzegO7Ju7WaElBFsl64g2c8scMcQpbnKrpHjaEBeBi5cSmYjnwnMXGTSr82hjGYrNhAMOVo8FBeoztwHmzYsg7B5GA0MwPpwsSSbj3sT4rZn0N8IFHF/sfzWaFvOIlodaSwP/AUIQxo+HQPXVswqmK9wqSdYoesTvTcAIpGaMKWBeictcmwohUbBePuy2Ov9u0j+BmAZ5mMD204smnXjZIAPXF0aorGYfk8q/+PhafG7v+P8UA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR05MB2856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2856; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(199003)(13464003)(189002)(377454003)(377424004)(122556002)(86362001)(68736007)(101416001)(33656002)(107886002)(189998001)(97736004)(7696004)(2900100001)(5001770100001)(92566002)(2950100002)(106116001)(3846002)(6116002)(102836003)(106356001)(5660300001)(105586002)(66066001)(27001)(3280700002)(8936002)(15650500001)(81166006)(81156014)(8676002)(6506006)(38730400001)(74316002)(77096006)(25786008)(229853002)(55016002)(305945005)(2501003)(9686003)(7736002)(99286003)(6306002)(3660700001)(8666007)(2906002)(230783001)(54356999)(76176999)(50986999)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2856; H:CY4PR05MB2854.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2017 06:48:23.8869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2856 Archived-At: Subject: Re: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.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, 16 Jan 2017 06:48:28 -0000 Hi Alexander, Thanks for your review.=20 I have noted this . -Thanks, Suraj -----Original Message----- From: Alexander Marhold [mailto:alexander.marhold@gmx.at]=20 Sent: Monday, January 16, 2017 12:16 PM To: Suraj Kumar ; bess@ietf.org Subject: AW: [bess] FW: New Version Notification for draft-surajk-evpn-acce= ss-security-00.txt Hi ! By checking your draft I think you missed the original type 5 route already= defined not in the base EVOPN RFC but in other drafts for L3 information w= hen writing, therefore should it not be type 6 ? This draft defines a new route (DHCP Snoop Advertisement route) The PE uses this route message for exchanging DHCP packet contents as well as complete bindings with other PE. ###################################### + 5 - DHCP Snoop Advertisement route ###################################### An DHCP Snoop Advertisement route type specific EVPN NLRI consists of the following: regards Alexander Marhold -----Urspr=FCngliche Nachricht----- Von: BESS [mailto:bess-bounces@ietf.org] Im Auftrag von Suraj Kumar Gesendet: Montag, 16. Januar 2017 06:25 An: bess@ietf.org Betreff: [bess] FW: New Version Notification for draft-surajk-evpn-access-s= ecurity-00.txt Hi, I have submitted a draft=20 "The draft defines a new BGP EVPN route message for syncing DHCP packet contents as well as snoop entry among PEs in an Ethernet Segment (ES). The snoop entry is required to implement Dynamic ARP inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor. Discovery Inspection (NDI) access security features." Please review this and provide your comments. -Thanks, Suraj -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Thursday, January 12, 2017 5:37 PM To: Deepak Kakrania ; Suraj Kumar ; Vijay Kumar Dunna ; Vijay Kumar Dunna Subject: New Version Notification for draft-surajk-evpn-access-security-00.txt A new version of I-D, draft-surajk-evpn-access-security-00.txt has been successfully submitted by Suraj Kumar and posted to the IETF repository. Name: draft-surajk-evpn-access-security Revision: 00 Title: EVPN ACCESS SECURITY Document date: 2017-01-12 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-surajk-evpn-access-security-00.t= x t Status: https://datatracker.ietf.org/doc/draft-surajk-evpn-access-security/ Htmlized: https://tools.ietf.org/html/draft-surajk-evpn-access-security-00 Abstract: The draft defines a new BGP EVPN route message for syncing DHCP packet contents as well as snoop entry among PEs in an Ethernet Segment (ES). The snoop entry is required to implement Dynamic ARP inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor Discovery Inspection (NDI) access security features. =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jan 16 11:16:35 2017 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 5DA63129485 for ; Mon, 16 Jan 2017 11:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.057 X-Spam-Level: X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, 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 JwpkgqwVwZva for ; Mon, 16 Jan 2017 11:16:31 -0800 (PST) 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 BA3A9129486 for ; Mon, 16 Jan 2017 11:16:30 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id A29AA3FA60AB; Mon, 16 Jan 2017 19:16: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 v0GJGRtm007009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jan 2017 19:16:28 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v0GJGQIx023028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jan 2017 19:16:26 GMT Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.179]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Mon, 16 Jan 2017 20:16:25 +0100 From: "Rabadan, Jorge (Nokia - US)" To: Suraj Kumar , "alexander.marhold@gmx.at" , "bess@ietf.org" Thread-Topic: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt Thread-Index: AQHSbMxwyDeBM5VHdkyMc4C5gq11jaE6lekQgAAIFYCAAAC1gIABZ9sA Date: Mon, 16 Jan 2017 19:16:24 +0000 Message-ID: <5D56E207-BC8F-4CDF-8171-8824BFFE7F4D@on.nokia.com> References: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.com> <001701d26fc4$2de6f6b0$89b4e410$@gmx.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.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, 16 Jan 2017 19:16:33 -0000 SGksDQoNCk5vdCBvbmx5IHJvdXRlIHR5cGUgNS4gVHlwZXMgNiB0byAxMSBhcmUgYWxzbyByZXF1 ZXN0ZWQgaW4gb3RoZXIgQkVTUyBkb2N1bWVudHMuDQpDaGVjayBvdXQgZHJhZnQtaWV0Zi1iZXNz LWV2cG4tYnVtLXByb2NlZHVyZS11cGRhdGVzIGZvciBpbnN0YW5jZS4NClBsZWFzZSBkbyBub3Qg dXNlIHRob3NlLg0KDQpUaHgNCkpvcmdlDQoNCk9uIDEvMTYvMTcsIDM6NDggUE0sICJCRVNTIG9u IGJlaGFsZiBvZiBTdXJhaiBLdW1hciIgPGJlc3MtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2Ygc3VyYWprQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KSGkgQWxleGFuZGVyLA0KVGhhbmtzIGZv ciB5b3VyIHJldmlldy4gDQpJIGhhdmUgbm90ZWQgdGhpcyAuDQoNCi1UaGFua3MsDQpTdXJhag0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxleGFuZGVyIE1hcmhvbGQgW21h aWx0bzphbGV4YW5kZXIubWFyaG9sZEBnbXguYXRdIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE2 LCAyMDE3IDEyOjE2IFBNDQpUbzogU3VyYWogS3VtYXIgPHN1cmFqa0BqdW5pcGVyLm5ldD47IGJl c3NAaWV0Zi5vcmcNClN1YmplY3Q6IEFXOiBbYmVzc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtc3VyYWprLWV2cG4tYWNjZXNzLXNlY3VyaXR5LTAwLnR4dA0KDQoNCkhp ICENCg0KQnkgY2hlY2tpbmcgeW91ciBkcmFmdCBJIHRoaW5rIHlvdSBtaXNzZWQgdGhlIG9yaWdp bmFsIHR5cGUgNSByb3V0ZSBhbHJlYWR5IGRlZmluZWQgbm90IGluIHRoZSBiYXNlIEVWT1BOIFJG QyBidXQgaW4gb3RoZXIgZHJhZnRzIGZvciBMMyBpbmZvcm1hdGlvbiB3aGVuIHdyaXRpbmcsIHRo ZXJlZm9yZSBzaG91bGQgaXQgbm90IGJlIHR5cGUgNiA/DQoNCsKgwqAgVGhpcyBkcmFmdCBkZWZp bmVzIGEgbmV3IHJvdXRlIChESENQIFNub29wIEFkdmVydGlzZW1lbnQgcm91dGUpIFRoZQ0KwqDC oCBQRSB1c2VzIHRoaXMgcm91dGUgbWVzc2FnZSBmb3IgZXhjaGFuZ2luZyBESENQIHBhY2tldCBj b250ZW50cyBhcw0KwqDCoCB3ZWxsIGFzIGNvbXBsZXRlIGJpbmRpbmdzIHdpdGggb3RoZXIgUEUu DQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KwqDCoCArIDUgLSBESENQ IFNub29wIEFkdmVydGlzZW1lbnQgcm91dGUNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjDQrCoMKgIEFuIERIQ1AgU25vb3AgQWR2ZXJ0aXNlbWVudCByb3V0ZSB0eXBlIHNw ZWNpZmljIEVWUE4gTkxSSSBjb25zaXN0cyBvZg0KwqDCoCB0aGUgZm9sbG93aW5nOg0KDQpyZWdh cmRzDQoNCkFsZXhhbmRlciBNYXJob2xkDQoNCg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hy aWNodC0tLS0tDQpWb246IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1 ZnRyYWcgdm9uIFN1cmFqIEt1bWFyDQpHZXNlbmRldDogTW9udGFnLCAxNi4gSmFudWFyIDIwMTcg MDY6MjUNCkFuOiBiZXNzQGlldGYub3JnDQpCZXRyZWZmOiBbYmVzc10gRlc6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3VyYWprLWV2cG4tYWNjZXNzLXNlY3VyaXR5LTAwLnR4 dA0KDQpIaSwNCkkgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdCANCsKgwqAgIlRoZSBkcmFmdCBkZWZp bmVzIGEgbmV3IEJHUCBFVlBOIHJvdXRlIG1lc3NhZ2UgZm9yIHN5bmNpbmcgREhDUA0KwqDCoMKg wqAgcGFja2V0IGNvbnRlbnRzIGFzIHdlbGwgYXMgc25vb3AgZW50cnkgYW1vbmcgUEVzIGluIGFu IEV0aGVybmV0DQrCoMKgwqDCoCBTZWdtZW50IChFUykuwqDCoFRoZSBzbm9vcCBlbnRyeSBpcyBy ZXF1aXJlZCB0byBpbXBsZW1lbnQgRHluYW1pYyBBUlANCsKgwqDCoMKgIGluc3BlY3Rpb24gKERB SSksIElQIFNvdXJjZSBHdWFyZCAoSVBTRy9JUFNHdjYpIGFuZCBJUHY2IE5laWdoYm9yLg0KwqDC oMKgwqAgRGlzY292ZXJ5IEluc3BlY3Rpb24gKE5ESSkgYWNjZXNzIHNlY3VyaXR5IGZlYXR1cmVz LiINCg0KUGxlYXNlIHJldmlldyB0aGlzIGFuZCBwcm92aWRlIHlvdXIgY29tbWVudHMuDQoNCi1U aGFua3MsDQpTdXJhag0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTcgNTozNyBQTQ0KVG86IERlZXBhayBLYWtyYW5p YSA8ZGtha3JhbmlhQGp1bmlwZXIubmV0PjsgU3VyYWogS3VtYXIgPHN1cmFqa0BqdW5pcGVyLm5l dD47IFZpamF5IEt1bWFyIER1bm5hIDxkdmlqYXlAanVuaXBlci5uZXQ+OyBWaWpheSBLdW1hciBE dW5uYSA8ZHZpamF5QGp1bmlwZXIubmV0Pg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KZHJhZnQtc3VyYWprLWV2cG4tYWNjZXNzLXNlY3VyaXR5LTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zdXJhamstZXZwbi1hY2Nlc3Mtc2VjdXJpdHktMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN1cmFqIEt1bWFyIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYNCnJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1zdXJhamstZXZw bi1hY2Nlc3Mtc2VjdXJpdHkNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlFVlBOIEFDQ0VTUyBTRUNV UklUWQ0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wMS0xMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOgkJMTINClVSTDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1zdXJhamstZXZwbi1hY2Nlc3Mtc2VjdXJpdHktMDAudHgNCnQNClN0YXR1czoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXN1cmFqay1ldnBuLWFjY2Vz cy1zZWN1cml0eS8NCkh0bWxpemVkOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXN1cmFqay1ldnBuLWFjY2Vzcy1zZWN1cml0eS0wMA0KDQoNCkFic3RyYWN0Og0KwqDCoCBUaGUg ZHJhZnQgZGVmaW5lcyBhIG5ldyBCR1AgRVZQTiByb3V0ZSBtZXNzYWdlIGZvciBzeW5jaW5nIERI Q1ANCsKgwqAgcGFja2V0IGNvbnRlbnRzIGFzIHdlbGwgYXMgc25vb3AgZW50cnkgYW1vbmcgUEVz IGluIGFuIEV0aGVybmV0DQrCoMKgIFNlZ21lbnQgKEVTKS7CoMKgVGhlIHNub29wIGVudHJ5IGlz IHJlcXVpcmVkIHRvIGltcGxlbWVudCBEeW5hbWljIEFSUA0KwqDCoCBpbnNwZWN0aW9uIChEQUkp LCBJUCBTb3VyY2UgR3VhcmQgKElQU0cvSVBTR3Y2KSBhbmQgSVB2NiBOZWlnaGJvcg0KwqDCoCBE aXNjb3ZlcnkgSW5zcGVjdGlvbiAoTkRJKSBhY2Nlc3Mgc2VjdXJpdHkgZmVhdHVyZXMuDQoNCg0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpC RVNTIG1haWxpbmcgbGlzdA0KQkVTU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iZXNzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpCRVNTIG1haWxpbmcgbGlzdA0KQkVTU0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQoNCg0KDQo= From nobody Mon Jan 16 20:06:35 2017 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 175D51299AF; Mon, 16 Jan 2017 20:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Gf-wNfQ93C1f; Mon, 16 Jan 2017 20:06:27 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0121.outbound.protection.outlook.com [104.47.32.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BC4129466; Mon, 16 Jan 2017 20:06:27 -0800 (PST) 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=bQjFBQ64bptQPloBQDh4zEQuBP2Hve82GhEFsE296X8=; b=VuQUSXpuVENw3x0Y7nI9t7MfXqaWFtkYElAlVDT/Dj2WtOGMJpfmlKAPEn1qglCLxJTV/EPX7YoRsCgQoe98R/j8fF6S7UmROn4L+/gZyDf6opbEthcJ7TN1nVylNhAYqJgiIuMm6rZ08d2Vnogo9dnuwxaAh207QvDxe0XEc7k= Received: from CY1PR0501MB2075.namprd05.prod.outlook.com (10.164.3.25) by CY1PR0501MB2076.namprd05.prod.outlook.com (10.164.3.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 04:06:25 +0000 Received: from CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) by CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) with mapi id 15.01.0860.012; Tue, 17 Jan 2017 04:06:25 +0000 From: Sudhin Jacob To: "bmwg@ietf.org" , "bess@ietf.org" Thread-Topic: REG:draft-kishjac-bmwg-evpntest-04 Thread-Index: AdJwdlX1rqaP3olNTsyIBf0wjozbVA== Date: Tue, 17 Jan 2017 04:06:24 +0000 Message-ID: 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=sjacob@juniper.net; x-originating-ip: [116.197.184.13] x-ms-office365-filtering-correlation-id: b92430b3-15bd-4d1e-5c44-08d43e8e345b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB2076; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2076; 7:Ry/z3nNLJ2PU8hpqdQsgkTSWRH06M+peaPSDEgV6n3+PV9GnBkREWd1MnAJJDupDC40s4oTXsxLxhQH83DBS3KB3P8DCMWApWQgphHrhNiOxiBw/4JD0frBsINZwKGxcPIooPJ30YNbFeAMYVeSUbgGGfAmJOOYayTTo+0LBXIJ4owmUs1SyDZ7nPVZ+cmqKD+w3ridhqE3vDtJTqHxlKECkcV1YK5l5h5CZb150PBawQ7Q3afiWmD9/NZX1SiE4K2x7rb9okzTWbSddTXCgl+jVHYecxs89z6A68i7VnqUNgYnVdHdolhFeVUot3eOTh99X7p0Ol9zjDBh70qci5yMAuoEKS3Fm/EtYSesdiFMRtAAJ2v2+QLfBctlUi/HrVcNwMs8YYnFJ0b9Y96P0fV7oLx80ny8EsMdWHsKdgxTecmrzz9C4KWzib1846Fgi2Xi15joHPlRWgDXNb3tKZA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR0501MB2076; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2076; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(53754006)(189002)(199003)(101416001)(6436002)(33656002)(106356001)(305945005)(105586002)(74316002)(6506006)(5660300001)(122556002)(54356999)(450100001)(38730400001)(25786008)(3660700001)(6306002)(50986999)(55016002)(77096006)(99286003)(68736007)(230783001)(81166006)(81156014)(66066001)(2906002)(6116002)(102836003)(3846002)(2900100001)(8676002)(7736002)(8936002)(97736004)(5001770100001)(2501003)(9686003)(7696004)(30001)(86362001)(3280700002)(92566002)(107886002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2076; H:CY1PR0501MB2075.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: multipart/alternative; boundary="_000_CY1PR0501MB2075D0694E764B94EF32CF41C27C0CY1PR0501MB2075_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 04:06:24.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2076 Archived-At: Subject: [bess] REG:draft-kishjac-bmwg-evpntest-04 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, 17 Jan 2017 04:06:29 -0000 --_000_CY1PR0501MB2075D0694E764B94EF32CF41C27C0CY1PR0501MB2075_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Could you please review the above draft. I have uploaded the latest version= of the draft, with the comments received from previous the IETF meeting. T= his draft is to benchmark the EVPN and PBB-EVPN services. May I humbly request you to review it and let me know the feedback. Regards, Sudhin --_000_CY1PR0501MB2075D0694E764B94EF32CF41C27C0CY1PR0501MB2075_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
Could you please review the above draft. I have uploaded the latest ve= rsion of the draft, with the comments received from previous the IETF meeti= ng. This draft is to benchmark the EVPN and PBB-EVPN services.
May I humbly request you to review it and let me know the feedback.
 
Regards,
Sudhin
 
 
 
 --_000_CY1PR0501MB2075D0694E764B94EF32CF41C27C0CY1PR0501MB2075_-- From nobody Mon Jan 16 21:19:55 2017 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 B8878129A61; Mon, 16 Jan 2017 21:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, 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 66GfOEodysQ5; Mon, 16 Jan 2017 21:19:53 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0139.outbound.protection.outlook.com [104.47.38.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94177129A5E; Mon, 16 Jan 2017 21:19:52 -0800 (PST) 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=8Q9Gt8m+LtQ7YHtFFzWMuPXIYNHNUnei16rfb43oIiU=; b=HxMEbVJoRfKPDPUcHDhZszwBNJ/cqP7B70XnsUzBDsws98hVN4p5Z4GgCtxe/HVQHdc6G8Z3PsZsxxAlZ3I72iG0QIqy/YA3QQxadcMmszR33Uq3zAnMOkq8qB6hQwzPZm3haB+YWX5ap5Vl/zvFhJawmP2vkxac9gIZ63++eN0= Received: from CY1PR0501MB2075.namprd05.prod.outlook.com (10.164.3.25) by CY1PR0501MB2074.namprd05.prod.outlook.com (10.164.3.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 05:19:50 +0000 Received: from CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) by CY1PR0501MB2075.namprd05.prod.outlook.com ([10.164.3.25]) with mapi id 15.01.0860.012; Tue, 17 Jan 2017 05:19:49 +0000 From: Sudhin Jacob To: "bmwg@ietf.org" , "bess@ietf.org" Thread-Topic: draft-kishjac-bmwg-evpntest-04 Thread-Index: AdJwgSfwWlLPj4JBQselwoIik/3u4Q== Date: Tue, 17 Jan 2017 05:19:49 +0000 Message-ID: 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=sjacob@juniper.net; x-originating-ip: [116.197.184.13] x-ms-office365-filtering-correlation-id: a120a18b-9c84-4faf-c27b-08d43e9875e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB2074; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2074; 7:go7QB6Vs0r5xKsQIvtfcKZB7HDC+et4CKPgPyRGPYl56Lf+3yVTvjga9XVHeSNGpH76NBPx6u8qn8QmBJH0BOXET1lAWSjLilo9VogrqssMCSMiyWwEb/jZas/nH5AGRPmRP8pXH3OpLmXrq1nDhL9Gi/rU3IFgq58drT4IofK0vYSs2mMIX30pfJygGJ8fyAtUR4hpRK1GDpCpW7o9QAjFdY4sPhbcjX+sPhiOrvr3cxwljhj2U5GU6RqbDWciy5vJlcToxRk1uzrVDK3OLlkx1LPUWg/hj3ESFNy2E4vh9Ln5vBesgbzqdEPzNw9H+3Oa4ECH1ZkePGP9we4iTTpsKhmxQLDBeAKA7h1Df2B4jRikpoPbwXCWjBD0u1j1RYdmHx9f0nPtlfAicG66aujNcR77FHRe+nLveHmNLUc3bszrOrAAc0tR/4/rtSFy5AZ21EhLE7F4Lnr517GK0Ww== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR0501MB2074; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2074; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39850400002)(39410400002)(39840400002)(53754006)(199003)(189002)(99286003)(2900100001)(6436002)(6306002)(66066001)(230783001)(105586002)(54356999)(8676002)(2501003)(38730400001)(6506006)(7696004)(81166006)(81156014)(33656002)(122556002)(9686003)(50986999)(8936002)(450100001)(55016002)(5001770100001)(97736004)(77096006)(74316002)(6116002)(25786008)(68736007)(2906002)(3660700001)(107886002)(3846002)(189998001)(86362001)(102836003)(3280700002)(106356001)(92566002)(305945005)(30001)(101416001)(7736002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2074; H:CY1PR0501MB2075.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0501MB2075D6D8D89CB3A4BF6E92E6C27C0CY1PR0501MB2075_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 05:19:49.9012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2074 Archived-At: Subject: [bess] REG:draft-kishjac-bmwg-evpntest-04 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, 17 Jan 2017 05:19:55 -0000 --_000_CY1PR0501MB2075D6D8D89CB3A4BF6E92E6C27C0CY1PR0501MB2075_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for the typo. Hi All, Could you please review the above draft. I have uploaded the latest version= of the draft with the comments addressed . This draft is to benchmark the = EVPN and PBB-EVPN services. May I humbly request you to review it and let me know the feedback. Regards, Sudhin --_000_CY1PR0501MB2075D6D8D89CB3A4BF6E92E6C27C0CY1PR0501MB2075_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Apologies for the typo.
 
Hi All,
 
Could you please review the above draft. I have uploaded the latest ve= rsion of the draft with the comments addressed . This draft is to benchmark= the EVPN and PBB-EVPN services.
May I humbly request you to review it and let me know the feedback.
 
Regards,
Sudhin
 
 
 --_000_CY1PR0501MB2075D6D8D89CB3A4BF6E92E6C27C0CY1PR0501MB2075_-- From nobody Tue Jan 17 01:02:29 2017 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 014AF12941E; Tue, 17 Jan 2017 01:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.433 X-Spam-Level: X-Spam-Status: No, score=-4.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-3.199, 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 Q8-89CVODQB8; Tue, 17 Jan 2017 01:02:26 -0800 (PST) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4950E129407; Tue, 17 Jan 2017 01:02:20 -0800 (PST) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3497FE300A0; Tue, 17 Jan 2017 10:02:19 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 28252E3009D; Tue, 17 Jan 2017 10:02:19 +0100 (CET) Received: from [172.31.0.98] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 17 Jan 2017 10:02:18 +0100 To: , , References: <148422284411.19397.4817202253327536010.idtracker@ietfa.amsl.com> <001701d26fc4$2de6f6b0$89b4e410$@gmx.at> <5D56E207-BC8F-4CDF-8171-8824BFFE7F4D@on.nokia.com> From: Thomas Morin Organization: Orange Message-ID: Date: Tue, 17 Jan 2017 10:02:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5D56E207-BC8F-4CDF-8171-8824BFFE7F4D@on.nokia.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [bess] early allocation of evpn route type 5 (was Re: FW: New Version Notification for draft-surajk-evpn-access-security-00.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: Tue, 17 Jan 2017 09:02:28 -0000 Hi Jorge, It sounds a lot like we should register an early allocation for route type 5 ? As the editor of draft-ietf-bess-evpn-prefix-advertisement , would you be ok to bootstrap the early allocation process [1] ? This draft looks to me like it would match the requirements for early allocations ([2]). We can consider doing the same for draft-ietf-bess-evpn-bum-procedure-updates , as soon as we're certain enough that the specs are stable. Opinions are welcome on this. Best, -Thomas [1] https://tools.ietf.org/html/rfc7120#section-3.1 [2] https://tools.ietf.org/html/rfc7120#section-2 Rabadan, Jorge (Nokia - US): > Hi, > > Not only route type 5. Types 6 to 11 are also requested in other BESS documents. > Check out draft-ietf-bess-evpn-bum-procedure-updates for instance. > Please do not use those. > > Thx > Jorge > > On 1/16/17, 3:48 PM, "BESS on behalf of Suraj Kumar" wrote: > > Hi Alexander, > Thanks for your review. > I have noted this . > > -Thanks, > Suraj > > -----Original Message----- > From: Alexander Marhold [mailto:alexander.marhold@gmx.at] > Sent: Monday, January 16, 2017 12:16 PM > To: Suraj Kumar ; bess@ietf.org > Subject: AW: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt > > > Hi ! > > By checking your draft I think you missed the original type 5 route already defined not in the base EVOPN RFC but in other drafts for L3 information when writing, therefore should it not be type 6 ? > > This draft defines a new route (DHCP Snoop Advertisement route) The > PE uses this route message for exchanging DHCP packet contents as > well as complete bindings with other PE. > ###################################### > + 5 - DHCP Snoop Advertisement route > ###################################### > An DHCP Snoop Advertisement route type specific EVPN NLRI consists of > the following: > > regards > > Alexander Marhold > > > > -----Ursprüngliche Nachricht----- > Von: BESS [mailto:bess-bounces@ietf.org] Im Auftrag von Suraj Kumar > Gesendet: Montag, 16. Januar 2017 06:25 > An: bess@ietf.org > Betreff: [bess] FW: New Version Notification for draft-surajk-evpn-access-security-00.txt > > Hi, > I have submitted a draft > "The draft defines a new BGP EVPN route message for syncing DHCP > packet contents as well as snoop entry among PEs in an Ethernet > Segment (ES). The snoop entry is required to implement Dynamic ARP > inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor. > Discovery Inspection (NDI) access security features." > > Please review this and provide your comments. > > -Thanks, > Suraj > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, January 12, 2017 5:37 PM > To: Deepak Kakrania ; Suraj Kumar ; Vijay Kumar Dunna ; Vijay Kumar Dunna > Subject: New Version Notification for > draft-surajk-evpn-access-security-00.txt > > > A new version of I-D, draft-surajk-evpn-access-security-00.txt > has been successfully submitted by Suraj Kumar and posted to the IETF > repository. > > Name: draft-surajk-evpn-access-security > Revision: 00 > Title: EVPN ACCESS SECURITY > Document date: 2017-01-12 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-surajk-evpn-access-security-00.tx > t > Status: > https://datatracker.ietf.org/doc/draft-surajk-evpn-access-security/ > Htmlized: > https://tools.ietf.org/html/draft-surajk-evpn-access-security-00 > > > Abstract: > The draft defines a new BGP EVPN route message for syncing DHCP > packet contents as well as snoop entry among PEs in an Ethernet > Segment (ES). The snoop entry is required to implement Dynamic ARP > inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor > Discovery Inspection (NDI) access security features. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Jan 20 15:35:02 2017 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 88BCD1295A9 for ; Fri, 20 Jan 2017 15:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 F_rO9wvU2lVQ for ; Fri, 20 Jan 2017 15:34:59 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDFB1295A7 for ; Fri, 20 Jan 2017 15:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1484955299; x=1486164899; h=from:to:cc:subject:date:message-id:mime-version; bh=Sc/35C5rMqdMFTiW1thV+K+hdHKFcsvTg4xTaxeXLmk=; b=fy+eL2DHExHfyuYdLOe5zto5XqAMPQ5tk5yEqULacDMmNkzHh70KbPsV sPXBJrya0GsjM+HlyKPaAtZhVKSmw5m6pGtuWR0e/qbYwSFZA46wLuz7E IWBTc08Y9RXFfTAK4dmUmEzMBRccxSEtH0UsCi0nV1rcH4SqSXfLrPhEF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuAQBPnoJY/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9OAQEBAQEfgXCNVKIIhSuCDYYighc/FAECAQEBAQEBAWMohGC?= =?us-ascii?q?BCRIBCwF0JwQOiQuxUopJAQEBAQEFAQEBAQEBIpVoBZtIAZFmkG6ScwEfOIFFF?= =?us-ascii?q?YZviQ+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,260,1477958400"; d="scan'208,217";a="375354450" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2017 23:34:38 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0KNYbBw005274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jan 2017 23:34:38 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 18:34:37 -0500 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, 20 Jan 2017 18:34:37 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "Vigoureux, Martin (Nokia - FR)" Thread-Topic: draft-sajassi-bess-evpn-igmp-mld-proxy-01 Thread-Index: AQHSc3XDmGjqNfUsBkmYcL96F0V0Uw== Date: Fri, 20 Jan 2017 23:34:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.224.119] Content-Type: multipart/alternative; boundary="_000_D4A7DE8A1C8A4Esajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: [bess] draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 20 Jan 2017 23:35:00 -0000 --_000_D4A7DE8A1C8A4Esajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, Martin: The authors of the above draft would like to request for a WG call on this = draft. Several vendors are currently implementing this draft. Regards, Ali --_000_D4A7DE8A1C8A4Esajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <548B44625B2E01449EFCFEE8E64C0CF0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas, Martin:

The authors of the above draft would like to request for a WG call on = this draft. Several vendors are currently implementing this draft.

Regards,
Ali


--_000_D4A7DE8A1C8A4Esajassiciscocom_-- From nobody Wed Jan 25 20:39:22 2017 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 D67E212946C; Wed, 25 Jan 2017 20:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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=-3.199, 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 alwplt-boB3b; Wed, 25 Jan 2017 20:39:16 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91165129428; Wed, 25 Jan 2017 20:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39438; q=dns/txt; s=iport; t=1485405556; x=1486615156; h=from:to:cc:subject:date:message-id:mime-version; bh=YeQyZ1/0GJNreiZCiU3TFTaUasoC7SV/h/cSNVs3h2U=; b=cB4shp/x2Eri2+00a7SN/rYkZCWppuxDWeniypHH0SphrtbyfaEerNXY PMbrnMHguGWZ0D+DIHUymFHQteeE9ShSbtPV8HtqTPWqS8fVw7XvrFztN waC0W8GhpEBHHCAcrQn051x32Tr/mPIIwzidWbLWkq3FR++zKBue2R5ma M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAQCafIlY/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9GAQEBAQEfYIEQg06KCac6gg2GIhyCBz8YAQIBAQEBAQEBYh0?= =?us-ascii?q?LhRMKRwUSAQY6CgIEMCcEDhkHBIkBkGOdToIlK4pIAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYZLggWHQYJ4LoIxBZU8hhMBkXWBd4USiWiSeQEfOIFJFTsQAYQrHIF?= =?us-ascii?q?hiAmBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,287,1477958400"; d="scan'208,217";a="198402629" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jan 2017 04:39:14 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v0Q4dEVd007986 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jan 2017 04:39:14 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 22:39:13 -0600 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; Wed, 25 Jan 2017 22:39:13 -0600 From: "Alvaro Retana (aretana)" To: "draft-ietf-bess-evpn-vpws@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-evpn-vpws-07 Thread-Index: AQHSd44kA2pNPLQMm0qn/KFCiMDXRw== Date: Thu, 26 Jan 2017 04:39:13 +0000 Message-ID: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.254.11] Content-Type: multipart/alternative; boundary="_000_71E62DB532E4441D9D22290CFFC5BAD1ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeffrey Zhang , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: [bess] AD Review of draft-ietf-bess-evpn-vpws-07 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, 26 Jan 2017 04:39:19 -0000 --_000_71E62DB532E4441D9D22290CFFC5BAD1ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhdXRob3JzOg0KDQpIaSENCg0KSSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgdGhpcyBkb2N1 bWVudC4gIFBsZWFzZSB0YWtlIGEgbG9vayBhdCBteSBjb21tZW50cyBiZWxvdyDigJMgSSB0aGlu ayB0aGV5IHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUuICBJIHdpbGwgc3RhcnQgdGhlIElFVEYg TGFzdCBDYWxsIHdoZW4gdGhlIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYW5kIGEgbmV3 IHJldmlzaW9uIGhhcyBiZWVuIHB1Ymxpc2hlZC4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0K TWFqb3I6DQoNCk0xLiBUaGVyZSBhcmUgOCBhdXRob3JzIGxpc3RlZCBvbiB0aGUgZnJvbnQgcGFn ZS4gIEZvbGxvd2luZyB0aGUgZ3VpZGVsaW5lcyBpbiB0aGUgUkZDIFN0eWxlIEd1aWRlIFtSRkM3 MzIyXSwgd2Ugd2FudCB0aGUgbGlzdCB0byBiZSBhdCBtb3N0IDUuICBQbGVhc2Ugd29yayBhbW9u ZyB5b3Vyc2VsdmVzIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIGF1dGhvcnMuICBBbHRlcm5hdGl2 ZWx5LCB5b3UgY2FuIGp1c3QgbGlzdCBhbiBFZGl0b3Igb3IgdHdvLg0KDQoNCk0yLiBGcm9tIHRo ZSBJbnRyb2R1Y3Rpb246IOKAnFVubGlrZSBFVlBOIHdoZXJlIEV0aGVybmV0IFRhZyBJRCBpbiBF VlBOIHJvdXRlcyBhcmUgc2V0IHRvIHplcm/igKZpbiBFVlBOLVZQV1MsIEV0aGVybmV0IHRhZyBJ RCBpbiB0aGUgRXRoZXJuZXQgQS1EIHJvdXRlIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgdmFsdWUg aW4gYWxsIHRoZSBzZXJ2aWNlIGludGVyZmFjZSB0eXBlcy7igJ0gIFplcm8gaXMgYSB2YWxpZCB2 YWx1ZSBmb3IgdGhlIEV0aGVybmV0IFRhZyBJRC4gIFNlY3Rpb24gMy4gKEJHUCBFeHRlbnNpb25z KSBzYXlzIHRoYXQg4oCcdGhlIEV0aGVybmV0IFRhZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0IHRv IHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXLigJ0sIGJ1dCBJIGNv dWxkbuKAmXQgZmluZCBhIHBsYWNlIHdoZXJlIHRoZSBkb2N1bWVudCB0b2xkIG1lIHdoYXQgYSB2 YWxpZCB2YWx1ZSBpcy4gIElPVywgaG93IGNhbiB0aGUg4oCcTVVTVOKAnSBiZSBlbmZvcmNlZCBp ZiB0aGVyZeKAmXMgbm8gY2xlYXIgaW5kaWNhdGlvbiBvZiB3aGF0IGlzIHZhbGlkPyAgT1RPSCwg YW55IHNwZWNpZmljYXRpb24gd2FudHMgdGhlIGZpZWxkcyB0byBjb250YWluIHZhbGlkIHZhbHVl cywgb2J2aW91c2x5ISAgV2hhdCBoYXBwZW5zIGlmIHRoZSB2YWx1ZSBpcyBub3QgdmFsaWQ/ICAg IEJUVywgYWxsIHRoaXMgaXMgdG8gc2F5IHRoYXQgd2l0aG91dCBhIHByb3BlciBleHBsYW5hdGlv biAod2hpY2ggcHJvYmFibHkgZG9lc27igJl0IGJlbG9uZyBpbiB0aGUgSW50cm9kdWN0aW9uKSwg dGhlIHdob2xlIHBhcmFncmFwaCBpcyBzdXBlcmZsdW91cy4NCg0KDQpNMy4gVGhlIEludHJvZHVj dGlvbiBzYXlzIHRoYXQg4oCcRm9yIEVWUEwgc2VydmljZSwgdGhlIEV0aGVybmV0IGZyYW1lcyB0 cmFuc3BvcnRlZCBvdmVyIGFuIE1QTFMvSVAgbmV0d29yayBTSE9VTEQgcmVtYWluIHRhZ2dlZCB3 aXRoIHRoZSBvcmlnaW5hdGluZyBWSUQgYW5kIGFueSBWSUQgdHJhbnNsYXRpb24gaXMgcGVyZm9y bWVkIGF0IHRoZSBkaXNwb3NpdGlvbiBQRS7igJ0sIGxhdGVyIHRoZSBzYW1lIChvciBhdCBsZWFz dCBzb21ldGhpbmcgc2ltaWxhcikgaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMi4xLiAoVkxBTi1C YXNlZCBTZXJ2aWNlIEludGVyZmFjZSk6IOKAnHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0 ZWQgb3ZlciBhbiBNUExTL0lQIG5ldHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUg b3JpZ2luYXRpbmcgVklELCBhbmQgYSBWSUQgdHJhbnNsYXRpb24gTVVTVCBiZSBzdXBwb3J0ZWQg aW4gdGhlIGRhdGEgcGF0aCBhbmQgTVVTVCBiZSBwZXJmb3JtZWQgb24gdGhlIGRpc3Bvc2l0aW9u IFBFLuKAnSAgUGxlYXNlIGtlZXAgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBvbmUgcGxhY2Ug 4oCTIEkgYW0gbm90IGZvbmQgb2Ygbm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoZSBJbnRyb2R1Y3Rp b247IG5vdGUgdGhhdCBldmVuIHRob3VnaCB0aGUgcmVzdWx0IHNob3VsZCBiZSB0aGUgc2FtZSwg dGhlIHRleHQgaXMgZGlmZmVyZW50ICh0aGUg4oCcTVVTVHPigJ0gYXJlIHVzZWQgaW4gMi4xKS4N Cg0KTTMuMS4gW21pbm9yXSBJdCBpcyBub3QgY2xlYXIgaW4gdGhlIHRleHQgdGhhdCBFVlBMIHNl cnZpY2UgY29ycmVzcG9uZHMgdG8gVkxBTi1iYXNlZCBzZXJ2aWNlLiAgUGxlYXNlIGNsYXJpZnkg dGhhdC4gIEluIGZhY3QsIHNvbWUgb2YgdGhlIGZsb3cgb2YgdGhlIGRvY3VtZW50IGZlZWwgZGlz am9pbnQgYmVjYXVzZSBzbGlnaHRseSBkaWZmZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCBhbmQg bm8gaGludCBvZiBob3cgaXQgYWxsIHRpZXMgdG9nZXRoZXIgaXMgcHJlc2VudGVkOyBtYXBwaW5n IEVQTC9FVlBMIHRvIHRoZSBTZXJ2aWNlIEludGVyZmFjZXMsIHdoaWNoIGFyZSBvbmx5IG1lbnRp b25lZCBpbiBTZWN0aW9uIDIgKGFuZCB2ZXJ5IGJyaWVmbHkgaW4gdGhlIEludHJvZHVjdGlvbiDi gJMgc2VlIE0yKS4NCg0KDQpNNC4gU2VjdGlvbiAxLjIgaXMgdGl0bGVkIFJlcXVpcmVtZW50cy4g IEhvd2V2ZXIsIHRoZSBsaXN0IHNlZW1zIHRvIGluY2x1ZGUgYSBjb21iaW5hdGlvbiBvZiBzdGF0 ZW1lbnRzIG9mIGZhY3QgKOKAnEVQTCBzZXJ2aWNlIGFjY2VzcyBjaXJjdWl0IG1hcHMgdG8gdGhl IHdob2xlIEV0aGVybmV0IHBvcnTigJ06IHRoaXMgaXMgcHJldHR5IG11Y2ggdGhlIGRlZmluaXRp b24gb2YgRVBMKSwgc29sdXRpb24tc291bmRpbmcgbGluZXMgKOKAnEVhY2ggVkxBTiBpbmRpdmlk dWFsbHkgKG9yIDxTLVZMQU4sQy1WTEFOPiBjb21iaW5hdGlvbikgd2lsbCBiZSBjb25zaWRlcmVk IHRvIGJlIGFuIGVuZHBvaW50IGZvciBhbiBFVlBMIHNlcnZpY2XigJ06IG5vdCBvbmx5IGRvZXMg aXQgc291bmQgbGlrZSB3aGF0IHRoZSBzb2x1dGlvbiB3aWxsIGRvLCBidXQgaXQgaXMgYWxzbyB0 aGUgZGVmaW5pdGlvbiBvZiBFVlBMKSwgYW5kIHN0YXRlbWVudHMgdGhhdCB0YWxrIHRvIHRoZSBj b25maWd1cmF0aW9uIGFuZCBub3Qgd2hhdCB0aGUgdGVjaG5pY2FsIHNvbHV0aW9uIGRlc2NyaWJl ZCBsYXRlciBjYW4gZG8gKOKAnEEgZ2l2ZW4gUEUgY291bGQgaGF2ZSB0aG91c2FuZHMgb2YgRVZQ THMgY29uZmlndXJlZC4gSXQgbXVzdCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgbXVsdGlwbGUg RVZQTCBzZXJ2aWNlcyB3aXRoaW4gdGhlIHNhbWUgRVZJLuKAnTogaXMgdGhlcmUgYW4gYWN0dWFs IHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50PykuICAgICBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgYWN0 dWFsIHJlcXVpcmVtZW50cyAoZm9yIGV4YW1wbGU6IOKAnEVQTCBzZXJ2aWNlIGFjY2VzcyBjaXJj dWl0cyBNVVNUIG1hcCB0byB0aGUgd2hvbGUgRXRoZXJuZXQgcG9ydOKAnTsgbm9ybWF0aXZlIGxh bmd1YWdlIGlzIG5vdCByZXF1aXJlZCkgdGhhdCBJIGNhbiB0aGVuIGNoZWNrIGFnYWluc3QgdGhl IHNvbHV0aW9uIOKAkyBidXQgaXQgYWxsIHNvdW5kcyBsaWtlIGEgcmVoYXNoIG9mIHdoYXQgd2Fz IGV4cGxhaW5lZCBiZWZvcmUuICDimLkNCg0KDQpNNS4gU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lv bnMpIHNheXMgdGhhdCDigJxUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgdGhlIHBl ciBFVkkgRXRoZXJuZXQgQS1EIHJvdXRlIHRvIHNpZ25hbCBWUFdTIHNlcnZpY2VzLiBUaGUgRXRo ZXJuZXQgU2VnbWVudCBJZGVudGlmaWVyIGZpZWxkIGlzIHNldCB0byB0aGUgY3VzdG9tZXIgRVMg YW5kIHRoZSBFdGhlcm5ldCBUYWcgSUQgMzItYml0IGZpZWxkIGlzIHNldCB0byB0aGUgMjQtYml0 IFZQV1Mgc2VydmljZSBpbnN0YW5jZSBpZGVudGlmaWVyLuKAnSAgRmlyc3Qgb2YgYWxsIFt0aGlz IGlzIG1pbm9yL2Egbml0XSwgaWYgdGhpcyBkb2N1bWVudCBpbnRlbmRzIHRvIGJlIGluIHRoZSBT dGFuZGFyZHMgVHJhY2sgdGhlbiBpdCBpcyBwYXN0IHRoZSDigJxwcm9wb3NpbmfigJ0gcGhhc2Us IGl0IGlzICpzcGVjaWZ5aW5nKi4gIEFzIGEgc3BlY2lmaWNhdGlvbiwgaXQgaXMgcmF0aGVyIHdl YWsgaW4gc29tZSBwbGFjZXM7IGZvciBleGFtcGxlLCBSRkM3NDMyIHNheXMgKGFzIGFuIGV4YW1w bGUpIHRoYXQgdGhlIOKAnEV0aGVybmV0IFRhZyBJRCBpbiBhbGwgRVZQTiByb3V0ZXMgTVVTVCBi ZSBzZXQgdG8gMOKAnTogdGhhdCBpcyBhIHN0cm9uZyBzdGF0ZW1lbnQgb2Ygd2hhdCBpcyBleHBl Y3RlZC4gIE9uIHRoZSBvdGhlciBoYW5kLCB0aGlzIGRvY3VtZW50IGlzIG1vZGlmeWluZyB0aGUg YmVoYXZpb3IsIGJ1dCBubyBOb3JtYXRpdmUgbGFuZ3VhZ2UgaXMgdXNlZC4gIFtJbiBnZW5lcmFs IEkgZG9u4oCZdCBhZHZvY2F0ZSBmb3IgdGhlIHVzZSBvZiBOb3JtYXRpdmUgbGFuZ3VhZ2UgZXZl cnl3aGVyZSwgYnV0IGluIGNhc2VzIGxpa2UgdGhpcyB3aGVyZSB0aGUgYmVoYXZpb3IgaXMgYmVp bmcgY2hhbmdlZCBmcm9tIHRoZSBiYXNlIHNwZWMgd2hlbiB1c2luZyB0aGlzIGV4dGVuc2lvbiwg aXQgc2VlbXMgbmVjZXNzYXJ5Ll0NCg0KTTUuMS4gU2VjdGlvbiAzOiDigJxFdGhlcm5ldCBUYWcg SUQgMzItYml0IGZpZWxkIGlzIHNldCB0byB0aGUgMjQtYml0IFZQV1Mgc2VydmljZSBpbnN0YW5j ZSBpZGVudGlmaWVy4oCdIEhvdyBzaG91bGQgdGhpcyBiZSBhbGlnbmVkIGludG8gdGhlIGxhcmdl ciBmaWVsZD8NCg0KDQpNNi4gU2VjdGlvbiAzLjEgKEVWUE4gTGF5ZXIgMiBhdHRyaWJ1dGVzIGV4 dGVuZGVkIGNvbW11bml0eSkuDQoNCk02LjEuIEZvciB0aGUgUCBmbGFnIOKAkyDigJxTSE9VTEQg YmUgc2V0IHRvIDEgZm9yIG11bHRpaG9taW5nIGFsbC1hY3RpdmUgc2NlbmFyaW9z4oCdOiBpbiBh IG11bHRpaG9taW5nIGFsbC1hY3RpdmUgc2NlbmFyaW8sIHdoZW4gd291bGQgdGhpcyBmbGFnIG5v dCBiZSBzZXQ/ICBJT1csIHdoeSBpcyB0aGUg4oCcU0hPVUxE4oCdIG5vdCBhIOKAnE1VU1TigJ0u ICBBIGNvdXBsZSBvZiBwYXJhZ3JhcGhzIGxhdGVyOiDigJzigKZ0aGUgUEVzIGluIHRoZSBFUyB0 aGF0IGFyZSBhY3RpdmUgYW5kIHJlYWR5IHRvIGZvcndhcmQgdHJhZmZpYyB0by9mcm9tIHRoZSBD RSB3aWxsIHNldCB0aGUgUCBiaXQgdG8gMeKAnS4gIEluIHRoZSBhbGwtYWN0aXZlIHNjZW5hcmlv LCBpcyB0aGVyZSBhIGNhc2Ugd2hlcmUgYSBQRSB3b3VsZCBub3QgYmUg4oCcYWN0aXZlIGFuZCBy ZWFkeeKAnT8gIFdoYXQgZG9lcyB0aGF0IG1lYW4/ICBDbGFyaWZ5aW5nIG1heSBqdXN0aWZ5IHRo ZSDigJxTSE9VTETigJ0uDQoNCk02LjIuIEhvdyBzaG91bGQgdGhlIG90aGVyIGZsYWdzIGluIHRo ZSBDb250cm9sIEZsYWdzIGZpZWxkIGJlIGFzc2lnbmVkPyAgUGxlYXNlIGRlZmluZSBhIG5ldyBy ZWdpc3RyeSBhbmQgaW5jbHVkZSB0aGUgZGV0YWlscyBpbiB0aGUgSUFOQSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uLg0KDQpNNi4zLiBXaGF0IHNob3VsZCBhIHJlbW90ZSBQRSBkbyBpZiBpdCByZWNl aXZlcyBib3RoIHRoZSBQIGFuZCBCIGZsYWdzIHNldCAob3IgYm90aCB1bnNldCk/ICBJIGtub3cg dGhhdCBpbiBhIHNpbmdsZS1hY3RpdmUgc2NlbmFyaW8gdGhleSBzaG91bGQgbm90IGJlIG9uIGF0 IHRoZSBzYW1lIHRpbWXigKZidXQgd2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvPw0KDQpNNi40 LiBXaGF0IGhhcHBlbnMgaWYgdGhlIEIgZmxhZyBpcyBzZXQgaW4gdGhlIGFsbC1hY3RpdmUgc2Nl bmFyaW8/ICAgSSBrbm93IHRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBvbiB0 aGUgbGlzdCDigJMgdGhlIGRvY3VtZW50IG5lZWRzIHRvIGV4cGxpY2l0bHkgdGFsayBhYm91dCBp dC4NCg0KTTYuNS4gV2hhdCB1bml0cyBpcyB0aGUgTVRVIGluPyAgSG93IGlzIGl0IGVuY29kZWQ/ DQoNCk02LjYuIOKAnG5vbi16ZXJvIE1UVSBTSE9VTEQgYmUgY2hlY2tlZCBhZ2FpbnN0IGxvY2Fs IE1UVeKAnSAgV2hlbiBpcyBpdCBvayBub3QgdG8gY2hlY2s/ICBJ4oCZbSB3b25kZXJpbmcgd2h5 IHRoaXMg4oCcU0hPVUxE4oCdIGlzIG5vdCBhIOKAnE1VU1TigJ0sIHNwZWNpYWxseSBiZWNhdXNl IHRoZSByZXN1bHQgb2YgdGhhdCBjaGVjayBpcyBhIOKAnE1VU1QgTk9U4oCdLg0KDQpNNi43LiDi gJxBcyBwZXIgW1JGQzY3OTBd4oCmdGhlIGNvbnRyb2wgd29yZCAoQyBiaXQgc2V0KSBTSE9VTEQg Tk9UIGJlIHVzZWTigKbigJ0gIFdoZXJlIGluIFJGQzY3OTAgZG9lcyBpdCBzYXkgdGhhdD8gIEkg c2VhcmNoZWQgZm9yIOKAnGNvbnRyb2wgd29yZOKAnSwgYnV0IGZvdW5kIG5vdGhpbmc/ICBBbHNv LCB0aGlzIOKAnFNIT1VMRCBOT1TigJ0gaXMgaW4gY29uZmxpY3Qgd2l0aCB0aGUgZGVmaW5pdGlv biBvZiB0aGUgQyBmbGFnOiDigJxJZiBzZXQgdG8gMSwgYSBDb250cm9sIHdvcmQgW1JGQzQ0NDhd IE1VU1QgYmUgcHJlc2VudOKApuKAnQ0KDQoNCk1pbm9yOg0KDQpQMS4gUGxlYXNlIGFkZCBhIHJl ZmVyZW5jZSBmb3IgVlBXUy4NCg0KUDIuIFRoZSBbTUVGXSByZWZlcmVuY2UgZGlkbuKAmXQgd29y ayBmb3IgbWU7IG9uIGFsbCB0cmllcyB0aGUgY29ubmVjdGlvbiB0aW1lZCBvdXQuICBJcyBpdCBw b3NzaWJsZSB0byBmaW5kIGEgbW9yZSBzdGFibGUgcmVmZXJlbmNlPw0KDQpQMy4gVGhlcmUgYXJl IHNldmVyYWwgYWNyb255bXMgdGhhdCB3b27igJl0IGJlIGZhbWlsaWFyIHRvIHRoZSBhdmVyYWdl IHJlYWRlciBhbmQgdGhhdCBuZWVkIHRvIGJlIGV4cGFuZGVkIG9uIGZpcnN0IHVzZTogRVMsIEFE IChBLUQpLCBFVkksIFZJRCwgVk5JLCBFUC1MQU4sIEVWUC1MQU4uIEkga25vdyB0aGF0IHNvbWUg b2YgdGhlc2UgYXJlIGV4cGFuZGVkIGluIHRoZSBUZXJtaW5vbG9neSBTZWN0aW9uLCBidXQgaW4g c29tZSBjYXNlcyB0aGF0IGNvbWVzIGxhdGVyIGluIHRoZSB0ZXh0Lg0KDQpQNC4gVGhlIEVWUE4t VlBXUyB0ZXJtIGlzIGludHJvZHVjZWQgZm9yIHRoZSBmaXJzdCB0aW1lIGluIHRoZSB0ZXh0IGF0 IHRoZSBib3R0b20gb2YgcGFnZSAzLiAgSSB0YWtlIGl0IHRoYXQgaXQgcmVmZXJzIHRvIHRoZSBz b2x1dGlvbiBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBpbmNsdWRlIGEgc2Vu dGVuY2UgYXQgdGhlIHRvcCBvZiB0aGUgaW50cm9kdWN0aW9uIHRvIGNsYXJpZnkg4oCTIG5vdGUg dGhhdCB0aGlzIHRhZyBjb3VsZCBiZSB1c2VmdWwgaW4gb3RoZXIgcGxhY2VzIGFzIHdlbGwuDQoN ClA1LiDigJxFdGhlcm5ldCB0YWcgZmllbGTigJ0gKGFuZCBub3Qg4oCcRXRoZXJuZXQgVGFnIElE 4oCdLCB3aGljaCBJ4oCZbSBhc3N1bWluZyBpcyB0aGUgc2FtZSB0aGluZykgaXMgdXNlZCBpbiBz ZXZlcmFsIHBhcnRzIG9mIHRoZSB0ZXh0LiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQuDQoNClA2LiDi gJxWeExBTiBlbmNhcOKAnSBpcyBtZW50aW9uZWQgaW4gdGhlIEludHJvZHVjdGlvbiwgYW5kIHBv dGVudGlhbCB0aGluZ3MgYWJvdXQgaGFuZGxpbmcgaXTigKZidXQgdGhlcmUgYXJlIG5vIHJlZmVy ZW5jZXMgYW5kIG5vIGFkZGl0aW9uYWwgbWVudGlvbiBhbnl3aGVyZSBlbHNlIGluIHRoZSBkb2N1 bWVudC4NCg0KUDcuIOKAnG1hc3Mgd2l0aGRyYXfigJ0gaXMgbWVudGlvbmVkIGluIHRoZSBJbnRy b2R1Y3Rpb24gKOKAnOKApmNhbiBiZSB1c2VkIGZvciBmbG93LWJhc2VkIGxvYWQtYmFsYW5jaW5n IGFuZCBtYXNzIHdpdGhkcmF3IGZ1bmN0aW9uc+KAnSksICBpbiBTZWN0aW9uIDQgKOKAnOKApmNh biBiZSB1c2VkIGZvciBtYXNzIHdpdGhkcmF34oCdKSwgYW5kIGZpbmFsbHkgU2VjdGlvbiA2LjIg KHRoZSBsYXN0IHNlY3Rpb24gaW4gdGhlIGRyYWZ0ISkgaGFzIGEgcmVmZXJlbmNl4oCmICBQbGVh c2UgbW92ZSBpdCBlYXJsaWVyIGluIHRoZSBkb2N1bWVudC4NCg0KUDguIFMtVkxBTiwgQy1WTEFO OiBleHBhbmQgYW5kIHB1dCBhIHJlZmVyZW5jZSBmb3IgdGhlbS4NCg0KUDkuIFRoZXJlIGlzIG5v IFJlZmVyZW5jZSB0byBhbnkgb2YgdGhlIEV4dGVuZGVkIENvbW11bml0aWVzIFJGQ3M6IDQzNjAs IDcxNTMsIGV0Y+KApg0KDQpQMTAuIFBsZWFzZSBhZGQgRmlndXJlIG51bWJlcnMvbmFtZXMuDQoN ClAxMS4gU2VjdGlvbiAzLjEgKEVWUE4gTGF5ZXIgMiBhdHRyaWJ1dGVzIGV4dGVuZGVkIGNvbW11 bml0eSkgZGVmaW5lcyAzIGNvbnRyb2wgKmZsYWdzKiwgYnV0IHRoZXkgYXJlIHJlZmVycmVkIHRv IGxhdGVyIGluIHRoZSB0ZXh0IGFzIOKAnGJpdHPigJ0uICBQbGVhc2UgYmUgY29uc2lzdGVudC4N Cg0KUDEyLiBTZWN0aW9uIDQgKE9wZXJhdGlvbik6IHMvd2l0aCBOZXh0IEhvcCBhdHRyaWJ1dGUg c2V0L3dpdGggdGhlIE5FWFRfSE9QIGF0dHJpYnV0ZSBzZXQgICBBbHNvLCBpbmNsdWRlIGFuIElu Zm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkM0MjcxLg0KDQpQMTMuIFNlY3Rpb24gNiAoRmFpbHVy ZSBTY2VuYXJpb3MpOiDigJzigKZ0aGUgUEUgbXVzdCB3aXRoZHJhdyBhbGwgdGhlIGFzc29jaWF0 ZWQgRXRoZXJuZXQgQUQgcm91dGVz4oCm4oCdICBTaG91bGQgdGhhdCBiZSBhIOKAnE1VU1TigJ0/ DQoNClAxNC4gQSByZWZlcmVuY2UgdG8g4oCcW2lldGYtZXZwbi1vdmVybGF5XeKAnSBhcHBlYXJz IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgYnV0IHRoZXJl4oCZcyBubyBSZWZlcmVu Y2UgbGF0ZXIgb24uDQoNCg0KTml0czoNCg0KTjEuIOKAnEJvdGggc2VydmljZXMgYXJlIHN1cHBv cnRlZCBieSB1c2luZ+KApkkuZS4sIGZvciBib3RoIEVQTCBhbmQgRVZQTCBzZXJ2aWNlc+KApuKA nSAgVGhlIHNlY29uZCBwYXJ0IG9mIHRoYXQgZXhwbGFuYXRpb24gaXMgYSBsb3QgY2xlYXJlciwg eW91IG1pZ2h0IHdhbnQgdG8gc2ltcGxpZnkgYnkganVzdCBsZWF2aW5nIHRoYXQgcGFydCBpbi4N Cg0KTjIuIFRoZSBpbnRyb2R1Y3Rpb24gcmVhZHMgbGlrZSBhIHJ1c2hlZCBzdW1tYXJ5IG9mIHRo ZSBzb2x1dGlvbiwgd2hpY2ggcmVzdWx0cyBpbiBwb3RlbnRpYWxseSBjb25mdXNpbmcgdGV4dC4g IFN1Z2dlc3Rpb246IGZvY3VzIHRoZSBJbnRyb2R1Y3Rpb24gb24gc2V0dGluZyB0aGUgc3RhZ2Uv YmFja2dyb3VuZCDigJMgaWYgeW91IHdhbnQgdG8gcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlIHNv bHV0aW9uIChnb29kIGlkZWEhKSwgdGhlbiBkbyBpdCBhZnRlciB0aGUgcmVxdWlyZW1lbnRzLg0K DQpOMy4gcy9FdGhlcm5ldCBTZWdtZW50IG9uIGEgUEUgcmVmZXIgdG8vRXRoZXJuZXQgU2VnbWVu dCBvbiBhIFBFIHJlZmVycyB0bw0KDQpONC4gcy9tdWx0aSBob21l4oCmc2luZ2xlIGhvbWUvbXVs dGkgaG9tZWTigKZzaW5nbGUgaG9tZWQNCg0KTjUuIFRoZSB0ZXh0IGluIFNlY3Rpb24gOSBpcyBt aXNhbGlnbmVkLg0K --_000_71E62DB532E4441D9D22290CFFC5BAD1ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <643ACF9506BF3C4198B1F0811DAE7E94@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ cGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0 Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpu b3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI3 Ii8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIi8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+RGVhciBhdXRob3JzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SGkhJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgdGhpcyBkb2N1bWVudC4m bmJzcDsgUGxlYXNlIHRha2UgYSBsb29rIGF0IG15IGNvbW1lbnRzIGJlbG93IOKAkyBJIHRoaW5r IHRoZXkgc2hvdWxkIGJlIGVhc3kgdG8gcmVzb2x2ZS4mbmJzcDsgSSB3aWxsIHN0YXJ0IHRoZSBJ RVRGIExhc3QgQ2FsbCB3aGVuIHRoZSBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2VkIGFuZCBh IG5ldyByZXZpc2lvbg0KIGhhcyBiZWVuIHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkFsdmFyby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYWpvcjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0xLiBUaGVyZSBhcmUgOCBhdXRob3JzIGxpc3Rl ZCBvbiB0aGUgZnJvbnQgcGFnZS4mbmJzcDsgRm9sbG93aW5nIHRoZSBndWlkZWxpbmVzIGluIHRo ZSBSRkMgU3R5bGUgR3VpZGUgW1JGQzczMjJdLCB3ZSB3YW50IHRoZSBsaXN0IHRvIGJlIGF0IG1v c3QgNS4mbmJzcDsgUGxlYXNlIHdvcmsgYW1vbmcgeW91cnNlbHZlcyB0byByZWR1Y2UgdGhlIG51 bWJlciBvZiBhdXRob3JzLiZuYnNwOw0KIEFsdGVybmF0aXZlbHksIHlvdSBjYW4ganVzdCBsaXN0 IGFuIEVkaXRvciBvciB0d28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTIuIEZyb20gdGhlIEludHJvZHVjdGlvbjog 4oCcVW5saWtlIEVWUE4gd2hlcmUgRXRoZXJuZXQgVGFnIElEIGluIEVWUE4gcm91dGVzIGFyZSBz ZXQgdG8gemVyb+KApmluIEVWUE4tVlBXUywgRXRoZXJuZXQgdGFnIElEIGluIHRoZSBFdGhlcm5l dCBBLUQgcm91dGUgTVVTVCBiZSBzZXQgdG8gYSB2YWxpZCB2YWx1ZSBpbiBhbGwgdGhlIHNlcnZp Y2UgaW50ZXJmYWNlDQogdHlwZXMu4oCdJm5ic3A7IFplcm8gaXMgYSB2YWxpZCB2YWx1ZSBmb3Ig dGhlIEV0aGVybmV0IFRhZyBJRC4mbmJzcDsgU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lvbnMpIHNh eXMgdGhhdCDigJx0aGUgRXRoZXJuZXQgVGFnIElEIDMyLWJpdCBmaWVsZCBpcyBzZXQgdG8gdGhl IDI0LWJpdCBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRlbnRpZmllcuKAnSwgYnV0IEkgY291bGRu 4oCZdCBmaW5kIGEgcGxhY2Ugd2hlcmUgdGhlIGRvY3VtZW50IHRvbGQgbWUgd2hhdCBhIHZhbGlk IHZhbHVlDQogaXMuJm5ic3A7IElPVywgaG93IGNhbiB0aGUg4oCcTVVTVOKAnSBiZSBlbmZvcmNl ZCBpZiB0aGVyZeKAmXMgbm8gY2xlYXIgaW5kaWNhdGlvbiBvZiB3aGF0IGlzIHZhbGlkPyZuYnNw OyBPVE9ILCBhbnkgc3BlY2lmaWNhdGlvbiB3YW50cyB0aGUgZmllbGRzIHRvIGNvbnRhaW4gdmFs aWQgdmFsdWVzLCBvYnZpb3VzbHkhJm5ic3A7IFdoYXQgaGFwcGVucyBpZiB0aGUgdmFsdWUgaXMg bm90IHZhbGlkPyZuYnNwOyZuYnNwOyZuYnNwOyBCVFcsIGFsbCB0aGlzIGlzIHRvIHNheSB0aGF0 IHdpdGhvdXQgYSBwcm9wZXINCiBleHBsYW5hdGlvbiAod2hpY2ggcHJvYmFibHkgZG9lc27igJl0 IGJlbG9uZyBpbiB0aGUgSW50cm9kdWN0aW9uKSwgdGhlIHdob2xlIHBhcmFncmFwaCBpcyBzdXBl cmZsdW91cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5NMy4gVGhlIEludHJvZHVjdGlvbiBzYXlzIHRoYXQg4oCcRm9y IEVWUEwgc2VydmljZSwgdGhlIEV0aGVybmV0IGZyYW1lcyB0cmFuc3BvcnRlZCBvdmVyIGFuIE1Q TFMvSVAgbmV0d29yayBTSE9VTEQgcmVtYWluIHRhZ2dlZCB3aXRoIHRoZSBvcmlnaW5hdGluZyBW SUQgYW5kIGFueSBWSUQgdHJhbnNsYXRpb24gaXMgcGVyZm9ybWVkIGF0IHRoZSBkaXNwb3NpdGlv bg0KIFBFLuKAnSwgbGF0ZXIgdGhlIHNhbWUgKG9yIGF0IGxlYXN0IHNvbWV0aGluZyBzaW1pbGFy KSBpcyBtZW50aW9uZWQgaW4gU2VjdGlvbiAyLjEuIChWTEFOLUJhc2VkIFNlcnZpY2UgSW50ZXJm YWNlKTog4oCcdGhlIEV0aGVybmV0IGZyYW1lcyB0cmFuc3BvcnRlZCBvdmVyIGFuIE1QTFMvSVAg bmV0d29yayBTSE9VTEQgcmVtYWluIHRhZ2dlZCB3aXRoIHRoZSBvcmlnaW5hdGluZyBWSUQsIGFu ZCBhIFZJRCB0cmFuc2xhdGlvbiBNVVNUIGJlIHN1cHBvcnRlZA0KIGluIHRoZSBkYXRhIHBhdGgg YW5kIE1VU1QgYmUgcGVyZm9ybWVkIG9uIHRoZSBkaXNwb3NpdGlvbiBQRS7igJ0mbmJzcDsgUGxl YXNlIGtlZXAgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBvbmUgcGxhY2Ug4oCTIEkgYW0gbm90 IGZvbmQgb2Ygbm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoZSBJbnRyb2R1Y3Rpb247IG5vdGUgdGhh dCBldmVuIHRob3VnaCB0aGUgcmVzdWx0IHNob3VsZCBiZSB0aGUgc2FtZSwgdGhlIHRleHQgaXMg ZGlmZmVyZW50ICh0aGUg4oCcTVVTVHPigJ0NCiBhcmUgdXNlZCBpbiAyLjEpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTMuMS4gW21pbm9yXSBJdCBpcyBub3Qg Y2xlYXIgaW4gdGhlIHRleHQgdGhhdCBFVlBMIHNlcnZpY2UgY29ycmVzcG9uZHMgdG8gVkxBTi1i YXNlZCBzZXJ2aWNlLiZuYnNwOyBQbGVhc2UgY2xhcmlmeSB0aGF0LiZuYnNwOyBJbiBmYWN0LCBz b21lIG9mIHRoZSBmbG93IG9mIHRoZSBkb2N1bWVudCBmZWVsIGRpc2pvaW50IGJlY2F1c2Ugc2xp Z2h0bHkgZGlmZmVyZW50IHRlcm1pbm9sb2d5DQogaXMgdXNlZCBhbmQgbm8gaGludCBvZiBob3cg aXQgYWxsIHRpZXMgdG9nZXRoZXIgaXMgcHJlc2VudGVkOyBtYXBwaW5nIEVQTC9FVlBMIHRvIHRo ZSBTZXJ2aWNlIEludGVyZmFjZXMsIHdoaWNoIGFyZSBvbmx5IG1lbnRpb25lZCBpbiBTZWN0aW9u IDIgKGFuZCB2ZXJ5IGJyaWVmbHkgaW4gdGhlIEludHJvZHVjdGlvbiDigJMgc2VlIE0yKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NNC4gU2VjdGlvbiAxLjIgaXMgdGl0bGVkIFJlcXVpcmVtZW50cy4mbmJzcDsgSG93 ZXZlciwgdGhlIGxpc3Qgc2VlbXMgdG8gaW5jbHVkZSBhIGNvbWJpbmF0aW9uIG9mIHN0YXRlbWVu dHMgb2YgZmFjdCAo4oCcRVBMIHNlcnZpY2UgYWNjZXNzIGNpcmN1aXQgbWFwcyB0byB0aGUgd2hv bGUgRXRoZXJuZXQgcG9ydOKAnTogdGhpcyBpcyBwcmV0dHkgbXVjaCB0aGUgZGVmaW5pdGlvbg0K IG9mIEVQTCksIHNvbHV0aW9uLXNvdW5kaW5nIGxpbmVzICjigJxFYWNoIFZMQU4gaW5kaXZpZHVh bGx5IChvciAmbHQ7Uy1WTEFOLEMtVkxBTiZndDsgY29tYmluYXRpb24pIHdpbGwgYmUgY29uc2lk ZXJlZCB0byBiZSBhbiBlbmRwb2ludCBmb3IgYW4gRVZQTCBzZXJ2aWNl4oCdOiBub3Qgb25seSBk b2VzIGl0IHNvdW5kIGxpa2Ugd2hhdCB0aGUgc29sdXRpb24gd2lsbCBkbywgYnV0IGl0IGlzIGFs c28gdGhlIGRlZmluaXRpb24gb2YgRVZQTCksIGFuZCBzdGF0ZW1lbnRzDQogdGhhdCB0YWxrIHRv IHRoZSBjb25maWd1cmF0aW9uIGFuZCBub3Qgd2hhdCB0aGUgdGVjaG5pY2FsIHNvbHV0aW9uIGRl c2NyaWJlZCBsYXRlciBjYW4gZG8gKOKAnEEgZ2l2ZW4gUEUgY291bGQgaGF2ZSB0aG91c2FuZHMg b2YgRVZQTHMgY29uZmlndXJlZC4gSXQgbXVzdCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgbXVs dGlwbGUgRVZQTCBzZXJ2aWNlcyB3aXRoaW4gdGhlIHNhbWUgRVZJLuKAnTogaXMgdGhlcmUgYW4g YWN0dWFsIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50PykuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQogSSB3b3VsZCBoYXZlIGV4cGVjdGVkIGFjdHVhbCByZXF1aXJlbWVudHMgKGZvciBleGFtcGxl OiDigJxFUEwgc2VydmljZSBhY2Nlc3MgY2lyY3VpdHMgTVVTVCBtYXAgdG8gdGhlIHdob2xlIEV0 aGVybmV0IHBvcnTigJ07IG5vcm1hdGl2ZSBsYW5ndWFnZSBpcyBub3QgcmVxdWlyZWQpIHRoYXQg SSBjYW4gdGhlbiBjaGVjayBhZ2FpbnN0IHRoZSBzb2x1dGlvbiDigJMgYnV0IGl0IGFsbCBzb3Vu ZHMgbGlrZSBhIHJlaGFzaCBvZiB3aGF0IHdhcyBleHBsYWluZWQNCiBiZWZvcmUuJm5ic3A7IDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3Mi Pkw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk01LiBT ZWN0aW9uIDMuIChCR1AgRXh0ZW5zaW9ucykgc2F5cyB0aGF0IOKAnFRoaXMgZG9jdW1lbnQgcHJv cG9zZXMgdGhlIHVzZSBvZiB0aGUgcGVyIEVWSSBFdGhlcm5ldCBBLUQgcm91dGUgdG8gc2lnbmFs IFZQV1Mgc2VydmljZXMuIFRoZSBFdGhlcm5ldCBTZWdtZW50IElkZW50aWZpZXIgZmllbGQgaXMg c2V0IHRvIHRoZSBjdXN0b21lciBFUyBhbmQgdGhlDQogRXRoZXJuZXQgVGFnIElEIDMyLWJpdCBm aWVsZCBpcyBzZXQgdG8gdGhlIDI0LWJpdCBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRlbnRpZmll ci7igJ0mbmJzcDsgRmlyc3Qgb2YgYWxsIFt0aGlzIGlzIG1pbm9yL2Egbml0XSwgaWYgdGhpcyBk b2N1bWVudCBpbnRlbmRzIHRvIGJlIGluIHRoZSBTdGFuZGFyZHMgVHJhY2sgdGhlbiBpdCBpcyBw YXN0IHRoZSDigJxwcm9wb3NpbmfigJ0gcGhhc2UsIGl0IGlzICo8Yj5zcGVjaWZ5aW5nPC9iPiou Jm5ic3A7IEFzIGEgc3BlY2lmaWNhdGlvbiwNCiBpdCBpcyByYXRoZXIgd2VhayBpbiBzb21lIHBs YWNlczsgZm9yIGV4YW1wbGUsIFJGQzc0MzIgc2F5cyAoYXMgYW4gZXhhbXBsZSkgdGhhdCB0aGUg 4oCcRXRoZXJuZXQgVGFnIElEIGluIGFsbCBFVlBOIHJvdXRlcyBNVVNUIGJlIHNldCB0byAw4oCd OiB0aGF0IGlzIGEgc3Ryb25nIHN0YXRlbWVudCBvZiB3aGF0IGlzIGV4cGVjdGVkLiZuYnNwOyBP biB0aGUgb3RoZXIgaGFuZCwgdGhpcyBkb2N1bWVudCBpcyBtb2RpZnlpbmcgdGhlIGJlaGF2aW9y LCBidXQgbm8NCiBOb3JtYXRpdmUgbGFuZ3VhZ2UgaXMgdXNlZC4mbmJzcDsgW0luIGdlbmVyYWwg SSBkb27igJl0IGFkdm9jYXRlIGZvciB0aGUgdXNlIG9mIE5vcm1hdGl2ZSBsYW5ndWFnZSBldmVy eXdoZXJlLCBidXQgaW4gY2FzZXMgbGlrZSB0aGlzIHdoZXJlIHRoZSBiZWhhdmlvciBpcyBiZWlu ZyBjaGFuZ2VkIGZyb20gdGhlIGJhc2Ugc3BlYyB3aGVuIHVzaW5nIHRoaXMgZXh0ZW5zaW9uLCBp dCBzZWVtcyBuZWNlc3NhcnkuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TTUuMS4gU2VjdGlvbiAzOiDigJxFdGhlcm5ldCBUYWcgSUQgMzItYml0IGZpZWxkIGlz IHNldCB0byB0aGUgMjQtYml0IFZQV1Mgc2VydmljZSBpbnN0YW5jZSBpZGVudGlmaWVy4oCdIEhv dyBzaG91bGQgdGhpcyBiZSBhbGlnbmVkIGludG8gdGhlIGxhcmdlciBmaWVsZD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5NNi4gU2VjdGlvbiAzLjEgKEVWUE4gTGF5ZXIgMiBhdHRyaWJ1dGVzIGV4dGVuZGVkIGNvbW11 bml0eSkuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi Pk02LjEuIEZvciB0aGUgUCBmbGFnIOKAkyDigJxTSE9VTEQgYmUgc2V0IHRvIDEgZm9yIG11bHRp aG9taW5nIGFsbC1hY3RpdmUgc2NlbmFyaW9z4oCdOiBpbiBhIG11bHRpaG9taW5nIGFsbC1hY3Rp dmUgc2NlbmFyaW8sIHdoZW4gd291bGQgdGhpcyBmbGFnIG5vdCBiZSBzZXQ/Jm5ic3A7IElPVywg d2h5IGlzIHRoZSDigJxTSE9VTETigJ0gbm90IGEg4oCcTVVTVOKAnS4gJm5ic3A7QSBjb3VwbGUg b2YNCiBwYXJhZ3JhcGhzIGxhdGVyOiDigJzigKZ0aGUgUEVzIGluIHRoZSBFUyB0aGF0IGFyZSBh Y3RpdmUgYW5kIHJlYWR5IHRvIGZvcndhcmQgdHJhZmZpYyB0by9mcm9tIHRoZSBDRSB3aWxsIHNl dCB0aGUgUCBiaXQgdG8gMeKAnS4mbmJzcDsgSW4gdGhlIGFsbC1hY3RpdmUgc2NlbmFyaW8sIGlz IHRoZXJlIGEgY2FzZSB3aGVyZSBhIFBFIHdvdWxkIG5vdCBiZSDigJxhY3RpdmUgYW5kIHJlYWR5 4oCdPyZuYnNwOyBXaGF0IGRvZXMgdGhhdCBtZWFuPyZuYnNwOyBDbGFyaWZ5aW5nIG1heSBqdXN0 aWZ5DQogdGhlIOKAnFNIT1VMROKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPk02LjIuIEhvdyBzaG91bGQgdGhlIG90aGVyIGZsYWdzIGluIHRoZSBDb250cm9s IEZsYWdzIGZpZWxkIGJlIGFzc2lnbmVkPyZuYnNwOyBQbGVhc2UgZGVmaW5lIGEgbmV3IHJlZ2lz dHJ5IGFuZCBpbmNsdWRlIHRoZSBkZXRhaWxzIGluIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNl Y3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNi4zLiBX aGF0IHNob3VsZCBhIHJlbW90ZSBQRSBkbyBpZiBpdCByZWNlaXZlcyBib3RoIHRoZSBQIGFuZCBC IGZsYWdzIHNldCAob3IgYm90aCB1bnNldCk/Jm5ic3A7IEkga25vdyB0aGF0IGluIGEgc2luZ2xl LWFjdGl2ZSBzY2VuYXJpbyB0aGV5IHNob3VsZCBub3QgYmUgb24gYXQgdGhlIHNhbWUgdGltZeKA pmJ1dCB3aGF0IHNob3VsZCB0aGUgcmVjZWl2ZXIgZG8/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5NNi40LiBXaGF0IGhhcHBlbnMgaWYgdGhlIEIgZmxhZyBpcyBz ZXQgaW4gdGhlIGFsbC1hY3RpdmUgc2NlbmFyaW8/Jm5ic3A7Jm5ic3A7IEkga25vdyB0aGVyZSB3 YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHRoaXMgb24gdGhlIGxpc3Qg4oCTIHRoZSBkb2N1bWVu dCBuZWVkcyB0byBleHBsaWNpdGx5IHRhbGsgYWJvdXQgaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNi41LiBXaGF0IHVuaXRzIGlzIHRoZSBNVFUgaW4/Jm5i c3A7IEhvdyBpcyBpdCBlbmNvZGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+TTYuNi4g4oCcbm9uLXplcm8gTVRVIFNIT1VMRCBiZSBjaGVja2VkIGFnYWluc3Qg bG9jYWwgTVRV4oCdJm5ic3A7IFdoZW4gaXMgaXQgb2sgbm90IHRvIGNoZWNrPyZuYnNwOyBJ4oCZ bSB3b25kZXJpbmcgd2h5IHRoaXMg4oCcU0hPVUxE4oCdIGlzIG5vdCBhIOKAnE1VU1TigJ0sIHNw ZWNpYWxseSBiZWNhdXNlIHRoZSByZXN1bHQgb2YgdGhhdCBjaGVjayBpcyBhIOKAnE1VU1QgTk9U 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNy4g4oCc QXMgcGVyIFtSRkM2NzkwXeKApnRoZSBjb250cm9sIHdvcmQgKEMgYml0IHNldCkgU0hPVUxEIE5P VCBiZSB1c2Vk4oCm4oCdJm5ic3A7IFdoZXJlIGluIFJGQzY3OTAgZG9lcyBpdCBzYXkgdGhhdD8m bmJzcDsgSSBzZWFyY2hlZCBmb3Ig4oCcY29udHJvbCB3b3Jk4oCdLCBidXQgZm91bmQgbm90aGlu Zz8mbmJzcDsgQWxzbywgdGhpcyDigJxTSE9VTEQgTk9U4oCdIGlzIGluIGNvbmZsaWN0IHdpdGgN CiB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgQyBmbGFnOiDigJxJZiBzZXQgdG8gMSwgYSBDb250cm9s IHdvcmQgW1JGQzQ0NDhdIE1VU1QgYmUgcHJlc2VudOKApuKAnSZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ TWlub3I6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMS4gUGxl YXNlIGFkZCBhIHJlZmVyZW5jZSBmb3IgVlBXUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlAyLiBUaGUgW01FRl0gcmVmZXJlbmNlIGRpZG7igJl0IHdvcmsgZm9y IG1lOyBvbiBhbGwgdHJpZXMgdGhlIGNvbm5lY3Rpb24gdGltZWQgb3V0LiZuYnNwOyBJcyBpdCBw b3NzaWJsZSB0byBmaW5kIGEgbW9yZSBzdGFibGUgcmVmZXJlbmNlPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDMuIFRoZXJlIGFyZSBzZXZlcmFsIGFjcm9ueW1z IHRoYXQgd29u4oCZdCBiZSBmYW1pbGlhciB0byB0aGUgYXZlcmFnZSByZWFkZXIgYW5kIHRoYXQg bmVlZCB0byBiZSBleHBhbmRlZCBvbiBmaXJzdCB1c2U6IEVTLCBBRCAoQS1EKSwgRVZJLCBWSUQs IFZOSSwgRVAtTEFOLCBFVlAtTEFOLiBJIGtub3cgdGhhdCBzb21lIG9mIHRoZXNlIGFyZSBleHBh bmRlZCBpbg0KIHRoZSBUZXJtaW5vbG9neSBTZWN0aW9uLCBidXQgaW4gc29tZSBjYXNlcyB0aGF0 IGNvbWVzIGxhdGVyIGluIHRoZSB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+UDQuIFRoZSBFVlBOLVZQV1MgdGVybSBpcyBpbnRyb2R1Y2VkIGZvciB0aGUg Zmlyc3QgdGltZSBpbiB0aGUgdGV4dCBhdCB0aGUgYm90dG9tIG9mIHBhZ2UgMy4mbmJzcDsgSSB0 YWtlIGl0IHRoYXQgaXQgcmVmZXJzIHRvIHRoZSBzb2x1dGlvbiBwcmVzZW50ZWQgaW4gdGhpcyBk b2N1bWVudC4mbmJzcDsgUGxlYXNlIGluY2x1ZGUgYSBzZW50ZW5jZSBhdCB0aGUgdG9wIG9mIHRo ZQ0KIGludHJvZHVjdGlvbiB0byBjbGFyaWZ5IOKAkyBub3RlIHRoYXQgdGhpcyB0YWcgY291bGQg YmUgdXNlZnVsIGluIG90aGVyIHBsYWNlcyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+UDUuIOKAnEV0aGVybmV0IHRhZyBmaWVsZOKAnSAoYW5kIG5v dCDigJxFdGhlcm5ldCBUYWcgSUTigJ0sIHdoaWNoIEnigJltIGFzc3VtaW5nIGlzIHRoZSBzYW1l IHRoaW5nKSBpcyB1c2VkIGluIHNldmVyYWwgcGFydHMgb2YgdGhlIHRleHQuJm5ic3A7IFBsZWFz ZSBiZSBjb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UDYuIOKAnFZ4TEFOIGVuY2Fw4oCdIGlzIG1lbnRpb25lZCBpbiB0aGUgSW50cm9kdWN0aW9u LCBhbmQgcG90ZW50aWFsIHRoaW5ncyBhYm91dCBoYW5kbGluZyBpdOKApmJ1dCB0aGVyZSBhcmUg bm8gcmVmZXJlbmNlcyBhbmQgbm8gYWRkaXRpb25hbCBtZW50aW9uIGFueXdoZXJlIGVsc2UgaW4g dGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UDcuIOKAnG1hc3Mgd2l0aGRyYXfigJ0gaXMgbWVudGlvbmVkIGluIHRoZSBJbnRyb2R1Y3Rpb24g KOKAnOKApmNhbiBiZSB1c2VkIGZvciBmbG93LWJhc2VkIGxvYWQtYmFsYW5jaW5nIGFuZCBtYXNz IHdpdGhkcmF3IGZ1bmN0aW9uc+KAnSksJm5ic3A7IGluIFNlY3Rpb24gNCAo4oCc4oCmY2FuIGJl IHVzZWQgZm9yIG1hc3Mgd2l0aGRyYXfigJ0pLCBhbmQgZmluYWxseSBTZWN0aW9uIDYuMiAodGhl DQogbGFzdCBzZWN0aW9uIGluIHRoZSBkcmFmdCEpIGhhcyBhIHJlZmVyZW5jZeKApiZuYnNwOyBQ bGVhc2UgbW92ZSBpdCBlYXJsaWVyIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA4LiBTLVZMQU4sIEMtVkxBTjogZXhwYW5kIGFuZCBw dXQgYSByZWZlcmVuY2UgZm9yIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5QOS4gVGhlcmUgaXMgbm8gUmVmZXJlbmNlIHRvIGFueSBvZiB0aGUgRXh0ZW5k ZWQgQ29tbXVuaXRpZXMgUkZDczogNDM2MCwgNzE1MywgZXRj4oCmPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTAuIFBsZWFzZSBhZGQgRmlndXJlIG51bWJlcnMv bmFtZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTEuIFNl Y3Rpb24gMy4xIChFVlBOIExheWVyIDIgYXR0cmlidXRlcyBleHRlbmRlZCBjb21tdW5pdHkpIGRl ZmluZXMgMyBjb250cm9sICo8Yj5mbGFnczwvYj4qLCBidXQgdGhleSBhcmUgcmVmZXJyZWQgdG8g bGF0ZXIgaW4gdGhlIHRleHQgYXMg4oCcYml0c+KAnS4mbmJzcDsgUGxlYXNlIGJlIGNvbnNpc3Rl bnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTIuIFNlY3Rp b24gNCAoT3BlcmF0aW9uKTogcy93aXRoIE5leHQgSG9wIGF0dHJpYnV0ZSBzZXQvd2l0aCB0aGUg TkVYVF9IT1AgYXR0cmlidXRlIHNldCZuYnNwOyZuYnNwOyBBbHNvLCBpbmNsdWRlIGFuIEluZm9y bWF0aXZlIHJlZmVyZW5jZSB0byBSRkM0MjcxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+UDEzLiBTZWN0aW9uIDYgKEZhaWx1cmUgU2NlbmFyaW9zKTog4oCc4oCm dGhlIFBFIG11c3Qgd2l0aGRyYXcgYWxsIHRoZSBhc3NvY2lhdGVkIEV0aGVybmV0IEFEIHJvdXRl c+KApuKAnSZuYnNwOyBTaG91bGQgdGhhdCBiZSBhIOKAnE1VU1TigJ0/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMTQuIEEgcmVmZXJlbmNlIHRvIOKAnFtpZXRm LWV2cG4tb3ZlcmxheV3igJ0gYXBwZWFycyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMs IGJ1dCB0aGVyZeKAmXMgbm8gUmVmZXJlbmNlIGxhdGVyIG9uLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Tml0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk4xLiDigJxC b3RoIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgYnkgdXNpbmfigKZJLmUuLCBmb3IgYm90aCBFUEwg YW5kIEVWUEwgc2VydmljZXPigKbigJ0mbmJzcDsgVGhlIHNlY29uZCBwYXJ0IG9mIHRoYXQgZXhw bGFuYXRpb24gaXMgYSBsb3QgY2xlYXJlciwgeW91IG1pZ2h0IHdhbnQgdG8gc2ltcGxpZnkgYnkg anVzdCBsZWF2aW5nIHRoYXQgcGFydCBpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk4yLiBUaGUgaW50cm9kdWN0aW9uIHJlYWRzIGxpa2UgYSBydXNoZWQgc3Vt bWFyeSBvZiB0aGUgc29sdXRpb24sIHdoaWNoIHJlc3VsdHMgaW4gcG90ZW50aWFsbHkgY29uZnVz aW5nIHRleHQuJm5ic3A7IFN1Z2dlc3Rpb246IGZvY3VzIHRoZSBJbnRyb2R1Y3Rpb24gb24gc2V0 dGluZyB0aGUgc3RhZ2UvYmFja2dyb3VuZCDigJMgaWYgeW91IHdhbnQgdG8gcHJvdmlkZSBhDQog c3VtbWFyeSBvZiB0aGUgc29sdXRpb24gKGdvb2QgaWRlYSEpLCB0aGVuIGRvIGl0IGFmdGVyIHRo ZSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5OMy4gcy9FdGhlcm5ldCBTZWdtZW50IG9uIGEgUEUgcmVmZXIgdG8vRXRoZXJuZXQgU2VnbWVu dCBvbiBhIFBFIHJlZmVycyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TjQuIHMvbXVsdGkgaG9tZeKApnNpbmdsZSBob21lL211bHRpIGhvbWVk4oCmc2luZ2xl IGhvbWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ONS4gVGhl IHRleHQgaW4gU2VjdGlvbiA5IGlzIG1pc2FsaWduZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_71E62DB532E4441D9D22290CFFC5BAD1ciscocom_-- From nobody Thu Jan 26 08:52:47 2017 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 7A9F21298A4; Thu, 26 Jan 2017 08:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.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 oXBLDrdP95m9; Thu, 26 Jan 2017 08:52:42 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0063.outbound.protection.outlook.com [104.47.32.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2541298C3; Thu, 26 Jan 2017 08:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mvpdvfsyqQIvXpBqiNQmSUNj6KmLdk7zmF1EOevmiZE=; b=s9KPVbsfQewh+pFNiKCvf2iX5BtYZkj6vw7hFiUapNgmm2W6O9svtmDg2HBvwm3SmO2DAPDU7uk8KuMAt80iNBZ16F17zKVOjtgaFdsFr2XEpIzISdpdsEcBct2mbhgpvGBleto/JULR+fAuRrjj/DfY83hSPouvhMbakQ8Neds= Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Thu, 26 Jan 2017 16:52:29 +0000 Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.0888.007; Thu, 26 Jan 2017 16:52:29 +0000 From: Sami Boutros To: "Alvaro Retana (aretana)" , "draft-ietf-bess-evpn-vpws@ietf.org" Thread-Topic: AD Review of draft-ietf-bess-evpn-vpws-07 Thread-Index: AQHSd44kA2pNPLQMm0qn/KFCiMDXR6FKc+4A Date: Thu, 26 Jan 2017 16:52:29 +0000 Message-ID: References: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@cisco.com> In-Reply-To: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@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=sboutros@vmware.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [208.91.2.4] x-ms-office365-filtering-correlation-id: 513b1886-c96d-4b42-1657-08d4460bb6fa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR05MB3009; x-microsoft-exchange-diagnostics: 1; BN6PR05MB3009; 7:dNbML+5ffDETdiweb8EHwS8m1F30T4bzWslyPfkiLwAmU5IEWLKEI9RYd6YKpj4rf5JvIIdL8f+R/JN/V0iFoEuXQWANU7kU1F4iunm9E+L4/3IL+vJjT5NgGJVbP5F0M4FqVOYq6KlR4Ocby+XgNXogWZwMcDfSm4JWgmq/MhDvCdlzM9nAc1b3fWrulj6HZ68Ev4qB7ItYjm0wK89Fsy1GThc2ujyI5MsjkJoSJGGRBHWgsTOSkrmqmuNat1Ul73/IQB+xgBVwBg7AZSDdtjIYJtyaP1BhNVT5gCJ3eAimoxpNyKdjziLoXgq1onyUCAkgnM5ScqTl2FbT1Y1l7IDOPqiv9uD4m5Had2cBi1A6YGTEIxt0tg9rdnhBKsAfPHmxZ5ektO7jWpVkWdbqkvCp+U+xetx+Gim9UfZkPTKGLKrXO3ygy7uQ4mpFEos2KSaIPMGlJ5P5pyui3N/bbA==; 20:N7gtsFDofavfYHx5EFgU98cvZ2sJ4Iom4oN5jzplSkJSkmwdCKsemCV0802q82UFk82DlcRK61fZwqxA+1E9eeMI2BAoNttRHk4S0vRbg2kMQS86EFuVeB76mRr6glSkC0tZrROUE1WOKnIPzjbsjqdtfk5ltRvmva9dRjyiZEY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(192374486261705)(138986009662008)(82608151540597)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021)(6072148); SRVR:BN6PR05MB3009; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3009; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(189002)(377454003)(45904002)(66066001)(122556002)(3660700001)(8676002)(6436002)(2950100002)(230783001)(3280700002)(33656002)(25786008)(5001770100001)(5660300001)(97736004)(189998001)(106356001)(7736002)(76176999)(105586002)(38730400001)(81156014)(229853002)(6506006)(54356999)(53936002)(81166006)(50986999)(101416001)(6486002)(77096006)(6116002)(8936002)(102836003)(3846002)(106116001)(2501003)(6306002)(92566002)(68736007)(86362001)(6512007)(4326007)(83716003)(236005)(82746002)(2906002)(2900100001)(54896002)(8666007)(99286003)(36756003)(54906002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3009; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F54AFFF3D6024852B280F2DBD97B81D3vmwarecom_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2017 16:52:29.1027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3009 Archived-At: Cc: Jeffrey Zhang , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07 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, 26 Jan 2017 16:52:45 -0000 --_000_F54AFFF3D6024852B280F2DBD97B81D3vmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFsdmFybyBmb3IgeW91ciBjb21tZW50cy4NCg0KV2lsbCBhZGRyZXNzIHRoZW0gYW5k IHJlc3VibWl0IHRoZSBkcmFmdC4NCg0KVGhhbmtzLA0KDQpTYW1pDQpGcm9tOiAiQWx2YXJvIFJl dGFuYSAoYXJldGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5j b20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDE3IGF0IDg6MzkgUE0NClRvOiAi ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tdnB3c0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1iZXNz LWV2cG4tdnB3c0BpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdzQGlldGYub3Jn PG1haWx0bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdzQGlldGYub3JnPj4NCkNjOiAiYmVzcy1j aGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmJlc3MtY2hhaXJzQGlldGYub3JnPiIgPGJlc3MtY2hhaXJz QGlldGYub3JnPG1haWx0bzpiZXNzLWNoYWlyc0BpZXRmLm9yZz4+LCBKZWZmcmV5IFpoYW5nIDx6 emhhbmdAanVuaXBlci5uZXQ8bWFpbHRvOnp6aGFuZ0BqdW5pcGVyLm5ldD4+LCAiYmVzc0BpZXRm Lm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4iIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGll dGYub3JnPj4NClN1YmplY3Q6IEFEIFJldmlldyBvZiBkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdz LTA3DQpSZXNlbnQtRnJvbTogPGFsaWFzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFsaWFzLWJv dW5jZXNAaWV0Zi5vcmc+Pg0KUmVzZW50LVRvOiA8c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNh amFzc2lAY2lzY28uY29tPj4sIDxzc2FsYW1AY2lzY28uY29tPG1haWx0bzpzc2FsYW1AY2lzY28u Y29tPj4sIDxqZHJha2VAanVuaXBlci5uZXQ8bWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldD4+LCA8 ZHdzQHN0ZWluYmVyZ25ldC5uZXQ8bWFpbHRvOmR3c0BzdGVpbmJlcmduZXQubmV0Pj4sIDx0aG9t YXMuYmVja2hhdXNAdGVsZWtvbS5kZTxtYWlsdG86dGhvbWFzLmJlY2toYXVzQHRlbGVrb20uZGU+ PiwgU2FtaSBCb3V0cm9zIDxzYm91dHJvc0B2bXdhcmUuY29tPG1haWx0bzpzYm91dHJvc0B2bXdh cmUuY29tPj4sIDxqZWZmdGFudEBnbWFpbC5jb208bWFpbHRvOmplZmZ0YW50QGdtYWlsLmNvbT4+ LCA8am9yZ2UucmFiYWRhbkBub2tpYS5jb208bWFpbHRvOmpvcmdlLnJhYmFkYW5Abm9raWEuY29t Pj4NClJlc2VudC1EYXRlOiBXZWRuZXNkYXksIEphbnVhcnkgMjUsIDIwMTcgYXQgODozOSBQTQ0K DQpEZWFyIGF1dGhvcnM6DQoNCkhpIQ0KDQpJIGp1c3QgZmluaXNoZWQgcmVhZGluZyB0aGlzIGRv Y3VtZW50LiAgUGxlYXNlIHRha2UgYSBsb29rIGF0IG15IGNvbW1lbnRzIGJlbG93IOKAkyBJIHRo aW5rIHRoZXkgc2hvdWxkIGJlIGVhc3kgdG8gcmVzb2x2ZS4gIEkgd2lsbCBzdGFydCB0aGUgSUVU RiBMYXN0IENhbGwgd2hlbiB0aGUgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBhbmQgYSBu ZXcgcmV2aXNpb24gaGFzIGJlZW4gcHVibGlzaGVkLg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0K DQpNYWpvcjoNCg0KTTEuIFRoZXJlIGFyZSA4IGF1dGhvcnMgbGlzdGVkIG9uIHRoZSBmcm9udCBw YWdlLiAgRm9sbG93aW5nIHRoZSBndWlkZWxpbmVzIGluIHRoZSBSRkMgU3R5bGUgR3VpZGUgW1JG QzczMjJdLCB3ZSB3YW50IHRoZSBsaXN0IHRvIGJlIGF0IG1vc3QgNS4gIFBsZWFzZSB3b3JrIGFt b25nIHlvdXJzZWx2ZXMgdG8gcmVkdWNlIHRoZSBudW1iZXIgb2YgYXV0aG9ycy4gIEFsdGVybmF0 aXZlbHksIHlvdSBjYW4ganVzdCBsaXN0IGFuIEVkaXRvciBvciB0d28uDQoNCg0KTTIuIEZyb20g dGhlIEludHJvZHVjdGlvbjog4oCcVW5saWtlIEVWUE4gd2hlcmUgRXRoZXJuZXQgVGFnIElEIGlu IEVWUE4gcm91dGVzIGFyZSBzZXQgdG8gemVyb+KApmluIEVWUE4tVlBXUywgRXRoZXJuZXQgdGFn IElEIGluIHRoZSBFdGhlcm5ldCBBLUQgcm91dGUgTVVTVCBiZSBzZXQgdG8gYSB2YWxpZCB2YWx1 ZSBpbiBhbGwgdGhlIHNlcnZpY2UgaW50ZXJmYWNlIHR5cGVzLuKAnSAgWmVybyBpcyBhIHZhbGlk IHZhbHVlIGZvciB0aGUgRXRoZXJuZXQgVGFnIElELiAgU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lv bnMpIHNheXMgdGhhdCDigJx0aGUgRXRoZXJuZXQgVGFnIElEIDMyLWJpdCBmaWVsZCBpcyBzZXQg dG8gdGhlIDI0LWJpdCBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRlbnRpZmllcuKAnSwgYnV0IEkg Y291bGRu4oCZdCBmaW5kIGEgcGxhY2Ugd2hlcmUgdGhlIGRvY3VtZW50IHRvbGQgbWUgd2hhdCBh IHZhbGlkIHZhbHVlIGlzLiAgSU9XLCBob3cgY2FuIHRoZSDigJxNVVNU4oCdIGJlIGVuZm9yY2Vk IGlmIHRoZXJl4oCZcyBubyBjbGVhciBpbmRpY2F0aW9uIG9mIHdoYXQgaXMgdmFsaWQ/ICBPVE9I LCBhbnkgc3BlY2lmaWNhdGlvbiB3YW50cyB0aGUgZmllbGRzIHRvIGNvbnRhaW4gdmFsaWQgdmFs dWVzLCBvYnZpb3VzbHkhICBXaGF0IGhhcHBlbnMgaWYgdGhlIHZhbHVlIGlzIG5vdCB2YWxpZD8g ICAgQlRXLCBhbGwgdGhpcyBpcyB0byBzYXkgdGhhdCB3aXRob3V0IGEgcHJvcGVyIGV4cGxhbmF0 aW9uICh3aGljaCBwcm9iYWJseSBkb2VzbuKAmXQgYmVsb25nIGluIHRoZSBJbnRyb2R1Y3Rpb24p LCB0aGUgd2hvbGUgcGFyYWdyYXBoIGlzIHN1cGVyZmx1b3VzLg0KDQoNCk0zLiBUaGUgSW50cm9k dWN0aW9uIHNheXMgdGhhdCDigJxGb3IgRVZQTCBzZXJ2aWNlLCB0aGUgRXRoZXJuZXQgZnJhbWVz IHRyYW5zcG9ydGVkIG92ZXIgYW4gTVBMUy9JUCBuZXR3b3JrIFNIT1VMRCByZW1haW4gdGFnZ2Vk IHdpdGggdGhlIG9yaWdpbmF0aW5nIFZJRCBhbmQgYW55IFZJRCB0cmFuc2xhdGlvbiBpcyBwZXJm b3JtZWQgYXQgdGhlIGRpc3Bvc2l0aW9uIFBFLuKAnSwgbGF0ZXIgdGhlIHNhbWUgKG9yIGF0IGxl YXN0IHNvbWV0aGluZyBzaW1pbGFyKSBpcyBtZW50aW9uZWQgaW4gU2VjdGlvbiAyLjEuIChWTEFO LUJhc2VkIFNlcnZpY2UgSW50ZXJmYWNlKTog4oCcdGhlIEV0aGVybmV0IGZyYW1lcyB0cmFuc3Bv cnRlZCBvdmVyIGFuIE1QTFMvSVAgbmV0d29yayBTSE9VTEQgcmVtYWluIHRhZ2dlZCB3aXRoIHRo ZSBvcmlnaW5hdGluZyBWSUQsIGFuZCBhIFZJRCB0cmFuc2xhdGlvbiBNVVNUIGJlIHN1cHBvcnRl ZCBpbiB0aGUgZGF0YSBwYXRoIGFuZCBNVVNUIGJlIHBlcmZvcm1lZCBvbiB0aGUgZGlzcG9zaXRp b24gUEUu4oCdICBQbGVhc2Uga2VlcCB0aGUgbm9ybWF0aXZlIGxhbmd1YWdlIGluIG9uZSBwbGFj ZSDigJMgSSBhbSBub3QgZm9uZCBvZiBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gdGhlIEludHJvZHVj dGlvbjsgbm90ZSB0aGF0IGV2ZW4gdGhvdWdoIHRoZSByZXN1bHQgc2hvdWxkIGJlIHRoZSBzYW1l LCB0aGUgdGV4dCBpcyBkaWZmZXJlbnQgKHRoZSDigJxNVVNUc+KAnSBhcmUgdXNlZCBpbiAyLjEp Lg0KDQpNMy4xLiBbbWlub3JdIEl0IGlzIG5vdCBjbGVhciBpbiB0aGUgdGV4dCB0aGF0IEVWUEwg c2VydmljZSBjb3JyZXNwb25kcyB0byBWTEFOLWJhc2VkIHNlcnZpY2UuICBQbGVhc2UgY2xhcmlm eSB0aGF0LiAgSW4gZmFjdCwgc29tZSBvZiB0aGUgZmxvdyBvZiB0aGUgZG9jdW1lbnQgZmVlbCBk aXNqb2ludCBiZWNhdXNlIHNsaWdodGx5IGRpZmZlcmVudCB0ZXJtaW5vbG9neSBpcyB1c2VkIGFu ZCBubyBoaW50IG9mIGhvdyBpdCBhbGwgdGllcyB0b2dldGhlciBpcyBwcmVzZW50ZWQ7IG1hcHBp bmcgRVBML0VWUEwgdG8gdGhlIFNlcnZpY2UgSW50ZXJmYWNlcywgd2hpY2ggYXJlIG9ubHkgbWVu dGlvbmVkIGluIFNlY3Rpb24gMiAoYW5kIHZlcnkgYnJpZWZseSBpbiB0aGUgSW50cm9kdWN0aW9u IOKAkyBzZWUgTTIpLg0KDQoNCk00LiBTZWN0aW9uIDEuMiBpcyB0aXRsZWQgUmVxdWlyZW1lbnRz LiAgSG93ZXZlciwgdGhlIGxpc3Qgc2VlbXMgdG8gaW5jbHVkZSBhIGNvbWJpbmF0aW9uIG9mIHN0 YXRlbWVudHMgb2YgZmFjdCAo4oCcRVBMIHNlcnZpY2UgYWNjZXNzIGNpcmN1aXQgbWFwcyB0byB0 aGUgd2hvbGUgRXRoZXJuZXQgcG9ydOKAnTogdGhpcyBpcyBwcmV0dHkgbXVjaCB0aGUgZGVmaW5p dGlvbiBvZiBFUEwpLCBzb2x1dGlvbi1zb3VuZGluZyBsaW5lcyAo4oCcRWFjaCBWTEFOIGluZGl2 aWR1YWxseSAob3IgPFMtVkxBTixDLVZMQU4+IGNvbWJpbmF0aW9uKSB3aWxsIGJlIGNvbnNpZGVy ZWQgdG8gYmUgYW4gZW5kcG9pbnQgZm9yIGFuIEVWUEwgc2VydmljZeKAnTogbm90IG9ubHkgZG9l cyBpdCBzb3VuZCBsaWtlIHdoYXQgdGhlIHNvbHV0aW9uIHdpbGwgZG8sIGJ1dCBpdCBpcyBhbHNv IHRoZSBkZWZpbml0aW9uIG9mIEVWUEwpLCBhbmQgc3RhdGVtZW50cyB0aGF0IHRhbGsgdG8gdGhl IGNvbmZpZ3VyYXRpb24gYW5kIG5vdCB3aGF0IHRoZSB0ZWNobmljYWwgc29sdXRpb24gZGVzY3Jp YmVkIGxhdGVyIGNhbiBkbyAo4oCcQSBnaXZlbiBQRSBjb3VsZCBoYXZlIHRob3VzYW5kcyBvZiBF VlBMcyBjb25maWd1cmVkLiBJdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSBtdWx0aXBs ZSBFVlBMIHNlcnZpY2VzIHdpdGhpbiB0aGUgc2FtZSBFVkku4oCdOiBpcyB0aGVyZSBhbiBhY3R1 YWwgc2NhbGFiaWxpdHkgcmVxdWlyZW1lbnQ/KS4gICAgIEkgd291bGQgaGF2ZSBleHBlY3RlZCBh Y3R1YWwgcmVxdWlyZW1lbnRzIChmb3IgZXhhbXBsZTog4oCcRVBMIHNlcnZpY2UgYWNjZXNzIGNp cmN1aXRzIE1VU1QgbWFwIHRvIHRoZSB3aG9sZSBFdGhlcm5ldCBwb3J04oCdOyBub3JtYXRpdmUg bGFuZ3VhZ2UgaXMgbm90IHJlcXVpcmVkKSB0aGF0IEkgY2FuIHRoZW4gY2hlY2sgYWdhaW5zdCB0 aGUgc29sdXRpb24g4oCTIGJ1dCBpdCBhbGwgc291bmRzIGxpa2UgYSByZWhhc2ggb2Ygd2hhdCB3 YXMgZXhwbGFpbmVkIGJlZm9yZS4gIOKYuQ0KDQoNCk01LiBTZWN0aW9uIDMuIChCR1AgRXh0ZW5z aW9ucykgc2F5cyB0aGF0IOKAnFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiB0aGUg cGVyIEVWSSBFdGhlcm5ldCBBLUQgcm91dGUgdG8gc2lnbmFsIFZQV1Mgc2VydmljZXMuIFRoZSBF dGhlcm5ldCBTZWdtZW50IElkZW50aWZpZXIgZmllbGQgaXMgc2V0IHRvIHRoZSBjdXN0b21lciBF UyBhbmQgdGhlIEV0aGVybmV0IFRhZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0IHRvIHRoZSAyNC1i aXQgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXIu4oCdICBGaXJzdCBvZiBhbGwgW3Ro aXMgaXMgbWlub3IvYSBuaXRdLCBpZiB0aGlzIGRvY3VtZW50IGludGVuZHMgdG8gYmUgaW4gdGhl IFN0YW5kYXJkcyBUcmFjayB0aGVuIGl0IGlzIHBhc3QgdGhlIOKAnHByb3Bvc2luZ+KAnSBwaGFz ZSwgaXQgaXMgKnNwZWNpZnlpbmcqLiAgQXMgYSBzcGVjaWZpY2F0aW9uLCBpdCBpcyByYXRoZXIg d2VhayBpbiBzb21lIHBsYWNlczsgZm9yIGV4YW1wbGUsIFJGQzc0MzIgc2F5cyAoYXMgYW4gZXhh bXBsZSkgdGhhdCB0aGUg4oCcRXRoZXJuZXQgVGFnIElEIGluIGFsbCBFVlBOIHJvdXRlcyBNVVNU IGJlIHNldCB0byAw4oCdOiB0aGF0IGlzIGEgc3Ryb25nIHN0YXRlbWVudCBvZiB3aGF0IGlzIGV4 cGVjdGVkLiAgT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgZG9jdW1lbnQgaXMgbW9kaWZ5aW5nIHRo ZSBiZWhhdmlvciwgYnV0IG5vIE5vcm1hdGl2ZSBsYW5ndWFnZSBpcyB1c2VkLiAgW0luIGdlbmVy YWwgSSBkb27igJl0IGFkdm9jYXRlIGZvciB0aGUgdXNlIG9mIE5vcm1hdGl2ZSBsYW5ndWFnZSBl dmVyeXdoZXJlLCBidXQgaW4gY2FzZXMgbGlrZSB0aGlzIHdoZXJlIHRoZSBiZWhhdmlvciBpcyBi ZWluZyBjaGFuZ2VkIGZyb20gdGhlIGJhc2Ugc3BlYyB3aGVuIHVzaW5nIHRoaXMgZXh0ZW5zaW9u LCBpdCBzZWVtcyBuZWNlc3NhcnkuXQ0KDQpNNS4xLiBTZWN0aW9uIDM6IOKAnEV0aGVybmV0IFRh ZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3Rh bmNlIGlkZW50aWZpZXLigJ0gSG93IHNob3VsZCB0aGlzIGJlIGFsaWduZWQgaW50byB0aGUgbGFy Z2VyIGZpZWxkPw0KDQoNCk02LiBTZWN0aW9uIDMuMSAoRVZQTiBMYXllciAyIGF0dHJpYnV0ZXMg ZXh0ZW5kZWQgY29tbXVuaXR5KS4NCg0KTTYuMS4gRm9yIHRoZSBQIGZsYWcg4oCTIOKAnFNIT1VM RCBiZSBzZXQgdG8gMSBmb3IgbXVsdGlob21pbmcgYWxsLWFjdGl2ZSBzY2VuYXJpb3PigJ06IGlu IGEgbXVsdGlob21pbmcgYWxsLWFjdGl2ZSBzY2VuYXJpbywgd2hlbiB3b3VsZCB0aGlzIGZsYWcg bm90IGJlIHNldD8gIElPVywgd2h5IGlzIHRoZSDigJxTSE9VTETigJ0gbm90IGEg4oCcTVVTVOKA nS4gIEEgY291cGxlIG9mIHBhcmFncmFwaHMgbGF0ZXI6IOKAnOKApnRoZSBQRXMgaW4gdGhlIEVT IHRoYXQgYXJlIGFjdGl2ZSBhbmQgcmVhZHkgdG8gZm9yd2FyZCB0cmFmZmljIHRvL2Zyb20gdGhl IENFIHdpbGwgc2V0IHRoZSBQIGJpdCB0byAx4oCdLiAgSW4gdGhlIGFsbC1hY3RpdmUgc2NlbmFy aW8sIGlzIHRoZXJlIGEgY2FzZSB3aGVyZSBhIFBFIHdvdWxkIG5vdCBiZSDigJxhY3RpdmUgYW5k IHJlYWR54oCdPyAgV2hhdCBkb2VzIHRoYXQgbWVhbj8gIENsYXJpZnlpbmcgbWF5IGp1c3RpZnkg dGhlIOKAnFNIT1VMROKAnS4NCg0KTTYuMi4gSG93IHNob3VsZCB0aGUgb3RoZXIgZmxhZ3MgaW4g dGhlIENvbnRyb2wgRmxhZ3MgZmllbGQgYmUgYXNzaWduZWQ/ICBQbGVhc2UgZGVmaW5lIGEgbmV3 IHJlZ2lzdHJ5IGFuZCBpbmNsdWRlIHRoZSBkZXRhaWxzIGluIHRoZSBJQU5BIENvbnNpZGVyYXRp b25zIHNlY3Rpb24uDQoNCk02LjMuIFdoYXQgc2hvdWxkIGEgcmVtb3RlIFBFIGRvIGlmIGl0IHJl Y2VpdmVzIGJvdGggdGhlIFAgYW5kIEIgZmxhZ3Mgc2V0IChvciBib3RoIHVuc2V0KT8gIEkga25v dyB0aGF0IGluIGEgc2luZ2xlLWFjdGl2ZSBzY2VuYXJpbyB0aGV5IHNob3VsZCBub3QgYmUgb24g YXQgdGhlIHNhbWUgdGltZeKApmJ1dCB3aGF0IHNob3VsZCB0aGUgcmVjZWl2ZXIgZG8/DQoNCk02 LjQuIFdoYXQgaGFwcGVucyBpZiB0aGUgQiBmbGFnIGlzIHNldCBpbiB0aGUgYWxsLWFjdGl2ZSBz Y2VuYXJpbz8gICBJIGtub3cgdGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9u IHRoZSBsaXN0IOKAkyB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gZXhwbGljaXRseSB0YWxrIGFib3V0 IGl0Lg0KDQpNNi41LiBXaGF0IHVuaXRzIGlzIHRoZSBNVFUgaW4/ICBIb3cgaXMgaXQgZW5jb2Rl ZD8NCg0KTTYuNi4g4oCcbm9uLXplcm8gTVRVIFNIT1VMRCBiZSBjaGVja2VkIGFnYWluc3QgbG9j YWwgTVRV4oCdICBXaGVuIGlzIGl0IG9rIG5vdCB0byBjaGVjaz8gIEnigJltIHdvbmRlcmluZyB3 aHkgdGhpcyDigJxTSE9VTETigJ0gaXMgbm90IGEg4oCcTVVTVOKAnSwgc3BlY2lhbGx5IGJlY2F1 c2UgdGhlIHJlc3VsdCBvZiB0aGF0IGNoZWNrIGlzIGEg4oCcTVVTVCBOT1TigJ0uDQoNCk02Ljcu IOKAnEFzIHBlciBbUkZDNjc5MF3igKZ0aGUgY29udHJvbCB3b3JkIChDIGJpdCBzZXQpIFNIT1VM RCBOT1QgYmUgdXNlZOKApuKAnSAgV2hlcmUgaW4gUkZDNjc5MCBkb2VzIGl0IHNheSB0aGF0PyAg SSBzZWFyY2hlZCBmb3Ig4oCcY29udHJvbCB3b3Jk4oCdLCBidXQgZm91bmQgbm90aGluZz8gIEFs c28sIHRoaXMg4oCcU0hPVUxEIE5PVOKAnSBpcyBpbiBjb25mbGljdCB3aXRoIHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBDIGZsYWc6IOKAnElmIHNldCB0byAxLCBhIENvbnRyb2wgd29yZCBbUkZDNDQ0 OF0gTVVTVCBiZSBwcmVzZW504oCm4oCdDQoNCg0KTWlub3I6DQoNClAxLiBQbGVhc2UgYWRkIGEg cmVmZXJlbmNlIGZvciBWUFdTLg0KDQpQMi4gVGhlIFtNRUZdIHJlZmVyZW5jZSBkaWRu4oCZdCB3 b3JrIGZvciBtZTsgb24gYWxsIHRyaWVzIHRoZSBjb25uZWN0aW9uIHRpbWVkIG91dC4gIElzIGl0 IHBvc3NpYmxlIHRvIGZpbmQgYSBtb3JlIHN0YWJsZSByZWZlcmVuY2U/DQoNClAzLiBUaGVyZSBh cmUgc2V2ZXJhbCBhY3JvbnltcyB0aGF0IHdvbuKAmXQgYmUgZmFtaWxpYXIgdG8gdGhlIGF2ZXJh Z2UgcmVhZGVyIGFuZCB0aGF0IG5lZWQgdG8gYmUgZXhwYW5kZWQgb24gZmlyc3QgdXNlOiBFUywg QUQgKEEtRCksIEVWSSwgVklELCBWTkksIEVQLUxBTiwgRVZQLUxBTi4gSSBrbm93IHRoYXQgc29t ZSBvZiB0aGVzZSBhcmUgZXhwYW5kZWQgaW4gdGhlIFRlcm1pbm9sb2d5IFNlY3Rpb24sIGJ1dCBp biBzb21lIGNhc2VzIHRoYXQgY29tZXMgbGF0ZXIgaW4gdGhlIHRleHQuDQoNClA0LiBUaGUgRVZQ Ti1WUFdTIHRlcm0gaXMgaW50cm9kdWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gdGhlIHRleHQg YXQgdGhlIGJvdHRvbSBvZiBwYWdlIDMuICBJIHRha2UgaXQgdGhhdCBpdCByZWZlcnMgdG8gdGhl IHNvbHV0aW9uIHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIGluY2x1ZGUgYSBz ZW50ZW5jZSBhdCB0aGUgdG9wIG9mIHRoZSBpbnRyb2R1Y3Rpb24gdG8gY2xhcmlmeSDigJMgbm90 ZSB0aGF0IHRoaXMgdGFnIGNvdWxkIGJlIHVzZWZ1bCBpbiBvdGhlciBwbGFjZXMgYXMgd2VsbC4N Cg0KUDUuIOKAnEV0aGVybmV0IHRhZyBmaWVsZOKAnSAoYW5kIG5vdCDigJxFdGhlcm5ldCBUYWcg SUTigJ0sIHdoaWNoIEnigJltIGFzc3VtaW5nIGlzIHRoZSBzYW1lIHRoaW5nKSBpcyB1c2VkIGlu IHNldmVyYWwgcGFydHMgb2YgdGhlIHRleHQuICBQbGVhc2UgYmUgY29uc2lzdGVudC4NCg0KUDYu IOKAnFZ4TEFOIGVuY2Fw4oCdIGlzIG1lbnRpb25lZCBpbiB0aGUgSW50cm9kdWN0aW9uLCBhbmQg cG90ZW50aWFsIHRoaW5ncyBhYm91dCBoYW5kbGluZyBpdOKApmJ1dCB0aGVyZSBhcmUgbm8gcmVm ZXJlbmNlcyBhbmQgbm8gYWRkaXRpb25hbCBtZW50aW9uIGFueXdoZXJlIGVsc2UgaW4gdGhlIGRv Y3VtZW50Lg0KDQpQNy4g4oCcbWFzcyB3aXRoZHJhd+KAnSBpcyBtZW50aW9uZWQgaW4gdGhlIElu dHJvZHVjdGlvbiAo4oCc4oCmY2FuIGJlIHVzZWQgZm9yIGZsb3ctYmFzZWQgbG9hZC1iYWxhbmNp bmcgYW5kIG1hc3Mgd2l0aGRyYXcgZnVuY3Rpb25z4oCdKSwgIGluIFNlY3Rpb24gNCAo4oCc4oCm Y2FuIGJlIHVzZWQgZm9yIG1hc3Mgd2l0aGRyYXfigJ0pLCBhbmQgZmluYWxseSBTZWN0aW9uIDYu MiAodGhlIGxhc3Qgc2VjdGlvbiBpbiB0aGUgZHJhZnQhKSBoYXMgYSByZWZlcmVuY2XigKYgIFBs ZWFzZSBtb3ZlIGl0IGVhcmxpZXIgaW4gdGhlIGRvY3VtZW50Lg0KDQpQOC4gUy1WTEFOLCBDLVZM QU46IGV4cGFuZCBhbmQgcHV0IGEgcmVmZXJlbmNlIGZvciB0aGVtLg0KDQpQOS4gVGhlcmUgaXMg bm8gUmVmZXJlbmNlIHRvIGFueSBvZiB0aGUgRXh0ZW5kZWQgQ29tbXVuaXRpZXMgUkZDczogNDM2 MCwgNzE1MywgZXRj4oCmDQoNClAxMC4gUGxlYXNlIGFkZCBGaWd1cmUgbnVtYmVycy9uYW1lcy4N Cg0KUDExLiBTZWN0aW9uIDMuMSAoRVZQTiBMYXllciAyIGF0dHJpYnV0ZXMgZXh0ZW5kZWQgY29t bXVuaXR5KSBkZWZpbmVzIDMgY29udHJvbCAqZmxhZ3MqLCBidXQgdGhleSBhcmUgcmVmZXJyZWQg dG8gbGF0ZXIgaW4gdGhlIHRleHQgYXMg4oCcYml0c+KAnS4gIFBsZWFzZSBiZSBjb25zaXN0ZW50 Lg0KDQpQMTIuIFNlY3Rpb24gNCAoT3BlcmF0aW9uKTogcy93aXRoIE5leHQgSG9wIGF0dHJpYnV0 ZSBzZXQvd2l0aCB0aGUgTkVYVF9IT1AgYXR0cmlidXRlIHNldCAgIEFsc28sIGluY2x1ZGUgYW4g SW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQzQyNzEuDQoNClAxMy4gU2VjdGlvbiA2IChGYWls dXJlIFNjZW5hcmlvcyk6IOKAnOKApnRoZSBQRSBtdXN0IHdpdGhkcmF3IGFsbCB0aGUgYXNzb2Np YXRlZCBFdGhlcm5ldCBBRCByb3V0ZXPigKbigJ0gIFNob3VsZCB0aGF0IGJlIGEg4oCcTVVTVOKA nT8NCg0KUDE0LiBBIHJlZmVyZW5jZSB0byDigJxbaWV0Zi1ldnBuLW92ZXJsYXld4oCdIGFwcGVh cnMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLCBidXQgdGhlcmXigJlzIG5vIFJlZmVy ZW5jZSBsYXRlciBvbi4NCg0KDQpOaXRzOg0KDQpOMS4g4oCcQm90aCBzZXJ2aWNlcyBhcmUgc3Vw cG9ydGVkIGJ5IHVzaW5n4oCmSS5lLiwgZm9yIGJvdGggRVBMIGFuZCBFVlBMIHNlcnZpY2Vz4oCm 4oCdICBUaGUgc2Vjb25kIHBhcnQgb2YgdGhhdCBleHBsYW5hdGlvbiBpcyBhIGxvdCBjbGVhcmVy LCB5b3UgbWlnaHQgd2FudCB0byBzaW1wbGlmeSBieSBqdXN0IGxlYXZpbmcgdGhhdCBwYXJ0IGlu Lg0KDQpOMi4gVGhlIGludHJvZHVjdGlvbiByZWFkcyBsaWtlIGEgcnVzaGVkIHN1bW1hcnkgb2Yg dGhlIHNvbHV0aW9uLCB3aGljaCByZXN1bHRzIGluIHBvdGVudGlhbGx5IGNvbmZ1c2luZyB0ZXh0 LiAgU3VnZ2VzdGlvbjogZm9jdXMgdGhlIEludHJvZHVjdGlvbiBvbiBzZXR0aW5nIHRoZSBzdGFn ZS9iYWNrZ3JvdW5kIOKAkyBpZiB5b3Ugd2FudCB0byBwcm92aWRlIGEgc3VtbWFyeSBvZiB0aGUg c29sdXRpb24gKGdvb2QgaWRlYSEpLCB0aGVuIGRvIGl0IGFmdGVyIHRoZSByZXF1aXJlbWVudHMu DQoNCk4zLiBzL0V0aGVybmV0IFNlZ21lbnQgb24gYSBQRSByZWZlciB0by9FdGhlcm5ldCBTZWdt ZW50IG9uIGEgUEUgcmVmZXJzIHRvDQoNCk40LiBzL211bHRpIGhvbWXigKZzaW5nbGUgaG9tZS9t dWx0aSBob21lZOKApnNpbmdsZSBob21lZA0KDQpONS4gVGhlIHRleHQgaW4gU2VjdGlvbiA5IGlz IG1pc2FsaWduZWQuDQo= --_000_F54AFFF3D6024852B280F2DBD97B81D3vmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: <45E42912C2B6FC47BFDFF7BDDE2EB508@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoYW5rcyBBbHZhcm8gZm9yIHlvdXIgY29tbWVudHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5XaWxsIGFkZHJlc3MgdGhlbSBhbmQgcmVzdWJtaXQgdGhlIGRyYWZ0LjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+U2FtaTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6 MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFE RElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAx cHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBbHZhcm8g UmV0YW5hIChhcmV0YW5hKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28u Y29tIj5hcmV0YW5hQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIEphbnVhcnkgMjUsIDIwMTcgYXQgODoz OSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWJlc3MtZXZwbi12cHdzQGlldGYub3JnIj5kcmFm dC1pZXRmLWJlc3MtZXZwbi12cHdzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtYmVzcy1ldnBuLXZwd3NAaWV0Zi5vcmciPmRyYWZ0LWlldGYtYmVzcy1l dnBuLXZwd3NAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpiZXNzLWNoYWlyc0BpZXRmLm9y ZyI+YmVzcy1jaGFpcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmVz cy1jaGFpcnNAaWV0Zi5vcmciPmJlc3MtY2hhaXJzQGlldGYub3JnPC9hPiZndDssIEplZmZyZXkg WmhhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzp6emhhbmdAanVuaXBlci5uZXQiPnp6aGFuZ0BqdW5p cGVyLm5ldDwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVz c0BpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmci PmJlc3NAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+QUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtYmVzcy1ldnBuLXZwd3Mt MDc8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UmVzZW50LUZyb206IDwvc3Bh bj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmFsaWFzLWJvdW5jZXNAaWV0Zi5vcmciPmFsaWFzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5S ZXNlbnQtVG86IDwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29tIj5z YWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNzYWxhbUBjaXNj by5jb20iPnNzYWxhbUBjaXNjby5jb208L2E+Jmd0OywgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJh a2VAanVuaXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmR3c0BzdGVpbmJlcmduZXQubmV0Ij5kd3NAc3RlaW5iZXJnbmV0Lm5ldDwvYT4mZ3Q7 LA0KICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLmJlY2toYXVzQHRlbGVrb20uZGUiPnRob21h cy5iZWNraGF1c0B0ZWxla29tLmRlPC9hPiZndDssIFNhbWkgQm91dHJvcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNib3V0cm9zQHZtd2FyZS5jb20iPnNib3V0cm9zQHZtd2FyZS5jb208L2E+Jmd0Oywg Jmx0OzxhIGhyZWY9Im1haWx0bzpqZWZmdGFudEBnbWFpbC5jb20iPmplZmZ0YW50QGdtYWlsLmNv bTwvYT4mZ3Q7LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmdlLnJhYmFkYW5Abm9raWEuY29tIj5q b3JnZS5yYWJhZGFuQG5va2lhLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlJlc2VudC1EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBKYW51YXJ5IDI1LCAyMDE3 IGF0IDg6MzkgUE08YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHhtbG5zOnY9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2Zm aWNlLzIwMDQvMTIvb21tbCIgeG1sbnM6bXY9Imh0dHA6Ly9tYWNWbWxTY2hlbWFVcmkiIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IlRpdGxlIiBj b250ZW50PSIiPg0KPG1ldGEgbmFtZT0iS2V5d29yZHMiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1l PSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0p Ij4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUg MyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpD YWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxp YnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdo dDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjciLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgYXV0aG9yczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpISZuYnNwOyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkganVzdCBmaW5pc2hlZCByZWFkaW5nIHRo aXMgZG9jdW1lbnQuJm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBhdCBteSBjb21tZW50cyBiZWxv dyDigJMgSSB0aGluayB0aGV5IHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUuJm5ic3A7IEkgd2ls bCBzdGFydCB0aGUgSUVURiBMYXN0IENhbGwgd2hlbiB0aGUgY29tbWVudHMgaGF2ZSBiZWVuIGFk ZHJlc3NlZCBhbmQgYSBuZXcgcmV2aXNpb24NCiBoYXMgYmVlbiBwdWJsaXNoZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWFqb3I6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMS4gVGhlcmUgYXJlIDgg YXV0aG9ycyBsaXN0ZWQgb24gdGhlIGZyb250IHBhZ2UuJm5ic3A7IEZvbGxvd2luZyB0aGUgZ3Vp ZGVsaW5lcyBpbiB0aGUgUkZDIFN0eWxlIEd1aWRlIFtSRkM3MzIyXSwgd2Ugd2FudCB0aGUgbGlz dCB0byBiZSBhdCBtb3N0IDUuJm5ic3A7IFBsZWFzZSB3b3JrIGFtb25nIHlvdXJzZWx2ZXMgdG8g cmVkdWNlIHRoZSBudW1iZXIgb2YgYXV0aG9ycy4mbmJzcDsNCiBBbHRlcm5hdGl2ZWx5LCB5b3Ug Y2FuIGp1c3QgbGlzdCBhbiBFZGl0b3Igb3IgdHdvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLiBGcm9tIHRoZSBJ bnRyb2R1Y3Rpb246IOKAnFVubGlrZSBFVlBOIHdoZXJlIEV0aGVybmV0IFRhZyBJRCBpbiBFVlBO IHJvdXRlcyBhcmUgc2V0IHRvIHplcm/igKZpbiBFVlBOLVZQV1MsIEV0aGVybmV0IHRhZyBJRCBp biB0aGUgRXRoZXJuZXQgQS1EIHJvdXRlIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgdmFsdWUgaW4g YWxsIHRoZSBzZXJ2aWNlIGludGVyZmFjZQ0KIHR5cGVzLuKAnSZuYnNwOyBaZXJvIGlzIGEgdmFs aWQgdmFsdWUgZm9yIHRoZSBFdGhlcm5ldCBUYWcgSUQuJm5ic3A7IFNlY3Rpb24gMy4gKEJHUCBF eHRlbnNpb25zKSBzYXlzIHRoYXQg4oCcdGhlIEV0aGVybmV0IFRhZyBJRCAzMi1iaXQgZmllbGQg aXMgc2V0IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXLigJ0s IGJ1dCBJIGNvdWxkbuKAmXQgZmluZCBhIHBsYWNlIHdoZXJlIHRoZSBkb2N1bWVudCB0b2xkIG1l IHdoYXQgYSB2YWxpZCB2YWx1ZQ0KIGlzLiZuYnNwOyBJT1csIGhvdyBjYW4gdGhlIOKAnE1VU1Ti gJ0gYmUgZW5mb3JjZWQgaWYgdGhlcmXigJlzIG5vIGNsZWFyIGluZGljYXRpb24gb2Ygd2hhdCBp cyB2YWxpZD8mbmJzcDsgT1RPSCwgYW55IHNwZWNpZmljYXRpb24gd2FudHMgdGhlIGZpZWxkcyB0 byBjb250YWluIHZhbGlkIHZhbHVlcywgb2J2aW91c2x5ISZuYnNwOyBXaGF0IGhhcHBlbnMgaWYg dGhlIHZhbHVlIGlzIG5vdCB2YWxpZD8mbmJzcDsmbmJzcDsmbmJzcDsgQlRXLCBhbGwgdGhpcyBp cyB0byBzYXkgdGhhdCB3aXRob3V0IGEgcHJvcGVyDQogZXhwbGFuYXRpb24gKHdoaWNoIHByb2Jh Ymx5IGRvZXNu4oCZdCBiZWxvbmcgaW4gdGhlIEludHJvZHVjdGlvbiksIHRoZSB3aG9sZSBwYXJh Z3JhcGggaXMgc3VwZXJmbHVvdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTMuIFRoZSBJbnRyb2R1Y3Rpb24gc2F5 cyB0aGF0IOKAnEZvciBFVlBMIHNlcnZpY2UsIHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0 ZWQgb3ZlciBhbiBNUExTL0lQIG5ldHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUg b3JpZ2luYXRpbmcgVklEIGFuZCBhbnkgVklEIHRyYW5zbGF0aW9uIGlzIHBlcmZvcm1lZCBhdCB0 aGUgZGlzcG9zaXRpb24NCiBQRS7igJ0sIGxhdGVyIHRoZSBzYW1lIChvciBhdCBsZWFzdCBzb21l dGhpbmcgc2ltaWxhcikgaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMi4xLiAoVkxBTi1CYXNlZCBT ZXJ2aWNlIEludGVyZmFjZSk6IOKAnHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0ZWQgb3Zl ciBhbiBNUExTL0lQIG5ldHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUgb3JpZ2lu YXRpbmcgVklELCBhbmQgYSBWSUQgdHJhbnNsYXRpb24gTVVTVCBiZSBzdXBwb3J0ZWQNCiBpbiB0 aGUgZGF0YSBwYXRoIGFuZCBNVVNUIGJlIHBlcmZvcm1lZCBvbiB0aGUgZGlzcG9zaXRpb24gUEUu 4oCdJm5ic3A7IFBsZWFzZSBrZWVwIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gb25lIHBsYWNl IOKAkyBJIGFtIG5vdCBmb25kIG9mIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgSW50cm9kdWN0 aW9uOyBub3RlIHRoYXQgZXZlbiB0aG91Z2ggdGhlIHJlc3VsdCBzaG91bGQgYmUgdGhlIHNhbWUs IHRoZSB0ZXh0IGlzIGRpZmZlcmVudCAodGhlIOKAnE1VU1Rz4oCdDQogYXJlIHVzZWQgaW4gMi4x KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0zLjEuIFttaW5v cl0gSXQgaXMgbm90IGNsZWFyIGluIHRoZSB0ZXh0IHRoYXQgRVZQTCBzZXJ2aWNlIGNvcnJlc3Bv bmRzIHRvIFZMQU4tYmFzZWQgc2VydmljZS4mbmJzcDsgUGxlYXNlIGNsYXJpZnkgdGhhdC4mbmJz cDsgSW4gZmFjdCwgc29tZSBvZiB0aGUgZmxvdyBvZiB0aGUgZG9jdW1lbnQgZmVlbCBkaXNqb2lu dCBiZWNhdXNlIHNsaWdodGx5IGRpZmZlcmVudCB0ZXJtaW5vbG9neQ0KIGlzIHVzZWQgYW5kIG5v IGhpbnQgb2YgaG93IGl0IGFsbCB0aWVzIHRvZ2V0aGVyIGlzIHByZXNlbnRlZDsgbWFwcGluZyBF UEwvRVZQTCB0byB0aGUgU2VydmljZSBJbnRlcmZhY2VzLCB3aGljaCBhcmUgb25seSBtZW50aW9u ZWQgaW4gU2VjdGlvbiAyIChhbmQgdmVyeSBicmllZmx5IGluIHRoZSBJbnRyb2R1Y3Rpb24g4oCT IHNlZSBNMikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+TTQuIFNlY3Rpb24gMS4yIGlzIHRpdGxlZCBSZXF1aXJlbWVu dHMuJm5ic3A7IEhvd2V2ZXIsIHRoZSBsaXN0IHNlZW1zIHRvIGluY2x1ZGUgYSBjb21iaW5hdGlv biBvZiBzdGF0ZW1lbnRzIG9mIGZhY3QgKOKAnEVQTCBzZXJ2aWNlIGFjY2VzcyBjaXJjdWl0IG1h cHMgdG8gdGhlIHdob2xlIEV0aGVybmV0IHBvcnTigJ06IHRoaXMgaXMgcHJldHR5IG11Y2ggdGhl IGRlZmluaXRpb24NCiBvZiBFUEwpLCBzb2x1dGlvbi1zb3VuZGluZyBsaW5lcyAo4oCcRWFjaCBW TEFOIGluZGl2aWR1YWxseSAob3IgJmx0O1MtVkxBTixDLVZMQU4mZ3Q7IGNvbWJpbmF0aW9uKSB3 aWxsIGJlIGNvbnNpZGVyZWQgdG8gYmUgYW4gZW5kcG9pbnQgZm9yIGFuIEVWUEwgc2VydmljZeKA nTogbm90IG9ubHkgZG9lcyBpdCBzb3VuZCBsaWtlIHdoYXQgdGhlIHNvbHV0aW9uIHdpbGwgZG8s IGJ1dCBpdCBpcyBhbHNvIHRoZSBkZWZpbml0aW9uIG9mIEVWUEwpLCBhbmQgc3RhdGVtZW50cw0K IHRoYXQgdGFsayB0byB0aGUgY29uZmlndXJhdGlvbiBhbmQgbm90IHdoYXQgdGhlIHRlY2huaWNh bCBzb2x1dGlvbiBkZXNjcmliZWQgbGF0ZXIgY2FuIGRvICjigJxBIGdpdmVuIFBFIGNvdWxkIGhh dmUgdGhvdXNhbmRzIG9mIEVWUExzIGNvbmZpZ3VyZWQuIEl0IG11c3QgYmUgcG9zc2libGUgdG8g Y29uZmlndXJlIG11bHRpcGxlIEVWUEwgc2VydmljZXMgd2l0aGluIHRoZSBzYW1lIEVWSS7igJ06 IGlzIHRoZXJlIGFuIGFjdHVhbCBzY2FsYWJpbGl0eSByZXF1aXJlbWVudD8pLiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KIEkgd291bGQgaGF2ZSBleHBlY3RlZCBhY3R1YWwgcmVxdWlyZW1lbnRz IChmb3IgZXhhbXBsZTog4oCcRVBMIHNlcnZpY2UgYWNjZXNzIGNpcmN1aXRzIE1VU1QgbWFwIHRv IHRoZSB3aG9sZSBFdGhlcm5ldCBwb3J04oCdOyBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm90IHJl cXVpcmVkKSB0aGF0IEkgY2FuIHRoZW4gY2hlY2sgYWdhaW5zdCB0aGUgc29sdXRpb24g4oCTIGJ1 dCBpdCBhbGwgc291bmRzIGxpa2UgYSByZWhhc2ggb2Ygd2hhdCB3YXMgZXhwbGFpbmVkDQogYmVm b3JlLiZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzIj5MPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NNS4gU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lvbnMpIHNheXMgdGhhdCDigJxUaGlz IGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgdGhlIHBlciBFVkkgRXRoZXJuZXQgQS1EIHJv dXRlIHRvIHNpZ25hbCBWUFdTIHNlcnZpY2VzLiBUaGUgRXRoZXJuZXQgU2VnbWVudCBJZGVudGlm aWVyIGZpZWxkIGlzIHNldCB0byB0aGUgY3VzdG9tZXIgRVMgYW5kIHRoZQ0KIEV0aGVybmV0IFRh ZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3Rh bmNlIGlkZW50aWZpZXIu4oCdJm5ic3A7IEZpcnN0IG9mIGFsbCBbdGhpcyBpcyBtaW5vci9hIG5p dF0sIGlmIHRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBiZSBpbiB0aGUgU3RhbmRhcmRzIFRyYWNr IHRoZW4gaXQgaXMgcGFzdCB0aGUg4oCccHJvcG9zaW5n4oCdIHBoYXNlLCBpdCBpcyAqPGI+c3Bl Y2lmeWluZzwvYj4qLiZuYnNwOyBBcyBhIHNwZWNpZmljYXRpb24sDQogaXQgaXMgcmF0aGVyIHdl YWsgaW4gc29tZSBwbGFjZXM7IGZvciBleGFtcGxlLCBSRkM3NDMyIHNheXMgKGFzIGFuIGV4YW1w bGUpIHRoYXQgdGhlIOKAnEV0aGVybmV0IFRhZyBJRCBpbiBhbGwgRVZQTiByb3V0ZXMgTVVTVCBi ZSBzZXQgdG8gMOKAnTogdGhhdCBpcyBhIHN0cm9uZyBzdGF0ZW1lbnQgb2Ygd2hhdCBpcyBleHBl Y3RlZC4mbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgZG9jdW1lbnQgaXMgbW9kaWZ5aW5n IHRoZSBiZWhhdmlvciwgYnV0IG5vDQogTm9ybWF0aXZlIGxhbmd1YWdlIGlzIHVzZWQuJm5ic3A7 IFtJbiBnZW5lcmFsIEkgZG9u4oCZdCBhZHZvY2F0ZSBmb3IgdGhlIHVzZSBvZiBOb3JtYXRpdmUg bGFuZ3VhZ2UgZXZlcnl3aGVyZSwgYnV0IGluIGNhc2VzIGxpa2UgdGhpcyB3aGVyZSB0aGUgYmVo YXZpb3IgaXMgYmVpbmcgY2hhbmdlZCBmcm9tIHRoZSBiYXNlIHNwZWMgd2hlbiB1c2luZyB0aGlz IGV4dGVuc2lvbiwgaXQgc2VlbXMgbmVjZXNzYXJ5Ll08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk01LjEuIFNlY3Rpb24gMzog4oCcRXRoZXJuZXQgVGFnIElEIDMy LWJpdCBmaWVsZCBpcyBzZXQgdG8gdGhlIDI0LWJpdCBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRl bnRpZmllcuKAnSBIb3cgc2hvdWxkIHRoaXMgYmUgYWxpZ25lZCBpbnRvIHRoZSBsYXJnZXIgZmll bGQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+TTYuIFNlY3Rpb24gMy4xIChFVlBOIExheWVyIDIgYXR0cmlidXRlcyBl eHRlbmRlZCBjb21tdW5pdHkpLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5NNi4xLiBGb3IgdGhlIFAgZmxhZyDigJMg4oCcU0hPVUxEIGJlIHNldCB0 byAxIGZvciBtdWx0aWhvbWluZyBhbGwtYWN0aXZlIHNjZW5hcmlvc+KAnTogaW4gYSBtdWx0aWhv bWluZyBhbGwtYWN0aXZlIHNjZW5hcmlvLCB3aGVuIHdvdWxkIHRoaXMgZmxhZyBub3QgYmUgc2V0 PyZuYnNwOyBJT1csIHdoeSBpcyB0aGUg4oCcU0hPVUxE4oCdIG5vdCBhIOKAnE1VU1TigJ0uICZu YnNwO0EgY291cGxlIG9mDQogcGFyYWdyYXBocyBsYXRlcjog4oCc4oCmdGhlIFBFcyBpbiB0aGUg RVMgdGhhdCBhcmUgYWN0aXZlIGFuZCByZWFkeSB0byBmb3J3YXJkIHRyYWZmaWMgdG8vZnJvbSB0 aGUgQ0Ugd2lsbCBzZXQgdGhlIFAgYml0IHRvIDHigJ0uJm5ic3A7IEluIHRoZSBhbGwtYWN0aXZl IHNjZW5hcmlvLCBpcyB0aGVyZSBhIGNhc2Ugd2hlcmUgYSBQRSB3b3VsZCBub3QgYmUg4oCcYWN0 aXZlIGFuZCByZWFkeeKAnT8mbmJzcDsgV2hhdCBkb2VzIHRoYXQgbWVhbj8mbmJzcDsgQ2xhcmlm eWluZyBtYXkganVzdGlmeQ0KIHRoZSDigJxTSE9VTETigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NNi4yLiBIb3cgc2hvdWxkIHRoZSBvdGhlciBmbGFncyBp biB0aGUgQ29udHJvbCBGbGFncyBmaWVsZCBiZSBhc3NpZ25lZD8mbmJzcDsgUGxlYXNlIGRlZmlu ZSBhIG5ldyByZWdpc3RyeSBhbmQgaW5jbHVkZSB0aGUgZGV0YWlscyBpbiB0aGUgSUFOQSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TTYuMy4gV2hhdCBzaG91bGQgYSByZW1vdGUgUEUgZG8gaWYgaXQgcmVjZWl2ZXMgYm90 aCB0aGUgUCBhbmQgQiBmbGFncyBzZXQgKG9yIGJvdGggdW5zZXQpPyZuYnNwOyBJIGtub3cgdGhh dCBpbiBhIHNpbmdsZS1hY3RpdmUgc2NlbmFyaW8gdGhleSBzaG91bGQgbm90IGJlIG9uIGF0IHRo ZSBzYW1lIHRpbWXigKZidXQgd2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNC4gV2hhdCBoYXBwZW5zIGlmIHRo ZSBCIGZsYWcgaXMgc2V0IGluIHRoZSBhbGwtYWN0aXZlIHNjZW5hcmlvPyZuYnNwOyZuYnNwOyBJ IGtub3cgdGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRoZSBsaXN0IOKA kyB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gZXhwbGljaXRseSB0YWxrIGFib3V0IGl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNS4gV2hhdCB1bml0cyBpcyB0 aGUgTVRVIGluPyZuYnNwOyBIb3cgaXMgaXQgZW5jb2RlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk02LjYuIOKAnG5vbi16ZXJvIE1UVSBTSE9VTEQgYmUgY2hl Y2tlZCBhZ2FpbnN0IGxvY2FsIE1UVeKAnSZuYnNwOyBXaGVuIGlzIGl0IG9rIG5vdCB0byBjaGVj az8mbmJzcDsgSeKAmW0gd29uZGVyaW5nIHdoeSB0aGlzIOKAnFNIT1VMROKAnSBpcyBub3QgYSDi gJxNVVNU4oCdLCBzcGVjaWFsbHkgYmVjYXVzZSB0aGUgcmVzdWx0IG9mIHRoYXQgY2hlY2sgaXMg YSDigJxNVVNUIE5PVOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPk02LjcuIOKAnEFzIHBlciBbUkZDNjc5MF3igKZ0aGUgY29udHJvbCB3b3JkIChDIGJpdCBz ZXQpIFNIT1VMRCBOT1QgYmUgdXNlZOKApuKAnSZuYnNwOyBXaGVyZSBpbiBSRkM2NzkwIGRvZXMg aXQgc2F5IHRoYXQ/Jm5ic3A7IEkgc2VhcmNoZWQgZm9yIOKAnGNvbnRyb2wgd29yZOKAnSwgYnV0 IGZvdW5kIG5vdGhpbmc/Jm5ic3A7IEFsc28sIHRoaXMg4oCcU0hPVUxEIE5PVOKAnSBpcyBpbiBj b25mbGljdCB3aXRoDQogdGhlIGRlZmluaXRpb24gb2YgdGhlIEMgZmxhZzog4oCcSWYgc2V0IHRv IDEsIGEgQ29udHJvbCB3b3JkIFtSRkM0NDQ4XSBNVVNUIGJlIHByZXNlbnTigKbigJ0mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk1pbm9yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UDEuIFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgZm9yIFZQV1MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMi4gVGhlIFtNRUZdIHJlZmVyZW5jZSBkaWRu 4oCZdCB3b3JrIGZvciBtZTsgb24gYWxsIHRyaWVzIHRoZSBjb25uZWN0aW9uIHRpbWVkIG91dC4m bmJzcDsgSXMgaXQgcG9zc2libGUgdG8gZmluZCBhIG1vcmUgc3RhYmxlIHJlZmVyZW5jZT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAzLiBUaGVyZSBhcmUgc2V2 ZXJhbCBhY3JvbnltcyB0aGF0IHdvbuKAmXQgYmUgZmFtaWxpYXIgdG8gdGhlIGF2ZXJhZ2UgcmVh ZGVyIGFuZCB0aGF0IG5lZWQgdG8gYmUgZXhwYW5kZWQgb24gZmlyc3QgdXNlOiBFUywgQUQgKEEt RCksIEVWSSwgVklELCBWTkksIEVQLUxBTiwgRVZQLUxBTi4gSSBrbm93IHRoYXQgc29tZSBvZiB0 aGVzZSBhcmUgZXhwYW5kZWQgaW4NCiB0aGUgVGVybWlub2xvZ3kgU2VjdGlvbiwgYnV0IGluIHNv bWUgY2FzZXMgdGhhdCBjb21lcyBsYXRlciBpbiB0aGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA0LiBUaGUgRVZQTi1WUFdTIHRlcm0gaXMgaW50cm9k dWNlZCBmb3IgdGhlIGZpcnN0IHRpbWUgaW4gdGhlIHRleHQgYXQgdGhlIGJvdHRvbSBvZiBwYWdl IDMuJm5ic3A7IEkgdGFrZSBpdCB0aGF0IGl0IHJlZmVycyB0byB0aGUgc29sdXRpb24gcHJlc2Vu dGVkIGluIHRoaXMgZG9jdW1lbnQuJm5ic3A7IFBsZWFzZSBpbmNsdWRlIGEgc2VudGVuY2UgYXQg dGhlIHRvcCBvZiB0aGUNCiBpbnRyb2R1Y3Rpb24gdG8gY2xhcmlmeSDigJMgbm90ZSB0aGF0IHRo aXMgdGFnIGNvdWxkIGJlIHVzZWZ1bCBpbiBvdGhlciBwbGFjZXMgYXMgd2VsbC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA1LiDigJxFdGhlcm5ldCB0YWcgZmll bGTigJ0gKGFuZCBub3Qg4oCcRXRoZXJuZXQgVGFnIElE4oCdLCB3aGljaCBJ4oCZbSBhc3N1bWlu ZyBpcyB0aGUgc2FtZSB0aGluZykgaXMgdXNlZCBpbiBzZXZlcmFsIHBhcnRzIG9mIHRoZSB0ZXh0 LiZuYnNwOyBQbGVhc2UgYmUgY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlA2LiDigJxWeExBTiBlbmNhcOKAnSBpcyBtZW50aW9uZWQgaW4gdGhl IEludHJvZHVjdGlvbiwgYW5kIHBvdGVudGlhbCB0aGluZ3MgYWJvdXQgaGFuZGxpbmcgaXTigKZi dXQgdGhlcmUgYXJlIG5vIHJlZmVyZW5jZXMgYW5kIG5vIGFkZGl0aW9uYWwgbWVudGlvbiBhbnl3 aGVyZSBlbHNlIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlA3LiDigJxtYXNzIHdpdGhkcmF34oCdIGlzIG1lbnRpb25lZCBpbiB0aGUg SW50cm9kdWN0aW9uICjigJzigKZjYW4gYmUgdXNlZCBmb3IgZmxvdy1iYXNlZCBsb2FkLWJhbGFu Y2luZyBhbmQgbWFzcyB3aXRoZHJhdyBmdW5jdGlvbnPigJ0pLCZuYnNwOyBpbiBTZWN0aW9uIDQg KOKAnOKApmNhbiBiZSB1c2VkIGZvciBtYXNzIHdpdGhkcmF34oCdKSwgYW5kIGZpbmFsbHkgU2Vj dGlvbiA2LjIgKHRoZQ0KIGxhc3Qgc2VjdGlvbiBpbiB0aGUgZHJhZnQhKSBoYXMgYSByZWZlcmVu Y2XigKYmbmJzcDsgUGxlYXNlIG1vdmUgaXQgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QOC4gUy1WTEFOLCBDLVZMQU46 IGV4cGFuZCBhbmQgcHV0IGEgcmVmZXJlbmNlIGZvciB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDkuIFRoZXJlIGlzIG5vIFJlZmVyZW5jZSB0byBhbnkg b2YgdGhlIEV4dGVuZGVkIENvbW11bml0aWVzIFJGQ3M6IDQzNjAsIDcxNTMsIGV0Y+KApjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDEwLiBQbGVhc2UgYWRkIEZp Z3VyZSBudW1iZXJzL25hbWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UDExLiBTZWN0aW9uIDMuMSAoRVZQTiBMYXllciAyIGF0dHJpYnV0ZXMgZXh0ZW5kZWQg Y29tbXVuaXR5KSBkZWZpbmVzIDMgY29udHJvbCAqPGI+ZmxhZ3M8L2I+KiwgYnV0IHRoZXkgYXJl IHJlZmVycmVkIHRvIGxhdGVyIGluIHRoZSB0ZXh0IGFzIOKAnGJpdHPigJ0uJm5ic3A7IFBsZWFz ZSBiZSBjb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+UDEyLiBTZWN0aW9uIDQgKE9wZXJhdGlvbik6IHMvd2l0aCBOZXh0IEhvcCBhdHRyaWJ1dGUg c2V0L3dpdGggdGhlIE5FWFRfSE9QIGF0dHJpYnV0ZSBzZXQmbmJzcDsmbmJzcDsgQWxzbywgaW5j bHVkZSBhbiBJbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDNDI3MS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAxMy4gU2VjdGlvbiA2IChGYWlsdXJlIFNjZW5h cmlvcyk6IOKAnOKApnRoZSBQRSBtdXN0IHdpdGhkcmF3IGFsbCB0aGUgYXNzb2NpYXRlZCBFdGhl cm5ldCBBRCByb3V0ZXPigKbigJ0mbmJzcDsgU2hvdWxkIHRoYXQgYmUgYSDigJxNVVNU4oCdPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDE0LiBBIHJlZmVyZW5j ZSB0byDigJxbaWV0Zi1ldnBuLW92ZXJsYXld4oCdIGFwcGVhcnMgaW4gdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zLCBidXQgdGhlcmXigJlzIG5vIFJlZmVyZW5jZSBsYXRlciBvbi4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk5pdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5OMS4g4oCcQm90aCBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIGJ5IHVzaW5n4oCmSS5lLiwg Zm9yIGJvdGggRVBMIGFuZCBFVlBMIHNlcnZpY2Vz4oCm4oCdJm5ic3A7IFRoZSBzZWNvbmQgcGFy dCBvZiB0aGF0IGV4cGxhbmF0aW9uIGlzIGEgbG90IGNsZWFyZXIsIHlvdSBtaWdodCB3YW50IHRv IHNpbXBsaWZ5IGJ5IGp1c3QgbGVhdmluZyB0aGF0IHBhcnQgaW4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OMi4gVGhlIGludHJvZHVjdGlvbiByZWFkcyBsaWtl IGEgcnVzaGVkIHN1bW1hcnkgb2YgdGhlIHNvbHV0aW9uLCB3aGljaCByZXN1bHRzIGluIHBvdGVu dGlhbGx5IGNvbmZ1c2luZyB0ZXh0LiZuYnNwOyBTdWdnZXN0aW9uOiBmb2N1cyB0aGUgSW50cm9k dWN0aW9uIG9uIHNldHRpbmcgdGhlIHN0YWdlL2JhY2tncm91bmQg4oCTIGlmIHlvdSB3YW50IHRv IHByb3ZpZGUgYQ0KIHN1bW1hcnkgb2YgdGhlIHNvbHV0aW9uIChnb29kIGlkZWEhKSwgdGhlbiBk byBpdCBhZnRlciB0aGUgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+TjMuIHMvRXRoZXJuZXQgU2VnbWVudCBvbiBhIFBFIHJlZmVyIHRvL0V0 aGVybmV0IFNlZ21lbnQgb24gYSBQRSByZWZlcnMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk40LiBzL211bHRpIGhvbWXigKZzaW5nbGUgaG9tZS9tdWx0aSBo b21lZOKApnNpbmdsZSBob21lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+TjUuIFRoZSB0ZXh0IGluIFNlY3Rpb24gOSBpcyBtaXNhbGlnbmVkLg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_F54AFFF3D6024852B280F2DBD97B81D3vmwarecom_-- From nobody Thu Jan 26 14:44:17 2017 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 6A2B6129C1C; Thu, 26 Jan 2017 14:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.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 Yxf08XC51SDN; Thu, 26 Jan 2017 14:44:13 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0075.outbound.protection.outlook.com [104.47.32.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BB3129C18; Thu, 26 Jan 2017 14:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oGJb+wyGLMj2uLxyUTSEvagZB131Ge3f7gUdTNZ2F5A=; b=VDJq/7eahvxl35W3T7MwFolg3Hcj81gdrtxqP+zYkhrD142v1PIs5R7HEmR9KD30gOmeM7cNcLvsqW4jcKJP1Gln8Ih3mhM6bLhznTtV72xxWb90pO2lIEDzcAoChDfbFYmJ87wjfClb2yP7Ys1cuqnczHRr9g6AnA5fysu9l80= Received: from DM2PR10CA0012.namprd10.prod.outlook.com (10.160.213.22) by BY1PR10MB0277.namprd10.prod.outlook.com (10.160.111.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 26 Jan 2017 22:44:09 +0000 Received: from DM3NAM03FT004.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::204) by DM2PR10CA0012.outlook.office365.com (2a01:111:e400:5014::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12 via Frontend Transport; Thu, 26 Jan 2017 22:44:08 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=owa.infinera.com; Received: from owa.infinera.com (204.128.141.23) by DM3NAM03FT004.mail.protection.outlook.com (10.152.82.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Thu, 26 Jan 2017 22:44:08 +0000 Received: from SV-EX13-PRD2.infinera.com (10.100.103.229) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 26 Jan 2017 14:44:07 -0800 Received: from SV-EX13-PRD2.infinera.com ([10.100.101.111]) by sv-ex13-prd2.infinera.com ([10.100.101.111]) with mapi id 15.00.1178.000; Thu, 26 Jan 2017 14:44:07 -0800 From: Iftekhar Hussain To: "Alvaro Retana (aretana)" , "draft-ietf-bess-evpn-vpws@ietf.org" Thread-Topic: [bess] AD Review of draft-ietf-bess-evpn-vpws-07 Thread-Index: AQHSd44rREICzuzqR0S54vFCQWaaRaFLTVsA Date: Thu, 26 Jan 2017 22:44:06 +0000 Message-ID: References: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@cisco.com> In-Reply-To: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_f57c905ca5884767a3e0a0c2369426c2svex13prd2infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(7916002)(39830400002)(39450400003)(39410400002)(2980300002)(438002)(45904002)(189002)(377454003)(199003)(229853002)(356003)(189998001)(7636002)(8936002)(92566002)(8666007)(77096006)(246002)(4546004)(6306002)(54356999)(76176999)(38730400001)(7906003)(2900100001)(606005)(5001770100001)(8676002)(54896002)(80792005)(54906002)(4326007)(106116001)(102836003)(230783001)(626004)(108616004)(106466001)(3846002)(6116002)(790700001)(33646002)(50986999)(7736002)(9326002)(236005)(2950100002)(5660300001)(512874002)(53946003)(2906002)(53416004)(7696004)(86362001)(2501003)(24736003)(84326002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR10MB0277; H:owa.infinera.com; FPR:; SPF:Pass; PTR:outgoingmail1.infinera.com; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM03FT004; 1:YC+oul+4FOZhfj0otcjfsdW8ZwkBnWF4s7N8munhO9ZupRbHYcDvty0vf0dvhwak2CivSxhA5szstU0NQRhWpSrwFX2PYz5j7U1DFiUFI+GAVIuCadaHyxv9CGxvxLp6JzQKPhkBk7dETRWVMzZJDSj0mAXR+6uILNahT8+UdIy53dKvYgkgqmv57msk+1Ze3o+sk8AILLS/Kwwl3bLwW+ruoc3hfqbXBHEUv8P5LZ3muKIJ/Rl/FVbqB3ZwmFQwrsSSsHjgcoTu9BnJ3/6lnK5RYd40BnF5CauYuhaDf7lpG08ZLxAUTrWjfXv1gM210WY0g2TBZ+/b++TPaFWFrqWkhsf2yxIjbZEon3UmGuczJXExtuH+RNMA60ONbms4sobSsMEcTja5nZMziLk+bWaDRDChEo8XgB5TnGB1bLU8KPoM1n/lJgM2X6igxheOZMvAiOYSrlcrkLkUY7Pe1gJD/4gngjcG52GEuw051m8r5vqiqVvJ80bTEJETxsRKhGDwo5TcvzwRKhtA7jTpDujtO5C0UdRShkzgw3Apl1I= X-MS-Office365-Filtering-Correlation-Id: 6e363222-f9af-4294-7429-08d4463cd72d X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(8251501002); SRVR:BY1PR10MB0277; X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0277; 3:94/d3W+5r63KULMdJGUL3iWFYyaWysOmMc9JjlY6RF5VJlkcpHXiTEWnDxsF9X1x8RlF94yHQG6ah3bUWZ7Z5vEvCjXeUjh9hXUXLEIhw//sm+bvH4do6DOx1dUBhl6AL1TNr1mPAWGIV92AEOAVP/F4/NvxE6nemGtC2SD/zTk7pE7kTvMrS+9COS5ivdu3arXzBSWGYdQYFUPlgt2lMjmim3GAyEma4cEm5DZmbxSpRKFqjuAwi6uSo7EXw1oJ4LQeewNSjfuPRfVHXdrppYwX3Q1QxO0AgI10IC2L8SjQqY/gDvmJifvTtE8V3CGPtcJKc4mqlQ1ESPM09fmilVa5nqFa/BcUL6oD9oqa9aunxkEVn+tWUWoXFVzaqU1OgVYoudvL0xmEdHutNhv76g==; 25:IkmETkHhmo2NpbRH3VTSjfE3OBCBW9Pv4WV495XXRs5wt1DBMem6MfXmjzwblRyOLvfpvcS3/6QyotD5KNbgHYcV5SKP18gpDqcGAuPKRMAmRbyOK2OzTMYZ6DbD9yTJMIgkfcWxBPyi/SdR6KWlX3gGQ/KdqIeKWvIaW+WffhdJsXzXtzPKnyn+vqdNwFcGlg48vC86lLoqoliA9xMepa1x1qtPoAkptBplb2edkzo+ebKLOCKwTjywEZjsrMRUaSI5ZRXHDE8Zj58Iz47fX46Q7Z+xdTIOsee+WTUbox7a4jWPNzZf8T/c6cYjQE6vurA8O1jVaNigse3Ozy3BMLV5tOZLG5zBx1SahBBrrCWGJpMi2WnKKbS44voFHWXx0hWF77TbS+y+fS7pWtKsw4srgH6TWHWKA4AZvK/SzFieIJOGAqxDBfQm8hTKe79NfFMr1yifFOGNhAeQA+73OQ== X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0277; 31:he3vex+5Wt7q+1Wq85F+L27GXNMBihySt7c25gaMoJ72H/4UPYjcOosUvO5wqxG2s61dJsJElXgHYOScWYaYy1XRjFp3ybCNrJdKN0nKblBnyFaumSGGTe6/miX3qmyyxBw9dYn4sDmvz+bcIrw9VrRQ4ffJLaDkKb079leBQDBhP/gU+vnan/YAu28/cdoW0nToW6ep2yf3KsmpmMJlNj51l4voiKtco46Ny1w/+BOj5WirUPbhkhXjTtYffDpcV6fIxjrZCI/2f4MvCWrbUw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(95692535739014)(21748063052155); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(13015025)(13017025)(13018025)(13023025)(13024025)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BY1PR10MB0277; BCL:0; PCL:0; RULEID:; SRVR:BY1PR10MB0277; X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0277; 4:pLPpMh5WtDCy1KCsL43rHt94JXdvN+b8CbgZTvkq9/5qpaf4VLKYdH/AMicQU4YxgUsFu19t/HWrXbJWRKxYwbmgJjXhqMdBgBPJ8CKcfYB1zLzmilru6I2cT8QKYSWMiNhA1vz2H9Ybgc6ZQy91hL2ixRiLTOMfWsnqn9AxSkmToRJ5ww6+gLzZRThbW8ByFl+T8OoQLKzACPRJRVKI+O1muXxh6Jhzdhz5S8J6dKjFjTUMMdn8gAd6i+vCgKceDiNwox3v2DOxmZBcqaBxI6uLF3w3y8nWqrQfrb9uvHpiSvBbAMeWz56B9QXLM4ocCPbiGqbb/WpAvSSENM5J9vzbS4lFf/7WS/AVM6vqUXx/NEvUrQJFBK8IASL5DFAvaWvOFBNj9p1514oSL9U36wNJmoaBX6QUoVew14fQbNejbqD6HdR0lkfjpSxNt6or3mi9i9jGBnRxHkSnS4vx3/DeR9XfSz2nd9nR7yvVSyFr5PxPgI/mO/6mE8OGEoZLEDNz3VSqtBshT4YE6zSHjPEdAcAfug6pqEXauzxy62GciaFTwrawI3ndgtzvt+XpvkfoOgiQc0CAOBAjh4HLjcRRG+mXmrhFWUhYGQkOoXuH+RerO1pGIp8iWylcdGIuI+Z25WMQAsx9A/0WzWh5osKof6lK0i6Fy2Ln8P82I7doWdjAmKmpZQMrQJ6voSWa+La+FUKyTHtSXH1yJqDFwoFAjl+l9BCCJ24zHcWssak8WOyvE0/5B6moZmsMG9VbMUjHuu797VLocbGnqhy4Tw== X-Forefront-PRVS: 019919A9E4 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR10MB0277; 23:Th+r7R88JtRFYZhYbqY/a+2Vs17Tuh6qtJSThWf82?= =?us-ascii?Q?LDd2vIVUtSFkcxpXtYd/Mwe32wMFKBZ7B6CxbTlX+GF9PvwsZwoyl8ifjp+T?= =?us-ascii?Q?SwWhecq2rocfhrWgtlSy8wHfM0vWymvnZnBPKPQL9Iivp5PeJMRMJ4bz9ClN?= =?us-ascii?Q?sN/Dm1ZD15CIzZ6UBpWSng3uEPjiFRYnRKHxklwjnV/PjtTxernftxJNS3dM?= =?us-ascii?Q?enkUtgJRfTKNe0CC6ULlujxXqWqTeFfl7RNJishWKIx0+cWi/PTS1Py3714j?= =?us-ascii?Q?EEs5aPbzz6b2b8/IDq69Wy3KolCHvw7/9398QM/0EnPpFa4MbZZjiPmGcvbP?= =?us-ascii?Q?Dy/GCZTb+2vqc82fohtusNiJy2dudesRJ+oWVnGMIE3fC0CQuO+9my/1G6+O?= =?us-ascii?Q?OANOhnpUT1BjzOMEa7WC5H6KJlOVESO/UjmvclcRuqdF+USWiWI74P+ndX6i?= =?us-ascii?Q?3oskMMDpw3vYdTS2xPGuboN15j6bBKX9y3ek9VhtJ8xI+DbfdAdfEw1LZiu3?= =?us-ascii?Q?ykF8IleXr6QKlfPkc4yBIlxx3/66r/LJVIz4tCDNzWVCjDXlLuY/CLqdAnj9?= =?us-ascii?Q?xCt7j9myJxr82QL575WzzL8/TVeHMsONLg+Yl/w6RfWhn8E128Nl2p7ADLhZ?= =?us-ascii?Q?xouy+3DL/w7typ0IJYhv4qL77VuBKpr/XbkI4Jo/b6wkWUMODgI38WSPKCrY?= =?us-ascii?Q?zjux6yn+YKyr2QW+FSC4v+U2dMhg/wXVOvHIQenwxo5pAjZXpQhpJWfF6Vq0?= =?us-ascii?Q?dG0warhN6jSCtZWBGjPtk/i4atGL/5bVXBVHXtN6BxuPvTdapN4z/wF50+x5?= =?us-ascii?Q?GZH5TUz3L5gxjauo30aR6t+jEgmcFrCjke0q892NJSiC2bZS6M2SloM98mlk?= =?us-ascii?Q?z3GLBa34i7YnwDWm32T7vVpKAwnzNXZCc8CJoPndIijoaDe4QoqZKAA44Ihk?= =?us-ascii?Q?UenXdO158/qaDT2jtwKilbabg0Id9k9SC62FEWd55W7440BZbNnjxyvnj7pZ?= =?us-ascii?Q?138D9g+3GaLw03dqTo6+eJqWSy6cWtVNDAbAHqsQQfauHioXHZrDFjMfMUi+?= =?us-ascii?Q?VXV6Tw0OLzqeUOXYMLkzwRc8K5wmiHgA7ZZcwg/csJlm6KKq9oUg6fAoh+rV?= =?us-ascii?Q?YNlsF9M1RSCbXpsSkVw83IRJSLpElIxOy5XyWSnjEPLK96IX3osSZLWqEs3W?= =?us-ascii?Q?beIWT3EGb04ESa0ZHJOBZ9cyPdCendnl2ZY5jiU1vh17vgKDSVlanaEeDdAH?= =?us-ascii?Q?42Rs+tL5Uh1tkk73VJl/sJx+IAo7yfzMZ1J0lWalYO/eZULLFcUj5AlN8j2K?= =?us-ascii?Q?HJiB0ExIBpj4l6QBDCsQydcUpoLW7z1gyADQaHvvC0IIzSQLwdatwcnHXO7n?= =?us-ascii?Q?SkXiQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0277; 6:QwUrzeR+2pty/bTLCg6wykN4qtPOOz9kerT0l3G0ji8dh3ETXhqu28mw3XjF/ZiUqgmFq0UHRb+NNa6+DVqxVZZLgOeJySVYIDcz6Mq/yopRIGqGjmbyhV+IcO+lhcGnlUIU7oJslhK5WOLHU9PXrJtiIEybVvnH6Xx62GewqdIuy/7grwnTYFZmYzvXL3X85xA1XzHWGnJTRRmkhkMyXU4IQJ1aK2ykW1X9KNxS05YD9r1gIgkkbmsRngyk4CJ0xVpuQiqnoqqtsSMEsj1j3i/bQ/K0TrYbZ7OGl0EjwXh64w+iL6KR4rhsfsk+Yy5j/1JG0ZeJ46dLu0HGX95Liq6WrHuN1yp+2CkDg2HBLtsIqC+g3t3bDuCO5d4hkvkjKSVYnr5p5962n3RCl02Ye7+mzKV8tTVMMpXVXpfhXrs=; 5:GeGxDegPv4kyIyjKp6K6udru5/MTELuolISKHohsq9MjtjHnUREKfv8oWkTyyAR2PyOO2e/OxbEw4nJ/nkw+F/2ZWq0Kd0ByUBBSd85AOu4omFL/72/33Vffb55woUHNCbOWBoFTXQYCBp+nF6/8bw==; 24:4aJGZIXUP9GRhebe1iNIGS8nKY8baUJIYBa+8noGvK7Y6LzFdtdjzCO/JlVDz2GOvXd1ZNhmMWby/L7BktSXOyM4aHoa/lzsYdx3wJXum/k= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY1PR10MB0277; 7:cDzqRDDloK4IZRiEEUTCyoopvN+7vqicNbCOH+tqWXgwzlcriiEe6u7ydZ8PMogf+kw1jB7ICnsKuJBzDqfZiIAqo6eA0hgW4M65aCd7nGJxFbX8MZT0r/p2pSizHsiV7BWMXLtLVx84Xu/DRBRnqqhKvz5G0Ld3fERXF2tT5wnVzd2u52qw6pkCUTzuZDi/4wqMPmkfoBlOjSmONDMbpZStpFI/pl5sN2oOw9+rffmMA88wshhUz0hu/GnIxsk4e+d76JnqQlqSowDIiD6KBfymRf3R0IWAaN4MiC30cPVwLYUa43aw9nw4nLfQaON9BwsPL+H9adEdj7zs/hbvpmxLhHuD0wjHV5ajt5OnDtDRJ069AdNwUMigVXHjrJZXfL9eiNspVPCrR8CUvxSw8yrzDwwYVDkc2xPR3swbnH0S5Za1gvrLDSrJAWlqu2bSDJH7rktK9J9CktnBKAR2Uw== X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2017 22:44:08.4707 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[owa.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR10MB0277 Archived-At: Cc: Jeffrey Zhang , "bess-chairs@ietf.org" , "bess@ietf.org" Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07 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, 26 Jan 2017 22:44:16 -0000 --_000_f57c905ca5884767a3e0a0c2369426c2svex13prd2infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KSSBzdXBwb3J0IHRoaXMgd29yay4gSG93ZXZlciwgSSBkbyBoYXZlIGZl dyBjb21tZW50cyB0aGF0IEkgd291bGQgbGlrZSB0byBhZGQgdG8gdGhlIGxpc3QgZnJvbSB0aGUg QUQ6DQoNCsK3ICAgICAgICAgU2VjdGlvbiAxOiAgVGhlIHRlcm1zIEVTIGFuZCBBQ3MgYXJlIHVz ZWQgaW50ZXJjaGFuZ2VhYmx5IChlLmcuLCBzZWUg4oCc4oCmLkV0aGVybmV0IFZpcnR1YWwgUHJp dmF0ZSBMaW5lIChFVlBMKSBzZXJ2aWNlIGFzIHAycCBzZXJ2aWNlIGJldHdlZW4gYSBwYWlyIG9m IEFDc+KAnSBhbmQg4oCc4oCmRXRoZXJuZXQgUHJpdmF0ZSBMaW5lIChFUEwpIHNlcnZpY2Ug4oCm IGEgc2luZ2xlIHBhaXIgb2YgRVNlc+KAnSAuICBUaGlzIGlzIGNvbmZ1c2luZy4gV2hhdCBpcyB0 aGUgcmVhc29uIGZvciBub3QgY29uc2lkZXJpbmcgYSBwb3J0IGFzIGFuIEFDPw0KDQpTdWdnZXN0 aW9uOiBQbGVhc2UgaW5jbHVkZSBhIGNvbXBsZXRlIHNlcnZpY2UgZW50aXR5IHJlZmVyZW5jZSBt b2RlIGluIHRoaXMgZHJhZnQuIENsZWFybHkgaW5kaWNhdGUgd2hhdCBlbnRpdGllcyBhcmUgaW52 b2x2ZWQgdG8gcHJvdmlzaW9uIGEgVlBXUyAoZm9yIGV4YW1wbGUsIEVTLUFDIC0gTFNQIGV0Yy4p LiBUaGlzIHdpbGwgYWxzbyBiZSBleHRyZW1lbHkgdXNlZnVsIGZvciBkYXRhIG1vZGVsaW5nIG9m IHRoZSBzZXJ2aWNlLg0KDQrCtyAgICAgICAgIFNlY3Rpb24gMTog4oCc4oCmd2hlcmVhcywgZm9y IG1vcmUgZ2VuZXJhbCBWUFdTLOKApuKAnSAgV2hhdCBpcyBhIG1vcmUgZ2VuZXJhbCBWUFdTPw0K DQrCtyAgICAgICAgIFNlY3Rpb24gMTogSXQgaXMgaGFyZCB0byBrZWVwIHRyYWNrIG9mIHdoYXQg ZW5oYW5jZW1lbnRzIGFyZSBiZWluZyBwcm9wb3NlZCBhbmQgd2hhdCBmdW5jdGlvbmFsaXRpZXMg ZGVmaW5lZCBpbiBSRkM3NDMyIGFwcGxpZXMgb3IgZG9u4oCZdCBhcHBseSB0byBWUFdTLg0KDQpT dWdnZXN0aW9uOiBBZGQgYSBzdW1tYXJ5IHRhYmxlIHdoaWNoIGNhcHR1cmVzIHdoYXQgUm91dGUg VHlwZXMgYXBwbHkgKG9yIGRvbuKAmXQgYXBwbHkpIHRvIFZQV1MNCg0KwrcgICAgICAgICBTZWN0 aW9uIDU6IFdoYXQgaXMgZXF1aXZhbGVudCBvZiBQVyBpbiBFVlBOLVZQVyBjYXNlPyBJbiB0aGUg c2VydmljZSBtb2RlbCwgaXMgdGhlcmUgYW55IGVudGl0eSB0aGF0IG5lZWQgdG8gYmUgbW9kZWxl ZD8gSSBzZWUgdGhhdCBpbiB0aGUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNh amFzc2ktYmVzcy1ldnBuLXZwd3MtZnhjLTAxIHlvdSBhcmUgaW50cm9kdWNpbmcgYSBuZXcgZW50 aXR5IG9uIHRoZSBQU04gc2lkZSBjYWxsZWQg4oCcVlBXUyBTZXJ2aWNlIFR1bm5lbCDigKYgYSBw YWlyIG9mIEVWUE4gc2VydmljZSBsYWJlbHMgYXNzb2NpYXRlZCB3aXRoIGEgcGFpciBvZiBlbmRw b2ludHPigJ0uIFdoYXQgaXMgZGlmZmVyZW5jZSBiZXR3ZWVuIGxhYmVscyBhc3NvY2lhdGVkIHdp dGggYSBwYWlyIG9mIFZQV1MgZW5kcG9pbnRzIGluIHRoaXMgZHJhZnQgdnMgdnB3cy1meGMgZHJh ZnQ/DQoNClN1Z2dlc3Rpb246IENsZWFybHkgaWRlbnRpZnkgZW50aXR5IHRoYXQgbmVlZHMgdG8g YmUgbW9kZWxlZCBvbiB0aGUgUFNOIHNpZGUuIElmIGl0IGlzIHNlcnZpY2UgdHVubmVsLCBwbGVh c2UgaW5kaWNhdGUgc28uIElmIHRoaXMgYXNwZWN0IGlzIG5vdCBhZGRyZXNzZWQgcHJvcGVybHks IElNSE8sIHRoaXMgd2lsbCBjYXVzZSBsb3Qgb2YgY29uZnVzaW9uLg0KDQpUaGFua3MsDQpJZnRl a2hhcg0KRnJvbTogQWx2YXJvIFJldGFuYSAoYXJldGFuYSkgW21haWx0bzphcmV0YW5hQGNpc2Nv LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNSwgMjAxNyA4OjM5IFBNDQpUbzogZHJh ZnQtaWV0Zi1iZXNzLWV2cG4tdnB3c0BpZXRmLm9yZw0KQ2M6IEplZmZyZXkgWmhhbmc7IGJlc3Mt Y2hhaXJzQGlldGYub3JnOyBiZXNzQGlldGYub3JnDQpTdWJqZWN0OiBbYmVzc10gQUQgUmV2aWV3 IG9mIGRyYWZ0LWlldGYtYmVzcy1ldnBuLXZwd3MtMDcNCg0KRGVhciBhdXRob3JzOg0KDQpIaSEN Cg0KSSBqdXN0IGZpbmlzaGVkIHJlYWRpbmcgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSB0YWtlIGEg bG9vayBhdCBteSBjb21tZW50cyBiZWxvdyDigJMgSSB0aGluayB0aGV5IHNob3VsZCBiZSBlYXN5 IHRvIHJlc29sdmUuICBJIHdpbGwgc3RhcnQgdGhlIElFVEYgTGFzdCBDYWxsIHdoZW4gdGhlIGNv bW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgYW5kIGEgbmV3IHJldmlzaW9uIGhhcyBiZWVuIHB1 Ymxpc2hlZC4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg0KTWFqb3I6DQoNCk0xLiBUaGVyZSBh cmUgOCBhdXRob3JzIGxpc3RlZCBvbiB0aGUgZnJvbnQgcGFnZS4gIEZvbGxvd2luZyB0aGUgZ3Vp ZGVsaW5lcyBpbiB0aGUgUkZDIFN0eWxlIEd1aWRlIFtSRkM3MzIyXSwgd2Ugd2FudCB0aGUgbGlz dCB0byBiZSBhdCBtb3N0IDUuICBQbGVhc2Ugd29yayBhbW9uZyB5b3Vyc2VsdmVzIHRvIHJlZHVj ZSB0aGUgbnVtYmVyIG9mIGF1dGhvcnMuICBBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIGp1c3QgbGlz dCBhbiBFZGl0b3Igb3IgdHdvLg0KDQoNCk0yLiBGcm9tIHRoZSBJbnRyb2R1Y3Rpb246IOKAnFVu bGlrZSBFVlBOIHdoZXJlIEV0aGVybmV0IFRhZyBJRCBpbiBFVlBOIHJvdXRlcyBhcmUgc2V0IHRv IHplcm/igKZpbiBFVlBOLVZQV1MsIEV0aGVybmV0IHRhZyBJRCBpbiB0aGUgRXRoZXJuZXQgQS1E IHJvdXRlIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgdmFsdWUgaW4gYWxsIHRoZSBzZXJ2aWNlIGlu dGVyZmFjZSB0eXBlcy7igJ0gIFplcm8gaXMgYSB2YWxpZCB2YWx1ZSBmb3IgdGhlIEV0aGVybmV0 IFRhZyBJRC4gIFNlY3Rpb24gMy4gKEJHUCBFeHRlbnNpb25zKSBzYXlzIHRoYXQg4oCcdGhlIEV0 aGVybmV0IFRhZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2 aWNlIGluc3RhbmNlIGlkZW50aWZpZXLigJ0sIGJ1dCBJIGNvdWxkbuKAmXQgZmluZCBhIHBsYWNl IHdoZXJlIHRoZSBkb2N1bWVudCB0b2xkIG1lIHdoYXQgYSB2YWxpZCB2YWx1ZSBpcy4gIElPVywg aG93IGNhbiB0aGUg4oCcTVVTVOKAnSBiZSBlbmZvcmNlZCBpZiB0aGVyZeKAmXMgbm8gY2xlYXIg aW5kaWNhdGlvbiBvZiB3aGF0IGlzIHZhbGlkPyAgT1RPSCwgYW55IHNwZWNpZmljYXRpb24gd2Fu dHMgdGhlIGZpZWxkcyB0byBjb250YWluIHZhbGlkIHZhbHVlcywgb2J2aW91c2x5ISAgV2hhdCBo YXBwZW5zIGlmIHRoZSB2YWx1ZSBpcyBub3QgdmFsaWQ/ICAgIEJUVywgYWxsIHRoaXMgaXMgdG8g c2F5IHRoYXQgd2l0aG91dCBhIHByb3BlciBleHBsYW5hdGlvbiAod2hpY2ggcHJvYmFibHkgZG9l c27igJl0IGJlbG9uZyBpbiB0aGUgSW50cm9kdWN0aW9uKSwgdGhlIHdob2xlIHBhcmFncmFwaCBp cyBzdXBlcmZsdW91cy4NCg0KDQpNMy4gVGhlIEludHJvZHVjdGlvbiBzYXlzIHRoYXQg4oCcRm9y IEVWUEwgc2VydmljZSwgdGhlIEV0aGVybmV0IGZyYW1lcyB0cmFuc3BvcnRlZCBvdmVyIGFuIE1Q TFMvSVAgbmV0d29yayBTSE9VTEQgcmVtYWluIHRhZ2dlZCB3aXRoIHRoZSBvcmlnaW5hdGluZyBW SUQgYW5kIGFueSBWSUQgdHJhbnNsYXRpb24gaXMgcGVyZm9ybWVkIGF0IHRoZSBkaXNwb3NpdGlv biBQRS7igJ0sIGxhdGVyIHRoZSBzYW1lIChvciBhdCBsZWFzdCBzb21ldGhpbmcgc2ltaWxhcikg aXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMi4xLiAoVkxBTi1CYXNlZCBTZXJ2aWNlIEludGVyZmFj ZSk6IOKAnHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0ZWQgb3ZlciBhbiBNUExTL0lQIG5l dHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUgb3JpZ2luYXRpbmcgVklELCBhbmQg YSBWSUQgdHJhbnNsYXRpb24gTVVTVCBiZSBzdXBwb3J0ZWQgaW4gdGhlIGRhdGEgcGF0aCBhbmQg TVVTVCBiZSBwZXJmb3JtZWQgb24gdGhlIGRpc3Bvc2l0aW9uIFBFLuKAnSAgUGxlYXNlIGtlZXAg dGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiBvbmUgcGxhY2Ug4oCTIEkgYW0gbm90IGZvbmQgb2Yg bm9ybWF0aXZlIGxhbmd1YWdlIGluIHRoZSBJbnRyb2R1Y3Rpb247IG5vdGUgdGhhdCBldmVuIHRo b3VnaCB0aGUgcmVzdWx0IHNob3VsZCBiZSB0aGUgc2FtZSwgdGhlIHRleHQgaXMgZGlmZmVyZW50 ICh0aGUg4oCcTVVTVHPigJ0gYXJlIHVzZWQgaW4gMi4xKS4NCg0KTTMuMS4gW21pbm9yXSBJdCBp cyBub3QgY2xlYXIgaW4gdGhlIHRleHQgdGhhdCBFVlBMIHNlcnZpY2UgY29ycmVzcG9uZHMgdG8g VkxBTi1iYXNlZCBzZXJ2aWNlLiAgUGxlYXNlIGNsYXJpZnkgdGhhdC4gIEluIGZhY3QsIHNvbWUg b2YgdGhlIGZsb3cgb2YgdGhlIGRvY3VtZW50IGZlZWwgZGlzam9pbnQgYmVjYXVzZSBzbGlnaHRs eSBkaWZmZXJlbnQgdGVybWlub2xvZ3kgaXMgdXNlZCBhbmQgbm8gaGludCBvZiBob3cgaXQgYWxs IHRpZXMgdG9nZXRoZXIgaXMgcHJlc2VudGVkOyBtYXBwaW5nIEVQTC9FVlBMIHRvIHRoZSBTZXJ2 aWNlIEludGVyZmFjZXMsIHdoaWNoIGFyZSBvbmx5IG1lbnRpb25lZCBpbiBTZWN0aW9uIDIgKGFu ZCB2ZXJ5IGJyaWVmbHkgaW4gdGhlIEludHJvZHVjdGlvbiDigJMgc2VlIE0yKS4NCg0KDQpNNC4g U2VjdGlvbiAxLjIgaXMgdGl0bGVkIFJlcXVpcmVtZW50cy4gIEhvd2V2ZXIsIHRoZSBsaXN0IHNl ZW1zIHRvIGluY2x1ZGUgYSBjb21iaW5hdGlvbiBvZiBzdGF0ZW1lbnRzIG9mIGZhY3QgKOKAnEVQ TCBzZXJ2aWNlIGFjY2VzcyBjaXJjdWl0IG1hcHMgdG8gdGhlIHdob2xlIEV0aGVybmV0IHBvcnTi gJ06IHRoaXMgaXMgcHJldHR5IG11Y2ggdGhlIGRlZmluaXRpb24gb2YgRVBMKSwgc29sdXRpb24t c291bmRpbmcgbGluZXMgKOKAnEVhY2ggVkxBTiBpbmRpdmlkdWFsbHkgKG9yIDxTLVZMQU4sQy1W TEFOPiBjb21iaW5hdGlvbikgd2lsbCBiZSBjb25zaWRlcmVkIHRvIGJlIGFuIGVuZHBvaW50IGZv ciBhbiBFVlBMIHNlcnZpY2XigJ06IG5vdCBvbmx5IGRvZXMgaXQgc291bmQgbGlrZSB3aGF0IHRo ZSBzb2x1dGlvbiB3aWxsIGRvLCBidXQgaXQgaXMgYWxzbyB0aGUgZGVmaW5pdGlvbiBvZiBFVlBM KSwgYW5kIHN0YXRlbWVudHMgdGhhdCB0YWxrIHRvIHRoZSBjb25maWd1cmF0aW9uIGFuZCBub3Qg d2hhdCB0aGUgdGVjaG5pY2FsIHNvbHV0aW9uIGRlc2NyaWJlZCBsYXRlciBjYW4gZG8gKOKAnEEg Z2l2ZW4gUEUgY291bGQgaGF2ZSB0aG91c2FuZHMgb2YgRVZQTHMgY29uZmlndXJlZC4gSXQgbXVz dCBiZSBwb3NzaWJsZSB0byBjb25maWd1cmUgbXVsdGlwbGUgRVZQTCBzZXJ2aWNlcyB3aXRoaW4g dGhlIHNhbWUgRVZJLuKAnTogaXMgdGhlcmUgYW4gYWN0dWFsIHNjYWxhYmlsaXR5IHJlcXVpcmVt ZW50PykuICAgICBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgYWN0dWFsIHJlcXVpcmVtZW50cyAoZm9y IGV4YW1wbGU6IOKAnEVQTCBzZXJ2aWNlIGFjY2VzcyBjaXJjdWl0cyBNVVNUIG1hcCB0byB0aGUg d2hvbGUgRXRoZXJuZXQgcG9ydOKAnTsgbm9ybWF0aXZlIGxhbmd1YWdlIGlzIG5vdCByZXF1aXJl ZCkgdGhhdCBJIGNhbiB0aGVuIGNoZWNrIGFnYWluc3QgdGhlIHNvbHV0aW9uIOKAkyBidXQgaXQg YWxsIHNvdW5kcyBsaWtlIGEgcmVoYXNoIG9mIHdoYXQgd2FzIGV4cGxhaW5lZCBiZWZvcmUuICDi mLkNCg0KDQpNNS4gU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lvbnMpIHNheXMgdGhhdCDigJxUaGlz IGRvY3VtZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgdGhlIHBlciBFVkkgRXRoZXJuZXQgQS1EIHJv dXRlIHRvIHNpZ25hbCBWUFdTIHNlcnZpY2VzLiBUaGUgRXRoZXJuZXQgU2VnbWVudCBJZGVudGlm aWVyIGZpZWxkIGlzIHNldCB0byB0aGUgY3VzdG9tZXIgRVMgYW5kIHRoZSBFdGhlcm5ldCBUYWcg SUQgMzItYml0IGZpZWxkIGlzIHNldCB0byB0aGUgMjQtYml0IFZQV1Mgc2VydmljZSBpbnN0YW5j ZSBpZGVudGlmaWVyLuKAnSAgRmlyc3Qgb2YgYWxsIFt0aGlzIGlzIG1pbm9yL2Egbml0XSwgaWYg dGhpcyBkb2N1bWVudCBpbnRlbmRzIHRvIGJlIGluIHRoZSBTdGFuZGFyZHMgVHJhY2sgdGhlbiBp dCBpcyBwYXN0IHRoZSDigJxwcm9wb3NpbmfigJ0gcGhhc2UsIGl0IGlzICpzcGVjaWZ5aW5nKi4g IEFzIGEgc3BlY2lmaWNhdGlvbiwgaXQgaXMgcmF0aGVyIHdlYWsgaW4gc29tZSBwbGFjZXM7IGZv ciBleGFtcGxlLCBSRkM3NDMyIHNheXMgKGFzIGFuIGV4YW1wbGUpIHRoYXQgdGhlIOKAnEV0aGVy bmV0IFRhZyBJRCBpbiBhbGwgRVZQTiByb3V0ZXMgTVVTVCBiZSBzZXQgdG8gMOKAnTogdGhhdCBp cyBhIHN0cm9uZyBzdGF0ZW1lbnQgb2Ygd2hhdCBpcyBleHBlY3RlZC4gIE9uIHRoZSBvdGhlciBo YW5kLCB0aGlzIGRvY3VtZW50IGlzIG1vZGlmeWluZyB0aGUgYmVoYXZpb3IsIGJ1dCBubyBOb3Jt YXRpdmUgbGFuZ3VhZ2UgaXMgdXNlZC4gIFtJbiBnZW5lcmFsIEkgZG9u4oCZdCBhZHZvY2F0ZSBm b3IgdGhlIHVzZSBvZiBOb3JtYXRpdmUgbGFuZ3VhZ2UgZXZlcnl3aGVyZSwgYnV0IGluIGNhc2Vz IGxpa2UgdGhpcyB3aGVyZSB0aGUgYmVoYXZpb3IgaXMgYmVpbmcgY2hhbmdlZCBmcm9tIHRoZSBi YXNlIHNwZWMgd2hlbiB1c2luZyB0aGlzIGV4dGVuc2lvbiwgaXQgc2VlbXMgbmVjZXNzYXJ5Ll0N Cg0KTTUuMS4gU2VjdGlvbiAzOiDigJxFdGhlcm5ldCBUYWcgSUQgMzItYml0IGZpZWxkIGlzIHNl dCB0byB0aGUgMjQtYml0IFZQV1Mgc2VydmljZSBpbnN0YW5jZSBpZGVudGlmaWVy4oCdIEhvdyBz aG91bGQgdGhpcyBiZSBhbGlnbmVkIGludG8gdGhlIGxhcmdlciBmaWVsZD8NCg0KDQpNNi4gU2Vj dGlvbiAzLjEgKEVWUE4gTGF5ZXIgMiBhdHRyaWJ1dGVzIGV4dGVuZGVkIGNvbW11bml0eSkuDQoN Ck02LjEuIEZvciB0aGUgUCBmbGFnIOKAkyDigJxTSE9VTEQgYmUgc2V0IHRvIDEgZm9yIG11bHRp aG9taW5nIGFsbC1hY3RpdmUgc2NlbmFyaW9z4oCdOiBpbiBhIG11bHRpaG9taW5nIGFsbC1hY3Rp dmUgc2NlbmFyaW8sIHdoZW4gd291bGQgdGhpcyBmbGFnIG5vdCBiZSBzZXQ/ICBJT1csIHdoeSBp cyB0aGUg4oCcU0hPVUxE4oCdIG5vdCBhIOKAnE1VU1TigJ0uICBBIGNvdXBsZSBvZiBwYXJhZ3Jh cGhzIGxhdGVyOiDigJzigKZ0aGUgUEVzIGluIHRoZSBFUyB0aGF0IGFyZSBhY3RpdmUgYW5kIHJl YWR5IHRvIGZvcndhcmQgdHJhZmZpYyB0by9mcm9tIHRoZSBDRSB3aWxsIHNldCB0aGUgUCBiaXQg dG8gMeKAnS4gIEluIHRoZSBhbGwtYWN0aXZlIHNjZW5hcmlvLCBpcyB0aGVyZSBhIGNhc2Ugd2hl cmUgYSBQRSB3b3VsZCBub3QgYmUg4oCcYWN0aXZlIGFuZCByZWFkeeKAnT8gIFdoYXQgZG9lcyB0 aGF0IG1lYW4/ICBDbGFyaWZ5aW5nIG1heSBqdXN0aWZ5IHRoZSDigJxTSE9VTETigJ0uDQoNCk02 LjIuIEhvdyBzaG91bGQgdGhlIG90aGVyIGZsYWdzIGluIHRoZSBDb250cm9sIEZsYWdzIGZpZWxk IGJlIGFzc2lnbmVkPyAgUGxlYXNlIGRlZmluZSBhIG5ldyByZWdpc3RyeSBhbmQgaW5jbHVkZSB0 aGUgZGV0YWlscyBpbiB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpNNi4zLiBX aGF0IHNob3VsZCBhIHJlbW90ZSBQRSBkbyBpZiBpdCByZWNlaXZlcyBib3RoIHRoZSBQIGFuZCBC IGZsYWdzIHNldCAob3IgYm90aCB1bnNldCk/ICBJIGtub3cgdGhhdCBpbiBhIHNpbmdsZS1hY3Rp dmUgc2NlbmFyaW8gdGhleSBzaG91bGQgbm90IGJlIG9uIGF0IHRoZSBzYW1lIHRpbWXigKZidXQg d2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvPw0KDQpNNi40LiBXaGF0IGhhcHBlbnMgaWYgdGhl IEIgZmxhZyBpcyBzZXQgaW4gdGhlIGFsbC1hY3RpdmUgc2NlbmFyaW8/ICAgSSBrbm93IHRoZXJl IHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBvbiB0aGUgbGlzdCDigJMgdGhlIGRvY3Vt ZW50IG5lZWRzIHRvIGV4cGxpY2l0bHkgdGFsayBhYm91dCBpdC4NCg0KTTYuNS4gV2hhdCB1bml0 cyBpcyB0aGUgTVRVIGluPyAgSG93IGlzIGl0IGVuY29kZWQ/DQoNCk02LjYuIOKAnG5vbi16ZXJv IE1UVSBTSE9VTEQgYmUgY2hlY2tlZCBhZ2FpbnN0IGxvY2FsIE1UVeKAnSAgV2hlbiBpcyBpdCBv ayBub3QgdG8gY2hlY2s/ICBJ4oCZbSB3b25kZXJpbmcgd2h5IHRoaXMg4oCcU0hPVUxE4oCdIGlz IG5vdCBhIOKAnE1VU1TigJ0sIHNwZWNpYWxseSBiZWNhdXNlIHRoZSByZXN1bHQgb2YgdGhhdCBj aGVjayBpcyBhIOKAnE1VU1QgTk9U4oCdLg0KDQpNNi43LiDigJxBcyBwZXIgW1JGQzY3OTBd4oCm dGhlIGNvbnRyb2wgd29yZCAoQyBiaXQgc2V0KSBTSE9VTEQgTk9UIGJlIHVzZWTigKbigJ0gIFdo ZXJlIGluIFJGQzY3OTAgZG9lcyBpdCBzYXkgdGhhdD8gIEkgc2VhcmNoZWQgZm9yIOKAnGNvbnRy b2wgd29yZOKAnSwgYnV0IGZvdW5kIG5vdGhpbmc/ICBBbHNvLCB0aGlzIOKAnFNIT1VMRCBOT1Ti gJ0gaXMgaW4gY29uZmxpY3Qgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgQyBmbGFnOiDigJxJ ZiBzZXQgdG8gMSwgYSBDb250cm9sIHdvcmQgW1JGQzQ0NDhdIE1VU1QgYmUgcHJlc2VudOKApuKA nQ0KDQoNCk1pbm9yOg0KDQpQMS4gUGxlYXNlIGFkZCBhIHJlZmVyZW5jZSBmb3IgVlBXUy4NCg0K UDIuIFRoZSBbTUVGXSByZWZlcmVuY2UgZGlkbuKAmXQgd29yayBmb3IgbWU7IG9uIGFsbCB0cmll cyB0aGUgY29ubmVjdGlvbiB0aW1lZCBvdXQuICBJcyBpdCBwb3NzaWJsZSB0byBmaW5kIGEgbW9y ZSBzdGFibGUgcmVmZXJlbmNlPw0KDQpQMy4gVGhlcmUgYXJlIHNldmVyYWwgYWNyb255bXMgdGhh dCB3b27igJl0IGJlIGZhbWlsaWFyIHRvIHRoZSBhdmVyYWdlIHJlYWRlciBhbmQgdGhhdCBuZWVk IHRvIGJlIGV4cGFuZGVkIG9uIGZpcnN0IHVzZTogRVMsIEFEIChBLUQpLCBFVkksIFZJRCwgVk5J LCBFUC1MQU4sIEVWUC1MQU4uIEkga25vdyB0aGF0IHNvbWUgb2YgdGhlc2UgYXJlIGV4cGFuZGVk IGluIHRoZSBUZXJtaW5vbG9neSBTZWN0aW9uLCBidXQgaW4gc29tZSBjYXNlcyB0aGF0IGNvbWVz IGxhdGVyIGluIHRoZSB0ZXh0Lg0KDQpQNC4gVGhlIEVWUE4tVlBXUyB0ZXJtIGlzIGludHJvZHVj ZWQgZm9yIHRoZSBmaXJzdCB0aW1lIGluIHRoZSB0ZXh0IGF0IHRoZSBib3R0b20gb2YgcGFnZSAz LiAgSSB0YWtlIGl0IHRoYXQgaXQgcmVmZXJzIHRvIHRoZSBzb2x1dGlvbiBwcmVzZW50ZWQgaW4g dGhpcyBkb2N1bWVudC4gIFBsZWFzZSBpbmNsdWRlIGEgc2VudGVuY2UgYXQgdGhlIHRvcCBvZiB0 aGUgaW50cm9kdWN0aW9uIHRvIGNsYXJpZnkg4oCTIG5vdGUgdGhhdCB0aGlzIHRhZyBjb3VsZCBi ZSB1c2VmdWwgaW4gb3RoZXIgcGxhY2VzIGFzIHdlbGwuDQoNClA1LiDigJxFdGhlcm5ldCB0YWcg ZmllbGTigJ0gKGFuZCBub3Qg4oCcRXRoZXJuZXQgVGFnIElE4oCdLCB3aGljaCBJ4oCZbSBhc3N1 bWluZyBpcyB0aGUgc2FtZSB0aGluZykgaXMgdXNlZCBpbiBzZXZlcmFsIHBhcnRzIG9mIHRoZSB0 ZXh0LiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQuDQoNClA2LiDigJxWeExBTiBlbmNhcOKAnSBpcyBt ZW50aW9uZWQgaW4gdGhlIEludHJvZHVjdGlvbiwgYW5kIHBvdGVudGlhbCB0aGluZ3MgYWJvdXQg aGFuZGxpbmcgaXTigKZidXQgdGhlcmUgYXJlIG5vIHJlZmVyZW5jZXMgYW5kIG5vIGFkZGl0aW9u YWwgbWVudGlvbiBhbnl3aGVyZSBlbHNlIGluIHRoZSBkb2N1bWVudC4NCg0KUDcuIOKAnG1hc3Mg d2l0aGRyYXfigJ0gaXMgbWVudGlvbmVkIGluIHRoZSBJbnRyb2R1Y3Rpb24gKOKAnOKApmNhbiBi ZSB1c2VkIGZvciBmbG93LWJhc2VkIGxvYWQtYmFsYW5jaW5nIGFuZCBtYXNzIHdpdGhkcmF3IGZ1 bmN0aW9uc+KAnSksICBpbiBTZWN0aW9uIDQgKOKAnOKApmNhbiBiZSB1c2VkIGZvciBtYXNzIHdp dGhkcmF34oCdKSwgYW5kIGZpbmFsbHkgU2VjdGlvbiA2LjIgKHRoZSBsYXN0IHNlY3Rpb24gaW4g dGhlIGRyYWZ0ISkgaGFzIGEgcmVmZXJlbmNl4oCmICBQbGVhc2UgbW92ZSBpdCBlYXJsaWVyIGlu IHRoZSBkb2N1bWVudC4NCg0KUDguIFMtVkxBTiwgQy1WTEFOOiBleHBhbmQgYW5kIHB1dCBhIHJl ZmVyZW5jZSBmb3IgdGhlbS4NCg0KUDkuIFRoZXJlIGlzIG5vIFJlZmVyZW5jZSB0byBhbnkgb2Yg dGhlIEV4dGVuZGVkIENvbW11bml0aWVzIFJGQ3M6IDQzNjAsIDcxNTMsIGV0Y+KApg0KDQpQMTAu IFBsZWFzZSBhZGQgRmlndXJlIG51bWJlcnMvbmFtZXMuDQoNClAxMS4gU2VjdGlvbiAzLjEgKEVW UE4gTGF5ZXIgMiBhdHRyaWJ1dGVzIGV4dGVuZGVkIGNvbW11bml0eSkgZGVmaW5lcyAzIGNvbnRy b2wgKmZsYWdzKiwgYnV0IHRoZXkgYXJlIHJlZmVycmVkIHRvIGxhdGVyIGluIHRoZSB0ZXh0IGFz IOKAnGJpdHPigJ0uICBQbGVhc2UgYmUgY29uc2lzdGVudC4NCg0KUDEyLiBTZWN0aW9uIDQgKE9w ZXJhdGlvbik6IHMvd2l0aCBOZXh0IEhvcCBhdHRyaWJ1dGUgc2V0L3dpdGggdGhlIE5FWFRfSE9Q IGF0dHJpYnV0ZSBzZXQgICBBbHNvLCBpbmNsdWRlIGFuIEluZm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBSRkM0MjcxLg0KDQpQMTMuIFNlY3Rpb24gNiAoRmFpbHVyZSBTY2VuYXJpb3MpOiDigJzigKZ0 aGUgUEUgbXVzdCB3aXRoZHJhdyBhbGwgdGhlIGFzc29jaWF0ZWQgRXRoZXJuZXQgQUQgcm91dGVz 4oCm4oCdICBTaG91bGQgdGhhdCBiZSBhIOKAnE1VU1TigJ0/DQoNClAxNC4gQSByZWZlcmVuY2Ug dG8g4oCcW2lldGYtZXZwbi1vdmVybGF5XeKAnSBhcHBlYXJzIGluIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucywgYnV0IHRoZXJl4oCZcyBubyBSZWZlcmVuY2UgbGF0ZXIgb24uDQoNCg0KTml0 czoNCg0KTjEuIOKAnEJvdGggc2VydmljZXMgYXJlIHN1cHBvcnRlZCBieSB1c2luZ+KApkkuZS4s IGZvciBib3RoIEVQTCBhbmQgRVZQTCBzZXJ2aWNlc+KApuKAnSAgVGhlIHNlY29uZCBwYXJ0IG9m IHRoYXQgZXhwbGFuYXRpb24gaXMgYSBsb3QgY2xlYXJlciwgeW91IG1pZ2h0IHdhbnQgdG8gc2lt cGxpZnkgYnkganVzdCBsZWF2aW5nIHRoYXQgcGFydCBpbi4NCg0KTjIuIFRoZSBpbnRyb2R1Y3Rp b24gcmVhZHMgbGlrZSBhIHJ1c2hlZCBzdW1tYXJ5IG9mIHRoZSBzb2x1dGlvbiwgd2hpY2ggcmVz dWx0cyBpbiBwb3RlbnRpYWxseSBjb25mdXNpbmcgdGV4dC4gIFN1Z2dlc3Rpb246IGZvY3VzIHRo ZSBJbnRyb2R1Y3Rpb24gb24gc2V0dGluZyB0aGUgc3RhZ2UvYmFja2dyb3VuZCDigJMgaWYgeW91 IHdhbnQgdG8gcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlIHNvbHV0aW9uIChnb29kIGlkZWEhKSwg dGhlbiBkbyBpdCBhZnRlciB0aGUgcmVxdWlyZW1lbnRzLg0KDQpOMy4gcy9FdGhlcm5ldCBTZWdt ZW50IG9uIGEgUEUgcmVmZXIgdG8vRXRoZXJuZXQgU2VnbWVudCBvbiBhIFBFIHJlZmVycyB0bw0K DQpONC4gcy9tdWx0aSBob21l4oCmc2luZ2xlIGhvbWUvbXVsdGkgaG9tZWTigKZzaW5nbGUgaG9t ZWQNCg0KTjUuIFRoZSB0ZXh0IGluIFNlY3Rpb24gOSBpcyBtaXNhbGlnbmVkLg0K --_000_f57c905ca5884767a3e0a0c2369426c2svex13prd2infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0K c3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2Vp Z2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4 dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0MjAyNTM0 MzQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MTY1 NDc4ODIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JIHN1cHBv cnQgdGhpcyB3b3JrLiBIb3dldmVyLCBJIGRvIGhhdmUgZmV3IGNvbW1lbnRzIHRoYXQgSSB3b3Vs ZCBsaWtlIHRvIGFkZCB0byB0aGUgbGlzdCBmcm9tIHRoZSBBRDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDE6ICZuYnNwO1Ro ZSB0ZXJtcyBFUyBhbmQgQUNzIGFyZSB1c2VkIGludGVyY2hhbmdlYWJseSAoZS5nLiwgc2VlIOKA nOKApi5FdGhlcm5ldCBWaXJ0dWFsIFByaXZhdGUgTGluZSAoRVZQTCkgc2VydmljZSBhcyBwMnAg c2VydmljZSBiZXR3ZWVuIGEgcGFpciBvZiBBQ3PigJ0gYW5kIOKAnOKApkV0aGVybmV0IFByaXZh dGUgTGluZQ0KIChFUEwpIHNlcnZpY2Ug4oCmIGEgc2luZ2xlIHBhaXIgb2YgRVNlc+KAnSAuICZu YnNwO1RoaXMgaXMgY29uZnVzaW5nLiBXaGF0IGlzIHRoZSByZWFzb24gZm9yIG5vdCBjb25zaWRl cmluZyBhIHBvcnQgYXMgYW4gQUM/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFG NDk3RCI+U3VnZ2VzdGlvbjogUGxlYXNlIGluY2x1ZGUgYSBjb21wbGV0ZSBzZXJ2aWNlIGVudGl0 eSByZWZlcmVuY2UgbW9kZSBpbiB0aGlzIGRyYWZ0LiBDbGVhcmx5IGluZGljYXRlIHdoYXQgZW50 aXRpZXMgYXJlIGludm9sdmVkIHRvIHByb3Zpc2lvbiBhIFZQV1MgKGZvciBleGFtcGxlLCBFUy1B QyAtIExTUCBldGMuKS4gVGhpcw0KIHdpbGwgYWxzbyBiZSBleHRyZW1lbHkgdXNlZnVsIGZvciBk YXRhIG1vZGVsaW5nIG9mIHRoZSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMTog4oCc4oCmd2hlcmVhcywgZm9y IG1vcmUgZ2VuZXJhbCBWUFdTLOKApuKAnSAmbmJzcDtXaGF0IGlzIGEgbW9yZSBnZW5lcmFsIFZQ V1M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3 RCI+U2VjdGlvbiAxOiBJdCBpcyBoYXJkIHRvIGtlZXAgdHJhY2sgb2Ygd2hhdCBlbmhhbmNlbWVu dHMgYXJlIGJlaW5nIHByb3Bvc2VkIGFuZCB3aGF0IGZ1bmN0aW9uYWxpdGllcyBkZWZpbmVkIGlu IFJGQzc0MzIgYXBwbGllcyBvciBkb27igJl0IGFwcGx5IHRvIFZQV1MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlN1Z2dlc3Rpb246IEFkZCBhIHN1bW1hcnkgdGFibGUg d2hpY2ggY2FwdHVyZXMgd2hhdCBSb3V0ZSBUeXBlcyBhcHBseSAob3IgZG9u4oCZdCBhcHBseSkg dG8gVlBXUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0QiPlNlY3Rpb24gNTogV2hhdCBpcyBlcXVpdmFsZW50IG9mIFBXIGluIEVWUE4tVlBXIGNh c2U/IEluIHRoZSBzZXJ2aWNlIG1vZGVsLCBpcyB0aGVyZSBhbnkgZW50aXR5IHRoYXQgbmVlZCB0 byBiZSBtb2RlbGVkPyBJIHNlZSB0aGF0IGluIHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktYmVzcy1ldnBuLXZwd3MtZnhjLTAxIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FqYXNzaS1iZXNzLWV2cG4tdnB3cy1meGMtMDE8 L2E+IHlvdSBhcmUgaW50cm9kdWNpbmcgYSBuZXcgZW50aXR5IG9uIHRoZSBQU04gc2lkZSBjYWxs ZWQg4oCcVlBXUyBTZXJ2aWNlIFR1bm5lbCDigKYgYSBwYWlyIG9mIEVWUE4gc2VydmljZSBsYWJl bHMgYXNzb2NpYXRlZA0KIHdpdGggYSBwYWlyIG9mIGVuZHBvaW50c+KAnS4gV2hhdCBpcyBkaWZm ZXJlbmNlIGJldHdlZW4gbGFiZWxzIGFzc29jaWF0ZWQgd2l0aCBhIHBhaXIgb2YgVlBXUyBlbmRw b2ludHMgaW4gdGhpcyBkcmFmdCB2cyB2cHdzLWZ4YyBkcmFmdD8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEIj5TdWdnZXN0aW9uOiBDbGVhcmx5IGlkZW50aWZ5IGVudGl0 eSB0aGF0IG5lZWRzIHRvIGJlIG1vZGVsZWQgb24gdGhlIFBTTiBzaWRlLiBJZiBpdCBpcyBzZXJ2 aWNlIHR1bm5lbCwgcGxlYXNlIGluZGljYXRlIHNvLiBJZiB0aGlzIGFzcGVjdCBpcyBub3QgYWRk cmVzc2VkIHByb3Blcmx5LCBJTUhPLCB0aGlzIHdpbGwgY2F1c2UNCiBsb3Qgb2YgY29uZnVzaW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5J ZnRla2hhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4gQWx2 YXJvIFJldGFuYSAoYXJldGFuYSkgW21haWx0bzphcmV0YW5hQGNpc2NvLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjUsIDIwMTcgODozOSBQTTxicj4NCjxiPlRv OjwvYj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tdnB3c0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g SmVmZnJleSBaaGFuZzsgYmVzcy1jaGFpcnNAaWV0Zi5vcmc7IGJlc3NAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW2Jlc3NdIEFEIFJldmlldyBvZiBkcmFmdC1pZXRmLWJlc3MtZXZwbi12 cHdzLTA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgYXV0aG9yczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpISZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkganVzdCBmaW5pc2hlZCByZWFkaW5nIHRoaXMgZG9j dW1lbnQuJm5ic3A7IFBsZWFzZSB0YWtlIGEgbG9vayBhdCBteSBjb21tZW50cyBiZWxvdyDigJMg SSB0aGluayB0aGV5IHNob3VsZCBiZSBlYXN5IHRvIHJlc29sdmUuJm5ic3A7IEkgd2lsbCBzdGFy dCB0aGUgSUVURiBMYXN0IENhbGwgd2hlbiB0aGUgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3Nl ZCBhbmQgYSBuZXcgcmV2aXNpb24NCiBoYXMgYmVlbiBwdWJsaXNoZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbHZhcm8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWFqb3I6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NMS4gVGhlcmUgYXJlIDggYXV0aG9y cyBsaXN0ZWQgb24gdGhlIGZyb250IHBhZ2UuJm5ic3A7IEZvbGxvd2luZyB0aGUgZ3VpZGVsaW5l cyBpbiB0aGUgUkZDIFN0eWxlIEd1aWRlIFtSRkM3MzIyXSwgd2Ugd2FudCB0aGUgbGlzdCB0byBi ZSBhdCBtb3N0IDUuJm5ic3A7IFBsZWFzZSB3b3JrIGFtb25nIHlvdXJzZWx2ZXMgdG8gcmVkdWNl IHRoZSBudW1iZXIgb2YgYXV0aG9ycy4mbmJzcDsNCiBBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIGp1 c3QgbGlzdCBhbiBFZGl0b3Igb3IgdHdvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0yLiBGcm9tIHRoZSBJbnRyb2R1 Y3Rpb246IOKAnFVubGlrZSBFVlBOIHdoZXJlIEV0aGVybmV0IFRhZyBJRCBpbiBFVlBOIHJvdXRl cyBhcmUgc2V0IHRvIHplcm/igKZpbiBFVlBOLVZQV1MsIEV0aGVybmV0IHRhZyBJRCBpbiB0aGUg RXRoZXJuZXQgQS1EIHJvdXRlIE1VU1QgYmUgc2V0IHRvIGEgdmFsaWQgdmFsdWUgaW4gYWxsIHRo ZSBzZXJ2aWNlIGludGVyZmFjZQ0KIHR5cGVzLuKAnSZuYnNwOyBaZXJvIGlzIGEgdmFsaWQgdmFs dWUgZm9yIHRoZSBFdGhlcm5ldCBUYWcgSUQuJm5ic3A7IFNlY3Rpb24gMy4gKEJHUCBFeHRlbnNp b25zKSBzYXlzIHRoYXQg4oCcdGhlIEV0aGVybmV0IFRhZyBJRCAzMi1iaXQgZmllbGQgaXMgc2V0 IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlkZW50aWZpZXLigJ0sIGJ1dCBJ IGNvdWxkbuKAmXQgZmluZCBhIHBsYWNlIHdoZXJlIHRoZSBkb2N1bWVudCB0b2xkIG1lIHdoYXQg YSB2YWxpZCB2YWx1ZQ0KIGlzLiZuYnNwOyBJT1csIGhvdyBjYW4gdGhlIOKAnE1VU1TigJ0gYmUg ZW5mb3JjZWQgaWYgdGhlcmXigJlzIG5vIGNsZWFyIGluZGljYXRpb24gb2Ygd2hhdCBpcyB2YWxp ZD8mbmJzcDsgT1RPSCwgYW55IHNwZWNpZmljYXRpb24gd2FudHMgdGhlIGZpZWxkcyB0byBjb250 YWluIHZhbGlkIHZhbHVlcywgb2J2aW91c2x5ISZuYnNwOyBXaGF0IGhhcHBlbnMgaWYgdGhlIHZh bHVlIGlzIG5vdCB2YWxpZD8mbmJzcDsmbmJzcDsmbmJzcDsgQlRXLCBhbGwgdGhpcyBpcyB0byBz YXkgdGhhdCB3aXRob3V0IGEgcHJvcGVyDQogZXhwbGFuYXRpb24gKHdoaWNoIHByb2JhYmx5IGRv ZXNu4oCZdCBiZWxvbmcgaW4gdGhlIEludHJvZHVjdGlvbiksIHRoZSB3aG9sZSBwYXJhZ3JhcGgg aXMgc3VwZXJmbHVvdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTMuIFRoZSBJbnRyb2R1Y3Rpb24gc2F5cyB0aGF0 IOKAnEZvciBFVlBMIHNlcnZpY2UsIHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0ZWQgb3Zl ciBhbiBNUExTL0lQIG5ldHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUgb3JpZ2lu YXRpbmcgVklEIGFuZCBhbnkgVklEIHRyYW5zbGF0aW9uIGlzIHBlcmZvcm1lZCBhdCB0aGUgZGlz cG9zaXRpb24NCiBQRS7igJ0sIGxhdGVyIHRoZSBzYW1lIChvciBhdCBsZWFzdCBzb21ldGhpbmcg c2ltaWxhcikgaXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMi4xLiAoVkxBTi1CYXNlZCBTZXJ2aWNl IEludGVyZmFjZSk6IOKAnHRoZSBFdGhlcm5ldCBmcmFtZXMgdHJhbnNwb3J0ZWQgb3ZlciBhbiBN UExTL0lQIG5ldHdvcmsgU0hPVUxEIHJlbWFpbiB0YWdnZWQgd2l0aCB0aGUgb3JpZ2luYXRpbmcg VklELCBhbmQgYSBWSUQgdHJhbnNsYXRpb24gTVVTVCBiZSBzdXBwb3J0ZWQNCiBpbiB0aGUgZGF0 YSBwYXRoIGFuZCBNVVNUIGJlIHBlcmZvcm1lZCBvbiB0aGUgZGlzcG9zaXRpb24gUEUu4oCdJm5i c3A7IFBsZWFzZSBrZWVwIHRoZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gb25lIHBsYWNlIOKAkyBJ IGFtIG5vdCBmb25kIG9mIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgSW50cm9kdWN0aW9uOyBu b3RlIHRoYXQgZXZlbiB0aG91Z2ggdGhlIHJlc3VsdCBzaG91bGQgYmUgdGhlIHNhbWUsIHRoZSB0 ZXh0IGlzIGRpZmZlcmVudCAodGhlIOKAnE1VU1Rz4oCdDQogYXJlIHVzZWQgaW4gMi4xKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk0zLjEuIFttaW5vcl0gSXQg aXMgbm90IGNsZWFyIGluIHRoZSB0ZXh0IHRoYXQgRVZQTCBzZXJ2aWNlIGNvcnJlc3BvbmRzIHRv IFZMQU4tYmFzZWQgc2VydmljZS4mbmJzcDsgUGxlYXNlIGNsYXJpZnkgdGhhdC4mbmJzcDsgSW4g ZmFjdCwgc29tZSBvZiB0aGUgZmxvdyBvZiB0aGUgZG9jdW1lbnQgZmVlbCBkaXNqb2ludCBiZWNh dXNlIHNsaWdodGx5IGRpZmZlcmVudCB0ZXJtaW5vbG9neQ0KIGlzIHVzZWQgYW5kIG5vIGhpbnQg b2YgaG93IGl0IGFsbCB0aWVzIHRvZ2V0aGVyIGlzIHByZXNlbnRlZDsgbWFwcGluZyBFUEwvRVZQ TCB0byB0aGUgU2VydmljZSBJbnRlcmZhY2VzLCB3aGljaCBhcmUgb25seSBtZW50aW9uZWQgaW4g U2VjdGlvbiAyIChhbmQgdmVyeSBicmllZmx5IGluIHRoZSBJbnRyb2R1Y3Rpb24g4oCTIHNlZSBN MikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+TTQuIFNlY3Rpb24gMS4yIGlzIHRpdGxlZCBSZXF1aXJlbWVudHMuJm5i c3A7IEhvd2V2ZXIsIHRoZSBsaXN0IHNlZW1zIHRvIGluY2x1ZGUgYSBjb21iaW5hdGlvbiBvZiBz dGF0ZW1lbnRzIG9mIGZhY3QgKOKAnEVQTCBzZXJ2aWNlIGFjY2VzcyBjaXJjdWl0IG1hcHMgdG8g dGhlIHdob2xlIEV0aGVybmV0IHBvcnTigJ06IHRoaXMgaXMgcHJldHR5IG11Y2ggdGhlIGRlZmlu aXRpb24NCiBvZiBFUEwpLCBzb2x1dGlvbi1zb3VuZGluZyBsaW5lcyAo4oCcRWFjaCBWTEFOIGlu ZGl2aWR1YWxseSAob3IgJmx0O1MtVkxBTixDLVZMQU4mZ3Q7IGNvbWJpbmF0aW9uKSB3aWxsIGJl IGNvbnNpZGVyZWQgdG8gYmUgYW4gZW5kcG9pbnQgZm9yIGFuIEVWUEwgc2VydmljZeKAnTogbm90 IG9ubHkgZG9lcyBpdCBzb3VuZCBsaWtlIHdoYXQgdGhlIHNvbHV0aW9uIHdpbGwgZG8sIGJ1dCBp dCBpcyBhbHNvIHRoZSBkZWZpbml0aW9uIG9mIEVWUEwpLCBhbmQgc3RhdGVtZW50cw0KIHRoYXQg dGFsayB0byB0aGUgY29uZmlndXJhdGlvbiBhbmQgbm90IHdoYXQgdGhlIHRlY2huaWNhbCBzb2x1 dGlvbiBkZXNjcmliZWQgbGF0ZXIgY2FuIGRvICjigJxBIGdpdmVuIFBFIGNvdWxkIGhhdmUgdGhv dXNhbmRzIG9mIEVWUExzIGNvbmZpZ3VyZWQuIEl0IG11c3QgYmUgcG9zc2libGUgdG8gY29uZmln dXJlIG11bHRpcGxlIEVWUEwgc2VydmljZXMgd2l0aGluIHRoZSBzYW1lIEVWSS7igJ06IGlzIHRo ZXJlIGFuIGFjdHVhbCBzY2FsYWJpbGl0eSByZXF1aXJlbWVudD8pLiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KIEkgd291bGQgaGF2ZSBleHBlY3RlZCBhY3R1YWwgcmVxdWlyZW1lbnRzIChmb3Ig ZXhhbXBsZTog4oCcRVBMIHNlcnZpY2UgYWNjZXNzIGNpcmN1aXRzIE1VU1QgbWFwIHRvIHRoZSB3 aG9sZSBFdGhlcm5ldCBwb3J04oCdOyBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm90IHJlcXVpcmVk KSB0aGF0IEkgY2FuIHRoZW4gY2hlY2sgYWdhaW5zdCB0aGUgc29sdXRpb24g4oCTIGJ1dCBpdCBh bGwgc291bmRzIGxpa2UgYSByZWhhc2ggb2Ygd2hhdCB3YXMgZXhwbGFpbmVkDQogYmVmb3JlLiZu YnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj5MPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5NNS4gU2VjdGlvbiAzLiAoQkdQIEV4dGVuc2lvbnMpIHNheXMgdGhhdCDigJxUaGlzIGRvY3Vt ZW50IHByb3Bvc2VzIHRoZSB1c2Ugb2YgdGhlIHBlciBFVkkgRXRoZXJuZXQgQS1EIHJvdXRlIHRv IHNpZ25hbCBWUFdTIHNlcnZpY2VzLiBUaGUgRXRoZXJuZXQgU2VnbWVudCBJZGVudGlmaWVyIGZp ZWxkIGlzIHNldCB0byB0aGUgY3VzdG9tZXIgRVMgYW5kIHRoZQ0KIEV0aGVybmV0IFRhZyBJRCAz Mi1iaXQgZmllbGQgaXMgc2V0IHRvIHRoZSAyNC1iaXQgVlBXUyBzZXJ2aWNlIGluc3RhbmNlIGlk ZW50aWZpZXIu4oCdJm5ic3A7IEZpcnN0IG9mIGFsbCBbdGhpcyBpcyBtaW5vci9hIG5pdF0sIGlm IHRoaXMgZG9jdW1lbnQgaW50ZW5kcyB0byBiZSBpbiB0aGUgU3RhbmRhcmRzIFRyYWNrIHRoZW4g aXQgaXMgcGFzdCB0aGUg4oCccHJvcG9zaW5n4oCdIHBoYXNlLCBpdCBpcyAqPGI+c3BlY2lmeWlu ZzwvYj4qLiZuYnNwOyBBcyBhIHNwZWNpZmljYXRpb24sDQogaXQgaXMgcmF0aGVyIHdlYWsgaW4g c29tZSBwbGFjZXM7IGZvciBleGFtcGxlLCBSRkM3NDMyIHNheXMgKGFzIGFuIGV4YW1wbGUpIHRo YXQgdGhlIOKAnEV0aGVybmV0IFRhZyBJRCBpbiBhbGwgRVZQTiByb3V0ZXMgTVVTVCBiZSBzZXQg dG8gMOKAnTogdGhhdCBpcyBhIHN0cm9uZyBzdGF0ZW1lbnQgb2Ygd2hhdCBpcyBleHBlY3RlZC4m bmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgZG9jdW1lbnQgaXMgbW9kaWZ5aW5nIHRoZSBi ZWhhdmlvciwgYnV0IG5vDQogTm9ybWF0aXZlIGxhbmd1YWdlIGlzIHVzZWQuJm5ic3A7IFtJbiBn ZW5lcmFsIEkgZG9u4oCZdCBhZHZvY2F0ZSBmb3IgdGhlIHVzZSBvZiBOb3JtYXRpdmUgbGFuZ3Vh Z2UgZXZlcnl3aGVyZSwgYnV0IGluIGNhc2VzIGxpa2UgdGhpcyB3aGVyZSB0aGUgYmVoYXZpb3Ig aXMgYmVpbmcgY2hhbmdlZCBmcm9tIHRoZSBiYXNlIHNwZWMgd2hlbiB1c2luZyB0aGlzIGV4dGVu c2lvbiwgaXQgc2VlbXMgbmVjZXNzYXJ5Ll08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk01LjEuIFNlY3Rpb24gMzog4oCcRXRoZXJuZXQgVGFnIElEIDMyLWJpdCBm aWVsZCBpcyBzZXQgdG8gdGhlIDI0LWJpdCBWUFdTIHNlcnZpY2UgaW5zdGFuY2UgaWRlbnRpZmll cuKAnSBIb3cgc2hvdWxkIHRoaXMgYmUgYWxpZ25lZCBpbnRvIHRoZSBsYXJnZXIgZmllbGQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+TTYuIFNlY3Rpb24gMy4xIChFVlBOIExheWVyIDIgYXR0cmlidXRlcyBleHRlbmRl ZCBjb21tdW5pdHkpLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NNi4xLiBGb3IgdGhlIFAgZmxhZyDigJMg4oCcU0hPVUxEIGJlIHNldCB0byAxIGZv ciBtdWx0aWhvbWluZyBhbGwtYWN0aXZlIHNjZW5hcmlvc+KAnTogaW4gYSBtdWx0aWhvbWluZyBh bGwtYWN0aXZlIHNjZW5hcmlvLCB3aGVuIHdvdWxkIHRoaXMgZmxhZyBub3QgYmUgc2V0PyZuYnNw OyBJT1csIHdoeSBpcyB0aGUg4oCcU0hPVUxE4oCdIG5vdCBhIOKAnE1VU1TigJ0uICZuYnNwO0Eg Y291cGxlIG9mDQogcGFyYWdyYXBocyBsYXRlcjog4oCc4oCmdGhlIFBFcyBpbiB0aGUgRVMgdGhh dCBhcmUgYWN0aXZlIGFuZCByZWFkeSB0byBmb3J3YXJkIHRyYWZmaWMgdG8vZnJvbSB0aGUgQ0Ug d2lsbCBzZXQgdGhlIFAgYml0IHRvIDHigJ0uJm5ic3A7IEluIHRoZSBhbGwtYWN0aXZlIHNjZW5h cmlvLCBpcyB0aGVyZSBhIGNhc2Ugd2hlcmUgYSBQRSB3b3VsZCBub3QgYmUg4oCcYWN0aXZlIGFu ZCByZWFkeeKAnT8mbmJzcDsgV2hhdCBkb2VzIHRoYXQgbWVhbj8mbmJzcDsgQ2xhcmlmeWluZyBt YXkganVzdGlmeQ0KIHRoZSDigJxTSE9VTETigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5NNi4yLiBIb3cgc2hvdWxkIHRoZSBvdGhlciBmbGFncyBpbiB0aGUg Q29udHJvbCBGbGFncyBmaWVsZCBiZSBhc3NpZ25lZD8mbmJzcDsgUGxlYXNlIGRlZmluZSBhIG5l dyByZWdpc3RyeSBhbmQgaW5jbHVkZSB0aGUgZGV0YWlscyBpbiB0aGUgSUFOQSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ TTYuMy4gV2hhdCBzaG91bGQgYSByZW1vdGUgUEUgZG8gaWYgaXQgcmVjZWl2ZXMgYm90aCB0aGUg UCBhbmQgQiBmbGFncyBzZXQgKG9yIGJvdGggdW5zZXQpPyZuYnNwOyBJIGtub3cgdGhhdCBpbiBh IHNpbmdsZS1hY3RpdmUgc2NlbmFyaW8gdGhleSBzaG91bGQgbm90IGJlIG9uIGF0IHRoZSBzYW1l IHRpbWXigKZidXQgd2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNC4gV2hhdCBoYXBwZW5zIGlmIHRoZSBCIGZs YWcgaXMgc2V0IGluIHRoZSBhbGwtYWN0aXZlIHNjZW5hcmlvPyZuYnNwOyZuYnNwOyBJIGtub3cg dGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIHRoZSBsaXN0IOKAkyB0aGUg ZG9jdW1lbnQgbmVlZHMgdG8gZXhwbGljaXRseSB0YWxrIGFib3V0IGl0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TTYuNS4gV2hhdCB1bml0cyBpcyB0aGUgTVRV IGluPyZuYnNwOyBIb3cgaXMgaXQgZW5jb2RlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPk02LjYuIOKAnG5vbi16ZXJvIE1UVSBTSE9VTEQgYmUgY2hlY2tlZCBh Z2FpbnN0IGxvY2FsIE1UVeKAnSZuYnNwOyBXaGVuIGlzIGl0IG9rIG5vdCB0byBjaGVjaz8mbmJz cDsgSeKAmW0gd29uZGVyaW5nIHdoeSB0aGlzIOKAnFNIT1VMROKAnSBpcyBub3QgYSDigJxNVVNU 4oCdLCBzcGVjaWFsbHkgYmVjYXVzZSB0aGUgcmVzdWx0IG9mIHRoYXQgY2hlY2sgaXMgYSDigJxN VVNUIE5PVOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk02 LjcuIOKAnEFzIHBlciBbUkZDNjc5MF3igKZ0aGUgY29udHJvbCB3b3JkIChDIGJpdCBzZXQpIFNI T1VMRCBOT1QgYmUgdXNlZOKApuKAnSZuYnNwOyBXaGVyZSBpbiBSRkM2NzkwIGRvZXMgaXQgc2F5 IHRoYXQ/Jm5ic3A7IEkgc2VhcmNoZWQgZm9yIOKAnGNvbnRyb2wgd29yZOKAnSwgYnV0IGZvdW5k IG5vdGhpbmc/Jm5ic3A7IEFsc28sIHRoaXMg4oCcU0hPVUxEIE5PVOKAnSBpcyBpbiBjb25mbGlj dCB3aXRoDQogdGhlIGRlZmluaXRpb24gb2YgdGhlIEMgZmxhZzog4oCcSWYgc2V0IHRvIDEsIGEg Q29udHJvbCB3b3JkIFtSRkM0NDQ4XSBNVVNUIGJlIHByZXNlbnTigKbigJ0mbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPk1pbm9yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UDEuIFBsZWFzZSBhZGQgYSByZWZlcmVuY2UgZm9yIFZQV1MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QMi4gVGhlIFtNRUZdIHJlZmVyZW5jZSBkaWRu4oCZdCB3 b3JrIGZvciBtZTsgb24gYWxsIHRyaWVzIHRoZSBjb25uZWN0aW9uIHRpbWVkIG91dC4mbmJzcDsg SXMgaXQgcG9zc2libGUgdG8gZmluZCBhIG1vcmUgc3RhYmxlIHJlZmVyZW5jZT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAzLiBUaGVyZSBhcmUgc2V2ZXJhbCBh Y3JvbnltcyB0aGF0IHdvbuKAmXQgYmUgZmFtaWxpYXIgdG8gdGhlIGF2ZXJhZ2UgcmVhZGVyIGFu ZCB0aGF0IG5lZWQgdG8gYmUgZXhwYW5kZWQgb24gZmlyc3QgdXNlOiBFUywgQUQgKEEtRCksIEVW SSwgVklELCBWTkksIEVQLUxBTiwgRVZQLUxBTi4gSSBrbm93IHRoYXQgc29tZSBvZiB0aGVzZSBh cmUgZXhwYW5kZWQgaW4NCiB0aGUgVGVybWlub2xvZ3kgU2VjdGlvbiwgYnV0IGluIHNvbWUgY2Fz ZXMgdGhhdCBjb21lcyBsYXRlciBpbiB0aGUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlA0LiBUaGUgRVZQTi1WUFdTIHRlcm0gaXMgaW50cm9kdWNlZCBm b3IgdGhlIGZpcnN0IHRpbWUgaW4gdGhlIHRleHQgYXQgdGhlIGJvdHRvbSBvZiBwYWdlIDMuJm5i c3A7IEkgdGFrZSBpdCB0aGF0IGl0IHJlZmVycyB0byB0aGUgc29sdXRpb24gcHJlc2VudGVkIGlu IHRoaXMgZG9jdW1lbnQuJm5ic3A7IFBsZWFzZSBpbmNsdWRlIGEgc2VudGVuY2UgYXQgdGhlIHRv cCBvZiB0aGUNCiBpbnRyb2R1Y3Rpb24gdG8gY2xhcmlmeSDigJMgbm90ZSB0aGF0IHRoaXMgdGFn IGNvdWxkIGJlIHVzZWZ1bCBpbiBvdGhlciBwbGFjZXMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlA1LiDigJxFdGhlcm5ldCB0YWcgZmllbGTigJ0g KGFuZCBub3Qg4oCcRXRoZXJuZXQgVGFnIElE4oCdLCB3aGljaCBJ4oCZbSBhc3N1bWluZyBpcyB0 aGUgc2FtZSB0aGluZykgaXMgdXNlZCBpbiBzZXZlcmFsIHBhcnRzIG9mIHRoZSB0ZXh0LiZuYnNw OyBQbGVhc2UgYmUgY29uc2lzdGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlA2LiDigJxWeExBTiBlbmNhcOKAnSBpcyBtZW50aW9uZWQgaW4gdGhlIEludHJv ZHVjdGlvbiwgYW5kIHBvdGVudGlhbCB0aGluZ3MgYWJvdXQgaGFuZGxpbmcgaXTigKZidXQgdGhl cmUgYXJlIG5vIHJlZmVyZW5jZXMgYW5kIG5vIGFkZGl0aW9uYWwgbWVudGlvbiBhbnl3aGVyZSBl bHNlIGluIHRoZSBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPlA3LiDigJxtYXNzIHdpdGhkcmF34oCdIGlzIG1lbnRpb25lZCBpbiB0aGUgSW50cm9k dWN0aW9uICjigJzigKZjYW4gYmUgdXNlZCBmb3IgZmxvdy1iYXNlZCBsb2FkLWJhbGFuY2luZyBh bmQgbWFzcyB3aXRoZHJhdyBmdW5jdGlvbnPigJ0pLCZuYnNwOyBpbiBTZWN0aW9uIDQgKOKAnOKA pmNhbiBiZSB1c2VkIGZvciBtYXNzIHdpdGhkcmF34oCdKSwgYW5kIGZpbmFsbHkgU2VjdGlvbiA2 LjIgKHRoZQ0KIGxhc3Qgc2VjdGlvbiBpbiB0aGUgZHJhZnQhKSBoYXMgYSByZWZlcmVuY2XigKYm bmJzcDsgUGxlYXNlIG1vdmUgaXQgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QOC4gUy1WTEFOLCBDLVZMQU46IGV4cGFu ZCBhbmQgcHV0IGEgcmVmZXJlbmNlIGZvciB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+UDkuIFRoZXJlIGlzIG5vIFJlZmVyZW5jZSB0byBhbnkgb2YgdGhl IEV4dGVuZGVkIENvbW11bml0aWVzIFJGQ3M6IDQzNjAsIDcxNTMsIGV0Y+KApjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDEwLiBQbGVhc2UgYWRkIEZpZ3VyZSBu dW1iZXJzL25hbWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UDExLiBTZWN0aW9uIDMuMSAoRVZQTiBMYXllciAyIGF0dHJpYnV0ZXMgZXh0ZW5kZWQgY29tbXVu aXR5KSBkZWZpbmVzIDMgY29udHJvbCAqPGI+ZmxhZ3M8L2I+KiwgYnV0IHRoZXkgYXJlIHJlZmVy cmVkIHRvIGxhdGVyIGluIHRoZSB0ZXh0IGFzIOKAnGJpdHPigJ0uJm5ic3A7IFBsZWFzZSBiZSBj b25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDEy LiBTZWN0aW9uIDQgKE9wZXJhdGlvbik6IHMvd2l0aCBOZXh0IEhvcCBhdHRyaWJ1dGUgc2V0L3dp dGggdGhlIE5FWFRfSE9QIGF0dHJpYnV0ZSBzZXQmbmJzcDsmbmJzcDsgQWxzbywgaW5jbHVkZSBh biBJbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDNDI3MS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlAxMy4gU2VjdGlvbiA2IChGYWlsdXJlIFNjZW5hcmlvcyk6 IOKAnOKApnRoZSBQRSBtdXN0IHdpdGhkcmF3IGFsbCB0aGUgYXNzb2NpYXRlZCBFdGhlcm5ldCBB RCByb3V0ZXPigKbigJ0mbmJzcDsgU2hvdWxkIHRoYXQgYmUgYSDigJxNVVNU4oCdPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UDE0LiBBIHJlZmVyZW5jZSB0byDi gJxbaWV0Zi1ldnBuLW92ZXJsYXld4oCdIGFwcGVhcnMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zLCBidXQgdGhlcmXigJlzIG5vIFJlZmVyZW5jZSBsYXRlciBvbi4mbmJzcDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPk5pdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5O MS4g4oCcQm90aCBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIGJ5IHVzaW5n4oCmSS5lLiwgZm9yIGJv dGggRVBMIGFuZCBFVlBMIHNlcnZpY2Vz4oCm4oCdJm5ic3A7IFRoZSBzZWNvbmQgcGFydCBvZiB0 aGF0IGV4cGxhbmF0aW9uIGlzIGEgbG90IGNsZWFyZXIsIHlvdSBtaWdodCB3YW50IHRvIHNpbXBs aWZ5IGJ5IGp1c3QgbGVhdmluZyB0aGF0IHBhcnQgaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5OMi4gVGhlIGludHJvZHVjdGlvbiByZWFkcyBsaWtlIGEgcnVz aGVkIHN1bW1hcnkgb2YgdGhlIHNvbHV0aW9uLCB3aGljaCByZXN1bHRzIGluIHBvdGVudGlhbGx5 IGNvbmZ1c2luZyB0ZXh0LiZuYnNwOyBTdWdnZXN0aW9uOiBmb2N1cyB0aGUgSW50cm9kdWN0aW9u IG9uIHNldHRpbmcgdGhlIHN0YWdlL2JhY2tncm91bmQg4oCTIGlmIHlvdSB3YW50IHRvIHByb3Zp ZGUgYQ0KIHN1bW1hcnkgb2YgdGhlIHNvbHV0aW9uIChnb29kIGlkZWEhKSwgdGhlbiBkbyBpdCBh ZnRlciB0aGUgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+TjMuIHMvRXRoZXJuZXQgU2VnbWVudCBvbiBhIFBFIHJlZmVyIHRvL0V0aGVybmV0 IFNlZ21lbnQgb24gYSBQRSByZWZlcnMgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk40LiBzL211bHRpIGhvbWXigKZzaW5nbGUgaG9tZS9tdWx0aSBob21lZOKA pnNpbmdsZSBob21lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ TjUuIFRoZSB0ZXh0IGluIFNlY3Rpb24gOSBpcyBtaXNhbGlnbmVkLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f57c905ca5884767a3e0a0c2369426c2svex13prd2infineracom_-- From nobody Tue Jan 31 01:08:30 2017 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 95C5E126D74; Tue, 31 Jan 2017 01:08:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148585370859.2503.7565324955196043623.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 01:08:28 -0800 Archived-At: Cc: aretana@cisco.com, thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org Subject: [bess] bess - New Meeting Session Request for IETF 98 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, 31 Jan 2017 09:08:28 -0000 A new meeting session request has just been submitted by Thomas Morin, a Chair of the bess working group. --------------------------------------------------------- Working Group Name: BGP Enabled ServiceS Area Name: Routing Area Session Requester: Thomas Morin Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgwg spring idr sfc sidr l2sm Second Priority: mpls pim nvo3 bier pals Third Priority: i2rs Special Requests: --------------------------------------------------------- From nobody Tue Jan 31 02:31:25 2017 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 47D081293EC for ; Tue, 31 Jan 2017 02:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.733 X-Spam-Level: X-Spam-Status: No, score=-6.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 vZwHQR_FLW2C for ; Tue, 31 Jan 2017 02:31:23 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C67D2128BA2 for ; Tue, 31 Jan 2017 02:31:22 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0AEEE5D8ADE for ; Tue, 31 Jan 2017 11:31:22 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 03D065D8A9B for ; Tue, 31 Jan 2017 11:31:22 +0100 (CET) Received: from [10.193.71.154] (10.193.71.154) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 11:31:20 +0100 References: <148585853165.2468.18443133207648603240.idtracker@ietfa.amsl.com> To: BESS From: Thomas Morin Organization: Orange X-Forwarded-Message-Id: <148585853165.2468.18443133207648603240.idtracker@ietfa.amsl.com> Message-ID: <41a557e6-ec60-ec87-aad9-64ad5c25866b@orange.com> Date: Tue, 31 Jan 2017 11:31:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148585853165.2468.18443133207648603240.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------76C333D41B4AF6081F04B5D3" Archived-At: Subject: [bess] Fwd: Tags changed for draft-ietf-bess-virtual-subnet-fib-reduction 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, 31 Jan 2017 10:31:24 -0000 --------------76C333D41B4AF6081F04B5D3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit FYI -Thomas --------------76C333D41B4AF6081F04B5D3 Content-Type: message/rfc822; name="Tags changed for draft-ietf-bess-virtual-subnet-fib-reduction" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Tags changed for draft-ietf-bess-virtual-subnet-fib-reductio"; filename*1="n" Received: from opfedar03.francetelecom.fr (10.117.25.5) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 11:28:53 +0100 Received: from opfedar27.francetelecom.fr (unknown [10.107.176.17]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id A9750180065 for ; Tue, 31 Jan 2017 11:28:53 +0100 (CET) Received: from opfedar27.francetelecom.fr (localhost [127.0.0.1]) by opfedar27.francetelecom.fr (ESMTP service) with SMTP id 9DBA260275 for ; Tue, 31 Jan 2017 11:28:53 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by relais-inet.orange.com (ESMTP service) with ESMTPS id 426E960170 for ; Tue, 31 Jan 2017 11:28:53 +0100 (CET) Received: by ietfa.amsl.com (Postfix, from userid 65534) id D5225129954; Tue, 31 Jan 2017 02:28:51 -0800 (PST) X-Original-To: bess-chairs@ietf.org Delivered-To: xfilter-bess-chairs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A03B5129443; Tue, 31 Jan 2017 02:28:51 -0800 (PST) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: Tags changed for draft-ietf-bess-virtual-subnet-fib-reduction X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148585853165.2468.18443133207648603240.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 02:28:51 -0800 Resent-From: Resent-To: , Resent-Message-ID: <20170131102851.D5225129954@ietfa.amsl.com> Resent-Date: Tue, 31 Jan 2017 02:28:51 -0800 X-Header: INET-IN Return-Path: ietf-secretariat-reply@ietf.org X-MS-Exchange-Organization-AuthSource: OPEXCLILM5D.corporate.adroot.infra.ftgroup X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: Sophos;-1070819838;0;PM MIME-Version: 1.0 The tags on draft-ietf-bess-virtual-subnet-fib-reduction have been changed by Thomas Morin: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet-fib-reduction/ Tag "Other - see Comment Log" added. Comment: One vendor has provided information on intent to implement. Pending at least an actual implementation this draft is kept on hold. --------------76C333D41B4AF6081F04B5D3-- From nobody Tue Jan 31 02:41:14 2017 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 7326C1279EB for ; Tue, 31 Jan 2017 02:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 cMzXB8_gay4x for ; Tue, 31 Jan 2017 02:41:12 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id DE0E21293EC for ; Tue, 31 Jan 2017 02:41:11 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4A3F1DE4001 for ; Tue, 31 Jan 2017 11:41:11 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 4233FA442C8 for ; Tue, 31 Jan 2017 11:41:11 +0100 (CET) Received: from [10.193.71.154] (10.193.71.154) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 11:41:09 +0100 References: <95C76D43-F286-45CA-BEC5-2F4BDE94A8D0@on.nokia.com> To: BESS From: Thomas Morin Organization: Orange X-Forwarded-Message-Id: <95C76D43-F286-45CA-BEC5-2F4BDE94A8D0@on.nokia.com> Message-ID: <53740749-45e3-63ff-a9ea-c5c7ce2512e1@orange.com> Date: Tue, 31 Jan 2017 11:41:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <95C76D43-F286-45CA-BEC5-2F4BDE94A8D0@on.nokia.com> Content-Type: multipart/mixed; boundary="------------CA3142F780B24AF4C8A3CBBF" Archived-At: Subject: [bess] Fwd: Early allocation for EVPN route type 5 - draft-ietf-bess-evpn-prefix-advertisement 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, 31 Jan 2017 10:41:13 -0000 --------------CA3142F780B24AF4C8A3CBBF Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit --------------CA3142F780B24AF4C8A3CBBF Content-Type: message/rfc822; name="Early allocation for EVPN route type 5 - draft-ietf-bess-evpn-prefix-advertisement" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="Early allocation for EVPN route type 5 - draft-ietf-bess-evp"; filename*1="n-prefix-advertisement" Received: from opfednr00.francetelecom.fr (10.117.32.64) by OPEXCLILM34.corporate.adroot.infra.ftgroup (10.114.31.18) with Microsoft SMTP Server id 14.3.319.2; Fri, 20 Jan 2017 19:56:26 +0100 Received: from opfednr26.francetelecom.fr (unknown [10.106.128.86]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 744061A006D for ; Fri, 20 Jan 2017 19:56:26 +0100 (CET) Received: from opfednr26.francetelecom.fr (localhost [127.0.0.1]) by opfednr26.francetelecom.fr (ESMTP service) with SMTP id 668CD209FE for ; Fri, 20 Jan 2017 19:56:26 +0100 (CET) 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 relais-inet.orange.com (ESMTP service) with ESMTPS id DB1C9209FA for ; Fri, 20 Jan 2017 19:56:25 +0100 (CET) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 77AE338B0CF16; Fri, 20 Jan 2017 18:56:21 +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 v0KIuOgB005043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2017 18:56:25 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v0KIuLiX016348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jan 2017 18:56:22 GMT Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.179]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Fri, 20 Jan 2017 19:56:21 +0100 From: "Rabadan, Jorge (Nokia - US)" To: MORIN Thomas IMT/OLN , "Vigoureux, Martin (Nokia - FR)" CC: John E Drake , "Ali Sajassi (sajassi)" , "draft-ietf-bess-evpn-prefix-advertisement@ietf.org" , Eric C Rosen Subject: Early allocation for EVPN route type 5 - draft-ietf-bess-evpn-prefix-advertisement Thread-Topic: Early allocation for EVPN route type 5 - draft-ietf-bess-evpn-prefix-advertisement Thread-Index: AQHSc07jcv51fc/js0S2bCkEPpXdbQ== Date: Fri, 20 Jan 2017 19:56:20 +0100 Message-ID: <95C76D43-F286-45CA-BEC5-2F4BDE94A8D0@on.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: OPEXCLILM34.corporate.adroot.infra.ftgroup X-MS-Has-Attach: X-Message-Flag: FollowUp X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik5va2lhIFB1cmUgVGV4dCI7DQoJcGFub3NlLTE6MiAxMSA1IDQgNCA2IDIgNiAzIDM7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luLXRvcDo2LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiTm9raWEgUHVyZSBUZXh0Ijt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj MDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpBcmlhbDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiTm9raWEgUHVyZSBUZXh0Ijt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTpBcmlhbCI+RGVhciBjaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWwiPkFzIHBlciBSRkM3MTIwLCBhbmQgb24gYmVoYWxmIG9mIG15IGNvLWF1dGhvcnMgdG9v LCBJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhbiBJQU5BIGVhcmx5IGFsbG9jYXRpb24gZm9yIGFu IEVWUE4gcm91dGUgdHlwZSwgaW4gcGFydGljdWxhciB2YWx1ZSA1LCBhcyBkZWZpbmVkIGluIGRy YWZ0LWlldGYtYmVzcy1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsIj5WYWx1ZSA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWwiPkRlc2NyaXB0aW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ UCBQcmVmaXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCI+UmVmZXJlbmNlOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLWJlc3Mt ZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCI+VGhhbmsgeW91 ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5Kb3JnZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --------------CA3142F780B24AF4C8A3CBBF-- From nobody Tue Jan 31 02:41:32 2017 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 936E01279EB for ; Tue, 31 Jan 2017 02:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.732 X-Spam-Level: X-Spam-Status: No, score=-6.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 D96ainmv9X_G for ; Tue, 31 Jan 2017 02:41:28 -0800 (PST) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 233F11293EC for ; Tue, 31 Jan 2017 02:41:27 -0800 (PST) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8C2E75D8ADE for ; Tue, 31 Jan 2017 11:41:26 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 7E8E65D8A9B for ; Tue, 31 Jan 2017 11:41:26 +0100 (CET) Received: from [10.193.71.154] (10.193.71.154) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 11:41:24 +0100 References: To: BESS From: Thomas Morin Organization: Orange X-Forwarded-Message-Id: Message-ID: Date: Tue, 31 Jan 2017 11:41:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------89B78399C41024C491BC56D3" Archived-At: Subject: [bess] Fwd: Re: Request for Assignment of EVPN Route Types 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, 31 Jan 2017 10:41:30 -0000 --------------89B78399C41024C491BC56D3 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit --------------89B78399C41024C491BC56D3 Content-Type: message/rfc822; name="Re: Request for Assignment of EVPN Route Types" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: Request for Assignment of EVPN Route Types" Received: from opfedar03.francetelecom.fr (10.117.25.5) by OPEXCLILM7C.corporate.adroot.infra.ftgroup (10.114.31.27) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 01:26:04 +0100 Received: from opfedar24.francetelecom.fr (unknown [10.107.176.14]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 033D0180067 for ; Tue, 31 Jan 2017 01:26:04 +0100 (CET) Received: from opfedar24.francetelecom.fr (localhost [127.0.0.1]) by opfedar24.francetelecom.fr (ESMTP service) with SMTP id EB433C09C5 for ; Tue, 31 Jan 2017 01:26:03 +0100 (CET) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0119.outbound.protection.outlook.com [104.47.41.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by relais-inet.orange.com (ESMTP service) with ESMTPS id C26EDC09C3 for ; Tue, 31 Jan 2017 01:26:02 +0100 (CET) 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=4ZerxJqrrHMiTyPWRUI5U2iiKYLWRUmxosovFOernGM=; b=WKYRHB7/A/mWRz1z/NHkrxgetqtAyhKOT6Jd/xmsKjNyzmnJ1qWN9QNByT/u1SlxwoyjGYXZeeK/dsx5xFFDiNOobLs7kEyKFsoNTqwhYQeUdeWny4ueqJUcBUlCD8auMg7BrLtY++bySa3J74xXZRn3zIiEeVG/uUcs7arnuXY= Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 31 Jan 2017 00:26:01 +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.0888.015; Tue, 31 Jan 2017 00:26:01 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "EXT - thomas.morin@orange.com" , "Martin Vigoureux" CC: "Rabadan, Jorge (Nokia - US)" Subject: RE: Request for Assignment of EVPN Route Types Thread-Topic: Request for Assignment of EVPN Route Types Thread-Index: AQHSc1ApvZ1IHFmrIkCOtSkM5LwPy6FRyE9g Date: Tue, 31 Jan 2017 00:26:00 +0000 Message-ID: References: <4E037C45-936E-4397-8C9C-23C505815DCA@on.nokia.com> In-Reply-To: <4E037C45-936E-4397-8C9C-23C505815DCA@on.nokia.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.11] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-office365-filtering-correlation-id: 2e717745-5239-4ca1-1806-08d4496fbbfe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB3145; x-microsoft-exchange-diagnostics: 1;DM5PR05MB3145;7:nkbWcDgp3IpSuzdc9psEXuu6g7r+i6B5/omb539uaEye/s5ONcZ14y9X/N/5FMihDWBCr5nWuGTNjL3bZ+KoAXBQhiQXBcIovlkAOpCuzx6gW3Fogsm1sBC2viwQ6/3noWoRQzlNSLaAa6DLZ/ZjxPXoFkiAAzPXZj10Eh/A/dQi5XMfOwF27bRMyo05D91+JKVwe60SgZdxlvrqWj48qimWWXdWuhJj5y619ZC1lN7vcPD38R0mJyJiES56c32SCaoKQLzQbiRAMo5iQr8G0mjYM02zNdm/PnuU1YDKmjhkGbLoJgCy1SAIhr2zFj1BroVoxegLAMba1wwvVXZb1N9Qu0Jx3jUnoWdDSyYh7AuW1Md1IQ1lkAgahXjQ3FkRTqzFB4F//RLOxElFXb7nJbu0+3N1t4vJRY1TMMOR53YjD9/RTqxtrI21DqscQsSifnXtu2tvtFNQVOeDoxWwIw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(18271650672692)(21748063052155)(1591387915157)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148);SRVR:DM5PR05MB3145;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB3145; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(7916002)(39840400002)(39450400003)(39860400002)(39850400002)(39410400002)(51914003)(377454003)(50944005)(189002)(199003)(252514010)(24454002)(377424004)(76176999)(33656002)(8936002)(2950100002)(7696004)(3660700001)(8676002)(81166006)(105586002)(122556002)(5660300001)(50986999)(6506006)(54356999)(229853002)(25786008)(38730400001)(6436002)(77096006)(106356001)(101416001)(606005)(55016002)(106116001)(99286003)(81156014)(2900100001)(966004)(92566002)(236005)(6306002)(53946003)(54896002)(2906002)(66066001)(9686003)(53936002)(4326007)(3280700002)(102836003)(3846002)(575784001)(5001770100001)(97736004)(6116002)(7736002)(189998001)(7906003)(68736007)(86362001)(74316002)(790700001)(579004)(559001);DIR:OUT;SFP:1102;SCL:1;SRVR:DM5PR05MB3145;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: multipart/alternative; boundary="_000_DM5PR05MB3145B00F703FD81DFCA6DE6BD44A0DM5PR05MB3145namp_" X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 00:26:00.8750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3145 X-Header: INET-IN X-PerlMx-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' HTML_90_100 0.1, HTML_95_100 0.1, HTML_98_100 0.1, HTML_99_100 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_3000_MORE 0, BODY_SIZE_10000_PLUS 0, DKIM_SIGNATURE 0, FROM_NAME_PHRASE 0, HTML_TAG_NAME_RND_CAP 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, SPF_PASS 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FRAUD_CONTACT_NAME 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_XOIP 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __RDNS_OUTLOOK 0, __REFERENCES 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NS , __URI_WITH_PATH 0' Return-Path: zzhang@juniper.net X-MS-Exchange-Organization-AuthSource: OPEXCLILM7C.corporate.adroot.infra.ftgroup X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: Sophos;-1070843902;0;PM MIME-Version: 1.0 --_000_DM5PR05MB3145B00F703FD81DFCA6DE6BD44A0DM5PR05MB3145namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzLCBNYXJ0aW4sDQoNCkFsaeKAmXMgcmVxdWVzdCB0byBJQU5BIGFsc28gaW5jbHVk ZWQgdGhyZWUgcm91dGUgdHlwZXMgZGVmaW5lZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tYnVtLXByb2NlZHVyZS11cGRhdGVzLTAxOg0KDQogICAg ICAgICArIDkgIC0gUGVyLVJlZ2lvbiBJLVBNU0kgQS1EIHJvdXRlDQogICAgICAgICArIDEwIC0g Uy1QTVNJIEEtRCByb3V0ZQ0KICAgICAgICAgKyAxMSAtIExlYWYgQS1EIHJvdXRlDQoNClRoaXMg aXMgaW4gY29sbGFib3JhdGlvbiB3aXRoIGF1dGhvcnMgb2Ygb3RoZXIgRVZQTiBkcmFmdHMgdGhh dCBpbnZvbHZlIEVWUE4gcm91dGUgdHlwZXMuIFdlIGJlbGlldmUgaXQgc2F0aXNmaWVzIHRoZSBm b2xsb3dpbmcgcmVxdWlyZW1lbnQ6DQoNCg0KICAgYy4gIFRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0 aGVzZSBjb2RlIHBvaW50cyBtdXN0IGJlIHN0YWJsZTsgaS5lLiwgaWYNCg0KICAgICAgIHRoZXJl IGlzIGEgY2hhbmdlLCBpbXBsZW1lbnRhdGlvbnMgYmFzZWQgb24gdGhlIGVhcmxpZXIgYW5kIGxh dGVyDQoNCiAgICAgICBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHNlYW1sZXNzbHkgaW50ZXJvcGVy YWJsZS4NCg0KV2Ugd291bGQgbGlrZSB0byBwcm9jZWVkIHdpdGggYW4gZWFybHkgYWxsb2NhdGlv biByZXF1ZXN0Lg0KDQpUaGFua3MuDQpKZWZmcmV5DQoNCg0KT24gMS8xOC8xNywgNjoyNyBBTSwg IlRob21hcyBNb3JpbiIgPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9y aW5Ab3JhbmdlLmNvbT4+IHdyb3RlOg0KDQpIaSBKb2huLA0KDQpUaGFua3MgZm9yIHRoZSBleHRy YSBpbmZvcm1hdGlvbi4NCg0KSnVzdCB0byBtYWtlIHN1cmU6IGRvIHdlIGhhdmUgYSBjb21tb24g dW5kZXJzdGFuZGluZyB0aGF0IHdlIG5lZWQgdG8gZm9sbG93IFJGQzcxMjAgZm9yIEVWUE4gcm91 dGUgdHlwZXMgKHNlY3Rpb24gMy4xKSA/DQoNCkFzc3VtaW5nIHNvLCB0aGUgZmlyc3Qgc3RlcCBm b3IgYXNraW5nIGZvciBlYXJseSBhbGxvY2F0aW9uIHdvdWxkIGJlIChzZXBhcmF0ZWx5IGZvciBl YWNoIG9mIHRoZXNlIGRyYWZ0cykgYW4gZW1haWwgZnJvbSBhbiBhdXRob3IvZWRpdG9yIHRvIHVz IGNoYWlycyBhc2tpbmcgZm9yIHRoZSBlYXJseSBhbGxvY2F0aW9uIChzZWUgaXRlbSAxIGluIHNl Y3Rpb24gMy4xIG9mIFJGQzcxMjApLCBhbmQgcHJvdmlkaW5nIHJhdGlvbmFsZSB0aGF0IGl0ZW1z IChjKSBvZiBzZWN0aW9uIDIgYXJlIG1ldCAod2hhdCB5b3UganVzdCBkaWQgZm9yIHR5cGUgNSBp cyB0aGUgaW5mbyB3ZSBuZWVkKS4gIFRoZSBhbnN3ZXIgYnkgY2hhaXJzIG9yIEFEcyBmb3IgZWFj aCBvZiB0aGUgdGhyZWUgZHJhZnRzIG1heSBlbmQgdXAgYmVpbmcgZGlmZmVyZW50IDsgaSBwYXJ0 aWN1bGFyIGJlY2F1c2UgdGhleSBhcmUgbm90IGF0IHRoZSBzYW1lIHN0YWdlIGluIHRoZSBwcm9j ZXNzIChlLmcuIGRyYWZ0LXNhamFzc2ktYmVzcy1ldnBuLWlnbXAtbWxkLXByb3h5IGlzIG5vdCBl dmVuIHlldCBhIFdHIGRvY3VtZW50KS4NCg0KVGhhbmtzLA0KDQotVGhvbWFzDQoNCjIwMTctMDEt MTgsIEpvaG4gRSBEcmFrZToNClRob21hcywNCg0KVGhlIGVtYWlsIGZyb20gQWxpIHRvIElBTkEg aXMgYmVsb3cgKEkgdW5kZXJzdGFuZCB0aGF0IGhlIHN1YnNlcXVlbnRseSBhbWVuZGVkIGl0IHRv IGluY2x1ZGUgUlQtNSkuICBSb3V0ZSB0eXBlcyA2LCA3LCBhbmQgOCBhcmUgZGVmaW5lZCBpbjog IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21w LW1sZC1wcm94eS0wMS4NCg0KQ2lzY28sIEp1bmlwZXIsIGFuZCBOb2tpYSBoYXZlIGhhZCBpbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgUlQtNSBkcmFmdCBmb3Igc2V2ZXJhbCB5 ZWFycywgYW5kIGFsbCB0aHJlZSBhcmUgY3VycmVudGx5IHdvcmtpbmcgb24gaW1wbGVtZW50YXRp b25zIG9mIHRoZSBJR01QIFByb3h5IGRyYWZ0IG1lbnRpb25lZCBhYm92ZS4NCg0KWW91cnMgSXJy ZXNwZWN0aXZlbHksDQoNCkpvaG4NCg0KRnJvbTogQWxpIFNhamFzc2kgKHNhamFzc2kpIFttYWls dG86c2FqYXNzaUBjaXNjby5jb21dDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDksIDIwMTYg MjowNCBQTQ0KVG86IGlhbmEtcXVlc3Rpb25zQGlhbmEub3JnPG1haWx0bzppYW5hLXF1ZXN0aW9u c0BpYW5hLm9yZz4NCkNjOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD48bWFpbHRv OmpkcmFrZUBqdW5pcGVyLm5ldD47IEFsaSBTYWphc3NpIChzYWphc3NpKSA8c2FqYXNzaUBjaXNj by5jb20+PG1haWx0bzpzYWphc3NpQGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlcXVlc3QgZm9yIEFz c2lnbm1lbnQgb2YgRVZQTiBSb3V0ZSBUeXBlcw0KDQoNCg0KQ29udGFjdCBOYW1lOg0KQWxpIFNh amFzc2kNCg0KQ29udGFjdCBFbWFpbDoNClNhamFzc2lAY2lzY28uY29tPG1haWx0bzpTYWphc3Np QGNpc2NvLmNvbT4NCg0KVHlwZSBvZiBBc3NpZ25tZW50Og0KRVZQTiBSb3V0ZSBUeXBlcw0KDQpS ZWdpc3RyeToNCkVWUE4gUm91dGUgVHlwZXMNCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVu dHMvZXZwbi9ldnBuLnhodG1sI3JvdXRlLXR5cGVzDQoNCjB4MDYgLSBTZWxlY3RpdmUgTXVsdGlj YXN0IEV0aGVybmV0IFRhZyBSb3V0ZQ0KMHgwNyAtIElHTVAgSm9pbiBTeW5jaCBSb3V0ZQ0KMHgw OCAtIElHTVAgTGVhdmUgU3luY2ggUm91dGUNCjB4MDkgLSBQZXItUmVnaW9uIEktUE1TSSBBLUQg cm91dGUNCjB4MEEgLSBTLVBNU0kgQS1EIHJvdXRlDQowWDBCIC0gTGVhZiBBLUQgcm91dGUNCg0K RGVzY3JpcHRpb246DQpUaGVzZSBFVlBOIHJvdXRlIHR5cGVzIGFyZSBkZWZpbmVkIGluIHRoZSBm b2xsb3dpbmcgRVZQTiBkcmFmdHMgYW5kIHNvbWUgb2YgdGhlc2UgZHJhZnRzIGFyZSBiZWluZyBp bXBsZW1lbnRlZCBhbmQgdGh1cyB0aGUgaW1tZWRpYXRlIG5lZWQgZm9yIGFsbG9jYXRpb24gb2Yg dGhlc2UgY29kZSBwb2ludHMgZm9yIHRoZSBwdXJwb3NlIG9mIGludGVyb3BlcmFiaWxpdHk6DQoN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21w LW1sZC1wcm94eS0wMQ0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1iZXNzLWV2 cG4tYnVtLXByb2NlZHVyZS11cGRhdGVzLTAwLnR4dA0KDQoNCkFkZGl0aW9uYWwgSW5mbzoNClBs ZWFzZSByZWZlciB0byB0aGUgYWJvdmUgZHJhZnRzLg0KDQoNClJlZ2FyZHMsDQpBbGkNCg0KDQoN Cg== --_000_DM5PR05MB3145B00F703FD81DFCA6DE6BD44A0DM5PR05MB3145namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNv bnRlbnQ9IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxNSI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iY2lkOmZpbGVsaXN0 LnhtbEAwMUQyN0IyRS5BRjkwQTUxMCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpPZmZp Y2VEb2N1bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPC9vOk9mZmljZURvY3VtZW50U2V0 dGluZ3M+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3Oldv cmREb2N1bWVudD4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3 OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3 OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpT YXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1p eGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlz U2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3Ro ZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlk VGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVD b21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1 cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJr Lz4NCjx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjx3OkJy b3dzZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQo8 bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4g bTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxs RnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4N CjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0K PG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4N CjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50 Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRT dHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIERl ZlNlbWlIaWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5IiBM YXRlbnRTdHlsZUNvdW50PSIzNzEiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJpbmRleCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i aW5kZXggNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9ImluZGV4IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJOb3JtYWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3Rl IHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0idGFibGUgb2YgZmlndXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBhZGRy ZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5u b3RhdGlvbiByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i ZW5kbm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Im1hY3JvIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxs ZXQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBCdWxsZXQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBOdW1iZXIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz dCBOdW1iZXIgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx MCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQ2xv c2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iQm9keSBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRl bnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJMaXN0IENvbnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250 aW51ZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVz c2FnZSBIZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlNhbHV0YXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJv ZHkgVGV4dCBGaXJzdCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhlYWRp bmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iQm9keSBUZXh0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJCbG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVybGlu ayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i U3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEb2N1 bWVudCBNYXAiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg VG9wIG9mIEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9ybSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iSFRNTCBBY3JvbnltIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN TCBDb2RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg UHJlZm9ybWF0dGVkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJI VE1MIFZhcmlhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iTm8gTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJP dXRsaW5lIExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBTaW1wbGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIENsYXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFz c2ljIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIENvbG9yZnVsIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBDb2x1bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1u cyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3Jp ZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBHcmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBHcmlkIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBMaXN0IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSAzRCBlZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29u dGVtcG9yYXJ5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFN1YnRsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIFdlYiAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBUaGVtZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2lu ZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0i TGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRp bmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFt ZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVt IEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg TmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdo dCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgTmFtZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMzQiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz MCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg TmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBM aXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdo dCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAy IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0g R3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNv bG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5h bWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQi IE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1 bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9 Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIg TmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFt ZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQg MiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBT aGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlz dCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAi IE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5h bWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBB Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIg TmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3Jm dWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIxOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJJbnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjMxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJs ZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBOYW1l PSJQbGFpbiBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQzIiBOYW1lPSJQbGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRh YmxlIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2 IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxl IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 IkdyaWQgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1 bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0i R3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUg MyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3Jp ZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikdy aWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDki IE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlk IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBO YW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRh YmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBU YWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt ZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi bGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 IkdyaWQgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUg NiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxl IDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH cmlkIFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYg Q29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAx IExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlz dCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIg TmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUg NCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIg TmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5h bWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAi IE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5h bWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1l PSJMaXN0IFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO YW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1l PSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt ZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i TGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxp c3QgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0 IFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJM aXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0 IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48 IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tZm9udC1jaGFy c2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6 dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTEwNzMwNTcyNyAwIDAg NDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWFsdDpTaW1TdW47DQoJbXNvLWZvbnQtY2hh cnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBp dGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDEzNTEzNTIzMiAxNiAwIDI2MjE0NCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1hbHQ6QXJpYWw7DQoJbXNvLWZvbnQtY2hhcnNldDow Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlh YmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU5OTA1IC0xMDczNzMyNDg1IDkgMCA1MTEg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxOw0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmlj LWZvbnQtZmFtaWx5Om1vZGVybjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9udC1z aWduYXR1cmU6MSAxMzUxMzUyMzIgMTYgMCAyNjIxNDQgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5 bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50 OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0 aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpz aW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcA0K CXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3Jw aGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47fQ0KcHJlDQoJe21zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCXRhYi1zdG9wczo0NS44 cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0 IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQg NzMyLjhwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcC5tc29ub3Jt YWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29u b3JtYWw7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJbXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCglmb250LWZh bWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkFyaWFsOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlh bDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpEZW5nWGlhbjsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6 eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1z by1zdHlsZS1sb2NrZWQ6eWVzOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LXNp emU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47 DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsNCgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyAxMF0+PHN0eWxlPi8qIFN0eWxlIERlZmluaXRpb25zICovDQp0YWJsZS5Nc29Ob3JtYWxU YWJsZQ0KCXttc28tc3R5bGUtbmFtZToiVGFibGUgTm9ybWFsIjsNCgltc28tdHN0eWxlLXJvd2Jh bmQtc2l6ZTowOw0KCW1zby10c3R5bGUtY29sYmFuZC1zaXplOjA7DQoJbXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJ bXNvLXBhZGRpbmctYWx0OjBpbiA1LjRwdCAwaW4gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2luOjBp bjsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lk b3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0idGFiLWludGVy dmFsOi41aW4iPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgVGhvbWFzLCBNYXJ0aW4sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRp LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFsaeKAmXMgcmVxdWVzdCB0byBJQU5BIGFsc28gaW5jbHVkZWQgdGhy ZWUgcm91dGUgdHlwZXMgZGVmaW5lZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWJ1bS1wcm9jZWR1cmUtdXBkYXRlcy0wMSI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tYnVtLXByb2Nl ZHVyZS11cGRhdGVzLTAxPC9hPjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIy OS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5 LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQg MzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2 NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj4mIzQzOyA5PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZu YnNwOyA8L3NwYW4+LSBQZXItUmVnaW9uIEktUE1TSSBBLUQgcm91dGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42 cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJw dCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPiYjNDM7 IDEwIC0gUy1QTVNJIEEtRCByb3V0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+JiM0MzsgMTEgLSBMZWFmIEEtRCByb3V0 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWIt c3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42 cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQxLjJw dCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5 MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEy LjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIu OHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1j b2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+VGhpcyBp cyBpbiBjb2xsYWJvcmF0aW9uIHdpdGggYXV0aG9ycyBvZiBvdGhlciBFVlBOIGRyYWZ0cyB0aGF0 DQogaW52b2x2ZSBFVlBOIHJvdXRlIHR5cGVzLiBXZSBiZWxpZXZlIGl0IHNhdGlzZmllcyB0aGUg Zm9sbG93aW5nIHJlcXVpcmVtZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjojMUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1 bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+Yy48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnll cyI+Jm5ic3A7IDwvc3Bhbj5UaGUgc3BlY2lmaWNhdGlvbnMgb2YgdGhlc2UgY29kZSBwb2ludHMg bXVzdCBiZSBzdGFibGU7IGkuZS4sIGlmPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+dGhlcmUgaXMgYSBjaGFu Z2UsIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiB0aGUgZWFybGllciBhbmQgbGF0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5zcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHNlYW1sZXNzbHkgaW50ZXJvcGVyYWJs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQgMjI5LjBwdCAyNzQuOHB0IDMy MC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1NDkuNnB0IDU5NS40cHQgNjQx LjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0RTc5O21zby1zdHls ZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxw aGE6MTAwLjAlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4w cHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0NTguMHB0IDUwMy44cHQgNTQ5LjZw dCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFG NEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0 ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+V2Ugd291bGQgbGlrZSB0byBwcm9jZWVkIHdpdGggYW4g ZWFybHkgYWxsb2NhdGlvbiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4y cHQgMjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhw dCA1NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztj b2xvcjojMUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMxRjRFNzk7bXNvLXN0 eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42cHQg MTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJwdCA0 NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDs7Y29sb3I6IzFGNEU3OTttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjoj MUY0RTc5O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+VGhhbmtzLjxicj4N CkplZmZyZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24g MS8xOC8xNywgNjoyNyBBTSwgJnF1b3Q7VGhvbWFzIE1vcmluJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5IaSBKb2huLDxicj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIGV4dHJhIGluZm9y bWF0aW9uLjxicj4NCjxicj4NCkp1c3QgdG8gbWFrZSBzdXJlOiBkbyB3ZSBoYXZlIGEgY29tbW9u IHVuZGVyc3RhbmRpbmcgdGhhdCB3ZSBuZWVkIHRvIGZvbGxvdyBSRkM3MTIwIGZvciBFVlBOIHJv dXRlIHR5cGVzIChzZWN0aW9uIDMuMSkgPzxicj4NCjxicj4NCkFzc3VtaW5nIHNvLCB0aGUgZmly c3Qgc3RlcCBmb3IgYXNraW5nIGZvciBlYXJseSBhbGxvY2F0aW9uIHdvdWxkIGJlIChzZXBhcmF0 ZWx5IGZvciBlYWNoIG9mIHRoZXNlIGRyYWZ0cykgYW4gZW1haWwgZnJvbSBhbiBhdXRob3IvZWRp dG9yIHRvIHVzIGNoYWlycyBhc2tpbmcgZm9yIHRoZSBlYXJseSBhbGxvY2F0aW9uIChzZWUgaXRl bSAxIGluIHNlY3Rpb24gMy4xIG9mIFJGQzcxMjApLCBhbmQgcHJvdmlkaW5nIHJhdGlvbmFsZSB0 aGF0IGl0ZW1zDQogKGMpIG9mIHNlY3Rpb24gMiBhcmUgbWV0ICh3aGF0IHlvdSBqdXN0IGRpZCBm b3IgdHlwZSA1IGlzIHRoZSBpbmZvIHdlIG5lZWQpLiZuYnNwOyBUaGUgYW5zd2VyIGJ5IGNoYWly cyBvciBBRHMgZm9yIGVhY2ggb2YgdGhlIHRocmVlIGRyYWZ0cyBtYXkgZW5kIHVwIGJlaW5nIGRp ZmZlcmVudCA7IGkgcGFydGljdWxhciBiZWNhdXNlIHRoZXkgYXJlIG5vdCBhdCB0aGUgc2FtZSBz dGFnZSBpbiB0aGUgcHJvY2VzcyAoZS5nLiBkcmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21wLW1s ZC1wcm94eQ0KIGlzIG5vdCBldmVuIHlldCBhIFdHIGRvY3VtZW50KS48YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KPGJyPg0KLVRob21hczxicj4NCjxicj4NCjIwMTctMDEtMTgsIEpvaG4gRSBEcmFr ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRob21hcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGVtYWlsIGZyb20gQWxpIHRv IElBTkEgaXMgYmVsb3cgKEkgdW5kZXJzdGFuZCB0aGF0IGhlIHN1YnNlcXVlbnRseSBhbWVuZGVk IGl0IHRvIGluY2x1ZGUgUlQtNSkuJm5ic3A7IFJvdXRlIHR5cGVzIDYsIDcsIGFuZCA4IGFyZSBk ZWZpbmVkDQogaW46ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21wLW1sZC1wcm94eS0wMSI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktYmVzcy1ldnBuLWlnbXAtbWxkLXByb3h5LTAxPC9h Pi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2lzY28sIEp1bmlwZXIsIGFu ZCBOb2tpYSBoYXZlIGhhZCBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgUlQt NSBkcmFmdCBmb3Igc2V2ZXJhbCB5ZWFycywgYW5kIGFsbCB0aHJlZSBhcmUgY3VycmVudGx5IHdv cmtpbmcNCiBvbiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIElHTVAgUHJveHkgZHJhZnQgbWVudGlv bmVkIGFib3ZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WW91 cnMgSXJyZXNwZWN0aXZlbHksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpv aG48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO21zby1vdXRs aW5lLWxldmVsOjEiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEFsaSBTYWphc3NpIChzYWphc3NpKSBbPGEgaHJlZj0ibWFpbHRvOnNhamFzc2lA Y2lzY28uY29tIj5tYWlsdG86c2FqYXNzaUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgOSwgMjAxNiAyOjA0IFBNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86aWFuYS1xdWVzdGlvbnNAaWFuYS5vcmciPmlhbmEtcXVlc3Rpb25zQGlh bmEub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gSm9obiBFIERyYWtlIDxhIGhyZWY9Im1haWx0bzpq ZHJha2VAanVuaXBlci5uZXQiPiZsdDtqZHJha2VAanVuaXBlci5uZXQmZ3Q7PC9hPjsgQWxpIFNh amFzc2kgKHNhamFzc2kpDQo8YSBocmVmPSJtYWlsdG86c2FqYXNzaUBjaXNjby5jb20iPiZsdDtz YWphc3NpQGNpc2NvLmNvbSZndDs8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlcXVlc3QgZm9y IEFzc2lnbm1lbnQgb2YgRVZQTiBSb3V0ZSBUeXBlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+Q29udGFjdCBOYW1lOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+QWxpIFNhamFzc2k8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Q29udGFjdCBFbWFpbDo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzpTYWphc3NpQGNpc2NvLmNvbSI+U2FqYXNzaUBjaXNjby5jb208L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPlR5cGUgb2YgQXNzaWdubWVudDo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPkVWUE4gUm91dGUgVHlwZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ UmVnaXN0cnk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj5FVlBOIFJvdXRlIFR5cGVzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL2V2cG4vZXZwbi54aHRtbCNyb3V0ZS10eXBlcyI+aHR0cDovL3d3dy5pYW5hLm9yZy9hc3Np Z25tZW50cy9ldnBuL2V2cG4ueGh0bWwjcm91dGUtdHlwZXM8L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPjB4MDYgLSBTZWxlY3RpdmUgTXVsdGljYXN0IEV0aGVybmV0IFRhZyBS b3V0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+MHgwNyAtIElHTVAgSm9pbiBTeW5jaCBSb3V0ZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+MHgwOCAtIElHTVAgTGVhdmUgU3luY2ggUm91dGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjB4MDkgLSZuYnNw O1Blci1SZWdpb24gSS1QTVNJIEEtRCByb3V0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+MHgwQSAtIFMtUE1TSSBB LUQgcm91dGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPjBYMEIgLSBMZWFmIEEtRCByb3V0ZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkRlc2NyaXB0aW9uOiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayI+VGhlc2UgRVZQTiByb3V0ZSB0eXBlcyBhcmUgZGVmaW5lZCBpbiB0aGUgZm9sbG93 aW5nIEVWUE4gZHJhZnRzIGFuZCBzb21lIG9mIHRoZXNlIGRyYWZ0cyBhcmUgYmVpbmcgaW1wbGVt ZW50ZWQgYW5kIHRodXMgdGhlIGltbWVkaWF0ZSBuZWVkIGZvciBhbGxvY2F0aW9uIG9mIHRoZXNl IGNvZGUNCiBwb2ludHMgZm9yIHRoZSBwdXJwb3NlIG9mIGludGVyb3BlcmFiaWxpdHk6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zYWphc3NpLWJlc3MtZXZwbi1pZ21wLW1sZC1wcm94eS0wMSI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktYmVzcy1ldnBuLWlnbXAtbWxkLXByb3h5LTAxPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWJ1bS1w cm9jZWR1cmUtdXBkYXRlcy0wMC50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWll dGYtYmVzcy1ldnBuLWJ1bS1wcm9jZWR1cmUtdXBkYXRlcy0wMC50eHQ8L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+QWRkaXRpb25hbCBJbmZv Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjayI+UGxlYXNlIHJlZmVyIHRvIHRoZSBhYm92ZSBkcmFmdHMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPkFsaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR05MB3145B00F703FD81DFCA6DE6BD44A0DM5PR05MB3145namp_-- --------------89B78399C41024C491BC56D3-- From nobody Tue Jan 31 02:56:09 2017 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 3D5E712940E for ; Tue, 31 Jan 2017 02:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 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=-1.156, 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=nokia.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 XKIEbAeJCC0Y for ; Tue, 31 Jan 2017 02:56:06 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0117.outbound.protection.outlook.com [104.47.0.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773D61293EC for ; Tue, 31 Jan 2017 02:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uRQqa1yYXGtqRNihAqRu7u04gVJLJL9gpqdQt6mQ140=; b=QzeQ5T/F7GiZBToD5GlCRddAKyzyI6DXS17eIla+qga+mtI5V+Kw2zlVEqwYl9zx5r+hQh+3rOosniMQmYHybfooPDvxHnLr19hzeuQ8YgaguPTyVP1Mr/U+7+Qk+KNv6tiMU+i4wMG092x6CzauDWIbmVvw/y1GmehzrPgrcmg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [192.168.1.5] (86.247.3.219) by DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 10:56:02 +0000 From: Martin Vigoureux To: BESS Message-ID: <11d877b2-223d-5343-33a2-367c553950c5@nokia.com> Date: Tue, 31 Jan 2017 11:55:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.247.3.219] X-ClientProxiedBy: VI1PR0602CA0005.eurprd06.prod.outlook.com (10.175.26.143) To DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) X-MS-Office365-Filtering-Correlation-Id: d7b3d36c-18ce-4fc2-af4a-08d449c7bfbb X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:DB6PR0701MB2469; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 3:z8Ds6H+uWPSC5N8K2cR8UCRwPPEvMbivTXrgmpT20Oh3nngL+YK5ysfVUfCWugrW2FEfr1TeHQTPQPvcxgVR5BSv1s4rDCiCRQmR6bGPi/8OKwtasfMnsK8bSiKi8xtA1I0W1HAgpNKiI+rimPI6oe+eJ7Tu7nnSa54InwKrHG7n6YGSwKs8bk3X3dNwsDN83r7su2EV32CIbaa/+nGV40ZZyPXZlgdmtk/uX2TVXkOZbH3QbvVHFSZ7hq9CdNJS5jB1GO5PCLnkO0vEfnPYGMj6StEJCjw8gdY6sHxnxpo= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 25:2VxM5O3n4K44+K2VmMhd9nfvzRxOTZvCI1Xtv09DOSq9oWbcWWTPClN6F+TKjbMVYj+Rn/Lfz72G7VuzLgfqPElgPH3xttE9Ft0YEstjRX4iXSPZbkNOKQeHcH8JG3A9j4ySGMY9i4VudLmAuGPlPn+B8Agz7tz/73eNgI590cJktpf0lssbsZLW+dqIV3LiXGSMjVk/wMnXCQU7yCznPhFG9DwFmWyA+KrGJOqBmZvAexg/N8e1MYz4SGHDMHybRmE05TLFjRyAayptPl1EKcvda4nIjEHGpXOVoz778b+1Ymr3Gt9aPA/lW5ngzfAenqSD14hP84QV0wP3alxkHkfjjlBFLfn36+gAvL5t1Zth2vlLgMNXFG5wwPHHzsUP1MDrvE7fAEoEt4OmwQnvschlL4S9Z6dy2JtbvAWLx07trfPbyW9FqamdJckSLr7b2PIfcPCuSViaGPPLby+fTEm0/U/30W7yN6syx4kYauvGNWNOIG6/Y1OGo6NeG/fiOa47Tdbp3wd9jSDiaQ7YMbwJtqJ3vkz59lRNTFkWz9+d6TasS55QHvqTI5cXBYc6hBUb6REYp4UKnyBZroyxLd2mWg+Z6VAQvP+4npOAkg9a7iRtQ4GJdFSh4ve5TYtQA6C+147d74XFx2gtNEpxwjCLLNkkgkfpZeVNOaWckHe2rszc7tH5GdQqHNtu9qiu2ridwfFIOymhcFnzhqY+dG8OkBi1L7pKtE1NOjfJbOgPtDsFciDB5sbn1Ikb3cK59Qkis5XIgGHzoFpqcDaJgnsFRPowwyntgC/AMJxacu9BEwmYz7lzYqjCYML5x5ra X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 31:C5sBVapb4+vyKPOnM5+1ILi+28+8VCsocPvjlpzA2+S8IfEKnOs+m+YQ63Vg/ZpaboxMfmDexu3HI1Ypv+ixwKG0fEUMvh6VpbpvJ0s/V3kTcAu3YSFnK3IQ9qc8bPEGk+ZYeZC1R80cdjyDD+pIFIq0nT2k03poqTa9EVu7uAWe79TUfb0bKr42EBqv6R9EDJ1RcI9ojCTAr7OhPaX8RNpoY+K+dDdHJrw4pU9Hv6FVDO5yCZTglKuK2bAJyrrgmgdiyIMPv8e6kehZRP26ndB59i+0gMDaMvni2XdhcKc=; 20:DoMo7RFQjseQzoNUw2K/2BuMldAz5DrSF9Ished/gUU8rtNH5OJyIBr59cjkJngCv04Wy7+166Q+ShI0CTFq/IJwgwUILfKThIMnk1h1dX+95IRWu1UBIF+bY6gPLjWYeQuIv2Cw/uaS2rLAv+BsboLYu7YYdYcrFbugdFy/oiKAVKpo6eLvk/2qKRsOPMqcZZwW653vm1j5pgeVYet85bReIFzDTwYTyEwLgxQ7Si0BT0MnCv/lv9TDY+wwUfjuf9DeVrJn6mUPUmZLQLPcGWeQWhpnDf+ZyyXjjciWOv7++22vEr0ExPmWG0xNj8j6zVnWDDv3ixhccK4DZUKmYu/cazYuPvDnqjicH/Ycxfm0L7lSINQM8hIj+hbE17iYO6oepdvpKbMY0kAT55Wsd2T6CTBDsj8+v4wwxh+m4E/d6Adm/7/vQ5PNZCUdKi1KWjHD9bG0BNUJw6GlAb+XaDI1GD9pqSw8610yx3bG1tdxSMsCtRlvJS1J6fdSIcj0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:DB6PR0701MB2469; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2469; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 4:DxPa4j5zbS+qv3gN5THUpAY7l+Bd2NtYZ5A8RjkJ27X69hCJL+Thc4mqwtrAdE3VByjJ6kSJA5/Jqc1AW6jJmAp3Wvx2ShNfnVrHNnBljrsmVX1fs8ELVZOtBnPaPYcW37kkXi6L0f45T0Y08p+OieWJdRom88liTSrikmm+OBW1u8YjkHdvsCoVnPyX3XPguLztpiGexlOqa0qwlRaAJmQTJxTz8i+UMPwqrwbn6OvcriZ5DR8S2ZDlfRobWmJQwnQQozThcw13Dp0bmHZqCcqGRRky9XTc+IIzP2wZ0QLxwKChVGu/EThkAp9UfaC+Um03t2nL6+3AYdAQKGGKPA2t+unurf1nQZlc7t2moYvoZTvcxAeyRL0DdDpM2zPX3LZyvgdry37oFzGuzxN9G8+nU0kXxUYS2uHke5MPpV3OdmqF21K5RUX2aRljQJGHlJGa4cLODcTE4pYg8hfhFuuJzssUnTTjCYQJqZdgwwH2+uLUdI58R3oQOITU0yoE2WCsu0y+rU5UR9GuUqBDC0qIuWrloroLoc9yGZMulwy0Q9YXMn8HCvBMUR2dHD4Czmb7mvGM7lscRjF4+lslt/mfFP5QzjCYCJMplgI2/LN7fVPXwFgv1HaYIYU+om4W X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39840400002)(39860400002)(199003)(189002)(2906002)(105586002)(8676002)(230700001)(106356001)(92566002)(77096006)(42186005)(23746002)(81156014)(38730400001)(36756003)(6486002)(107886002)(81166006)(6306002)(83506001)(68736007)(25786008)(65826007)(7736002)(305945005)(6116002)(64126003)(54356999)(6916009)(3846002)(101416001)(50986999)(31686004)(5660300001)(6666003)(65806001)(450100001)(189998001)(110136003)(90366009)(86362001)(66066001)(53936002)(47776003)(97736004)(4001350100001)(65956001)(31696002)(50466002)(117156001)(33646002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2469; H:[192.168.1.5]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB6PR0701MB2469; 23:jv91WwRvo/0bnpT4tFuSxZBnRzSmnAMpCTJ?= =?Windows-1252?Q?xTMiWRS8XSPogzwQOi3z2241Lq5kR8Yo82gk7ktzuJn4rSzqC6NtdrvF?= =?Windows-1252?Q?P0h5laMpNgXwQyF1rsVI5ZXTgilKxcvv64PYdVHTxnFi+TnJIDW34Tpq?= =?Windows-1252?Q?iI364g9l8Jp29Cp+VljBHb5Ej+CAhD0dMVLrYel+9E2h5ixpPzyuG0gc?= =?Windows-1252?Q?Sa7KqmpycstbRiSpleEPFyfjBGgqh6XSPsYmtmlMMDRh/CBiQjd2oact?= =?Windows-1252?Q?A010bYN8C04iUUgzBvnO94+AcwDWnsHhG2o17+qgvd29noq79SZ0SrqF?= =?Windows-1252?Q?2/RHIS6gHkfiyPm5m5xXQQMb3yaQzs+cHr5TfJQUayQh6yTgo1qgEoBT?= =?Windows-1252?Q?wGVxNKtQtl7sFL5aBlHE8IVbIi5Zzg/HkDbzHrE6zhB0Rzw1D7zoXAgz?= =?Windows-1252?Q?Qgg23nvvLhKmGuH++ciy9UAf904h1Y2QGyHUPqe3QCigXGEJjQv/fyhY?= =?Windows-1252?Q?j8lltzBNR+LD1KP5K7siTkHpQPDdpG/fNVvuoqOa6HyOb6vJcZ90wvAA?= =?Windows-1252?Q?qFhiLtp4UmL3pQG0aQXaQgiO7IX9Zt6yTd5+FcEjhlIOQDuoWuIlzcP3?= =?Windows-1252?Q?awyhQeSajWvLdxPe0KQbaIhRlFkl6ZtAUQcwOZT9zCv7Y2DhOfkTVdA6?= =?Windows-1252?Q?DCUF5ce1Alo9gugGmp/hr9Ts/HcoiE4IpStwWTLvAQW8BYmgjhAahWaB?= =?Windows-1252?Q?qisyJUHp2EiWAFAlxjWW8uZvTeiNRyKwevtFEnU/+SnTiHRshAaohh1t?= =?Windows-1252?Q?Mk6CwVdCVQ8xJhPhYDaAdwePcqvostg69NfXxDZPv8GSJGj6DyQnUPyB?= =?Windows-1252?Q?K5RLwK9WjCUOBtNcnJJ2aQVIix6/JSH99jDEhf3imR+TRsZn5OESly8D?= =?Windows-1252?Q?vJPdtIr+tWQknkWGfYAtDqyVcUeoi1uk+15oWCYn0Wpjb/pdGCDFVFV8?= =?Windows-1252?Q?VLXrkZZdQVxL5UQ12FkWxuNjvSF72eo1Psf2OefQXSITfya29miU5QdT?= =?Windows-1252?Q?Zsrwvm42xQoGuBtWfqZWJAlroxNpDR85xDQh2accA+9vlfSU0IBNq4pu?= =?Windows-1252?Q?II4AzbIyq7QjLQSnkD9YsP54f1HfYpuNQx5Ru4WgSAXRQmdV02OH0Hkz?= =?Windows-1252?Q?G6rNTBIhFRsV4Pag86S4JgpZIWzO6E3A2+17JDtrEGnaHmo60wA1co9X?= =?Windows-1252?Q?cmmdtSvxBiz1lHjerpi8vaHQSjKMyVf8IZibsTSvhimb4v6vXNJEu2lO?= =?Windows-1252?Q?yRAP5EOis5nODSkJK3Wki6cZvk3tHxsLPUM9E7QgqOR37bRfwtQBLNQU?= =?Windows-1252?Q?O4rmIeC3deRXWLVf2XaeuEmHfmzvfx3ISmCj3/2CTyZsWUz2tOiTlyZZ?= =?Windows-1252?Q?fbQW6nnbiDZkqnhWmF9Mt8ANmk1swYs5hz46YpSt6qmyNuX+jb4l+i/q?= =?Windows-1252?Q?pAM9jew7jnNGBQBJzCtelMznSSMv5EPKLB3h2ZAHr3zgoDuAT2w=3D?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 6:YV6Otsq6b7wPX4bGozUD0RRw9yWTkaE+ORSheZp9aCFQsgqmo+rsUVVInXIvHtHZYK7yVbH06kXNAkwgrhf67QhYFuRMAJUaNTwJQkm8t+cDbayMPVrh5TyGzxtEKPCtNUbZ0lUjzrGw7cd1QMcXStjJ6B3zZ5QRvB15oqicAJr4oChKKxfAOcnJpsoMRT4VwIv0gNd5TZiFqJtGYOP20JNsztK1Xa+hiqAadBzP2kPaRs2Mplj/sR5NuBTHhs4QYGxNw/RS96/wHfqGHFalWt8ncZGzBtCV4QtcttO9zWz7OkuckraL16EJChhQ/HbgnDvNCsBbOlnLt5ott8E2psiYxa8Tvmt81dsBAI/2hdXeJOjrpqTFmss8Ylj4OrbF/WZx90jz5qkiwk5qWMas8y3Vn7jwvJqTCT7WUhJiAu2JrZsDCGeiUqxrk04i3jXx; 5:zWTpG/Rz+J+YpT067mA21VDmlgKQ4j2o8oxuJWEHoqNYBBdUgqTP1kjGPQpV+hE97Bzt1j5GV2Z0cBN+ecc3Z7Jh/oRnWMVrd9CP+R7wLN85n7YMgb5344SOjjComveIfu1v2qElJG8IISz1NCGsfg==; 24:NqDVQB4SAka9HnIqA8F3Giain4bNXo0OwhEk+6rY0crI7OO7YqzB2JaXA3Vd+9IE+cRlOdYbJJlQqsGermVOGySjjkJAlCAcSydlspB5whI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2469; 7:oEvLKTD0tTCktNQc3ovJLrDtoYpMw5PbYeX9Wu2kSfxjhr9HiGz3MtqcX1Qs3dcRU/pFYJK5Oy0CkqCN63PHqQ/+9gaq/0ijGYUmYmOlif2vl9h8BjOQ00A7voQr5PxlS8B4pn61HcPymS1OgO2zwPrr8R+3QRLwLAm2VnI5CG/2xKVx9u9mDTf+kF8HFcRVf1bOLs8QnCzEezvg8xS3b0EPJl/5hyD7ch421d7bPyXgNIhEQsv/rZYhClH0OC1jxLgujn09gYYhwcnQ6bCuwuAIeXWuHeBm5a9VNx4V9p2eEIdnWlQUhHFPfQRp8V4r5jST9+4I26/l0W6o8sBbcSuXkfRs1QGfJYQlM370CUWZURDn4kgxFYprbBqZBsOJM5L1KaTj1a1Oy5+gil0YsKxCPkATn+JXw4e4iNj6eTN1SMIt+O+m7s+2J0nnNrY0pwWEU8flMeuaB1I9wkadedzWMow7q8RYzGKM6cTySqKZtevVGCCxeDeAUxRcZ95qyX47L+ldDVnoyn3RuMrqKcEmWRGWLdMajO/M3MoQUGKYoYVSnvByckALoaXe/sYI X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2017 10:56:02.7087 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2469 Archived-At: Subject: [bess] WG feedback on early allocation requests for new EVPN Route types 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, 31 Jan 2017 10:56:08 -0000 Dear WG, we have received early allocation requests from the authors of draft-ietf-bess-evpn-prefix-advertisement and draft-ietf-bess-evpn-bum-procedure-updates: (see details below). Please let us know if you are aware of any code-point conflict, or if you have issues with the WG moving forward with this early allocation. We envisage to proceed with the request on the 6th of February. Thank you M&T --- "EVPN Route Types" from registry defined by RFC7432 https://www.iana.org/assignments/evpn/evpn.xhtml 5 - IP Prefix route 9 - Per-Region I-PMSI A-D route 10 - S-PMSI A-D route 11 - Leaf A-D route --- From nobody Tue Jan 31 06:58:36 2017 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 6B2CB129499; Tue, 31 Jan 2017 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.733 X-Spam-Level: X-Spam-Status: No, score=-6.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 n7dQhgpZ0oha; Tue, 31 Jan 2017 06:58:33 -0800 (PST) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CD8CF12943F; Tue, 31 Jan 2017 06:58:29 -0800 (PST) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F6F7A442D8; Tue, 31 Jan 2017 15:58:28 +0100 (CET) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 876E5A442D6; Tue, 31 Jan 2017 15:58:28 +0100 (CET) Received: from [10.193.71.154] (10.193.71.154) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 15:58:27 +0100 From: Thomas Morin To: Organization: Orange Message-ID: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> Date: Tue, 31 Jan 2017 15:58:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org Subject: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 31 Jan 2017 14:58:34 -0000 Hello working group, This email starts a two-week poll on adopting draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item. Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons). This poll runs until **February 14th**. *Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). ==> *If* you are listed as a document author or contributor please respond to this email and indicate whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are 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-sajassi-bess-evpn-igmp-mld-proxy-01 From nobody Tue Jan 31 06:58:47 2017 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 AB7881294AF; Tue, 31 Jan 2017 06:58:45 -0800 (PST) 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.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148587472569.2572.16540161969760299018.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 06:58:45 -0800 Archived-At: Subject: [bess] The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state "Call For Adoption By WG Issued" 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, 31 Jan 2017 14:58:46 -0000 The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state Call For Adoption By WG Issued (entered by Thomas Morin) The document is available at https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy/ From nobody Tue Jan 31 07:45:02 2017 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 77E66129514; Tue, 31 Jan 2017 07:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 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=-1.156, 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 0BUb2Lzt1D_G; Tue, 31 Jan 2017 07:44:59 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0092.outbound.protection.outlook.com [104.47.41.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475A5129989; Tue, 31 Jan 2017 07:44:59 -0800 (PST) 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=bSiQgn+Da9vbpGlR4d7pZyBBRvk8+umkrSPHSq3FmPY=; b=GwyATbN1hoCT5Lo60Sn0pmS9Ctv3IpnMp0GoGx3ZADtI+nrqmh230WSjq1PsVURBO7g+yDIgocLEhvyzUBIeYlXUmjo9P8A1bsS0zIG0gpTn+71k8+O2iTCgz2FKU30zcx4BLW/8HRkwZQm/BXYU5SmcG8KmB6IRzeAL3skpxPA= 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.888.5; Tue, 31 Jan 2017 15:44:58 +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.0888.016; Tue, 31 Jan 2017 15:44:58 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 Thread-Index: AQHSe9KB7yVS/QwnDkuteGOUydnfSaFSuiyg Date: Tue, 31 Jan 2017 15:44:57 +0000 Message-ID: References: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> In-Reply-To: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.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.11] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-ms-office365-filtering-correlation-id: 42156f6f-3eba-495a-dd13-08d449f01c3b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401076); SRVR:DM5PR05MB3147; x-microsoft-exchange-diagnostics: 1; DM5PR05MB3147; 7:+KYCL3f1Y8jMW2b572S4TC4FBB/NseelPzYW6gtQpUcW7TDr7w7ovYdhhnKFedoiT1wSrkiINC0umS7cSY+b9UcCxTgM4eUWArOjAW9SOEWA9221qS/zkPYL2XbCibcoZW6jwC7f78gBpEH61DzRnVmfhKktVov7J0w3WuTB4HX/RDF5b5x3PPPMKRMGNsVz71vs+LwRBubvUt/PbMfX9tqV3ExfQ3MnRcDHsRZbSUMcro1LInuGgOk0aJEGdlWBEZJ55T+BEgtljzCa+Jhj8I0dXWhMdMhbhd1qwAEb5SlW5vEI4BhKGiGykX0/NJAiZiwq6CxEZHHCIdujw5gaj04E5kmw2Woi0xBMoxnTfriuiCaalKyOD42joH+3sbUOgcvwXry186tykJCTBQbzMRNudRpf06l68mv34Egu5WZbhMgUR3ajcrpE09+lzzaiOMSrf8Bn9AnRQ0e8MC0TbdO8USKvn6qrqsEd+xZRk46B4GTFh72KFIWhb6ZjHnNr+wz9eDGEmlweQGn+aGBuqwWE6Ca3uqPmkM/0g2JO982vVWSWjY/Pngy/NXvp/5q4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:DM5PR05MB3147; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3147; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(199003)(13464003)(189002)(377454003)(38730400001)(55016002)(2501003)(77096006)(3660700001)(305945005)(189998001)(230783001)(25786008)(6436002)(74316002)(7696004)(6506006)(97736004)(33656002)(66066001)(5001770100001)(7736002)(122556002)(2950100002)(81166006)(8676002)(81156014)(5660300001)(8936002)(3280700002)(50986999)(86362001)(53936002)(229853002)(54356999)(2906002)(6116002)(106356001)(3846002)(106116001)(105586002)(102836003)(76176999)(101416001)(9686003)(68736007)(2900100001)(6306002)(4326007)(99286003)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3147; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 15:44:57.9445 (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: "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 31 Jan 2017 15:45:01 -0000 Support. > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin > Sent: Tuesday, January 31, 2017 9:58 AM > To: bess@ietf.org > Cc: draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org > Subject: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy= -01 >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item. >=20 > Please send comments to the list and state if you support adoption or > not (in the later case, please also state the reasons). >=20 > This poll runs until **February 14th**. >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that > applies to this draft, to ensure that IPR has been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). >=20 > =3D=3D> *If* you are listed as a document author or contributor please > respond to this email and indicate whether or not you are aware of any > relevant IPR. >=20 > The draft will not be adopted until a response has been received from > each author and contributor. >=20 > 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. >=20 > Thank you, >=20 > Martin & Thomas > bess chairs >=20 > [1] > https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-0= 1 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jan 31 11:17:46 2017 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 331A8129867; Tue, 31 Jan 2017 11:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, 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 nl7RLoatRWvJ; Tue, 31 Jan 2017 11:17:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E03129762; Tue, 31 Jan 2017 11:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=455; q=dns/txt; s=iport; t=1485890263; x=1487099863; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qCgr5WDlcj7XybvdAXNBIhcS4PHu6p+PbuisTCaksF0=; b=Ts7QPHIv7Ul/UJVlucXjwLcNn86RCUlUUk6/jYFUA+WKvLKOeIY5BqVr 3OkQAH7SjYzg0Vo74qHYM83Zw/5O8mHjqIkHfErv+yaqn1wUWh2MBBTrS nKafjIELGcgMiBhEICYeyUnuxBAPxllJSrIpps8evTv7dtzMuh8hx7kiV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAQCS4ZBY/5ldJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1NhgQkHjVilK4IPgg0shXYCgjU/GAECAQEBAQEBAWIohGoGHR1PAgE?= =?us-ascii?q?INgULMiUCBAESiW4OrjKLMwEBAQEBAQEBAQEBAQEBAQEBAQEaBYs6ijEFm1cBh?= =?us-ascii?q?maLF4FhjxeSfgEfOIFLFYUsgUh1hx6BDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208";a="379606412" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 19:17:42 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0VJHgmi023884 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 19:17:42 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 14:17:41 -0500 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; Tue, 31 Jan 2017 14:17:41 -0500 From: "Ali Sajassi (sajassi)" To: IETF Secretariat , "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state "Call For Adoption By WG Issued" Thread-Index: AQHSe9KG+vm5iDMWv0qurPo5fjEvPKFSw3CA Date: Tue, 31 Jan 2017 19:17:41 +0000 Message-ID: References: <148587472569.2572.16540161969760299018.idtracker@ietfa.amsl.com> In-Reply-To: <148587472569.2572.16540161969760299018.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.224.157] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state "Call For Adoption By WG Issued" 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, 31 Jan 2017 19:17:45 -0000 Support as a co-author. This draft is targeted to be available in some of Cisco products this year. Regards, Ali On 1/31/17, 6:58 AM, "IETF Secretariat" wrote: > >The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state >Call For Adoption By WG Issued (entered by Thomas Morin) > >The document is available at >https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy/ > From nobody Tue Jan 31 11:42:54 2017 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 A604D1299F9; Tue, 31 Jan 2017 11:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 HR8q0PMgDojy; Tue, 31 Jan 2017 11:42:52 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 040421299F6; Tue, 31 Jan 2017 11:42:52 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id e4so109938329pfg.1; Tue, 31 Jan 2017 11:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PMnUb7QLJGuyTBJn2S675BW+5tM5uas6ExZhGN4N3uo=; b=ox486dJ1P9x8U0y3SQ/n4ocCK52OhUHDfnXY4U1v8MvtlT94NKR8ViOV91I5scwmuW mMA4jQ32mRE5Ujv1uOjBMVE61k+9foV8Yf6hDNVpPZwHUEXIz7wM1cFklnJgQRZ7P+X0 q9xukQQ2cwsgnCF7Wk2fLPaqx62XfgB/Zq7g4OYvi7b3ISOcMMrY5Ckfpmgqq1N2D/lU qDGXP3Fl9o/LVqpEgd2MFVCPn/U6YvPnFrKqJueujKGBuQFSYcr9oAPY057UlPcPOl9C c606w29GIcYBFRLZzxguAZ45jih4aqSxRmp6jsqgPiSzA+B7bDpmcgOcNiZkCs7P5zSy kqDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PMnUb7QLJGuyTBJn2S675BW+5tM5uas6ExZhGN4N3uo=; b=Z97HWQ9d0sgx/9Nflr2/q1ANBDVAFUXdFWm4ItSReKFfz2pUtx69X3C+dDZDdSkVcY UvO/7YBORCKfASwx6njUg6nYZynOy/ip26QGcg84mqJa6ZH5g4PvK5eLsqm1vUPA4cew 1A3r5kRppaBIuMudIKAb4675y3QA3/Wvd+o2A9je6CpCxd+UdgcW6I4gDZSUetOnNUbb c5+TZvdiqdBUEb+t4cpqVxseaP1xCH9tL4SFzXpFbfVqgp+hxapFEaXs/fVs59EmqItr V1epNddGwqFFvsr2qgjXlApcjj5nS54/UHWd7YQvbudfnxHeyp2RSis7t5Yv9LeIUmD3 E8ng== X-Gm-Message-State: AIkVDXKC6UK9u5pFywpYsoG1oaN31wXuVSQw33YukaoQhMBHAF5YrQqDwgEyNewUI04LkA== X-Received: by 10.99.101.131 with SMTP id z125mr32189158pgb.218.1485891771554; Tue, 31 Jan 2017 11:42:51 -0800 (PST) Received: from [22.180.246.162] ([172.56.39.74]) by smtp.gmail.com with ESMTPSA id d68sm43151721pfj.92.2017.01.31.11.42.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 31 Jan 2017 11:42:50 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sami Boutros X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 31 Jan 2017 11:42:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <312C6DFB-3E62-41A7-85EB-1FEE800F11AA@gmail.com> References: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> To: "Jeffrey (Zhaohui) Zhang" Archived-At: Cc: "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 31 Jan 2017 19:42:53 -0000 Support. Sami > On Jan 31, 2017, at 7:44 AM, Jeffrey (Zhaohui) Zhang w= rote: >=20 > Support. >=20 >> -----Original Message----- >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin >> Sent: Tuesday, January 31, 2017 9:58 AM >> To: bess@ietf.org >> Cc: draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org >> Subject: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy= -01 >>=20 >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >> draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item. >>=20 >> Please send comments to the list and state if you support adoption or >> not (in the later case, please also state the reasons). >>=20 >> This poll runs until **February 14th**. >>=20 >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to this draft, to ensure that IPR has been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >> more details). >>=20 >> =3D=3D> *If* you are listed as a document author or contributor please >> respond to this email and indicate whether or not you are aware of any >> relevant IPR. >>=20 >> The draft will not be adopted until a response has been received from >> each author and contributor. >>=20 >> 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. >>=20 >> Thank you, >>=20 >> Martin & Thomas >> bess chairs >>=20 >> [1] >> https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-0= 1 >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jan 31 11:52:35 2017 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 09C01129581; Tue, 31 Jan 2017 11:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 fd0kBG5spXJF; Tue, 31 Jan 2017 11:52:31 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 863BA1299F8; Tue, 31 Jan 2017 11:52:31 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id y143so29465732pfb.1; Tue, 31 Jan 2017 11:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=kbUoGXSHh57zAzhJBfUCr/DR+ruvbrkNbGd91BF//7E=; b=psjNO3LGAc3tqDEAziUGneFHaItcJXPeMofKiY/KzRVB9TdJ3D3FheCV1KjGzV4Hr+ meU18VCApkjIO72KwE7d6JrgX595EYld+LvJi3VJb1JSdNIAdf616Lz7ZRdN/na5Uipt u1B62oYEcI3OeAklIjIBSPlVcIZgfjPqcAXt4adFTWLoWcguSOfNpt6oKz4aDGntYH6V 7nEfFdccNYt1rMXPmjQ5C6146oQhPNDSZ8jNoVGJ5iBz1i2ofKzCTutQNUWf7qzy1iKm uHY6O5m8s0Evo3CAHkIU7Xz7JmdTJne82vFnN652ubId5HRSZfGZ8vZMYlDlYS0hjd74 621A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=kbUoGXSHh57zAzhJBfUCr/DR+ruvbrkNbGd91BF//7E=; b=pdQiqp8VC+J+OOw+oAwaCmMuqwDq4PkJ+cYkukgQe+Tgj/KAky7ehEjwUV65WNjOxs q/IjwSWv0PYQTA5RxNqvykltn7bJK28vBSZzn7090/WdxMy4MZ6syNCjhbZrEAvPAZyw Jj7tmfm8QP4dQIeSHXOKWsAukAP4ZeQQRjKIKOswKMKGRnqg8Ccw28udctxTzTN6zVPW wxzTOCUYOyJzNrs5DA6TJARpQOjF8+6e24QZtRbC8F06jMcf3TeeC9R/u57r3gtKZU2V seOLv3MAZqfFNmCcLfFkOpylDveVG12T9YdEnQzDKHIVs33oc1mjyaCOEBH+N66QRMy4 slEA== X-Gm-Message-State: AIkVDXLnlSRu9Vl2y7VGzsZkLOW9gtY0sv3jXXG5jJ6xfbcSumCUBIxzkSXou00h5D3mUA== X-Received: by 10.99.167.74 with SMTP id w10mr33129063pgo.2.1485892351163; Tue, 31 Jan 2017 11:52:31 -0800 (PST) Received: from [192.168.254.79] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id v4sm43221423pfb.36.2017.01.31.11.52.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 11:52:30 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Tue, 31 Jan 2017 11:52:31 -0800 From: Jeff Tantsura To: "EXT - thomas.morin@orange.com" Message-ID: <783B736B-5297-493A-8946-CC8880FEED02@gmail.com> Thread-Topic: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 References: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> <312C6DFB-3E62-41A7-85EB-1FEE800F11AA@gmail.com> In-Reply-To: <312C6DFB-3E62-41A7-85EB-1FEE800F11AA@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" , "bess@ietf.org" Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 31 Jan 2017 19:52:34 -0000 Yes/support Cheers, Jeff >> -----Original Message----- >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin >> Sent: Tuesday, January 31, 2017 9:58 AM >> To: bess@ietf.org >> Cc: draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org >> Subject: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 >> >> Hello working group, >> >> This email starts a two-week poll on adopting >> draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item. >> >> Please send comments to the list and state if you support adoption or >> not (in the later case, please also state the reasons). >> >> This poll runs until **February 14th**. >> >> *Coincidentally*, we are also polling for knowledge of any IPR that >> applies to this draft, to ensure that IPR has been disclosed in >> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >> more details). >> >> ==> *If* you are listed as a document author or contributor please >> respond to this email and indicate whether or not you are aware of any >> relevant IPR. >> >> The draft will not be adopted until a response has been received from >> each author and contributor. >> >> If you are 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-sajassi-bess-evpn-igmp-mld-proxy-01 >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jan 31 12:35:01 2017 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 50360129A6D; Tue, 31 Jan 2017 12:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, 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 HTVing7x-j7j; Tue, 31 Jan 2017 12:34:58 -0800 (PST) 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 D00A0129A75; Tue, 31 Jan 2017 12:34:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=932; q=dns/txt; s=iport; t=1485894895; x=1487104495; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Js20JyFjcQSO2RT5LAaPYLc54NxO8wgp995NjDv0cFg=; b=E4SyhoayTuUklpLoURJXICt2dMe7R1mONp5y+kWgxEcHeu862IstZpS8 5LekFZA4o2fQW6qIgMTr3iXCYgg606tT3S2BdcwDjKx9/QSASkuD8Nfda 9fsEC8414RlLFA+hTv6gdiahKW8KNAX23UoQV4vZddYIR84hI/Rq2uLPn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAQAY9JBY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHg0+KCZFolVKCDR8NhXYCGoIdPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?qAgQBARsGETobAgEIGgIfBwICAiULFRACBAESiW4OrBqCJYs4AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWBC4VAggUIgmKETBeCby6CMQEEm1cBhmaLF5B4kn4BHzi?= =?us-ascii?q?BSxU7EAGEYIFIdYcegQwBAQE?= X-IronPort-AV: E=Sophos;i="5.33,316,1477958400"; d="scan'208";a="378179202" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jan 2017 20:34:54 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0VKYriC023423 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 20:34:54 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 15:34:52 -0500 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; Tue, 31 Jan 2017 15:34:52 -0500 From: "Patrice Brissette (pbrisset)" To: IETF Secretariat , "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" , "bess-chairs@ietf.org" , "bess@ietf.org" Thread-Topic: [bess] The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state "Call For Adoption By WG Issued" Thread-Index: AQHSfAF5UYfO5TGnS0OVaHOkzqf/pg== Date: Tue, 31 Jan 2017 20:34:52 +0000 Message-ID: <95229E64-AF12-4915-AF4B-F077263906AA@cisco.com> References: <148587472569.2572.16540161969760299018.idtracker@ietfa.amsl.com> In-Reply-To: <148587472569.2572.16540161969760299018.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.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.225.210] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] The BESS WG has placed draft-sajassi-bess-evpn-igmp-mld-proxy in state "Call For Adoption By WG Issued" 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, 31 Jan 2017 20:34:59 -0000 SSBzdXBwb3J0Lg0KVGhhdCBkcmFmdCBpcyBxdWl0ZSB3ZWxsIHdyaXR0ZW4gYW5kIGNvdmVyIGFu IGltcG9ydGFudCBwcm9ibGVtIHRvIHNvbHZlLA0KDQpSZWdhcmRzLA0KUGF0cmljZSBCcmlzc2V0 dGUNCg0KT24gMjAxNy0wMS0zMSwgOTo1OCBBTSwgIkJFU1Mgb24gYmVoYWxmIG9mIElFVEYgU2Vj cmV0YXJpYXQiIDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGYtc2VjcmV0 YXJpYXQtcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgVGhlIEJFU1MgV0cgaGFz IHBsYWNlZCBkcmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21wLW1sZC1wcm94eSBpbiBzdGF0ZSAN CiAgICBDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1ZWQgKGVudGVyZWQgYnkgVGhvbWFzIE1v cmluKQ0KICAgIA0KICAgIFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQNCiAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zYWphc3NpLWJlc3MtZXZwbi1pZ21wLW1s ZC1wcm94eS8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIEJFU1MgbWFpbGluZyBsaXN0DQogICAgQkVTU0BpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVzcw0KICAgIA0KDQo= From nobody Tue Jan 31 13:30:24 2017 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 1C0971295EC; Tue, 31 Jan 2017 13:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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=-3.199, 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 hIOAlo7WImnr; Tue, 31 Jan 2017 13:30:21 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54791295D4; Tue, 31 Jan 2017 13:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1358; q=dns/txt; s=iport; t=1485898221; x=1487107821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YNBW9OHmmr1tyfOjM2C1b+X2pvU1Gr34WfNKfTaCm7w=; b=kbdWkgTLlfi6zxYrZ6Hpf0AcOV2uPb0wYC8fLEFv0qIy7/WKPaJXFwVz g1lLtC8pzvyBjo+WiZ95EMNIjgeogy6yEi1NHidc5MU6u20xEccrtlKgf dPqNMZlzKGXXtCXboGTUaUQURtfJHwSQMHJ2d41gfq1Xpwlm7X4RwqHIi A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAtAZFY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQkHjVinOoINLIV2AoI3PxgBAgEBAQEBAQFiKIRqBh1cEAI?= =?us-ascii?q?BCEYyJQIEAQ0FiW4OrkmLNgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFizqEHhEBh?= =?us-ascii?q?gEFj3SLYwGGZosXgXmFFYlqkn4BHzh2VRU7hjl1hX2BIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,316,1477958400"; d="scan'208";a="377832332" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2017 21:30:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0VLUK2F021303 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 21:30:20 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 16:30:19 -0500 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; Tue, 31 Jan 2017 16:30:19 -0500 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 Thread-Index: AQHSe9KBEzwEDWPNoUiAji78cikt96FS6FuA Date: Tue, 31 Jan 2017 21:30:19 +0000 Message-ID: References: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> In-Reply-To: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.224.157] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <96BA8F53A12C8E4085EC2A981FE890AE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 31 Jan 2017 21:30:23 -0000 Support as a co-author. I am not aware of any IPR related to this draft that hasn=B9t already been disclosed. Regards, Ali On 1/31/17, 6:58 AM, "Thomas Morin" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-sajassi-bess-evpn-igmp-mld-proxy-01 [1] as a working group item. > >Please send comments to the list and state if you support adoption or >not (in the later case, please also state the reasons). > >This poll runs until **February 14th**. > >*Coincidentally*, we are also polling for knowledge of any IPR that >applies to this draft, to ensure that IPR has been disclosed in >compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >more details). > >=3D=3D> *If* you are listed as a document author or contributor please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you are 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]=20 >https://datatracker.ietf.org/doc/draft-sajassi-bess-evpn-igmp-mld-proxy-01 From nobody Tue Jan 31 18:54:41 2017 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 5D49012984C; Tue, 31 Jan 2017 18:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 pHq4kkfxBMcn; Tue, 31 Jan 2017 18:54:37 -0800 (PST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (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 B8EA3129801; Tue, 31 Jan 2017 18:54:37 -0800 (PST) Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 0BB398004C; Wed, 1 Feb 2017 02:54:37 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx3-us4.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id BF3E46004F; Wed, 1 Feb 2017 02:54:36 +0000 (UTC) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0182.outbound.protection.outlook.com [216.32.180.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx3-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id D70E76005D; Wed, 1 Feb 2017 02:54:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z2M7Txau0P2Ag8wvkH3I2GDk1CBtUda+dwtrXr0aFMM=; b=qXcd4ihXj1DkGpN624AJag5nt2MY1f4kWsfw0bsbc0CMJ5gMsMve2Nt16g6CWidE2qevWyqYkpJBuvK+Var7l4MYn3p+o8Tv5mHz2V8dRNqJfdhk+kPbF6Yy37lX90PqyqWnEaQ6YP5xRkW7htVor53XajPL6/rFB+N/nJ4lRq4= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0263.namprd18.prod.outlook.com (10.163.72.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 1 Feb 2017 02:54:30 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0860.026; Wed, 1 Feb 2017 02:54:30 +0000 From: Keyur Patel To: "Ali Sajassi (sajassi)" , Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 Thread-Index: AQHSe9KFAV9G3Chqs0SnCM3Ca2p88qFTGsuA///UdoA= Date: Wed, 1 Feb 2017 02:54:30 +0000 Message-ID: References: <0e9dab75-413a-bc13-4b8e-050811e59123@orange.com> In-Reply-To: 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=keyur@arrcus.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [23.124.104.14] x-ms-office365-filtering-correlation-id: aa78ae4c-6f37-48f3-2fd9-08d44a4da4d0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0263; x-microsoft-exchange-diagnostics: 1; BY2PR18MB0263; 7:M7N4Xm9PW3SKMc2YPOpIYAkxNvLJThIbJlaRdtHRnqLQJ+nvpTTuzb5oZ2P5W5ZoNdRoXxBela6Mi54+bm56JrEUDSSdjn8iuRpMFd24D0UwLLqrs24YSZKAeA51j9zmNQumFqG+RIXT9wZTg919PbTcuEe4n+BjFAFc8mgYc+XLdJYR652ddWPPc52hhtpMicHAptzwIECX/zK/XWvisBT42u7zXfySiVH7BB5dmS9l/S3iWErsqJuBqFxw5n2BVV5fR/v4iuUnWjy6DviHlo91ehmhkdEBfxrJQ6dreQOAtSc3O2eSwNDYIyysvfuofwpmsueYRvivDwPWoEsaI/hEjxBzUCUCViNkGUKeZrPY0SRzWDulexGG5FZ8XwHQjczzAQ+lMa59Om7Sh2ZHmrcV9MADXmuWp9W6AmHBa1Pk2WhLHdHscZmo+mv4b5FY8hxh63GJ2lSzUK+wtsy2aKTrhM+XaEf/QJAU0JbQMZLWTd6oc4V+AguRfo04liLilG3qLTOODr0y/5ayKK/PeOuVP2qM42fSMX8i9NZWMokMSggl0L9Lc0u0O4ePLblL x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(2016111802025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(20161123564025)(6043046)(6072148); SRVR:BY2PR18MB0263; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0263; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39410400002)(39450400003)(39830400002)(199003)(189002)(377454003)(24454002)(122556002)(86362001)(38730400001)(33656002)(81166006)(8936002)(77096006)(6306002)(92566002)(25786008)(6512007)(97736004)(6436002)(81156014)(2950100002)(3280700002)(229853002)(6486002)(8676002)(6506006)(99286003)(5001770100001)(36756003)(189998001)(66066001)(2900100001)(53936002)(3660700001)(106116001)(6116002)(5660300001)(305945005)(105586002)(54356999)(50986999)(4326007)(7736002)(68736007)(83716003)(2501003)(102836003)(3846002)(101416001)(2906002)(82746002)(106356001)(230783001)(76176999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0263; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 02:54:30.2251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0263 X-MDID: 1485917677-HDLO4YWJSNp8 Archived-At: Cc: "draft-sajassi-bess-evpn-igmp-mld-proxy@ietf.org" Subject: Re: [bess] Call for adoption: draft-sajassi-bess-evpn-igmp-mld-proxy-01 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, 01 Feb 2017 02:54:39 -0000 U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVk IHRvIHRoaXMgZHJhZnQuDQoNClJlZ2FyZHMsDQpLZXl1cg0KDQpPbiAxLzMxLzE3LCAxOjMwIFBN LCAiQWxpIFNhamFzc2kgKHNhamFzc2kpIiA8c2FqYXNzaUBjaXNjby5jb20+IHdyb3RlOg0KDQog ICAgDQogICAgU3VwcG9ydCBhcyBhIGNvLWF1dGhvci4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElQ UiByZWxhdGVkIHRvIHRoaXMgZHJhZnQNCiAgICB0aGF0IGhhc27CuXQgYWxyZWFkeSBiZWVuIGRp c2Nsb3NlZC4NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIEFsaQ0KICAgIA0KICAgIE9uIDEvMzEv MTcsIDY6NTggQU0sICJUaG9tYXMgTW9yaW4iIDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4gd3Jv dGU6DQogICAgDQogICAgPkhlbGxvIHdvcmtpbmcgZ3JvdXAsDQogICAgPg0KICAgID5UaGlzIGVt YWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBvbGwgb24gYWRvcHRpbmcNCiAgICA+ZHJhZnQtc2FqYXNz aS1iZXNzLWV2cG4taWdtcC1tbGQtcHJveHktMDEgWzFdIGFzIGEgd29ya2luZyBncm91cCBpdGVt Lg0KICAgID4NCiAgICA+UGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYW5kIHN0YXRl IGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yDQogICAgPm5vdCAoaW4gdGhlIGxhdGVyIGNhc2Us IHBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCiAgICA+DQogICAgPlRoaXMgcG9sbCBy dW5zIHVudGlsICoqRmVicnVhcnkgMTR0aCoqLg0KICAgID4NCiAgICA+KkNvaW5jaWRlbnRhbGx5 Kiwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdA0KICAg ID5hcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNj bG9zZWQgaW4NCiAgICA+Y29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAz OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvcg0KICAgID5tb3JlIGRldGFpbHMpLg0KICAgID4N CiAgICA+PT0+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IgcGxlYXNlDQogICAgPnJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkNCiAgICA+cmVsZXZhbnQgSVBSLg0K ICAgID4NCiAgICA+VGhlIGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tDQogICAgPmVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRv ci4NCiAgICA+DQogICAgPklmIHlvdSBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29u dHJpYnV0b3IsIHRoZW4gcGxlYXNlDQogICAgPmV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlv dSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0DQogICAgPmJlZW4gZGlzY2xv c2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCiAgICA+DQogICAgPlRoYW5rIHlv dSwNCiAgICA+DQogICAgPk1hcnRpbiAmIFRob21hcw0KICAgID5iZXNzIGNoYWlycw0KICAgID4N CiAgICA+WzFdIA0KICAgID5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1z YWphc3NpLWJlc3MtZXZwbi1pZ21wLW1sZC1wcm94eS0wMQ0KICAgIA0KICAgIA0KDQo=