From nobody Thu Sep 1 00:05:00 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9712D195; Thu, 1 Sep 2016 00:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd-yBWrOmhPU; Thu, 1 Sep 2016 00:04:56 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 65F091200DF; Thu, 1 Sep 2016 00:04:56 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id v143so5661598wmv.0; Thu, 01 Sep 2016 00:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=C63e++VUMfhgmTF7VbhShEQvIzUDau3csia7+2IGxE0=; b=hVyncdhz0XZiFRFljzj2HR/zqorYexiACFVwRfZ93KicKAyuhUOS/D0yY4jr3NwzVQ vN+vR+ulzKm22TSE5PuzLVmRpO16XlRx/7hmfkOQtfvUNLPwD1ErJziYS0pdX5hv0sZw XN4/MmHgPrT+H04Mh4o+IckAIVSr9bu9xf0CgrJcxhfJRejwWIOIxWj5zEUjlcaBFwtM QI1IEWtYmhWyBNChgWBlrJsp99sgZScE8QqPc9/aRDtzMSbb1QPIZR+G3yotRlnexGOO PQYi2P3kOxfM8mlQ6JRauePaOlagdH2sWJNNg2iTGNz8wNr55gTwaQD6tILrYtNSTjsO UNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=C63e++VUMfhgmTF7VbhShEQvIzUDau3csia7+2IGxE0=; b=DJN3zXyrNiLWgqOjOHZKwRcaKwJfod7HEt7MO4ut9bQtA3+brbqP1qvBarCQDWwtHi N6vDkIDH8eSB2AV69zTSfBAST8VmB9RhbrBOFv33iNliHb36I5o6YNmKFzzcAeMnGdyZ wlVfeeytGld0f2J7fvGTZrkkMjm1Lv9f4QJ1Rza/WEKymFuSLYd8zcbGdx4oJO7D7dJB rJmAONFKKs0cZ56dfLd7EGpU6pBIdbM8z5KDtc/QYA1bmU83+zWFC/h6g2tPfYCLPjBk HB6yThiN8aOQ6ygTd3KrAklSfIU8Hu1I+Fpvb8s0dXSyDhrJT4TuIOf3z0qgsslRoclN kLEw== X-Gm-Message-State: AE9vXwOTMUOY2WI0BoeHKhIyAxgJF44vewxJHo1+VSLIpTUKaHbYf5vbBi+VKCjV7d81+Qq8Lp8865kTMoLYOA== X-Received: by 10.194.89.228 with SMTP id br4mr12447816wjb.187.1472713494689; Thu, 01 Sep 2016 00:04:54 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.194.60.51 with HTTP; Thu, 1 Sep 2016 00:04:53 -0700 (PDT) In-Reply-To: References: <8A502F2D-E7EC-4497-9BF1-1295E1F21A02@pi.nu> From: Robert Raszuk Date: Thu, 1 Sep 2016 09:04:53 +0200 X-Google-Sender-Auth: U6tBW-b3jDG4Nao7mC6flP2sN6k Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=047d7bf10adab4fdf0053b6cd406 Archived-At: Cc: idr wg , "bess@ietf.org" , Eric Rosen , "mpls@ietf.org" Subject: Re: [bess] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis 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, 01 Sep 2016 07:04:58 -0000 --047d7bf10adab4fdf0053b6cd406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BAcee,=E2=80=8B > The current capability is specific to support of multiple labels - not > your parochial view on the interaction between SAFIs. > =E2=80=8BSince "bis" specification obsoletes the base document I was under = the assumption that new capability will also obsolete the current used. It is no longer "3107bis" but just a new draft or at best errata - to the best of my understanding of IETF rules "bis" obsoletes the original spec. Requiring implmentors to read and follow both specifications to correctly implement the labeled BGP AF seems a bit odd ... don't you think ? Are you suggesting a second capability? All the more reason for a separate > draft. > =E2=80=8BNo.=E2=80=8B See above. In any event, the non-backward compatible behavior you are proposing would > be better served in a separate draft than to burden RFC 3107 BIS. > =E2=80=8BSection 5 already discusses that point - so my comment should be considered as feedback towards that section . If there is WG consensus to proceed with that it would be pure waist of time to write a separate draft to argue against it. It seems interesting that IETF WG feedback expressed on the list for specific section of the draft in adoption call or during WG progress is turned around and request is made to write a new draft instead. Especially that document wise the feedback consideration may require addition of two sentences within section 5 :). Cheers, R. --047d7bf10adab4fdf0053b6cd406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BAcee,=E2=80=8B
=C2=A0
The current capability is specific to support of multiple labels - not you= r parochial view on the interaction between SAFIs.

=E2=80=8BSince "bis" spec= ification obsoletes the base document I was under the assumption that new c= apability will also obsolete the current used.=C2=A0

It is no longer "3107bis" but just= a new draft or at best errata - =C2=A0to the best of my understanding of I= ETF rules "bis" obsoletes the original spec. Requiring implmentor= s to read and follow both specifications to correctly implement the labeled= BGP AF seems a bit odd ... don't you think ? =C2=A0
Are you suggesting a second capabil= ity? All the more reason for a separate draft.=C2=A0

=E2=80=8BNo.=E2=80=8B See above.= =C2=A0

In any event, the non-backward compati= ble behavior you are proposing would be better served in a separate draft than to burde= n RFC 3107 BIS.=C2=A0

=E2=80=8BSection 5 already discusses that point - so my comment s= hould be considered as feedback towards that section . If there is WG conse= nsus to proceed with that it would be pure waist of time to write a separat= e draft to argue against it.

It seems interesting that IETF WG feedback expressed on the list f= or specific section of the draft in adoption call or during WG progress is = turned around and request is made to write a new draft instead.=C2=A0
=

Especially that document wi= se the feedback consideration may require addition of two sentences within = section 5 :).

Ch= eers,
R.


=
=C2=A0
--047d7bf10adab4fdf0053b6cd406-- From nobody Thu Sep 1 15:03:24 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A812D7AD; Thu, 1 Sep 2016 15:03:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147276739938.32070.10287782364763380785.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 15:03:19 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-07.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: Thu, 01 Sep 2016 22:03:19 -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-07.txt Pages : 18 Date : 2016-09-01 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 1 15:05:43 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B0712B014; Thu, 1 Sep 2016 15:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 qeRFqPixK3dk; Thu, 1 Sep 2016 15:05:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118B412DB17; Thu, 1 Sep 2016 15:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=122681; q=dns/txt; s=iport; t=1472767526; x=1473977126; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BR2gcB3eKpu+iSEzrsxbljws/hHcGKq3clO2r31aPwY=; b=OgpQ0MMchSkJ+4gi/QmkMpQntixBGhnYK5SdV2OWb5njSkTai3Zlf//O htD/QLJhGU1Rq0DcYRczZmv15CfphBVvyOCKtJpI0HkW07ES7m1Qn3AFc ag+WnATTiAUpUTQXoVcR0G579EcpUrcmnH4P1+VBArmejKouE4sX6mfsS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAgAkpchX/51dJa1TCoMdMwEBAQEBH?= =?us-ascii?q?ld8B7gqggIkgh0Bg1oCgVY4FAECAQEBAQEBAV4nhGEBAQUaAQxABgwQAgEIEQM?= =?us-ascii?q?BAiEBBgcyFAkIAgQBDQMCFAeILQ66ewEBAQEBAQEBAQEBAQEBAQEBAQEBARcFi?= =?us-ascii?q?nyEBxEFQwwMhSQBBIgthXeFZYVHAYYfgwGGEIFthF2JDYZwhViDeAEeNluBbgU?= =?us-ascii?q?WgU0/MQGEPQEEAh+BCX8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,268,1470700800"; d="scan'208,217";a="148048398" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2016 22:05:23 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u81M5N6J003779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Sep 2016 22:05:23 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; Thu, 1 Sep 2016 18:05:22 -0400 Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Thu, 1 Sep 2016 18:05:22 -0400 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" , Eric Rosen , BESS Thread-Topic: shepherd review of draft-ietf-bess-evpn-etree Thread-Index: AQHSAgSQiVios9dTSUOmTfNWP8T6rqBlA4UA Date: Thu, 1 Sep 2016 22:05:22 +0000 Message-ID: References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> In-Reply-To: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.58] Content-Type: multipart/alternative; boundary="_000_D3EA14B31B9CAEsajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Ali Sajassi \(sajassi\)" , 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, 01 Sep 2016 22:05:34 -0000 --_000_D3EA14B31B9CAEsajassiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks very much for your thorough review and valuable comments. I have res= olved all of them and incorporated all the required modifications. Please r= efer to the comment resolutions below and let me know if there are any furt= her comments. You can find the latest rev of the draft with the incorporate= d changes in: https://www.ietf.org/id/draft-ietf-bess-evpn-etree-07.txt Thanks, Ali From: Thomas Morin = > Organization: Orange Date: Monday, August 29, 2016 at 7:49 AM To: "draft-ietf-bess-evpn-etree@ietf.org" >, Loa Andersson >, "George Swa= llow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" >, Eric Rosen >, BESS > Cc: Martin Vigoureux > Subject: shepherd review of draft-ietf-bess-evpn-etree Resent-From: > Resent-To: Cisco Employee >, >, >, >, >, > Resent-Date: Monday, August 29, 2016 at 7:49 AM Hi, Here is the review I did while preparing the shepherd write-up for draft-ie= tf-bess-evpn-etree . There is one thing that stands out: the document uses the most significant = bit of the "PMSI Tunnel Attribute" Tunnel Type field, which cant't be done= I think without updating the structure of the corresponding registry (RFC7= 385). I suggest how that can be done at the end of this review (a few peop= le Cc'd for this reason). Please find my comments below... [...] 2 E-Tree Scenarios and EVPN / PBB-EVPN Support In this section, we will categorize support for E-Tree into three different scenarios, depending on the nature of the site association (Root/Leaf) per PE or per Ethernet Segment: - Leaf OR Root site(s) per PE - Leaf OR Root site(s) per AC - Leaf OR Root site(s) per MAC 2.1 Scenario 1: Leaf OR Root site(s) per PE In this scenario, a PE may receive traffic from either Root sites OR Leaf sites for a given MAC-VRF/bridge table, but not both concurrently. In other words, a given EVI on a PE is either associated with a root or leaf. s/with a root or leaf/with roots or leaves/ ? Done. Changed it to =93root(s) or leaf(s)" The PE may have both Root and Leaf s/both Root and Leaf/both Roots and Leaves/ ? In this sentence =93Root=94 and =93Leaf=94 are used as adjectives for sites= , so AFAIK, they should remain singular. sites albeit for different EVIs. +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+---ES1----+--+ | | | MPLS | | | +--+----ES2-----+CE2| +---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+ | |VRF| | | | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+----ES3-----+CE3| | +---+ | +------+ | +---+ | (Leaf) +---+ +---------+ +---------+ Figure 1: Scenario 1 In such scenario, an EVPN PE implementation MAY provide E-TREE service using topology constraint among the PEs belonging to the same "topology constraint" is a bit opaque as a term, perhaps "using tailored BG= P RT import/export policies" would be more descriptive (assuming I understo= od your intent) Done. Changed it to =93topology constraint tailored by BGP Route Target (RT= ) import/export policies" EVI. The purpose of this topology constraint is to avoid having PEs with only Leaf sites importing and processing BGP MAC routes from each other. To support such topology constrain in EVPN, two BGP Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is associated with the Root sites and the other is associated with the Leaf sites. On a per EVI basis, every PE exports the single RT associated with its type of site(s). Furthermore, a PE with Root site(s) imports both Root and Leaf RTs, whereas a PE with Leaf site(s) only imports the Root RT. The text seems to imply that the above is sufficient to deliver the service= , but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves = bound to the same MAC-VRF (ES2 and ES3 in firgure1). Shouldn't the text me= ntion the use of a split-horizon in Leaf MAC-VRFs ? Agree, nice catch!. I changed the first sentence from: "In such scenario, an EVPN PE implementation MAY provide E-TREE service usi= ng topology constraint among the PEs belonging to the same EVI." TO "In such scenario, topology constraint, provided by BGP Route Target (RT) i= mport/export policies among the PEs belonging to the same EVI, can be used = to restrict the communications among Leaf PEs." (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. 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 Ro= ots) because Leafs and Roots need to talk to each other and thus we want th= em to be in the same MAC-VRF. However, Leafs should not talk among themselv= es and thus we can put all the Leaf ACs in a split-horizon group. If this is not possible, I think the text should explain why. I don=92t think we need an explanation because of the above reason but if y= ou think otherwise, then please suggest a text as what do you think I shoul= d add. If the number of EVIs is very large (e.g., more than 64K), then RT type 0 as defined in [RFC4360] SHOULD be used; otherwise, RT type 2 is sufficient [RFC7153]. This is not specific to E-VPN E-TREE, or even to E-VPN, why mention that ? Agree, it is not specific to E-TREE. I will take it out. 2.2 Scenario 2: Leaf OR Root site(s) per AC In this scenario, a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI. In other words, an AC (ES or ES/VLAN) is either associated with a Root or Leaf (but not both). s/with a Root or Leaf/with Roots or Leaves/ ? Agree =96 Changed it to "Root(s) or Leaf(s)" +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ | |VRF| | | /IP | | |VRF| | | | | | | | | | | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Root) +---+ +---------+ +---------+ Figure 2: Scenario 2 In this scenario, if there are PEs with only root (or leaf) sites per EVI, then the RT constrain procedures described in section 2.1 can also be used here. However, when a Root site is added to a Leaf PE, then that PE needs to process MAC routes from all other Leaf PEs and add them to its forwarding table. This is the case in 2.1 as well, isn't it ? It can start as 2.1 but as soon as you add Root site to a Leaf PE, then it = becomes different (per last sentence of the above para). 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 :-) 2.3 Scenario 3: Leaf OR Root site(s) per MAC In this scenario, a PE may receive traffic from both Root AND Leaf sites on a given Attachment Circuit (AC) of an EVI. Since an Attachment Circuit (ES or ES/VLAN) carries traffic from both Root and Leaf sites, the granularity at which Root or Leaf sites are identifies s/identifies/identified/ Done. is on a per MAC address. This scenario is considered in this draft for EVPN service with only known unicast traffic - i.e., there is no BUM traffic. "there is no BUM" is quite a bold claim ! :=3D Maybe the text should say "no BUM traffic is supported (BUM traffic will be= dropped)" ? (possibly "BUM traffic from Leaves will be dropped" would be sufficient ?) Changed it to =93BUM traffic is not supported in this scenario and it is dr= opped=94. +---------+ +---------+ | PE1 | | PE2 | +---+ | +---+ | +------+ | +---+ | +---+ |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| +---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+ | | V | | | /IP | | | V | | | | I | | | | | | I | | +---+ | | | | | | | | +--+---ES2/AC2--+CE3| | +---+ | +------+ | +---+ | (Leaf) +---+ +---------+ +---------+ Figure 3: Scenario 3 3 Operation for EVPN [RFC7432] defines the notion of ESI MPLS label used for split-horizon filtering of BUM traffic at the egress PE. Such egress filtering capabilities can be leveraged in provision of E-TREE services as seen shortly. In other words, [RFC7432] has inherent capability to support E-TREE services without defining any new BGP routes but by just defining a new BGP Extended Community for leaf indication as shown later in this document. 3.1 Known Unicast Traffic Since in EVPN, MAC learning is performed in control plane via advertisement of BGP routes, the filtering needed by E-TREE service for known unicast traffic can be performed at the ingress PE, thus providing very efficient filtering and avoiding sending known unicast traffic over MPLS/IP core to be filtered at the egress PE as done in traditional E-TREE solutions (e.g., E-TREE for VPLS). To provide such ingress filtering for known unicast traffic, a PE MUST indicate to other PEs what kind of sites (root or leaf) its MAC addresses are associated with by advertising a leaf indication flag (via an Extended Community) along with each of its MAC/IP Advertisement route. The lack of such flag indicates that the MAC address is associated with a root site. This scheme applies to all scenarios described in section 2. Furthermore, for multi-homing scenario of section 2.2, where an AC is either root or leaf (but not both), the PE MAY advertise leaf indication along with the Ethernet A-D per EVI route. This advertisement is used for sanity checking in control-plane to ensure that there is no discrepancy in configuration among different PEs of the same redundancy group. For example, if a leaf site is multi-homed to PE1 an PE2, and PE1 advertises the Ethernet A-D per EVI corresponding to this leaf site with the leaf-indication flag but PE2 does not, then the receiving PE notifies the operator of such discrepancy and ignore the leaf-indication flag on PE1. In other words, in case of discrepancy, the multi-homing for that pair of PEs is assumed to be in default "root" mode for that or . The leaf indication flag on Ethernet A-D per EVI route tells the receiving PEs that all MAC addresses associated with this or are from a leaf site. Therefore, if a PE receives a leaf indication for an AC via the Ethernet A-D per EVI route but doesn't receive a leaf indication in the corresponding MAC route, "MAC route" --> "MAC/IP Advertisement route" ? I changed it to =93MAC/IP Advertisement route=94. then it notify the operator and ignore the leaf indication on s/notify/notifies/ Done. the Ethernet A-D per EVI route. The procedure above should I think be rephrased to provide unambiguous inte= rpretation in the case where a given MAC is being announced in more than on= e MAC/IP advertisement route, possibly carrying a different leaf indication= (and even possibly from different ESes, or from PEs not advertising Ethern= et A-D route). Are you talking about MAC move where a MAC can move between Root and Leaf s= ites? If so, MAC mobility procedure takes precedence. I have added the foll= owing paragraph toward the end of this section: "In situation where MAC moves are allowed among Leaf and Root sites (e.g., = non-static MAC), PEs can receive multiple MAC/IP advertisements routes for = the same MAC address with different Leaf/Root indications (and possibly dif= ferent ESIs for multi-homing scenarios). In such situations, MAC mobility p= rocedures take precedence to first identify the location of the MAC before = associating that MAC with a Root or a Leaf site." Tagging MAC addresses with a leaf indication enables remote PEs to perform ingress filtering for known unicast traffic - i.e., on the ingress PE, the MAC destination address lookup yields, in addition to the forwarding adjacency, a flag which indicates whether the target MAC is associated with a Leaf site or not. Ditto, more or less: the procedure above should I think be rephrased to pro= vide unambiguous interpretation in the case where a given MAC is being anno= unced in more than one MAC/IP advertisement route, possibly carrying a diff= erent leaf indication. The new paragraph will take care of it. The ingress PE cross- checks this flag with the status of the originating AC, and if both are Leafs, then the packet is not forwarded. To support the above ingress filtering functionality, a new E-TREE Extended Community with a Leaf indication flag is introduced [section 5.2]. This new Extended Community MUST be advertised with MAC/IP Advertisement route and MAY be advertised with an Ethernet A-D per EVI route as described above. 3.2 BUM Traffic For BUM traffic, it is not possible to perform filtering on the ingress PE, as is the case with known unicast, because of the multi- destination nature of the traffic. Saying "it is not possible" without more explanation is not very useful (th= e reader may think about using RPF-like techniques on the egress PE). It seems to me more reasonable to formulate things in terms of "This specif= ication does not provide support for filtering BUM traffic on the ingress P= E", and avoid a sentence like the one above. OK, Changed the sentence to: "This specification does not provide support for filtering BUM traffic on t= he ingress PE because it is not possible to perform filtering of BUM traffi= c on the ingress PE, as is the case with known unicast described above, due= to the multi-destination nature of BUM traffic." As such, the solution relies on egress filtering. In order to apply the proper egress filtering, which varies based on whether a packet is sent from a Leaf AC or a root AC, the MPLS-encapsulated frames MUST be tagged with an indication when they originated from a Leaf AC. In other words, leaf indication for BUM traffic is done at the granularity of AC. This can be achieved in EVPN through the use of a MPLS label where it can be used to either identify the Ethernet segment of origin per [RFC7432] (i.e., ESI label) or it can be used to indicate that the packet is originated from a leaf site (Leaf label). BUM traffic sent over a P2MP LSP or ingress replication, may need to carry an upstream assigned or downstream assigned MPLS label (respectively) for the purpose of egress filtering to indicate to the egress PEs whether this packet is originated from a leaf AC. The main difference between downstream and upstream assigned MPLS label is that in case of downstream assigned not all egress PE devices need to receive the label just like ingress replication procedures defined in [RFC7432]. There are four scenarios to consider as follow. s/follow/follows/ Done. In all these scenarios, the imposition PE imposes the right MPLS label associated s/the imposition PE imposes/the ingress PE imposes/ ? Done. with the originated Ethernet Segment (ES) depending on whether the Ethernet frame originated from a Root or a Leaf site on that Ethernet Segment (ESI or Leaf label). The mechanism by which the PE identifies whether a given frame originated from a Root or a Leaf site on the segment is based on the Ethernet Tag associated with the frame (e.g., whether the frame received on a leaf or a root AC). First comment: it seems that the formulation should also support the case w= here an AC does not use .1q. Agree. Change the sentence to: "The mechanism by which the PE identifies whether a given frame originated = from a Root or a Leaf site on the segment is based on the AC identifier for= that segment (e.g., Ethernet Tag of the frame for 802.1Q frames). Other me= chanisms for identifying root or leaf (e.g., on a per MAC address basis) is= beyond the scope of this document." (side comment: doing the identification based on the source MAC address wou= ld seem to allow BUM in the context of 2.3; it is out of the scope of my re= view to extend the scope of these specs, but I'm curious why it is not prop= osed....) If we went for per MAC root/leaf identification, then this would have expan= ded the scope of DF election and egress filtering beyond that of RFC 7432. = Currently, we don=92t have any such requirements from operators and service= providers. Other mechanisms for identifying whether an ingress AC is a root or leaf is beyond the scope of this document. 3.2.1 BUM traffic originated from a single-homed site on a leaf AC In this scenario, the ingress PE adds a special MPLS label indicating a Leaf site. This special Leaf MPLS label, used for single-homing scenarios, is not on a per ES basis but rather on a per PE basis - i.e., a single Leaf MPLS label is used for all single-homed ES's on that PE. This Leaf label is advertised to other PE devices, using a new EVPN Extended Community called E-TREE Extended Community (section 5.1) along with an Ethernet A-D per ES route with ESI of zero and a set of Route Targets (RTs) corresponding to all EVIs on the PE with at least one leaf site per EVI. The set of Ethernet A-D per ES routes may be needed if the number of Route Targets (RTs) that need to be sent exceed the limit on a single route per [RFC7432]. The ESI for the Ethernet A-D per ES route is set to zero to indicate single-homed sites. When a PE receives this special Leaf label in the data path, it blocks the packet if the destination AC is of type Leaf; otherwise, it forwards the packet. 3.2.2 BUM traffic originated from a single-homed site on a root AC In this scenario, the ingress PE does not add any ESI or Leaf label and it operates per [RFC7432] procedures. 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC In this scenario, it is assumed that While different ACs (VLANs) on s/While/while/ Done. the same ES could have different root/leaf designation (some being roots and some being leaves), the same VLAN does have the same root/leaf designation on all PEs on the same ES. Furthermore, it is assumed that there is no forwarding among subnets - ie, the service is EVPN L2 and not EVPN IRB. IRB use case is outside the scope of this document. In such scenarios, If a multicast packet is originated from a leaf s/multicast/multicast or broadcast/ ? Done. AC, then it only needs to carry Leaf label described in section 3.2.1. This label is sufficient in providing the necessary egress filtering of BUM traffic from getting sent to leaf ACs including the leaf AC on the same Ethernet Segment. 3.2.4 BUM traffic originated from a multi-homed site on a root AC In this scenario, both the ingress and egress PE devices follows the procedure defined in [RFC7432] for adding and/or processing an ESI MPLS label. 3.3 E-TREE Traffic Flows for EVPN Per [RFC7387], a generic E-Tree service supports all of the following traffic flows: - Ethernet Unicast from Root to Roots & Leaf - Ethernet Unicast from Leaf to Root - Ethernet Broadcast/Multicast from Root to Roots & Leafs - Ethernet Broadcast/Multicast from Leaf to Roots A particular E-Tree service may need to support all of the above types of flows or only a select subset, depending on the target application. In the case where unicast flows need not be supported, the L2VPN PEs can avoid performing any MAC learning function. In the subsections that follow, we will describe the operation of EVPN to support E-Tree service with and without MAC learning. 3.3.1 E-Tree with MAC Learning The PEs implementing an E-Tree service must perform MAC learning when unicast traffic flows must be supported among Root and Leaf sites. In this case, the PE with Root sites performs MAC learning in the data- s/the PE with Root sites/the PEs with Root sites/ ? (or "PE(s)"...) Done. path over the Ethernet Segments, and advertises reachability in EVPN MAC Advertisement routes. These routes will be imported by all PEs for that EVI (i.e., PEs that have Leaf sites as well as PEs that have Root sites). Similarly, the PEs with Leaf sites perform MAC learning in the data-path over their Ethernet Segments, and advertise reachability in EVPN MAC Advertisement routes. For the scenario described in section 2.1 (or possibly section 2.2), these routes are imported only by PEs with at least one Root site in the EVI - i.e., a PE with only Leaf sites will not import these routes. PEs with Root and/or Leaf sites may use the Ethernet A-D routes for aliasing (in the case of multi-homed segments) and for mass MAC withdrawal per [RFC7432]. To support multicast/broadcast from Root to Leaf sites, either a P2MP tree rooted at the PE(s) with the Root site(s) or ingress replication can be used. The multicast tunnels are set up through the exchange of the EVPN Inclusive Multicast route, as defined in [RFC7432]. To support multicast/broadcast from Leaf to Root sites, ingress replication should be sufficient for most scenarios where there are only a few Roots (typically two). Therefore, in a typical scenario, a root PE needs to support both a P2MP tunnel in transmit direction from itself to leaf PEs and at the same time it needs to support ingress-replication tunnels in receive direction from leaf PEs to itself. In order to signal this efficiently from the root PE, a new composite tunnel type is defined per section 5.3. This new composite tunnel type is advertised by the root PE to simultaneously indicate a P2MP tunnel in transmit direction and an ingress-replication tunnel in the receive direction for the BUM traffic. If the number of Roots is large, P2MP tunnels originated at the PEs with Leaf sites may be used and thus there will be no need to use the modified PMSI tunnel attribute in section 5.2 for composite tunnel type. 3.3.2 E-Tree without MAC Learning The PEs implementing an E-Tree service need not perform MAC learning when the traffic flows between Root and Leaf sites are only multicast or broadcast. In this case, the PEs do not exchange EVPN MAC Advertisement routes. Instead, the Inclusive Multicast Ethernet Tag (IMET) routes are used to support BUM traffic. It's nicer to avoid "acronym soup" when possible. Here the acronym is used only once... Using "Inclusive Multicast Ethernet = Tag route" in these two places is ok I think. Done. The fields of the IMET route are populated per the procedures defined in [RFC7432], and the multicast tunnel setup criteria are as described in the previous section. Just as in the previous section, if the number of PEs with root sites are only a few and thus ingress replication is desired from leaf PEs to these root PEs, then the modified PMSI attribute as defined in section 5.3 should be used. 4 Operation for PBB-EVPN In PBB-EVPN, the PE advertises a Root/Leaf indication along with each B-MAC Advertisement route, to indicate whether the associated B-MAC address corresponds to a Root or a Leaf site. Just like the EVPN case, the new E-TREE Extended Community defined in section [5.1] is advertised with each MAC Advertisement route. In the case where a multi-homed Ethernet Segment has both Root and Leaf sites attached, two B-MAC addresses are advertised: one B-MAC address is per ES as specified in [RFC7623] and implicitly denoting Root, and the other B-MAC address is per PE and explicitly denoting Leaf. The former B-MAC address is not advertised with the E-TREE extended community but the latter B-MAC denoting Leaf is advertised with the new E-TREE extended community where "Leaf-indication" flag is set. In such multi-homing scenarios where and Ethernet Segment has both Root and Leaf ACs, it is assumed that While different ACs (VLANs) on the same ES could have different root/leaf designation (some being roots and some being leaves), the same VLAN does have the same root/leaf designation on all PEs on the same ES. Furthermore, it is assumed that there is no forwarding among subnets - ie, the service is L2 and not IRB. IRB use case is outside the scope of this document. The ingress PE uses the right B-MAC source address depending on whether the Ethernet frame originated from the Root or Leaf AC on that Ethernet Segment. The mechanism by which the PE identifies whether a given frame originated from a Root or Leaf site on the segment is based on the Ethernet Tag associated with the frame. Other mechanisms of identification, beyond the Ethernet Tag, are outside the scope of this document. Furthermore, a PE advertises two special global B-MAC addresses: one for Root and another for Leaf, and tags the Leaf one as such in the MAC Advertisement route. These B-MAC addresses are used as source addresses for traffic originating from single-homed segments. The B- MAC address used for indicating Leaf sites can be the same for both single-homed and multi-homed segments. 4.1 Known Unicast Traffic For known unicast traffic, the PEs perform ingress filtering: On the ingress PE, the C-MAC destination address lookup yields, in addition to the target B-MAC address and forwarding adjacency, a flag which indicates whether the target B-MAC is associated with a Root or a Leaf site. The ingress PE cross-checks this flag with the status of the originating site, and if both are a Leaf, then the packet is not forwarded. 4.2 BUM Traffic For BUM traffic, the PEs must perform egress filtering. When a PE receives a MAC advertisement route (which will be used as a source B- MAC), it updates its Ethernet Segment egress filtering function The "its Ethernet Segment egress filtering function" phrase makes it sounds= like we're talking about a wellknown function defined somewhere. If this is indeed the case, providing a reference would be in order. If not, then explaining what this function is would be required. Changed the sentence to: "When a PE receives a MAC advertisement route (which will be used as a sour= ce B-MAC for BUM traffic), it updates its egress filtering (based on the so= urce B-MAC address), as follows:" (Are you talking about doing something similar to what 3.2 specifies for th= e non-PBB procedures ?) Correct. Similar to 3.2 but based on B-MAC address. (based on the source B-MAC address), as follows: - If the MAC Advertisement route indicates that the advertised B-MAC is a Leaf, and the local Ethernet Segment is a Leaf as well, then the source B-MAC address is added to the B-MAC filtering list. Changed it to: =93=85 is added to its B-MAC list used for egress filtering." Implicitly we can guess that this "filtering list" is a list of things to i= nclude, rather than a list of things to include, but the text should I thin= k be explicit. Changed it as above. - Otherwise, the B-MAC filtering list is not updated. When the egress PE receives the packet, it examines the B-MAC source address to check whether it should filter or forward the frame. Note that this uses the same filtering logic as baseline [RFC7623] and does not require any additional flags in the data-plane. The PE places all Leaf Ethernet Segments of a given bridge domain in a single split-horizon group in order to prevent intra-PE forwarding among Leaf segments. As per a previous comment: isn't this something that should be common betwe= en the EVPN and the PBB-EVPN procedures ? Last paragraph is the same. So, I changed it to: =93Just as in section 3.2, the PE palaces all Leaf Ethernet Segments =85." This split-horizon function applies to BUM traffic. Does it mean "only" ? (if yes, please be explicit, and if no, adding "as well" or something like = that would be better) It applies to both known unicast and BUM. So, I am adding =93as well=94 to = the sentence: 4.3 E-Tree without MAC Learning In scenarios where the traffic of interest is only Multicast and/or broadcast, the PEs implementing an E-Tree service do not need to do any MAC learning. In such scenarios the filtering must be performed on egress PEs. For PBB-EVPN, the handling of such traffic is per section 4.2 without C-MAC learning part of it at both ingress and egress PEs. 5 BGP Encoding This document defines two new BGP Extended Community for EVPN. 5.1 E-TREE Extended Community This Extended Community is a new transitive Extended Community having a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. It is used for leaf indication of known unicast and BUM traffic. For BUM traffic, the Leaf Label field is set to a valid MPLS label and this EC is advertised along with Ethernet A-D per ES route with an ESI of zero to enable egress filtering on disposition PEs per section 3.2.1 and 3.2.3. There is no need to send ESI Label Extended Community when sending Ethernet A-D per ES route with an ESI of zero. For known unicast traffic, the Leaf flag bit is set to one and this EC is advertised along with MAC/IP Advertisement route per section 3.1. The E-TREE Extended Community is encoded as an 8-octet value as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3D0x06 | Sub-Type=3D0x05 | Flags(1 Octet)| Reserved=3D0 = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved=3D0 | Leaf Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The low-order bit of the Flags octet is defined as the "Leaf- Indication" bit. A value of one indicates a Leaf AC/Site. When this EC is advertised along with MAC/IP Advertisement route (for known unicast traffic), the Leaf-Indication flag MUST be set to one and Leaf Label is set to zero. The received PE should ignore Leaf Label and only processes Leaf-Indication flag. A value of zero for Leaf-Indication flag is invalid when sent along with MAC/IP advertisement route and an error should be logged. When this EC is advertised along with Ethernet A-D per ES route (with ESI of zero) for BUM traffic, the Leaf Label MUST be set to a valid MPLS label and the Leaf-Indication flag should be set to zero. The received PE should ignore the Leaf-Indication flag. A non-valid MPLS label when sent along with the Ethernet A-D per ES route, should be logged as an error. 5.2 PMSI Tunnel Attribute [RFC6514] defines PMSI Tunnel attribute which is an optional transitive attribute with the following format: +---------------------------------+ | Flags (1 octet) | +---------------------------------+ | Tunnel Type (1 octets) | +---------------------------------+ | MPLS Label (3 octets) | +---------------------------------+ | Tunnel Identifier (variable) | +---------------------------------+ This draft uses all the fields per existing definition except for the following modifications to the Tunnel Type and Tunnel Identifier: When receiver ingress-replication label is needed, the high-order bit of the tunnel type field (C bit - Composite tunnel bit) is set while the remaining low-order seven bits indicate the tunnel type as before. When this C bit is set, the "tunnel identifier" field would begin with a three-octet label, followed by the actual tunnel identifier for the transmit tunnel. PEs that don't understand the new meaning of the high-order bit would treat the tunnel type as an invalid tunnel type. For the PEs that do understand the new meaning of the high-order, if ingress replication is desired when sending BUM traffic, the PE will use the the label in the Tunnel Identifier field when sending its BUM traffic. I think we should have some text to unambiguously state that: "Using the Co= mposite flag for Tunnel Types 0x00 'no tunnel information present' and 0x06= 'Ingress Replication' is invalid, and should be treated as an invalid tunn= el type on reception". Done. Additionally, since RFC7385 has created a registry for PMSI Tunnel attribut= e tunnel types, taking the most significant bit from this field can't be do= ne without a significant change of how this registry is organized (because= now you can't take value in 0x7b-0x7f without colliding into values which = are Experimental or Reserved). Achieving the above requires an update of RFC7385, so I would suggest addin= g an 8.1 section saying this: --- The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" regis= try in the "Border Gateway Protocol (BGP) Parameters" registry needs to be = updated to reflect the use of the most significant bit to advertise the use= of "composite tunnels" (section 5.2). For this purpose, this document updates RFC7385. The registry is to be updated, by removing the entries for 0xFB-0xFE and 0x= 0F, and replacing them by: - 0x7B-0x7E Reserved for Experimental Use [this document] - 0x7F Reserved [this document] - 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types [this do= cument] The allocation policy for values 0x00 to 0x7A is IETF Review [RFC5226]. The range for experimental use is now 0x7B-0x7E, and value in this range ar= e not to be assigned. The status of 0x7F may only be changed through Standards Action [RFC5226]. Done. Thanks for providing the text. It was very helpful. ---- Additionally to this section 8.1: - the document header needs to specify "Updates: RFC7385" . - the following can be added to the abstract (because reviewer often want t= o see in the abstract the explanation for why an RFC is updated): "This doc= ument makes use of the most significant bit of the scope governed by the IA= NA registry created by RFC7385, and hence updates that RFC accordingly." Done. 6 Acknowledgement We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey Zhang for their valuable comments. 7 Security Considerations Since this draft uses the EVPN constructs of [RFC7432] and [RFC7623], the same security considerations in these drafts are also applicable here. Furthermore, this draft provides additional security check by allowing sites (or ACs) of an EVPN instance to be designated as "Root" or "Leaf" and preventing any traffic exchange among "Leaf" sites of that VPN through ingress filtering for known unicast traffic and egress filtering for BUM traffic. 8 IANA Considerations This document requests the allocation of value 5 in the "EVPN Extended Community Sub-Types" registry defined in [RFC7153] and modification of the registry as follow: The text above should be reformulated to reflect the fact that IANA has alr= eady allocated the value: "IANA has allocated value 5 in the "EVPN Extended= Community Sub-Types" registry defined in [RFC7153] as follow:" SUB-TYPE VALUE NAME Reference 0x05 E-TREE Extended Community This document Done. 9 References 9.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", February, 2015. [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", September, 2015. RFC7385 will have to be added to the list. Done. 9.2 Informative References [RFC7387] Key et al., "A Framework for E-Tree Service over MPLS Network", October 2014. [RFC7153] Rosen et al., "IANA Registries for BGP Extended Communities", March, 2014. This should be I think under Normative References. Done [RFC6514] Aggarwal et al., "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", February, 2012. Ditto. Done Thanks, -Thomas --_000_D3EA14B31B9CAEsajassiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Thomas,

Thanks very much for your thorough review and valuable c= omments. I have resolved all of them and incorporated all the req= uired modifications. Please refer to the comment resolutions below and let me know if there are any further comments. You c= an find the latest rev of the draft with the incorporated changes= in:


Thanks,
Ali

From: Thomas Morin <thomas.morin@orange.com>
Organization: Orange
Date: Monday, August 29, 2016 at 7:= 49 AM
To: "draft-ietf-bess-evpn-etree@ietf.org"= <draft-ietf-bess= -evpn-etree@ietf.org>, Loa Andersson <loa@pi.nu>, "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at C= isco)" <swallow@cisco.com&= gt;, Eric Rosen <erosen@juniper.ne= t>, BESS <bess@ietf.org><= br> Cc: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: shepherd review of draft-i= etf-bess-evpn-etree
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <ssalam@cisco.com>, <ju1738@att.com>, <jdrake@juniper.net>, <sboutros@vmware.com>, &l= t;jorge.rabadan@nokia.com>= ;
Resent-Date: Monday, August 29, 201= 6 at 7:49 AM

Hi,

Here is the review I did while preparing the shepherd write-up for draft-ie= tf-bess-evpn-etree .

There is one thing that stands out: the document uses the most significant = bit of the "PMSI Tunnel Attribute" Tunnel Type  field, which= cant't be done I think without updating the structure of the corresponding= registry (RFC7385).  I suggest how that can be done at the end of this review (a few people Cc'd for this reason).

Please find my comments below...
[...]

2  E-Tree Scenarios and EVPN / PBB-EVPN Support

   In this section, we will categorize support for E-Tree into th= ree
   different scenarios, depending on the nature of the site assoc= iation
   (Root/Leaf) per PE or per Ethernet Segment:

   - Leaf OR Root site(s) per PE

   - Leaf OR Root site(s) per AC

   - Leaf OR Root site(s) per MAC

2.1 Scenario 1: Leaf OR Root site(s) per PE


   In this scenario, a PE may receive traffic from either Root si= tes OR
   Leaf sites for a given MAC-VRF/bridge table, but not both
   concurrently. In other words, a given EVI on a PE is either    associated with a root or leaf.

s/with a root or leaf/with roots or leaves/ ?

Done. Changed = it to =93root(s) or leaf(s)"

The PE may have both Root and Leaf

s/both Root and Leaf/both Roots and Leaves/ ?

In this senten= ce =93Root=94 and =93Leaf=94 are used as adjectives for sites, so= AFAIK, they should remain singular. 

   sites albeit for different EVIs.


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

   Figure 1: Scenario 1

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

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

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

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

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

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


(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. Besides, I don= =92t understand what good does it do to have two MAC-VRFs on the same PE (o= ne for Leafs and another for Roots) because Leafs and Roots need to talk to each other and thus we want them to be in the sa= me MAC-VRF. However, Leafs should not talk among themselves and thus we can= put all the Leaf ACs in a split-horizon group.


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

I don=92t think we need = an explanation because of the above reason but if you think otherwise, then= please suggest a text as what do you think I should add.
If the number of EVIs is very large
   (e.g., more than 64K), then RT type 0 as defined in [RFC4360] = SHOULD
   be used; otherwise, RT type 2 is sufficient [RFC7153].

This is not specific to E-VPN E-TREE, or even to E-VPN, why mention that ?<= br>

Agree, it is not = specific to E-TREE. I will take it out.


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

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

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

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



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

   Figure 2: Scenario 2

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

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

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

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 :-)



2.3 Scenario 3: Leaf OR Root site(s) per MAC

   In this scenario, a PE may receive traffic from both Root AND = Leaf
   sites on a given Attachment Circuit (AC) of an EVI. Since an    Attachment Circuit (ES or ES/VLAN) carries traffic from both R= oot and
   Leaf sites, the granularity at which Root or Leaf sites are    identifies

s/identifies/identified/

Done.

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

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

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

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

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


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

   Figure 3: Scenario 3

3 Operation for EVPN

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

3.1 Known Unicast Traffic

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

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



  This scheme applies to all
   scenarios described in section 2.

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

"MAC route" --> "= ;MAC/IP Advertisement route" ?

I changed it to =93MAC/IP Advertisement route= =94.

then it notify the operator and ignore the leaf indication on

s/notify/notifies/

Do= ne.
   the Ethernet A-D per EVI route.


The procedure above should I think= be rephrased to provide unambiguous interpretation in the case where a giv= en MAC is being announced in more than one MAC/IP advertisement route, possibly carrying a different leaf indicat= ion (and even possibly from different ESes, or from PEs not advertising Eth= ernet A-D route).

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


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

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

The new paragraph will take care of it.

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




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

3.2 BUM Traffic

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

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

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


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

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

   There are four scenarios to consider as follow.

s/follow/follows/
Done.

In all these
   scenarios, the imposition PE imposes the right MPLS label asso= ciated

s/the imposition PE imposes/the in= gress PE imposes/ ?
Done.
   with the originated Ethernet Segment (ES) depending on whether= the
   Ethernet frame originated from a Root or a Leaf site on that E= thernet
   Segment (ESI or Leaf label).

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

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


(side comment: doing the identific= ation based on the source MAC address would seem to allow BUM in the contex= t of 2.3; it is out of the scope of my review to extend the scope of these specs, but I'm curious why it is no= t proposed....)

If we went for per MAC root/leaf identification, th= en this would have expanded the scope of DF election and egress filtering b= eyond that of RFC 7432. Currently, we don=92t have any such requirements fr= om operators and service providers.
Other mechanisms
   for identifying whether an ingress AC is a root or leaf is bey= ond the
   scope of this document.

3.2.1 BUM traffic originated from a single-homed site on a leaf AC

   In this scenario, the ingress PE adds a special MPLS label ind= icating
   a Leaf site. This special Leaf MPLS label, used for single-hom= ing
   scenarios, is not on a per ES basis but rather on a per PE bas= is -
   i.e., a single Leaf MPLS label is used for all single-homed ES= 's on
   that PE. This Leaf label is advertised to other PE devices, us= ing a
   new EVPN Extended Community called E-TREE Extended Community (= section
   5.1) along with an Ethernet A-D per ES route with ESI of zero = and a
   set of Route Targets (RTs) corresponding to all EVIs on the PE= with
   at least one leaf site per EVI. The set of Ethernet A-D per ES= routes
   may be needed if the number of Route Targets (RTs) that need t= o be
   sent exceed the limit on a single route per [RFC7432]. The ESI= for
   the Ethernet A-D per ES route is set to zero to indicate singl= e-homed
   sites.

   When a PE receives this special Leaf label in the data path, i= t
   blocks the packet if the destination AC is of type Leaf; other= wise,
   it forwards the packet.

3.2.2 BUM traffic originated from a single-homed site on a root AC

   In this scenario, the ingress PE does not add any ESI or Leaf = label
   and it operates per [RFC7432] procedures.

3.2.3 BUM traffic originated from a multi-homed site on a leaf AC

   In this scenario, it is assumed that While different ACs (VLAN= s) on

s/While/while/
Done.
   the same ES could have different root/leaf designation (some b= eing
   roots and some being leaves), the same VLAN does have the same=
   root/leaf designation on all PEs on the same ES. Furthermore, = it is
   assumed that there is no forwarding among subnets - ie, the se= rvice
   is EVPN L2 and not EVPN IRB. IRB use case is outside the scope= of
   this document.

   In such scenarios,  If a multicast packet is originated f= rom a leaf

s/multicast/multicast or broadcast= / ?
Done.
   AC, then it only needs to carry Leaf label described in sectio= n
   3.2.1. This label is sufficient in providing the necessary egr= ess
   filtering of BUM traffic from getting sent to leaf ACs includi= ng the
   leaf AC on the same Ethernet Segment.

3.2.4 BUM traffic originated from a multi-homed site on a root AC

   In this scenario, both the ingress and egress PE devices follo= ws the
   procedure defined in [RFC7432] for adding and/or processing an= ESI
   MPLS label.

3.3 E-TREE Traffic Flows for EVPN

   Per [RFC7387], a generic E-Tree service supports all of the fo= llowing
   traffic flows:

        - Ethernet Unicast from Root to = Roots & Leaf
        - Ethernet Unicast from Leaf to = Root
        - Ethernet Broadcast/Multicast f= rom Root to Roots & Leafs
        - Ethernet Broadcast/Multicast f= rom Leaf to Roots

   A particular E-Tree service may need to support all of the abo= ve
   types of flows or only a select subset, depending on the targe= t
   application. In the case where unicast flows need not be suppo= rted,
   the L2VPN PEs can avoid performing any MAC learning function.<= br>
   In the subsections that follow, we will describe the operation= of
   EVPN to support E-Tree service with and without MAC learning.<= br>
3.3.1 E-Tree with MAC Learning

   The PEs implementing an E-Tree service must perform MAC learni= ng when
   unicast traffic flows must be supported among Root and Leaf si= tes. In
   this case, the PE with Root sites performs MAC learning in the= data-

s/the PE with Root sites/the PEs w= ith Root sites/ ?
(or "PE(s)"...) Done.
   path over the Ethernet Segments, and advertises reachability i= n EVPN
   MAC Advertisement routes. These routes will be imported by all= PEs
   for that EVI (i.e., PEs that have Leaf sites as well as PEs th= at have
   Root sites). Similarly, the PEs with Leaf sites perform MAC le= arning
   in the data-path over their Ethernet Segments, and advertise    reachability in EVPN MAC Advertisement routes. For the scenari= o
   described in section 2.1 (or possibly section 2.2), these rout= es are
   imported only by PEs with at least one Root site in the EVI - = i.e., a
   PE with only Leaf sites will not import these routes. PEs with= Root
   and/or Leaf sites may use the Ethernet A-D routes for aliasing= (in
   the case of multi-homed segments) and for mass MAC withdrawal = per
   [RFC7432].

   To support multicast/broadcast from Root to Leaf sites, either= a P2MP
   tree rooted at the PE(s) with the Root site(s) or ingress repl= ication
   can be used. The multicast tunnels are set up through the exch= ange of
   the EVPN Inclusive Multicast route, as defined in [RFC7432].
   To support multicast/broadcast from Leaf to Root sites, ingres= s
   replication should be sufficient for most scenarios where ther= e are
   only a few Roots (typically two). Therefore, in a typical scen= ario, a
   root PE needs to support both a P2MP tunnel in transmit direct= ion
   from itself to leaf PEs and at the same time it needs to suppo= rt
   ingress-replication tunnels in receive direction from leaf PEs= to
   itself. In order to signal this efficiently from the root PE, = a new
   composite tunnel type is defined per section 5.3.  This n= ew composite
   tunnel type is advertised by the root PE to simultaneously ind= icate a
   P2MP tunnel in transmit direction and an ingress-replication t= unnel
   in the receive direction for the BUM traffic.

   If the number of Roots is large, P2MP tunnels originated at th= e PEs
   with Leaf sites may be used and thus there will be no need to = use the
   modified PMSI tunnel attribute in section 5.2 for composite tu= nnel
   type.

3.3.2 E-Tree without MAC Learning

   The PEs implementing an E-Tree service need not perform MAC le= arning
   when the traffic flows between Root and Leaf sites are only mu= lticast
   or broadcast. In this case, the PEs do not exchange EVPN MAC    Advertisement routes. Instead, the Inclusive Multicast Etherne= t Tag
   (IMET) routes are used to support BUM traffic.

It's nicer to avoid "acronym = soup" when possible.
Here the acronym is used only once= ... Using  "Inclusive Multicast Ethernet Tag route" in these= two places is ok I think.
Done.

   The fields of the IMET route are populated per the procedures = defined
   in [RFC7432], and the multicast tunnel setup criteria are as    described in the previous section.

   Just as in the previous section, if the number of PEs with roo= t sites
   are only a few and thus ingress replication is desired from le= af PEs
   to these root PEs, then the modified PMSI attribute as defined= in
   section 5.3 should be used.

4 Operation for PBB-EVPN

   In PBB-EVPN, the PE advertises a Root/Leaf indication along wi= th each
   B-MAC Advertisement route, to indicate whether the associated = B-MAC
   address corresponds to a Root or a Leaf site. Just like the EV= PN
   case, the new E-TREE Extended Community defined in section [5.= 1] is
   advertised with each MAC Advertisement route.

   In the case where a multi-homed Ethernet Segment has both Root= and
   Leaf sites attached, two B-MAC addresses are advertised: one B= -MAC
   address is per ES as specified in [RFC7623] and implicitly den= oting
   Root, and the other B-MAC address is per PE and explicitly den= oting
   Leaf. The former B-MAC address is not advertised with the E-TR= EE
   extended community but the latter B-MAC denoting Leaf is adver= tised
   with the new E-TREE extended community where "Leaf-indica= tion" flag
   is set. In such multi-homing scenarios where and Ethernet Segm= ent has
   both Root and Leaf ACs, it is assumed that While different ACs=
   (VLANs) on the same ES could have different root/leaf designat= ion
   (some being roots and some being leaves), the same VLAN does h= ave the
   same root/leaf designation on all PEs on the same ES. Furtherm= ore, it
   is assumed that there is no forwarding among subnets - ie, the=
   service is L2 and not IRB. IRB use case is outside the scope o= f this
   document.

   The ingress PE uses the right B-MAC source address depending o= n
   whether the Ethernet frame originated from the Root or Leaf AC= on
   that Ethernet Segment. The mechanism by which the PE identifie= s
   whether a given frame originated from a Root or Leaf site on t= he
   segment is based on the Ethernet Tag associated with the frame= . Other
   mechanisms of identification, beyond the Ethernet Tag, are out= side
   the scope of this document.

   Furthermore, a PE advertises two special global B-MAC addresse= s: one
   for Root and another for Leaf, and tags the Leaf one as such i= n the
   MAC Advertisement route. These B-MAC addresses are used as sou= rce
   addresses for traffic originating from single-homed segments. = The B-
   MAC address used for indicating Leaf sites can be the same for= both
   single-homed and multi-homed segments.

4.1 Known Unicast Traffic

   For known unicast traffic, the PEs perform ingress filtering: = On the
   ingress PE, the C-MAC destination address lookup yields, in ad= dition
   to the target B-MAC address and forwarding adjacency, a flag w= hich
   indicates whether the target B-MAC is associated with a Root o= r a
   Leaf site. The ingress PE cross-checks this flag with the stat= us of
   the originating site, and if both are a Leaf, then the packet = is not
   forwarded.

4.2 BUM Traffic

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

The "its Ethernet Segment egr= ess filtering function" phrase makes it sounds like we're talking abou= t a wellknown function defined somewhere.
If this is indeed the case, provid= ing a reference would be in order.
If not, then explaining what this = function is would be required.

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

(Are you talking about doing somet= hing similar to what 3.2 specifies for the non-PBB procedures ?)
Correct. Similar to 3.2 but based on B-MAC address.=

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

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

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

Changed it as above.


   - Otherwise, the B-MAC filtering list is not updated.

   When the egress PE receives the packet, it examines the B-MAC = source
   address to check whether it should filter or forward the frame= . Note
   that this uses the same filtering logic as baseline [RFC7623] = and
   does not require any additional flags in the data-plane.

   The PE places all Leaf Ethernet Segments of a given bridge dom= ain in
   a single split-horizon group in order to prevent intra-PE forw= arding
   among Leaf segments.

As per a previous comment: isn't t= his something that should be common between the EVPN and the PBB-EVPN proce= dures ?
Last paragraph is= the same. So, I changed it to:
=93Just as in section 3.2, the PE palaces all Leaf = Ethernet Segments =85."


This split-horizon function applies to BUM
   traffic.

Does it mean "only" ?
(if yes, please be explicit, and i= f no, adding "as well" or something like that would be better)
It applies to both known unicast and BUM. So, I am = adding =93as well=94 to the sentence:



4.3 E-Tree without MAC Learning

   In scenarios where the traffic of interest is only Multicast a= nd/or
   broadcast, the PEs implementing an E-Tree service do not need = to do
   any MAC learning. In such scenarios the filtering must be perf= ormed
   on egress PEs. For PBB-EVPN, the handling of such traffic is p= er
   section 4.2 without C-MAC learning part of it at both ingress = and
   egress PEs.

5 BGP Encoding

   This document defines two new BGP Extended Community for EVPN.=

5.1 E-TREE Extended Community

   This Extended Community is a new transitive Extended Community= having
   a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. It is= used
   for leaf indication of known unicast and BUM traffic. For BUM<= br>    traffic, the Leaf Label field is set to a valid MPLS label and= this
   EC is advertised along with Ethernet A-D per ES route with an = ESI of
   zero to enable egress filtering on disposition PEs per section= 3.2.1
   and 3.2.3. There is no need to send ESI Label Extended Communi= ty when
   sending Ethernet A-D per ES route with an ESI of zero. For kno= wn
   unicast traffic, the Leaf flag bit is set to one and this EC i= s
   advertised along with MAC/IP Advertisement route per section 3= .1.

   The E-TREE Extended Community is encoded as an 8-octet value a= s
   follows:

        0     &= nbsp;           &nbs= p; 1            = ;       2      =              3<= br>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       | Type=3D0x06     = | Sub-Type=3D0x05 | Flags(1 Octet)|  Reserved=3D0   |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+
       |  Reserved=3D0   |&nbs= p;          Leaf Label &n= bsp;            = ;            |
       +-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+

   The low-order bit of the Flags octet is defined as the "L= eaf-
   Indication" bit. A value of one indicates a Leaf AC/Site.=

   When this EC is advertised along with MAC/IP Advertisement rou= te (for
   known unicast traffic), the Leaf-Indication flag MUST be set t= o one
   and Leaf Label is set to zero. The received PE should ignore L= eaf
   Label and only processes Leaf-Indication flag. A value of zero= for
   Leaf-Indication flag is invalid when sent along with MAC/IP    advertisement route and an error should be logged.

   When this EC is advertised along with Ethernet A-D per ES rout= e (with
   ESI of zero) for BUM traffic, the Leaf Label MUST be set to a = valid
   MPLS label and the Leaf-Indication flag should be set to zero.= The
   received PE should ignore the Leaf-Indication flag. A non-vali= d MPLS
   label when sent along with the Ethernet A-D per ES route, shou= ld be
   logged as an error.

5.2 PMSI Tunnel Attribute

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

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

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

   When receiver ingress-replication label is needed, the high-or= der bit
   of the tunnel type field (C bit - Composite tunnel bit) is set= while
   the remaining low-order seven bits indicate the tunnel type as=
   before. When this C bit is set, the "tunnel identifier&qu= ot; field would
   begin with a three-octet label, followed by the actual tunnel<= br>    identifier for the transmit tunnel.  PEs that don't under= stand the
   new meaning of the high-order bit would treat the tunnel type = as an
   invalid tunnel type. For the PEs that do understand the new me= aning
   of the high-order, if ingress replication is desired when send= ing BUM
   traffic, the PE will use the the label in the Tunnel Identifie= r field
   when sending its BUM traffic.

I think we should have some text t= o unambiguously state that: "Using the Composite flag for Tunnel Types= 0x00 'no tunnel information present' and 0x06 'Ingress Replication' is invalid, and should be treated as an invalid= tunnel type on reception".

Done.

Additionally, since RFC7385 has cr= eated a registry for PMSI Tunnel attribute tunnel types, taking the most si= gnificant bit from this field can't be done without a significant change of how this registry is organized&nbs= p; (because now you can't take value in 0x7b-0x7f without colliding into va= lues which are Experimental or Reserved).

Achieving the above requires an up= date of RFC7385, so I would suggest adding an 8.1 section saying this:

---
The "P-Multicast Service Inte= rface Tunnel (PMSI Tunnel) Tunnel Types" registry in the "Border = Gateway Protocol (BGP) Parameters" registry needs to be updated to reflect the use of the most significant bit to advertise the= use of "composite tunnels" (section 5.2).
 
For this purpose, this document up= dates RFC7385.

The registry is to be updated, by = removing the entries for 0xFB-0xFE and 0x0F, and replacing them by:
- 0x7B-0x7E Reserved for Experimen= tal Use [this document]
- 0x7F  Reserved [this docume= nt]
- 0x80-0xFF Not Allocatable, corre= sponds to Composite tunnel types [this document]

The allocation policy for values 0= x00 to 0x7A is IETF Review [RFC5= 226].
The range for experimental use is = now 0x7B-0x7E, and value in this range are not to be assigned.
The status of 0x7F may only be cha= nged through Standards Action [RFC5= 226].

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

----
 
Additionally to this section 8.1:<= /font>
- the document header needs to spe= cify "Updates: RFC7385" .
- the following can be added to th= e abstract (because reviewer often want to see in the abstract the explanat= ion for why an RFC is updated): "This document makes use of the most significant bit of the scope governed by th= e IANA registry created by RFC7385, and hence updates that RFC accordingly.= "

Done.


6  Acknowledgement

   We would like to thank Dennis Cai, Antoni Przygienda, and Jeff= rey
   Zhang for their valuable comments.

7  Security Considerations

   Since this draft uses the EVPN constructs of [RFC7432] and [RF= C7623],
   the same security considerations in these drafts are also appl= icable
   here. Furthermore, this draft provides additional security che= ck by
   allowing sites (or ACs) of an EVPN instance to be designated a= s
   "Root" or "Leaf" and preventing any traffi= c exchange among "Leaf"
   sites of that VPN through ingress filtering for known unicast = traffic
   and egress filtering for BUM traffic.

8  IANA Considerations

   This document requests the allocation of value 5 in the "= EVPN
   Extended Community Sub-Types" registry defined in [RFC715= 3] and
   modification of the registry as follow:

The text above should be reformula= ted to reflect the fact that IANA has already allocated the value: "IA= NA has allocated value 5 in the "EVPN Extended Community Sub-Types" registry defined in [RFC7153] as follow:"


         SUB-TYPE VALUE  =    NAME         &nbs= p;            &= nbsp; Reference
         0x05   &nbs= p;           E-TREE Exten= ded Community   This document

Done.
 

9  References

9.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", Febru=
ary,
              2015.

   [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
              Ethernet VPN (PBB-EVPN)", September, 2015.

RFC7385 will have to be added to the list.
Done.
9.2  Informative References

   [RFC7387] Key et al., "A Framework for E-Tree Service over MPLS
   Network", October 2014.
=20



   [RFC7153] Rosen et al., "IANA Registries for BGP Extended
   Communities",  March, 2014.

This should be I think under Normative References.
Done
   [RFC6514] Aggarwal et al., "BGP Encodings and Procedures for
   Multicast in MPLS/BGP IP VPNs",  February, 2012.

Ditto.
Done


Thanks,

-Thomas






 --_000_D3EA14B31B9CAEsajassiciscocom_-- From nobody Fri Sep 2 07:00:46 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7215A12D8AD; Fri, 2 Sep 2016 07:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 oP5e_Liz2Me6; Fri, 2 Sep 2016 07:00:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F33312D7D9; Fri, 2 Sep 2016 07:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1472824841; x=1474034441; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=ZrLaCFmCuHNy4lTqyLJsIggaYSg/1fN8fE4fImy4Gq8=; b=Fis/hxjDaJRLXThY2zpFqJV8perll+dqeQVS0EyIBQaVcJCey4dmjn6r JqY4Uyuzq045YsL7pIkV0dsSWH3dpuWvORVlBUcP7M8o7E4yZ8wKQW1SQ OUHDRz2H1ISCxtN6xpxj04Nywc4jqgez31dw2khS46QO76wn19MeS5LU4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJBQCMhMlX/xbLJq1cg1ABAQEBAXV8A?= =?us-ascii?q?aJ/DAEBAQEBAQUBgRCUCoICJIV4ghMUAQIBAQEBAQEBXieFC1YvBgImAmAtiC8?= =?us-ascii?q?OrwGMSgEBAQEGAQEBAQEBIYEFhGKCQIoXK4IvBZlThiGJFYFuToQQgzSFWYxLg?= =?us-ascii?q?3oeNoQ/OjWGWAEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,271,1470700800"; d="scan'208";a="687526492" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2016 14:00:38 +0000 Received: from ams-iwijnand-88111.cisco.com (ams-iwijnand-88111.cisco.com [10.60.202.92]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u82E0cBO028779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2016 14:00:38 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2016 16:00:37 +0200 Message-Id: <1675911D-6E27-477E-A040-FA29C95847C8@cisco.com> To: bess-chairs@ietf.org, draft-ietf-bess-evpn-overlay@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: rtg-dir@ietf.org, bess@ietf.org Subject: [bess] RtgDir review: draft-ietf-bess-evpn-overlay 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, 02 Sep 2016 14:00:45 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-bess-evpn-overlay=20 Reviewer: IJsbrand Wijnands=20 Review Date: 02-09-2016 Intended Status: Standards Track Summary:=20 This document is basically ready for publication. Comments: For somebody who is not following this technology in great detail I = found this interesting and educational to read (ok, I had to read it a = couple of times ;-). The document is well written and seems to document = the solution in enough detail. Major Issues:=20 No major issues found. Minor Issues:=20 No minor issues found. Thx, Ice.= From nobody Fri Sep 2 08:11:19 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9697912D1AC; Fri, 2 Sep 2016 08:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 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=-0.548, 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 r6YG4g492wJp; Fri, 2 Sep 2016 08:11:14 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1364A12D0E3; Fri, 2 Sep 2016 08:11:13 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F2E1F5D86D9; Fri, 2 Sep 2016 17:11:11 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id E41875D8680; Fri, 2 Sep 2016 17:11:11 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Fri, 2 Sep 2016 17:11:11 +0200 To: "Ali Sajassi (sajassi)" , "draft-ietf-bess-evpn-etree@ietf.org" , Loa Andersson , "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" , Eric Rosen , BESS References: <3323ddae-c96f-49a4-2dec-1bfc4ed857dc@orange.com> From: Thomas Morin Organization: Orange Message-ID: <6cb41698-b98b-ecbf-9e34-660771bd3fb8@orange.com> Date: Fri, 2 Sep 2016 17:11:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B643EBB71558E85BDD6ACEAC" 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, 02 Sep 2016 15:11:17 -0000 --------------B643EBB71558E85BDD6ACEAC Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Ali, Thanks for the quick respin, which covers many of the points. (inlined below, skipping the resolved points) 2016-09-02, Ali Sajassi (sajassi): >> sites albeit for different EVIs. > >> >> +---------+ +---------+ >> | PE1 | | PE2 | >> +---+ | +---+ | +------+ | +---+ | +---+ >> |CE1+---ES1----+--+ | | | MPLS | | | +--+----ES2-----+CE2| >> +---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+ >> | |VRF| | | | | |VRF| | >> | | | | | | | | | | +---+ >> | | | | | | | | +--+----ES3-----+CE3| >> | +---+ | +------+ | +---+ | (Leaf) +---+ >> +---------+ +---------+ >> >> Figure 1: Scenario 1 >> >> In such scenario, an EVPN PE implementation MAY provide E-TREE >> service using topology constraint among the PEs belonging to the same > > "topology constraint" is a bit opaque as a term, perhaps "using > tailored BGP RT import/export policies" would be more descriptive > (assuming I understood your intent) > > Done. Changed it to “topology constraint tailored by BGP Route Target > (RT) import/export policies" > (I still think that "topology" is not a helpful terme to use here.) >> EVI. The purpose of this topology constraint is to avoid having PEs >> with only Leaf sites importing and processing BGP MAC routes from >> each other. To support such topology constrain in EVPN, two BGP >> Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is >> associated with the Root sites and the other is associated with the >> Leaf sites. On a per EVI basis, every PE exports the single RT >> associated with its type of site(s). Furthermore, a PE with Root >> site(s) imports both Root and Leaf RTs, whereas a PE with Leaf >> site(s) only imports the Root RT. > > The text seems to imply that the above is sufficient to deliver the > service, but I fail to see what would prevent Leaf-to-Leaf traffic > between Leaves bound to the same MAC-VRF (ES2 and ES3 in firgure1). > Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ? > > > Agree, nice catch!. I changed the first sentence from: > "In such scenario, an EVPN PE implementation MAY provide E-TREE > service using topology constraint among the PEs belonging to the same > EVI." > TO > "In such scenario, topology constraint, provided by BGP Route Target > (RT) import/export policies among the PEs belonging to the same EVI, > can be used to restrict the communications among Leaf PEs." The sentence above does not address my question in fact, which was about communication between Leaf ACs (rather than about communication between Leaf PEs) Let me restate here, more clearly: I fail to see what would prevent Leaf-to-Leaf traffic between **ACs** bound to the same MAC-VRF (ES2 and ES3 in firgure1). Shouldn't the text mention the use of a split-horizon in Leaf MAC-VRFs ? > > (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) > 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. > 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). > However, Leafs should not talk among themselves and thus we can put > all the Leaf ACs in a split-horizon group. Yes, this is the meaning of my initial comment above and it is true independently of whether or not you consider the possibility of having both a Roots MAC-VRF and Leaf MAC-VRF on a same PE. > > If this is not possible, I think the text should explain why. > > I don’t think we need an explanation because of the above reason but > if you think otherwise, then please suggest a text as what do you > think I should add. > Two possibilities: - if indeed there is no possibility of having, for a given E-Tree, both a Root MAC-VRF and a Leaf MAC-VRF, on a given PE, then the text only misses an explanation of why it is not possible - else, if the possibility exists, then it means that the asymetric RT procedure currently described in 2.1 are in fact another way of addressing the scenario supported by 2.2 ("a PE receives traffic from either Root OR Leaf sites (but not both) on a given Attachment Circuit (AC) of an EVI.") - so the content of 2.1 and 2.2 would be two approaches for supporting this scenario and (2.1 --> "Approach A, Root MAC-VRF + Leaf MAC-VRF, two RTs", and 2.2 -> "Approach B, Root/Leaf MAC-VRF, single RT" ) >> >> 2.2 Scenario 2: Leaf OR Root site(s) per AC >> >> In this scenario, a PE receives traffic from either Root OR Leaf >> sites (but not both) on a given Attachment Circuit (AC) of an EVI. In >> other words, an AC (ES or ES/VLAN) is either associated with a Root >> or Leaf (but not both). > > s/with a Root or Leaf/with Roots or Leaves/ ? > > Agree – Changed it to "Root(s) or Leaf(s)" > Re-reading and thinking a bit: "an AC is either a Root AC or a Leaf AC (but not both)" would be much much clearer ? or "an AC is either associated as a Root or as a Leaf (but not both)" perhaps. (but my initial suggestion wasn't great) >> >> +---------+ +---------+ >> | PE1 | | PE2 | >> +---+ | +---+ | +------+ | +---+ | +---+ >> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >> +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ >> | |VRF| | | /IP | | |VRF| | >> | | | | | | | | | | +---+ >> | | | | | | | | +--+---ES2/AC2--+CE3| >> | +---+ | +------+ | +---+ | (Root) +---+ >> +---------+ +---------+ >> >> Figure 2: Scenario 2 >> >> In this scenario, if there are PEs with only root (or leaf) sites per >> EVI, then the RT constrain procedures described in section 2.1 can >> also be used here. However, when a Root site is added to a Leaf PE, >> then that PE needs to process MAC routes from all other Leaf PEs and >> add them to its forwarding table. > > This is the case in 2.1 as well, isn't it ? > > It can start as 2.1 but as soon as you add Root site to a Leaf PE, > then it becomes different (per last sentence of the above para). > I guess we need to first conclude the discussion about the section 2.1, before the above can be discussed efficiently. >> 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 ?) > >> is on a per MAC address. This scenario is considered in >> this draft for EVPN service with only known unicast traffic - i.e., >> there is no BUM traffic. > > "there is no BUM" is quite a bold claim ! := > > Maybe the text should say "no BUM traffic is supported (BUM traffic > will be dropped)" ? > > (possibly "BUM traffic from Leaves will be dropped" would be sufficient ?) > > Changed it to “BUM traffic is not supported in this scenario and it is > dropped”. > adding "by the ingress PE" ? >> >> +---------+ +---------+ >> | PE1 | | PE2 | >> +---+ | +---+ | +------+ | +---+ | +---+ >> |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| >> +---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+ >> | | V | | | /IP | | | V | | >> | | I | | | | | | I | | +---+ >> | | | | | | | | +--+---ES2/AC2--+CE3| >> | +---+ | +------+ | +---+ | (Leaf) +---+ >> +---------+ +---------+ >> >> Figure 3: Scenario 3 >> >> 3 Operation for EVPN >> >> [RFC7432] defines the notion of ESI MPLS label used for split-horizon >> filtering of BUM traffic at the egress PE. Such egress filtering >> capabilities can be leveraged in provision of E-TREE services as seen >> shortly. In other words, [RFC7432] has inherent capability to support >> E-TREE services without defining any new BGP routes but by just >> defining a new BGP Extended Community for leaf indication as shown >> later in this document. >> >> 3.1 Known Unicast Traffic >> >> Since in EVPN, MAC learning is performed in control plane via >> advertisement of BGP routes, the filtering needed by E-TREE service >> for known unicast traffic can be performed at the ingress PE, thus >> providing very efficient filtering and avoiding sending known unicast >> traffic over MPLS/IP core to be filtered at the egress PE as done in >> traditional E-TREE solutions (e.g., E-TREE for VPLS). >> >> To provide such ingress filtering for known unicast traffic, a PE >> MUST indicate to other PEs what kind of sites (root or leaf) its MAC >> addresses are associated with by advertising a leaf indication flag >> (via an Extended Community) along with each of its MAC/IP >> Advertisement route. The lack of such flag indicates that the MAC >> address is associated with a root site. > > > >> This scheme applies to all >> scenarios described in section 2. >> >> Furthermore, for multi-homing scenario of section 2.2, where an AC is >> either root or leaf (but not both), the PE MAY advertise leaf >> indication along with the Ethernet A-D per EVI route. This >> advertisement is used for sanity checking in control-plane to ensure >> that there is no discrepancy in configuration among different PEs of >> the same redundancy group. For example, if a leaf site is multi-homed >> to PE1 an PE2, and PE1 advertises the Ethernet A-D per EVI >> corresponding to this leaf site with the leaf-indication flag but PE2 >> does not, then the receiving PE notifies the operator of such >> discrepancy and ignore the leaf-indication flag on PE1. In other >> words, in case of discrepancy, the multi-homing for that pair of PEs >> is assumed to be in default "root" mode for that or > EVI/VLAN>. The leaf indication flag on Ethernet A-D per EVI route >> tells the receiving PEs that all MAC addresses associated with this >> or are from a leaf site. Therefore, if a >> PE receives a leaf indication for an AC via the Ethernet A-D per EVI >> route but doesn't receive a leaf indication in the corresponding MAC >> route,then it notify the operator and ignore the leaf indication on >> the Ethernet A-D per EVI route. > > > The procedure above should I think be rephrased to provide unambiguous > interpretation in the case where a given MAC is being announced in > more than one MAC/IP advertisement route, possibly carrying a > different leaf indication (and even possibly from different ESes, or > from PEs not advertising Ethernet A-D route). > > Are you talking about MAC move where a MAC can move between Root and > Leaf sites? If so, MAC mobility procedure takes precedence. I have > added the following paragraph toward the end of this section: > "In situation where MAC moves are allowed among Leaf and Root sites > (e.g., non-static MAC), PEs can receive multiple MAC/IP advertisements > routes for the same MAC address with different Leaf/Root indications > (and possibly different ESIs for multi-homing scenarios). In such > situations, MAC mobility procedures take precedence to first identify > the location of the MAC before associating that MAC with a Root or a > Leaf site." > >> >> Tagging MAC addresses with a leaf indication enables remote PEs to >> perform ingress filtering for known unicast traffic - i.e., on the >> ingress PE, the MAC destination address lookup yields, in addition to >> the forwarding adjacency, a flag which indicates whether the target >> MAC is associated with a Leaf site or not. > > Ditto, more or less: the procedure above should I think be rephrased > to provide unambiguous interpretation in the case where a given MAC is > being announced in more than one MAC/IP advertisement route, possibly > carrying a different leaf indication. > > The new paragraph will take care of it. The new paragraph takes care of the MAC mobility case, but there possibly remains the case of a MAC being advertised in two distinct MAC/IP advertisement route for a same dual-homed ES, in the case where this ES is flagged as Leaf or Root consistently from the two dual-homing PEs. > >> The ingress PE cross- >> checks this flag with the status of the originating AC, and if both >> are Leafs, then the packet is not forwarded. > >> To support the above ingress filtering functionality, a new E-TREE >> Extended Community with a Leaf indication flag is introduced [section >> 5.2]. This new Extended Community MUST be advertised with MAC/IP >> Advertisement route and MAY be advertised with an Ethernet A-D per >> EVI route as described above. >> >> 3.2 BUM Traffic >> >> For BUM traffic, it is not possible to perform filtering on the >> ingress PE, as is the case with known unicast, because of the multi- >> destination nature of the traffic. > > Saying "it is not possible" without more explanation is not very > useful (the reader may think about using RPF-like techniques on the > egress PE). > It seems to me more reasonable to formulate things in terms of "This > specification does not provide support for filtering BUM traffic on > the ingress PE", and avoid a sentence like the one above. > > OK, Changed the sentence to: > "This specification does not provide support for filtering BUM traffic > on the ingress PE because it is not possible to perform filtering of > BUM traffic on the ingress PE, as is the case with known unicast > described above, due to the multi-destination nature of BUM traffic." Ok. > > >> As such, the solution relies on >> egress filtering. In order to apply the proper egress filtering, >> which varies based on whether a packet is sent from a Leaf AC or a >> root AC, the MPLS-encapsulated frames MUST be tagged with an >> indication when they originated from a Leaf AC. In other words, leaf >> indication for BUM traffic is done at the granularity of AC. This can >> be achieved in EVPN through the use of a MPLS label where it can be >> used to either identify the Ethernet segment of origin per [RFC7432] >> (i.e., ESI label) or it can be used to indicate that the packet is >> originated from a leaf site (Leaf label). >> >> BUM traffic sent over a P2MP LSP or ingress replication, may need to >> carry an upstream assigned or downstream assigned MPLS label >> (respectively) for the purpose of egress filtering to indicate to the >> egress PEs whether this packet is originated from a leaf AC. >> >> The main difference between downstream and upstream assigned MPLS >> label is that in case of downstream assigned not all egress PE >> devices need to receive the label just like ingress replication >> procedures defined in [RFC7432]. >> >> There are four scenarios to consider as follow. In all these >> scenarios, the imposition PE imposes the right MPLS label associated >> with the originated Ethernet Segment (ES) depending on whether the >> Ethernet frame originated from a Root or a Leaf site on that Ethernet >> Segment (ESI or Leaf label). > >> The mechanism by which the PE identifies >> whether a given frame originated from a Root or a Leaf site on the >> segment is based on the Ethernet Tag associated with the frame (e.g., >> whether the frame received on a leaf or a root AC). > > First comment: it seems that the formulation should also support the > case where an AC does not use .1q. > > Agree. Change the sentence to: > "The mechanism by which the PE identifies whether a given frame > originated from a Root or a Leaf site on the segment is based on the > AC identifier for that segment (e.g., Ethernet Tag of the frame for > 802.1Q frames). Other mechanisms for identifying root or leaf (e.g., > on a per MAC address basis) is beyond the scope of this document." > Ok. > > (side comment: doing the identification based on the source MAC > address would seem to allow BUM in the context of 2.3; it is out of > the scope of my review to extend the scope of these specs, but I'm > curious why it is not proposed....) > > If we went for per MAC root/leaf identification, then this would have > expanded the scope of DF election and egress filtering beyond that of > RFC 7432. Currently, we don’t have any such requirements from > operators and service providers. Does the above mean that scenario 2.3 excludes BUM because the DF Election mechanism would not be compatible with the egress filtering mechanism ? Providing the explanation in 2.3 would I think be helpful. > >> >> 4.2 BUM Traffic >> >> For BUM traffic, the PEs must perform egress filtering. When a PE >> receives a MAC advertisement route (which will be used as a source B- >> MAC), it updates its Ethernet Segment egress filtering function > > The "its Ethernet Segment egress filtering function" phrase makes it > sounds like we're talking about a wellknown function defined somewhere. > If this is indeed the case, providing a reference would be in order. > If not, then explaining what this function is would be required. > > Changed the sentence to: > "When a PE receives a MAC advertisement route (which will be used as a > source B-MAC for BUM traffic), it updates its egress filtering (based > on the source B-MAC address), as follows:" > > (Are you talking about doing something similar to what 3.2 specifies > for the non-PBB procedures ?) > Correct. Similar to 3.2 but based on B-MAC address. Ok. > >> (based on the source B-MAC address), as follows: >> >> - If the MAC Advertisement route indicates that the advertised B-MAC >> is a Leaf, and the local Ethernet Segment is a Leaf as well, then the >> source B-MAC address is added to the B-MAC filtering list. > Changed it to: > “… is added to its B-MAC list used for egress filtering." > > Implicitly we can guess that this "filtering list" is a list of things > to include, rather than a list of things to include, but the text > should I think be explicit. > > Changed it as above. We still don't know if the list is a list of B-MAC to reject or to accept ? (filter out what is specified in the list vs. filter to keep only what is specified in the list) >> >> 5.2 PMSI Tunnel Attribute >> >> [RFC6514] defines PMSI Tunnel attribute which is an optional >> transitive attribute with the following format: >> >> +---------------------------------+ >> | Flags (1 octet) | >> +---------------------------------+ >> | Tunnel Type (1 octets) | >> +---------------------------------+ >> | MPLS Label (3 octets) | >> +---------------------------------+ >> | Tunnel Identifier (variable) | >> +---------------------------------+ >> >> This draft uses all the fields per existing definition except for the >> following modifications to the Tunnel Type and Tunnel Identifier: >> >> When receiver ingress-replication label is needed, the high-order bit >> of the tunnel type field (C bit - Composite tunnel bit) is set while >> the remaining low-order seven bits indicate the tunnel type as >> before. When this C bit is set, the "tunnel identifier" field would >> begin with a three-octet label, followed by the actual tunnel >> identifier for the transmit tunnel. PEs that don't understand the >> new meaning of the high-order bit would treat the tunnel type as an >> invalid tunnel type. For the PEs that do understand the new meaning >> of the high-order, if ingress replication is desired when sending BUM >> traffic, the PE will use the the label in the Tunnel Identifier field >> when sending its BUM traffic. > > > Additionally, since RFC7385 has created a registry for PMSI Tunnel > attribute tunnel types, taking the most significant bit from this > field can't be done without a significant change of how this registry > is organized (because now you can't take value in 0x7b-0x7f without > colliding into values which are Experimental or Reserved). > > Achieving the above requires an update of RFC7385, so I would suggest > adding an 8.1 section saying this: > > --- > The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" > registry in the "Border Gateway Protocol (BGP) Parameters" registry > needs to be updated to reflect the use of the most significant bit to > advertise the use of "composite tunnels" (section 5.2). > > For this purpose, this document updates RFC7385. > > The registry is to be updated, by removing the entries for 0xFB-0xFE > and 0x0F, and replacing them by: > - 0x7B-0x7E Reserved for Experimental Use [this document] > - 0x7F Reserved [this document] > - 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types > [this document] > > The allocation policy for values 0x00 to 0x7A is IETF Review [RFC5226 > ]. > The range for experimental use is now 0x7B-0x7E, and value in this > range are not to be assigned. > The status of 0x7F may only be changed through Standards Action > [RFC5226 ]. > > Done. Thanks for providing the text. It was very helpful. Ok. One thing: in the revised text, line breaks are missing for the bullet list ("- 0x7B-0x7E Reserved for Experimental Use [this document]- 0x7F Reserved [this document]- 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types [this document]"). --------------B643EBB71558E85BDD6ACEAC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi Ali,

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

(inlined below, skipping the resolved points)

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

   sites albeit for different EVIs.


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

   Figure 1: Scenario 1

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

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

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


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

   EVI. The purpose of this topology constraint is to avoid having PEs
   with only  Leaf sites importing and processing BGP MAC routes from
   each other. To support such topology constrain in EVPN, two BGP
   Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
   associated with the Root sites and the other is associated with the
   Leaf sites. On a per EVI basis, every PE exports the single RT
   associated with its type of site(s). Furthermore, a PE with Root
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
   site(s) only imports the Root RT.

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

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

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



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

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.

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


However, Leafs should not talk among themselves and thus we can put all the Leaf ACs in a split-horizon group.

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



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

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


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

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

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

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

Agree – Changed it to "Root(s) or Leaf(s)"


Re-reading and thinking a bit: "an AC is either a Root AC or a Leaf AC (but not both)" would be much much clearer ?
or "an AC is either associated as a Root or as a Leaf (but not both)" perhaps.
(but my initial suggestion wasn't great)


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

   Figure 2: Scenario 2

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

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

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


I guess we need to first conclude the discussion about the section 2.1, before the above can be discussed efficiently.


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 ?)


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

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

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

(possibly "BUM traffic from Leaves will be dropped" would be sufficient ?)

Changed it to “BUM traffic is not supported in this scenario and it is dropped”.


adding "by the ingress PE" ?



                     +---------+            +---------+
                     |   PE1   |            |   PE2   |
    +---+            |  +---+  |  +------+  |  +---+  |            +---+
    |CE1+-----ES1----+--+   |  |  |      |  |  |   +--+---ES2/AC1--+CE2|
    +---+    (Root)  |  | E |  |  | MPLS |  |  | E |  | (Leaf/Root)+---+
                     |  | V |  |  |  /IP |  |  | V |  |
                     |  | I |  |  |      |  |  | I |  |            +---+
                     |  |   |  |  |      |  |  |   +--+---ES2/AC2--+CE3|
                     |  +---+  |  +------+  |  +---+  |   (Leaf)   +---+
                     +---------+            +---------+

   Figure 3: Scenario 3

3 Operation for EVPN

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

3.1 Known Unicast Traffic

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

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



  This scheme applies to all
   scenarios described in section 2.

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


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

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


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

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

The new paragraph will take care of it.

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



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

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

3.2 BUM Traffic

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

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

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

Ok.




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

   BUM traffic sent over a P2MP LSP or ingress replication, may need to
   carry an upstream assigned or downstream assigned MPLS label
   (respectively) for the purpose of egress filtering to indicate to the
   egress PEs whether this packet is originated from a leaf AC.

   The main difference between downstream and upstream assigned MPLS
   label is that in case of downstream assigned not all egress PE
   devices need to receive the label just like ingress replication
   procedures defined in [RFC7432].

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

The mechanism by which the PE identifies
   whether a given frame originated from a Root or a Leaf site on the
   segment is based on the Ethernet Tag associated with the frame (e.g.,
   whether the frame received on a leaf or a root AC).

First comment: it seems that the formulation should also support the case where an AC does not use .1q.

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


Ok.


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

If we went for per MAC root/leaf identification, then this would have expanded the scope of DF election and egress filtering beyond that of RFC 7432. Currently, we don’t have any such requirements from operators and service providers.

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




4.2 BUM Traffic

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

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

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

(Are you talking about doing something similar to what 3.2 specifies for the non-PBB procedures ?)
Correct. Similar to 3.2 but based on B-MAC address.

Ok.

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

   - If the MAC Advertisement route indicates that the advertised B-MAC
   is a Leaf, and the local Ethernet Segment is a Leaf as well, then the
   source B-MAC address is added to the B-MAC filtering list.
Changed it to:
“… is added to its B-MAC list used for egress filtering."

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

Changed it as above.

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




5.2 PMSI Tunnel Attribute

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

         +---------------------------------+
         |  Flags (1 octet)                |
         +---------------------------------+
         |  Tunnel Type (1 octets)         |
         +---------------------------------+
         |  MPLS Label (3 octets)          |
         +---------------------------------+
         |  Tunnel Identifier (variable)   |
         +---------------------------------+

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

   When receiver ingress-replication label is needed, the high-order bit
   of the tunnel type field (C bit - Composite tunnel bit) is set while
   the remaining low-order seven bits indicate the tunnel type as
   before. When this C bit is set, the "tunnel identifier" field would
   begin with a three-octet label, followed by the actual tunnel
   identifier for the transmit tunnel.  PEs that don't understand the
   new meaning of the high-order bit would treat the tunnel type as an
   invalid tunnel type. For the PEs that do understand the new meaning
   of the high-order, if ingress replication is desired when sending BUM
   traffic, the PE will use the the label in the Tunnel Identifier field
   when sending its BUM traffic.
Additionally, since RFC7385 has created a registry for PMSI Tunnel attribute tunnel types, taking the most significant bit from this field can't be done without a significant change of how this registry is organized  (because now you can't take value in 0x7b-0x7f without colliding into values which are Experimental or Reserved).

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

---
The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry in the "Border Gateway Protocol (BGP) Parameters" registry needs to be updated to reflect the use of the most significant bit to advertise the use of "composite tunnels" (section 5.2).
 
For this purpose, this document updates RFC7385.

The registry is to be updated, by removing the entries for 0xFB-0xFE and 0x0F, and replacing them by:
- 0x7B-0x7E Reserved for Experimental Use [this document]
- 0x7F  Reserved [this document]
- 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types [this document]

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

Done. Thanks for providing the text. It was very helpful.

Ok.
One thing: in the revised text, line breaks are missing for the bullet list ("- 0x7B-0x7E Reserved for Experimental Use [this document]- 0x7F Reserved [this document]- 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types [this document]").

--------------B643EBB71558E85BDD6ACEAC-- From nobody Fri Sep 2 14:17:31 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6856312D54F; Fri, 2 Sep 2016 14:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 tGRizgN7aq1q; Fri, 2 Sep 2016 14:17:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A119C12D54C; Fri, 2 Sep 2016 14:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2352; q=dns/txt; s=iport; t=1472851048; x=1474060648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bJz0Pp2jLa2LSdEJallIEdOnw+CH5E/sAvQvUwIbHlY=; b=crRI7wdlhcZzbzM4mFWjRUm7WwrKIPYMgpOwQJMbEg5FkF+TidT18pWK GmiI+b1hKYqM4xGgbCA5zbp5D5J+q8OuOyLB8x0pjgO10Uz3/BsSOKA6/ LSI8UAD+jrTbbH3LD2JilSCB56nUeT7yoEjyLydglAuXChBGWBtqQnTTT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAgBt68lX/5RdJa1cg1ABAQEBAR5Xf?= =?us-ascii?q?Ae4L4ICJIV4AoFgOBQBAgEBAQEBAQFeJ4RhAQEFAQE4NAsMBAIBCBEEAQEBHgk?= =?us-ascii?q?HJwsUCQgCBAENBYhJAQ68CwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhi+ETYocB?= =?us-ascii?q?ZlTAY81j1mMS4N5AR42hD1whXkBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,272,1470700800"; d="scan'208";a="148429061" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2016 21:17:27 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u82LHRaK028497 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Sep 2016 21:17:27 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 2 Sep 2016 16:17:26 -0500 Received: from xch-rcd-011.cisco.com ([173.37.102.21]) by XCH-RCD-011.cisco.com ([173.37.102.21]) with mapi id 15.00.1210.000; Fri, 2 Sep 2016 16:17:26 -0500 From: "Arun Prakash (arprakas)" To: "Jeffrey (Zhaohui) Zhang" , "Swadesh Agrawal (swaagraw)" , Eric Rosen , "Martin Vigoureux" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHR/xbLj8Uv+bSJTEOMVvTdiMvC4aBbJjWAgARj8QCABxTxAA== Date: Fri, 2 Sep 2016 21:17:26 +0000 Message-ID: References: <57B308FA.4090201@nokia.com> <47146bd3-9273-5c85-5d2a-77cd10e7881e@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.70.247.23] Content-Type: text/plain; charset="us-ascii" Content-ID: <329E3A5649256643BB606B2ABFCF6DDA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Nikhil Shetty \(nikshett\)" , "draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org" Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:17:30 -0000 Hi Jeffrey, Thank you for the explanation. Am not clear if this draft is only for L2 or can it be used for L3 as well? What if we have both L2 and L3 multicast ? Thanks Arun On 8/28/16, 7:08 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" wrote: >Hi Swadesh, > >"Enable MVPN safi and enhance it for EVPN" is not a trivial thing that >can be cleanly done on top of MVPN. You'd end up complicating MVPN >procedures a lot for EVPN specific things. Instead, we can apply the same >principles to EVPN safi and procedures, and that's what this draft is >about. > >BTW, we don't yet see the need of the equivalent of MVPN type-5 routes >for EVPN. Draft-sajassi-bess-evpn-igmp-mld-proxy already proposed SMET >route which is very similar to MVPN type-6/7 (to be exact, a combination >of type-4/6/7). That is explained in >draft-zzhang-bess-mvpn-evpn-cmcast-enhancements. > >Jeffrey > >> -----Original Message----- >> From: Swadesh Agrawal (swaagraw) [mailto:swaagraw@cisco.com] >> Sent: Friday, August 26, 2016 3:06 AM >> To: Eric Rosen ; Martin Vigoureux >> ; bess@ietf.org >> Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org >> Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum- >> procedure-updates-03 >>=20 >> Why we need to copy MVPN procedures in EVPN. Why not enable MVPN safi >>and >> enhance it for any EVPN specific requiremnt. Also going in this >>direction >> may require to add 5,6 and 7 routes as well in future. >>=20 >> Regards >> Swadesh >>=20 >> On 8/25/16, 2:22 PM, "Eric C Rosen" wrote: >>=20 >> >Support. >> > >> >MVPN has a number of multicast features that are valuable, but haven't >> >yet been incorporated into EVPN. This draft takes a comprehensive look >> >at the MVPN procedures that provide those features, and shows how to >> >adapt them to EVPN. This seems quite valuable to me, and thus I think >> >the WG should adopt this draft. >> > >> >_______________________________________________ >> >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 Fri Sep 2 14:47:45 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA212D56C; Fri, 2 Sep 2016 14:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KP0yNsffDYY; Fri, 2 Sep 2016 14:47:40 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D0D12B076; Fri, 2 Sep 2016 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E0ntXMSEH6vBhmUU1vItDTvXtypNFF7CDeDaIId3BdY=; b=L6+ZPzhkjqPpdD28pK3bLdIEmI0NAF3jZEBaTVjAZLL08uTViyDPfJ0V4H1Kh2Qahow0y5qd7ZaZBxI79pTuueymQEc2tSVuC7t2ThK+XZlBq3VAeNfEh7D7+wUgeRrl/UWDoLfNJQZXd+5DFZij/SDCJjE6BgaQ66mVAPlPw5Y= Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by CY1PR05MB2186.namprd05.prod.outlook.com (10.166.192.10) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.8; Fri, 2 Sep 2016 21:47:38 +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.0599.008; Fri, 2 Sep 2016 21:47:38 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Arun Prakash (arprakas)" , "Swadesh Agrawal (swaagraw)" , Eric Rosen , "Martin Vigoureux" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHR/xbFfCPq5Uf5cEuX52pcqjLuZ6Ba0mOAgARhkTCAB4ytAIAAB12A Date: Fri, 2 Sep 2016 21:47:38 +0000 Message-ID: References: <57B308FA.4090201@nokia.com> <47146bd3-9273-5c85-5d2a-77cd10e7881e@juniper.net> 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=zzhang@juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 7e378ef5-d491-4a0b-b5bb-08d3d37ac1f2 x-microsoft-exchange-diagnostics: 1; CY1PR05MB2186; 6:qK44+v6Nc11fXXlEZw5K6stnwW2YQdaEu1SpD+AfEjIdzfeZkkJvdGGf82a3/lhaMF1l6dyGBFNI6gL/zz4PHrnxi5+vHZzPZd32bKt1rRKu3nZS60HinyQH3AzqD1fMMeFafUczaVw9hGkClSh4aMDXp4lzfIPaF0yvwKmR1/bCAqqUCLl1jncvNUzEMvXzcz7cgmE9/o2fSvX0mD9St8i5KXuz/hyf51AuRNa6T/wk8SXXKAObhkZhfnw87OpITIsn12GSC6P7i15MJiFeTUTaiQcLLNbkEgp+v5Z5bUElrXypSpvRRLjetWqKIW9OHihyjHWe9hD1NFia8e3dWQ==; 5:xLO2BQKCkZqq/ZJ8NykkS3Ei9SY2SNcWmk8G2ntmtvnoW3jmaySF66aPPwdd+RylI3slfbl0YVekzIPDknYbpDlOaQm5d3+F7gnPEhfq/Z6TumurLMFuShyNcWrhpMxOKGY5e88vQR6gMYkglEtECA==; 24:1Ngrt4I2/85tDe3aFj87eXAqAdXkFXfIB5BdDE0e4soYmUMPscaWv3l35Un+ovj8c9GXnoD31pLXpJFD8tE9AwP8K/FAuJ3GZBTx8MofI2Q=; 7:Ce5a+nMYGgd9ZlOWqD39Ipteg0nnWozyIdnGvXJN691/MSXhPxnp07skLxkuqNQU7Rv4qf507GJDMpRjKhIXbcQQXIDjo4Um/LoSV/r4mLe7rl552DDBrN1WEO+R3MOnoUFhYDad1gUMBuLrslL+Z7Y47SiqqjEvsz4s5ea8V1Xt1rKZg+coHbavE+FBjjnnYkkNztchCyTnXVoGPkUik27lVk+ATaVsVorrAY6eEzH3huBJEjzH3GCsS2xKwff/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2186; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR05MB2186; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2186; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(13464003)(106116001)(345774005)(15975445007)(15650500001)(2501003)(77096005)(92566002)(19580395003)(189998001)(87936001)(305945005)(7696003)(122556002)(7736002)(3280700002)(7846002)(5002640100001)(5001770100001)(86362001)(33656002)(97736004)(1941001)(8676002)(68736007)(93886004)(74316002)(5660300001)(76576001)(19580405001)(2900100001)(230783001)(54356999)(76176999)(81166006)(81156014)(99286002)(50986999)(66066001)(105586002)(8936002)(106356001)(2950100001)(11100500001)(101416001)(102836003)(6116002)(4326007)(3846002)(586003)(10400500002)(2906002)(9686002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2186; 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: 02 Sep 2016 21:47:38.1330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2186 Archived-At: Cc: "Nikhil Shetty \(nikshett\)" , "draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org" Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 21:47:43 -0000 Hi Arun, It's for EVPN only, but using the same concept that has been developed for = L3. If we have both L2 and L3, it would be "ships in the night", and https://to= ols.ietf.org/html/draft-lin-bess-evpn-irb-mcast-02 is one way to optimize t= hings. That draft talked about using MVPN when a bridge domain is not conne= cted everywhere. Jeffrey > -----Original Message----- > From: Arun Prakash (arprakas) [mailto:arprakas@cisco.com] > Sent: Friday, September 02, 2016 5:17 PM > To: Jeffrey (Zhaohui) Zhang ; Swadesh Agrawal > (swaagraw) ; Eric Rosen ; Martin > Vigoureux ; bess@ietf.org > Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org; Nikhil Shetty > (nikshett) > Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum- > procedure-updates-03 >=20 > Hi Jeffrey, >=20 > Thank you for the explanation. Am not clear if this draft is only for L2 > or can it be used for L3 as well? > What if we have both L2 and L3 multicast ? >=20 > Thanks > Arun >=20 > On 8/28/16, 7:08 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > wrote: >=20 > >Hi Swadesh, > > > >"Enable MVPN safi and enhance it for EVPN" is not a trivial thing that > >can be cleanly done on top of MVPN. You'd end up complicating MVPN > >procedures a lot for EVPN specific things. Instead, we can apply the sam= e > >principles to EVPN safi and procedures, and that's what this draft is > >about. > > > >BTW, we don't yet see the need of the equivalent of MVPN type-5 routes > >for EVPN. Draft-sajassi-bess-evpn-igmp-mld-proxy already proposed SMET > >route which is very similar to MVPN type-6/7 (to be exact, a combination > >of type-4/6/7). That is explained in > >draft-zzhang-bess-mvpn-evpn-cmcast-enhancements. > > > >Jeffrey > > > >> -----Original Message----- > >> From: Swadesh Agrawal (swaagraw) [mailto:swaagraw@cisco.com] > >> Sent: Friday, August 26, 2016 3:06 AM > >> To: Eric Rosen ; Martin Vigoureux > >> ; bess@ietf.org > >> Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org > >> Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum- > >> procedure-updates-03 > >> > >> Why we need to copy MVPN procedures in EVPN. Why not enable MVPN safi > >>and > >> enhance it for any EVPN specific requiremnt. Also going in this > >>direction > >> may require to add 5,6 and 7 routes as well in future. > >> > >> Regards > >> Swadesh > >> > >> On 8/25/16, 2:22 PM, "Eric C Rosen" wrote: > >> > >> >Support. > >> > > >> >MVPN has a number of multicast features that are valuable, but haven'= t > >> >yet been incorporated into EVPN. This draft takes a comprehensive > look > >> >at the MVPN procedures that provide those features, and shows how to > >> >adapt them to EVPN. This seems quite valuable to me, and thus I > think > >> >the WG should adopt this draft. > >> > > >> >_______________________________________________ > >> >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 Sun Sep 4 21:24:30 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95F12B158; Sun, 4 Sep 2016 21:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001, 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 koVs-Np81rOT; Sun, 4 Sep 2016 21:24:26 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E1812B171; Sun, 4 Sep 2016 21:24:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2D3714DCF0C0D; Mon, 5 Sep 2016 04:24:17 +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 u854OHLh011494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2016 04:24:18 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u854OHR5028489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Sep 2016 06:24:17 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.252]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 5 Sep 2016 06:24:17 +0200 From: "Rabadan, Jorge (Nokia - US)" To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSApsAMCdK5xth+UW9SG2KGAmE96BpvqEA Date: Mon, 5 Sep 2016 04:24:16 +0000 Message-ID: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.19.0.160817 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_3D34778C5A924E898492F08900B9400Fonnokiacom_" MIME-Version: 1.0 Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 04:24:28 -0000 --_000_3D34778C5A924E898492F08900B9400Fonnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3IuDQpOb3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiByZWxh dGVkIHRvIHRoaXMgZG9jdW1lbnQuDQoNClRoYW5rIHlvdS4NCkpvcmdlDQoNCk9uIDgvMzAvMTYs IDE6NDUgQU0sICJUaG9tYXMgTW9yaW4iIDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86 dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KSGVsbG8gd29ya2luZyBncm91cCwN Cg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1y YWJhZGFuLWJlc3MtZXZwbi1hYy1kZi0wNSBbMV0gYXMgYSBXb3JraW5nIEdyb3VwIGRvY3VtZW50 Lg0KDQpQbGVhc2Ugc3RhdGUgb24gdGhlIGxpc3QgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Ig bm90IChpbiBib3RoIGNhc2VzLA0KcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KDQpU aGlzIHBvbGwgcnVucyB1bnRpbCAqU2VwdGVtYmVyIDE0dGgqLg0KDQpXZSBhcmUgYWxzbyBwb2xs aW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFwcGxpZXMgdG8N CnRoaXMgZG9jdW1lbnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4g Y29tcGxpYW5jZSB3aXRoDQpJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2 OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KKipJZiB5b3UgYXJlIGxpc3RlZCBhcyBh biBhdXRob3Igb3IgY29udHJpYnV0b3IqKiBvZiB0aGlzIGRvY3VtZW50DQpwbGVhc2UgcmVzcG9u ZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJl DQpvZiBhbnkgcmVsZXZhbnQgdW5kaXNjbG9zZWQgSVBSLiBUaGUgZG9jdW1lbnQgd29uJ3QgcHJv Z3Jlc3Mgd2l0aG91dA0KYW5zd2VycyBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0 b3JzLg0KDQpBdCB0aGlzIGRhdGUsIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0 aGlzIERvY3VtZW50Lg0KDQpJZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNv bnRyaWJ1dG9yLCB0aGVuIHBsZWFzZQ0KZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFy ZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQNCmJlZW4gZGlzY2xvc2VkIGluIGNv bmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhhbmsgeW91DQoNCk1hcnRpbiAmIFRob21h cw0KYmVzcyBjaGFpcnMNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmDQoNCg== --_000_3D34778C5A924E898492F08900B9400Fonnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <08A337026D7B724DA4BA1C97C3060306@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5TdXBwb3J0IGFzIGNvLWF1dGhvci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCI+Tm90IGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCI+ VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj5Kb3JnZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIDgvMzAvMTYsIDE6NDUgQU0s ICZxdW90O1Rob21hcyBNb3JpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3Jp bkBvcmFuZ2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBjbSIg aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+SGVsbG8gd29ya2luZyBncm91cCw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhpcyBlbWFpbCBzdGFydHMg YSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5kcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZi0wNSBbMV0g YXMgYSBXb3JraW5nIEdyb3VwIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5QbGVhc2Ugc3RhdGUgb24gdGhlIGxpc3QgaWYgeW91IHN1 cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiBib3RoIGNhc2VzLA0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5wbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVh c29ucykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2si PlRoaXMgcG9sbCBydW5zIHVudGlsICpTZXB0ZW1iZXIgMTR0aCouPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPldlIGFyZSBhbHNvIHBvbGxpbmcgZm9y IGtub3dsZWRnZSBvZiBhbnkgdW5kaXNjbG9zZWQgSVBSIHRoYXQgYXBwbGllcyB0bw0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj50aGlzIGRvY3VtZW50 LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0 aA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5JRVRG IElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+KipJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IqKiBvZiB0 aGlzIGRvY3VtZW50DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPnBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayI+b2YgYW55IHJlbGV2YW50IHVuZGlzY2xvc2VkIElQUi4gVGhlIGRvY3Vt ZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+YW5zd2VycyBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgY29u dHJpYnV0b3JzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5BdCB0aGlzIGRhdGUsIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlz IERvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5JZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0 aGVuIHBsZWFzZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5leHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIg dGhhdCBoYXMgbm90IHlldA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj5iZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5r IHlvdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5N YXJ0aW4gJmFtcDsgVGhvbWFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj5iZXNzIGNoYWlyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYiPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGY8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3D34778C5A924E898492F08900B9400Fonnokiacom_-- From nobody Mon Sep 5 00:31:37 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEA912B029; Mon, 5 Sep 2016 00:31:35 -0700 (PDT) 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.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147306069541.3045.6102193397527910611.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 00:31:35 -0700 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org Subject: [bess] bess - New Meeting Session Request for IETF 97 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 07:31:35 -0000 A new meeting session request has just been submitted by Martin Vigoureux, a Chair of the bess working group. --------------------------------------------------------- Working Group Name: BGP Enabled ServiceS Area Name: Routing Area Session Requester: Martin Vigoureux Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgwg spring idr sfc sidr l3sm Second Priority: mpls pim nvo3 bier pals Third Priority: i2rs Special Requests: not on Friday please (will not be in Seoul that day), thank you --------------------------------------------------------- From nobody Mon Sep 5 07:29:51 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1861412B229; Mon, 5 Sep 2016 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNPnSwLjQuHW; Mon, 5 Sep 2016 07:29:42 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0133.outbound.protection.outlook.com [104.47.34.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0B912B3F4; Mon, 5 Sep 2016 07:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d/Ah+ejpe875kBClLGfGFGpUvytbTi6sJ1u7BZzd5Wk=; b=Zm476jaVrozeieRX+dw0t1lm3TpCL/Qdg89HhNVTtdZ2bHX/kOuolxrWUNbbX/YTfuTDfDytnpRaWzHs0uKCrgYZ+ov2Ybs/PEZw6nL7Ce9SSLuw69PmXv/fSWVTb5972CgwOjRUH3L7k1FJU83wNjh6xKR3dFgtSZm6CQbcea4= Received: from CO2PR05MB683.namprd05.prod.outlook.com (10.141.229.145) by CO2PR05MB681.namprd05.prod.outlook.com (10.141.229.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.8; Mon, 5 Sep 2016 14:29:40 +0000 Received: from CO2PR05MB683.namprd05.prod.outlook.com ([10.141.229.145]) by CO2PR05MB683.namprd05.prod.outlook.com ([10.141.229.145]) with mapi id 15.01.0609.006; Mon, 5 Sep 2016 14:29:40 +0000 From: Wen Lin To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSAprw3i8LmM8dqEavyavqvePbI6BqVYMAgABmGgA= Date: Mon, 5 Sep 2016 14:29:40 +0000 Message-ID: <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> In-Reply-To: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=wlin@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [173.76.179.201] x-ms-office365-filtering-correlation-id: 5360ae0d-8031-445d-0d5e-08d3d599125f x-microsoft-exchange-diagnostics: 1; CO2PR05MB681; 6:7kd2O/l20MgA5pXwYq1L1NhCO7Sjdjf3u0d6vBcE4uu+psIB3N0FwGrLJ55w0MP/BW8qIcg4fGpvhCgdl3WNPC+jhLTsMZUoyXzxwNHZrAvCT3PK4T4+BH2/0KSuXtNvkSUWlcBHIrhzzyKnIUnjFS0XJR3xgSHZiQi82WkIoP3wJh8aA16nu2JU6kY68eailH9r+h31k0VKYV7mcy3aP1UyC25RyG3KuEsn116JO/xe2rY9mmdjO3jTI5FdOt/CluMZMGQz+xVt8/25UwIYfHSyaijsvRSr2cqY9VtdZhNTZCgXIiiYrP+uTDwlAfx++cKZTfb8bUGOYgmlW9oG8A==; 5:OfSyOewFtMlJ2cg3YxNwxfuJTXDlN0vwWT6DKujFTIB8bX3UUiIvG9ripOyxvB1VVe2304GpeAD67puBeHQeVvgOIWqgJqhhdrTvOS0vQ8i91CJl55ZTmxqo2LRWeVVhCbMi1woQLqYmSFO9+91AFw==; 24:4ubFDKW88BK9MNQEyq+HsDBlOORBRmFFrIqtZuo0D5De0rwElW6lv0KZk8QhPEdiCjfraI3OveXy32GZrElGOpOqnY6ikDLHsxfFewChyJk=; 7:44ertJgmM+bkaOPIw6nCQkqcjtHBVMjpy6p25BMVr06qrMS0YNIjt490LQiTFGDBIDCcEFTT7Pn4QbtW2F8xMEiJrWdQCNgSsKFbO9yXvH4oAGGdD/t4Nl8JyokAThA2uAtMMaRJr6U14crE22AHUl58P8kFOpWhqLiWkR9FutSxbrNHLCDl/Qll/AfPkDh0TTEsiAqkgxBtOc2HBujB6u8oYV4tP/mHM9MMPTqaDOJan0OMPghIvE6l+txd78Eo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB681; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB681; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB681; x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(19300405004)(92566002)(33656002)(19617315012)(77096005)(87936001)(11100500001)(19580395003)(4326007)(2900100001)(230783001)(2950100001)(106116001)(83506001)(3846002)(19580405001)(586003)(36756003)(106356001)(102836003)(76176999)(66066001)(68736007)(105586002)(82746002)(86362001)(5001770100001)(19625215002)(8936002)(5002640100001)(2501003)(8676002)(81156014)(81166006)(16236675004)(6116002)(7906003)(3280700002)(5660300001)(7846002)(15975445007)(122556002)(101416001)(83716003)(7736002)(2906002)(54356999)(97736004)(189998001)(3660700001)(99286002)(10400500002)(50986999)(4001350100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB681; H:CO2PR05MB683.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_1B5ABC5B664A412ABF5F37FA06010471junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2016 14:29:40.1991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB681 Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 14:29:49 -0000 --_000_1B5ABC5B664A412ABF5F37FA06010471junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpTdXBwb3J0IGFzIGEgY28tYXV0aG9yLiAgSSBhbSB1bmF3YXJlIG9mIGFueSBJUFIgcmVsYXRl ZCB0byB0aGlzIGRyYWZ0Lg0KDQpUaGFua3MsDQpXZW4NCg0KDQoNCk9uIDgvMzAvMTYsIDE6NDUg QU0sICJUaG9tYXMgTW9yaW4iIDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFz Lm1vcmluQG9yYW5nZS5jb20+PiB3cm90ZToNCg0KSGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhp cyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1yYWJhZGFu LWJlc3MtZXZwbi1hYy1kZi0wNSBbMV0gYXMgYSBXb3JraW5nIEdyb3VwIGRvY3VtZW50Lg0KDQpQ bGVhc2Ugc3RhdGUgb24gdGhlIGxpc3QgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90IChp biBib3RoIGNhc2VzLA0KcGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KDQpUaGlzIHBv bGwgcnVucyB1bnRpbCAqU2VwdGVtYmVyIDE0dGgqLg0KDQpXZSBhcmUgYWxzbyBwb2xsaW5nIGZv ciBrbm93bGVkZ2Ugb2YgYW55IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFwcGxpZXMgdG8NCnRoaXMg ZG9jdW1lbnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoDQpJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg NTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KKipJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBhdXRo b3Igb3IgY29udHJpYnV0b3IqKiBvZiB0aGlzIGRvY3VtZW50DQpwbGVhc2UgcmVzcG9uZCB0byB0 aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlDQpvZiBh bnkgcmVsZXZhbnQgdW5kaXNjbG9zZWQgSVBSLiBUaGUgZG9jdW1lbnQgd29uJ3QgcHJvZ3Jlc3Mg d2l0aG91dA0KYW5zd2VycyBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzLg0K DQpBdCB0aGlzIGRhdGUsIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIERv Y3VtZW50Lg0KDQpJZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1 dG9yLCB0aGVuIHBsZWFzZQ0KZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQNCmJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1h bmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhhbmsgeW91DQoNCk1hcnRpbiAmIFRob21hcw0KYmVz cyBjaGFpcnMNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJh YmFkYW4tYmVzcy1ldnBuLWFjLWRmDQoNCg== --_000_1B5ABC5B664A412ABF5F37FA06010471junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <6730C2971F65544DAD428194C1293EF8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjp3 aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlN1cHBv cnQgYXMgYSBjby1hdXRob3IuJm5ic3A7IEkgYW0gdW5hd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQg dG8gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+V2VuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+T24gOC8zMC8xNiwgMTo0 NSBBTSwgJnF1b3Q7VGhvbWFzIE1vcmluJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGhvbWFz Lm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+SGVsbG8gd29ya2luZyBncm91cCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhpcyBlbWFpbCBzdGFydHMgYSB0d28td2VlayBwb2xs IG9uIGFkb3B0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5kcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZi0wNSBbMV0gYXMgYSBXb3JraW5nIEdy b3VwIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OmJsYWNrIj5QbGVhc2Ugc3RhdGUgb24gdGhlIGxpc3QgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24g b3Igbm90IChpbiBib3RoIGNhc2VzLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5wbGVhc2UgYWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoaXMgcG9sbCBydW5z IHVudGlsICpTZXB0ZW1iZXIgMTR0aCouPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPldlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBh bnkgdW5kaXNjbG9zZWQgSVBSIHRoYXQgYXBwbGllcyB0bw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj50aGlzIGRvY3VtZW50LCB0byBlbnN1cmUgdGhh dCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aA0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5JRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+KipJZiB5b3UgYXJl IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IqKiBvZiB0aGlzIGRvY3VtZW50DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPnBsZWFzZSBy ZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ b2YgYW55IHJlbGV2YW50IHVuZGlzY2xvc2VkIElQUi4gVGhlIGRvY3VtZW50IHdvbid0IHByb2dy ZXNzIHdpdGhvdXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+YW5zd2VycyBmcm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5BdCB0aGlzIGRh dGUsIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIERvY3VtZW50Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5JZiB5b3UgYXJl IG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZQ0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5leHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5iZWVu IGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoYW5rIHlvdTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5NYXJ0aW4gJmFtcDsgVGhv bWFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5iZXNz IGNoYWlyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFi YWRhbi1iZXNzLWV2cG4tYWMtZGYiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGY8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1B5ABC5B664A412ABF5F37FA06010471junipernet_-- From nobody Mon Sep 5 11:17:56 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF7B12B447; Mon, 5 Sep 2016 11:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.001, 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 cpF4Rl9CKTYx; Mon, 5 Sep 2016 11:17:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7ED12B446; Mon, 5 Sep 2016 11:17:52 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0049E442F192; Mon, 5 Sep 2016 18:17:46 +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 u85IHn8r002102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Sep 2016 18:17:50 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u85IHmrB029692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Sep 2016 20:17:48 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.202]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 5 Sep 2016 20:17:48 +0200 From: "Henderickx, Wim (Nokia - BE)" To: Wen Lin , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSApsAMCdK5xth+UW9SG2KGAmE96BpvqEAgAEegQCAAGFEAA== Date: Mon, 5 Sep 2016 18:17:47 +0000 Message-ID: References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> In-Reply-To: <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.19.0.160817 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_D86B9529538C47BCB2A3D92EFA3BEE4Fnokiacom_" MIME-Version: 1.0 Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 18:17:55 -0000 --_000_D86B9529538C47BCB2A3D92EFA3BEE4Fnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3Igbm90IGF3YXJlIG9mIElQUiByZWxhdGVkIHRvIHRoaXMgZHJh ZnQNCg0KRnJvbTogQkVTUyA8YmVzcy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgV2Vu IExpbiA8d2xpbkBqdW5pcGVyLm5ldD4NCkRhdGU6IE1vbmRheSA1IFNlcHRlbWJlciAyMDE2IGF0 IDE2OjI5DQpUbzogIkVYVCAtIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tIiA8dGhvbWFzLm1vcmlu QG9yYW5nZS5jb20+LCAiYmVzc0BpZXRmLm9yZyIgPGJlc3NAaWV0Zi5vcmc+DQpDYzogImRyYWZ0 LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmQGlldGYub3JnIiA8ZHJhZnQtcmFiYWRhbi1iZXNzLWV2 cG4tYWMtZGZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Jlc3NdIFBvbGwgZm9yIGFkb3B0aW9u OiBkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZg0KDQoNClN1cHBvcnQgYXMgYSBjby1hdXRo b3IuICBJIGFtIHVuYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNClRo YW5rcywNCldlbg0KDQoNCg0KT24gOC8zMC8xNiwgMTo0NSBBTSwgIlRob21hcyBNb3JpbiIgPHRo b21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4+IHdy b3RlOg0KDQpIZWxsbyB3b3JraW5nIGdyb3VwLA0KDQpUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13 ZWVrIHBvbGwgb24gYWRvcHRpbmcNCmRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmLTA1IFsx XSBhcyBhIFdvcmtpbmcgR3JvdXAgZG9jdW1lbnQuDQoNClBsZWFzZSBzdGF0ZSBvbiB0aGUgbGlz dCBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvciBub3QgKGluIGJvdGggY2FzZXMsDQpwbGVhc2Ug YWxzbyBzdGF0ZSB0aGUgcmVhc29ucykuDQoNClRoaXMgcG9sbCBydW5zIHVudGlsICpTZXB0ZW1i ZXIgMTR0aCouDQoNCldlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgdW5k aXNjbG9zZWQgSVBSIHRoYXQgYXBwbGllcyB0bw0KdGhpcyBkb2N1bWVudCwgdG8gZW5zdXJlIHRo YXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGgNCklFVEYgSVBSIHJ1 bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMp Lg0KDQoqKklmIHlvdSBhcmUgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvcioqIG9m IHRoaXMgZG9jdW1lbnQNCnBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRl IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUNCm9mIGFueSByZWxldmFudCB1bmRpc2Nsb3Nl ZCBJUFIuIFRoZSBkb2N1bWVudCB3b24ndCBwcm9ncmVzcyB3aXRob3V0DQphbnN3ZXJzIGZyb20g YWxsIHRoZSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMuDQoNCkF0IHRoaXMgZGF0ZSwgbm8gSVBS IGhhcyBiZWVuIGRpc2Nsb3NlZCBhZ2FpbnN0IHRoaXMgRG9jdW1lbnQuDQoNCklmIHlvdSBhcmUg bm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlDQpleHBs aWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMg bm90IHlldA0KYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0K DQpUaGFuayB5b3UNCg0KTWFydGluICYgVGhvbWFzDQpiZXNzIGNoYWlycw0KDQpbMV0gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYN Cg0K --_000_D86B9529538C47BCB2A3D92EFA3BEE4Fnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <0D917EDC92EBCB4EBD5A8296A8343A24@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjp3 aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29s b3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+U3VwcG9ydCBh cyBjby1hdXRob3Igbm90IGF3YXJlIG9mIElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5CRVNT ICZsdDtiZXNzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBXZW4gTGluICZsdDt3 bGluQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXkgNSBTZXB0ZW1iZXIg MjAxNiBhdCAxNjoyOTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7RVhUIC0gdGhvbWFzLm1vcmluQG9y YW5nZS5jb20mcXVvdDsgJmx0O3Rob21hcy5tb3JpbkBvcmFuZ2UuY29tJmd0OywgJnF1b3Q7YmVz c0BpZXRmLm9yZyZxdW90OyAmbHQ7YmVzc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O2RyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFm dC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8 L2I+UmU6IFtiZXNzXSBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4t YWMtZGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5T dXBwb3J0IGFzIGEgY28tYXV0aG9yLiZuYnNwOyBJIGFtIHVuYXdhcmUgb2YgYW55IElQUiByZWxh dGVkIHRvIHRoaXMgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPldlbjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk9uIDgvMzAvMTYs IDE6NDUgQU0sICZxdW90O1Rob21hcyBNb3JpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRo b21hcy5tb3JpbkBvcmFuZ2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6YmxhY2siPkhlbGxvIHdvcmtpbmcgZ3JvdXAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsg cG9sbCBvbiBhZG9wdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+ZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYtMDUgWzFdIGFzIGEgV29ya2lu ZyBHcm91cCBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+UGxlYXNlIHN0YXRlIG9uIHRoZSBsaXN0IGlmIHlvdSBzdXBwb3J0IGFkb3B0 aW9uIG9yIG5vdCAoaW4gYm90aCBjYXNlcywNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+cGxlYXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGlzIHBvbGwg cnVucyB1bnRpbCAqU2VwdGVtYmVyIDE0dGgqLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5XZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ug b2YgYW55IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFwcGxpZXMgdG8NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+dGhpcyBkb2N1bWVudCwgdG8gZW5zdXJl IHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGgNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+SUVURiBJUFIgcnVsZXMg KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPioqSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiogb2YgdGhpcyBkb2N1bWVu dA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5wbGVh c2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3Ug YXJlIGF3YXJlDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPm9mIGFueSByZWxldmFudCB1bmRpc2Nsb3NlZCBJUFIuIFRoZSBkb2N1bWVudCB3b24ndCBw cm9ncmVzcyB3aXRob3V0DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPmFuc3dlcnMgZnJvbSBhbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+QXQgdGhp cyBkYXRlLCBubyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBEb2N1bWVudC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+SWYgeW91 IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ZXhwbGlj aXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5v dCB5ZXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGFuayB5b3U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+TWFydGluICZhbXA7 IFRob21hczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ YmVzcyBjaGFpcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpi bGFjayI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D86B9529538C47BCB2A3D92EFA3BEE4Fnokiacom_-- From nobody Mon Sep 5 15:34:55 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2069112B0B4; Mon, 5 Sep 2016 15:34:50 -0700 (PDT) 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=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 giEm2y-U9Pbm; Mon, 5 Sep 2016 15:34:47 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0082.outbound.protection.outlook.com [104.47.42.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729E012B0C2; Mon, 5 Sep 2016 15:34:47 -0700 (PDT) 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=e41B5PqDl/k693CVJ3n1XLvplVq33gN4wmeCRZEPLN0=; b=Oub4ODs9Owq/eIa9knW+eHOa1LRkFa7uTKOQqpAclEb+XJjWYelmXFV0o/CFWV/qKrat3HTOJGIu3QIuPrNyvcwK94O6FG5pPOJFf1AQz7uMAsgyQg1wnCtn/ByhmPMliiMtmxJehujC2zRNxVzSJnrcOUsyv+iPt/cTXIiMGqo= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0264.namprd18.prod.outlook.com (10.163.72.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Mon, 5 Sep 2016 22:34:45 +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.0599.016; Mon, 5 Sep 2016 22:34:44 +0000 From: Keyur Patel To: "bess-chairs@ietf.org" , "bess@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt Thread-Index: AQHSB8Gs2FQD5hIOJ0qWQD+BeJeuuA== Date: Mon, 5 Sep 2016 22:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [73.241.11.75] x-ms-office365-filtering-correlation-id: 593998c7-8846-453b-bb5f-08d3d5dcd5fb x-microsoft-exchange-diagnostics: 1; BY2PR18MB0264; 6:phJWoX+VOhi338cZ6Xj3p0gRcjyKmC4Q3LctJaF0BiOufmFS2G5QZdlqRvA186/SmySBOp6m2ElYSD8guiTaqbtnTLXCnM5OYybMGstqLZnobzswxNIMbWl4NdNvHjDwPV8z4LtXKY9iLUKh4d+revVp4nwbsfVhwbQBLmZ314xYp7Zb3kzNo0gTTCve8r+CYx3cLvY5+1+NI5DbXI4b12E/D1eXz4RBmOZqzhOOXvx1jzT8ifvWucfaLiHY4ZB74Cr87X3MBeM+tCnXE3DMaB+qMNvYfuQM63uak1k9+ojSZFG2xUtJN7whlY92e3Cc; 5:MuZserjKL8BCCm75pMh6gyO+YimhiS5zDwWadXfqDHbo0mDAeUREaG2KCKe9OT8FPe2/pz0c5jx6sim/PDHkWJvrUl6XnJGXZYBnAMtufKN/1PagiASG/thcSWvOxXZoIKsbKPic4cBrgKc0+LzP8Q==; 24:dwt7DN+ahxvPhM+jE0vEuKpzzgg4azxy1aAaBEszqNL1HO1XY062HGIAexfMo6HjEsMR88VuyVqlXPGEbfJBkO908O2FJ/eSd3nM9LRcWyc=; 7:LcsUrcglqKzHXD/4aKy6Y54bWR4QGAkmlu8GISOqNdBWhftbwYEnmFxtTlbqGeCGcST52B5no2tLzaag/wnQEZSe+2h7tKWe9pv7K/JjsarHRyw19ujmD47QOWvPJ7t02hDyMOdViTyoTO40+KAAmUhagKKz4Cz5b15EZP2g+63EgU8zxDqausWzvcE6PDqFshz10DF+EB1NklYiyGAZVSOoME6Iv8rYYO62rxiNpNopjIF5wzFPanUh4r5AQo7W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0264; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:BY2PR18MB0264; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0264; x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(57704003)(66066001)(2906002)(19627595001)(87936001)(7736002)(7846002)(19627405001)(2900100001)(54356999)(50986999)(17760045003)(3280700002)(16236675004)(3660700001)(122556002)(18206015028)(99936001)(2201001)(86362001)(68736007)(76576001)(101416001)(19625215002)(229853001)(33656002)(106356001)(10400500002)(105586002)(106116001)(230783001)(81156014)(81166006)(8936002)(74316002)(189998001)(107886002)(2501003)(8676002)(99286002)(450100001)(77096005)(102836003)(6116002)(586003)(3846002)(97736004)(9686002)(5001770100001)(5002640100001)(5660300001)(19580395003)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0264; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2016 22:34:43.8318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0264 Archived-At: Subject: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:34:50 -0000 --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: multipart/alternative; boundary="_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_" --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IFFBIHJldmlld2VyIGZvciBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LTA0LnR4dC4NCg0K DQpUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBRQSByZXZpZXdzIGFyZSBpbnRlbmRlZCB0byBiZSBh IHN1cHBvcnQgdG8gaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiBSVEcgQXJlYSBkb2N1bWVudHMgYXMg dGhleSBwYXNzIHRocm91Z2ggdGhlIElFVEYgcHJvY2Vzcy4gVGhpcyBpcyB0aGUgUUEgcmV2aWV3 IGF0IHRoZSB0aW1lIG9mIHRoZSBXRyBkb2N1bWVudCBhZG9wdGlvbiBwb2xsLg0KDQoNClN1bW1h cnk6DQoNCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IEV0aGVybmV0IFZQTiAoRVZQTikg W1JGQzc0MzJdIGNhbiBiZSB1c2VkIGFzIGEgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBPdmVybGF5 IChOVk8pIHNvbHV0aW9uIGFuZCBleHBsb3JlcyB0aGUgdmFyaW91cyB0dW5uZWwgZW5jYXBzdWxh dGlvbiBvcHRpb25zIG92ZXIgSVAgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgRVZQTiBjb250cm9s LXBsYW5lIGFuZCBwcm9jZWR1cmVzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgZm9sbG93aW5nIGVuY2Fw c3VsYXRpb24gb3B0aW9ucyBhcmUgYW5hbHl6ZWQ6IFZYTEFOLCBOVkdSRSwgYW5kIE1QTFMgb3Zl ciBHUkUuDQoNCg0KDQpUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLCBlYXN5IHRvIHJlYWQg YW5kIGZvbGxvdy4gU29tZSBtaW5vciBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Og0KDQoNCkNv bW1lbnRzOg0KDQoNCjEpIEludHJvZHVjdGlvbiBzZWN0aW9uIHN1Z2dlc3RzIHhtcHAgYmFzZWQg YXBwcm9hY2ggYXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIEJHUCBhcyBhIGNvbnRyb2wgcGxhbmUu IEl0IGlzIHVuY2xlYXIgaG93IHRoZSBkcmFmdCBzZWN0aW9ucyA4LTEwIGFuZCB0aGUgc2VjdXJp dHkgc2VjdGlvbiAxMiByZWxhdGUgdG8gdGhlIGFsdGVybmF0aXZlIHNvbHV0aW9uLiBNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUgcmVmZXJlbmNlIGlmIHBvc3NpYmxlIGNvbnNp ZGVyaW5nIHRoZSBkcmFmdCBpcyBzcGVjaWZpYyB0byBCR1AgYXMgYSBjb250cm9sIHBsYW5lLg0K DQoNCjIpIFNlY3Rpb24gNS4xLjIuMSBkZWZpbmVzIEF1dG9kZXJpdmF0aW9uIFJUIHdoaWNoIHN1 Z2dlc3RzIHRoZSB1c2Ugb2YgMiBieXRlIEFTIG51bWJlci4gRG8gd2UgbmVlZCB0byBjb25zaWRl ciA0IGJ5dGUgQVMgbnVtYmVyIGFzIHdlbGw/IFvwn5iKXQ0KDQoNCjMpIFNlY3Rpb24gNjogTWlu b3IgTml0LiBDb25zaWRlciByZXBsYWNpbmcgInN0YXRpY2FsbHkiIHdpdGggImxvY2FsbHkiLg0K DQoNCjQpIFNlY3Rpb24gNy4xOiBUYWxrcyBhYm91dCB1c2luZyBSRCB2YWx1ZSBvZiAwLiBSRCBh cyBhIHR5cGU6dmFsdWUgZmllbGQuIFR5cGUgMCBSRCByZXF1aXJlcyB0aGUgdXNhZ2Ugb2YgMiBi eXRlIEFTIG51bWJlciAocHJpdmF0ZSB2YWx1ZXMgYXJlIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkKSB3 aGljaCBuZWVkcyB0byBiZSAwIGZvciBSRCB2YWx1ZSB0byBiZSAwLiBBUyAwIGFjY29yZGluZyB0 byBJQU5BIGlzIHJlc2VydmVkLiBTZWVtcyB0byBiZSBsaWtlIHVzYWdlIG9mIEFTIDAgaXMgcHJv aGliaXRlZC4gV291bGQgYSByZXNlcnZlIFJEIHZhbHVlIGJlIG1vcmUgYXBwcm9wcmlhdGU/DQoN Cg0KNSkgc2VjdGlvbiA4LjMuMSBkZXNjcmliZXMgdGhlIGRyYWZ0IGNvbnN0cmFpbiB3cnQgbXBs cyBvdmVyIGdyZSB2ZXJzdXMgdnhsYW4vbnZncmUuIFBlcmhhcHMgaXQgd291bGQgYmUgZ3JlYXQg dG8gaGlnaGxpZ2h0IHRoZSBjb25zdHJhaW4gdXBmcm9udCBpbiB0aGUgaW50cm9kdWN0aW9uIHNl Y3Rpb24/DQoNCg0KNikgRG8geW91IG5lZWQgdG8gYWRkIHRleHQgdG8gZGVzY3JpYmUgQVJQL05E IHN1cHByZXNzaW9uIGluIHByZXNlbmNlIG9mIGRlZmF1bHQgcm91dGU/DQoNCg0KQmVzdCBSZWdh cmRzLA0KDQpLZXl1cg0K --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3Vu ZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMt c2VyaWY7Ij4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5 OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGlu ZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5IZWxsbywKCkkgaGF2ZSBiZWVuIHNl bGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIFFBIHJldmlld2VyIGZvciA8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxZW07IGZvbnQtd2VpZ2h0OiBib2xkOyI+ZHJhZnQtaWV0Zi1iZXNz LWV2cG4tb3ZlcmxheS0wNC50eHQuPC9zcGFuPjxicj4KClRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IFFBIHJldmlld3MgYXJlIGludGVuZGVkIHRvIGJlIGEgc3VwcG9ydCB0byBpbXByb3ZlIHRoZSBx dWFsaXR5IG9mIFJURyBBcmVhIGRvY3VtZW50cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCB0aGUgSUVU RiBwcm9jZXNzLiBUaGlzIGlzIHRoZSBRQSByZXZpZXcgYXQgdGhlIHRpbWUgb2YgdGhlIFdHIGRv Y3VtZW50IGFkb3B0aW9uIHBvbGwuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRl cjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBm b250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PGJy PjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6 IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5l LWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPlN1bW1hcnk6PC9wcmU+DQo8cHJlIGNs YXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJp ZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBpbmhlcml0 OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13 cmFwOiBicmVhay13b3JkOyI+PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxl PSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3Jk ZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsg Zm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJh c2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPlRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBFdGhlcm5ldCBWUE4gKEVWUE4pIFtSRkM3NDMyXSBj YW4gYmUgdXNlZCBhcyBhIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheSAoTlZPKSBzb2x1 dGlvbiBhbmQgZXhwbG9yZXMgdGhlIHZhcmlvdXMgdHVubmVsIGVuY2Fwc3VsYXRpb24gb3B0aW9u cyBvdmVyIElQIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIEVWUE4gY29udHJvbC1wbGFuZSBhbmQg cHJvY2VkdXJlcy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBlbmNhcHN1bGF0aW9uIG9w dGlvbnMgYXJlIGFuYWx5emVkOiBWWExBTiwgTlZHUkUsIGFuZCBNUExTIG92ZXIgR1JFLjwvcHJl Pg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJp ZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdo dDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPiA8L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFw IiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBw eDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25v c3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFs aWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7Ij5UaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLCBlYXN5IHRvIHJlYWQgYW5kIGZvbGxv dy4gU29tZSBtaW5vciBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93OjwvcHJlPg0KPHByZSBjbGFz cz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg cGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVy IE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsiPjxicj48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVy OiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5Db21t ZW50czogPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZh bWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHByZSBzdHlsZT0iZm9udC1z aXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3By ZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+MSkgSW50cm9kdWN0aW9uIHNlY3Rpb24gc3VnZ2VzdHMgeG1wcCBiYXNlZCBh cHByb2FjaCBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgQkdQIGFzIGEgY29udHJvbCBwbGFuZS4g SXQgaXMgdW5jbGVhciBob3cgdGhlIGRyYWZ0IHNlY3Rpb25zIDgtMTAgYW5kIHRoZSBzZWN1cml0 eSBzZWN0aW9uIDEyIHJlbGF0ZSB0byB0aGUgYWx0ZXJuYXRpdmUgc29sdXRpb24uIE15IHN1Z2dl c3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoZSByZWZlcmVuY2UgaWYgcG9zc2libGUgY29uc2lk ZXJpbmcgdGhlIGRyYWZ0IGlzIHNwZWNpZmljIHRvIEJHUCBhcyBhIGNvbnRyb2wgcGxhbmUuPC9w cmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+MikgU2VjdGlvbiA1LjEuMi4xIGRlZmlu ZXMgQXV0b2Rlcml2YXRpb24gUlQgd2hpY2ggc3VnZ2VzdHMgdGhlIHVzZSBvZiAyIGJ5dGUgQVMg bnVtYmVyLiBEbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIDQgYnl0ZSBBUyBudW1iZXIgYXMgd2VsbD8g PGltZyBjbGFzcz0iRW1vamlJbnNlcnQiIGlkPSJPV0FFbW9qaTIyNjI0OSIgYWx0PSLwn5iKIiBz dHlsZT0idmVydGljYWwtYWxpZ246IGJvdHRvbTsiIHNyYz0iY2lkOmYwOWQxODM1LTNlZWItNDZm Zi1iZGMyLWYzOWUzNzMwZGYxYSI+IDwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+PHByZSBzdHls ZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsi PjMpIFNlY3Rpb24gNjogTWlub3IgTml0LiBDb25zaWRlciByZXBsYWNpbmcgJnF1b3Q7c3RhdGlj YWxseSZxdW90OyB3aXRoICZxdW90O2xvY2FsbHkmcXVvdDsuPC9wcmU+PHByZSBzdHlsZT0iZm9u dC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48 L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyI+NCkgU2VjdGlvbiA3LjE6IFRhbGtzIGFib3V0IHVzaW5nIFJEIHZhbHVl IG9mIDAuIFJEIGFzIGEgdHlwZTp2YWx1ZSBmaWVsZC4gVHlwZSAwIFJEIHJlcXVpcmVzIHRoZSB1 c2FnZSBvZiAyIGJ5dGUgQVMgbnVtYmVyIChwcml2YXRlIHZhbHVlcyBhcmUgc3Ryb25nbHkgZGlz Y291cmFnZWQpIHdoaWNoIG5lZWRzIHRvIGJlIDAgZm9yIFJEIHZhbHVlIHRvIGJlIDAuIEFTIDAg YWNjb3JkaW5nIHRvIElBTkEgaXMgcmVzZXJ2ZWQuIFNlZW1zIHRvIGJlIGxpa2UgdXNhZ2Ugb2Yg QVMgMCBpcyBwcm9oaWJpdGVkLiBXb3VsZCBhIHJlc2VydmUgUkQgdmFsdWUgYmUgbW9yZSBhcHBy b3ByaWF0ZT8gPC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6 IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+NSkgc2VjdGlvbiA4 LjMuMSBkZXNjcmliZXMgdGhlIGRyYWZ0IGNvbnN0cmFpbiB3cnQgbXBscyBvdmVyIGdyZSB2ZXJz dXMgdnhsYW4vbnZncmUuIFBlcmhhcHMgaXQgd291bGQgYmUgZ3JlYXQgdG8gaGlnaGxpZ2h0IHRo ZSBjb25zdHJhaW4gdXBmcm9udCBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24/PC9wcmU+PHBy ZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+NikgRG8geW91IG5lZWQgdG8gYWRkIHRleHQgdG8g ZGVzY3JpYmUgQVJQL05EIHN1cHByZXNzaW9uIGluIHByZXNlbmNlIG9mIGRlZmF1bHQgcm91dGU/ IDwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPkJlc3QgUmVnYXJkcyw8L3ByZT48 cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyI+S2V5dXI8L3ByZT48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_-- --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: image/png; name="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?=" Content-Description: =?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?= Content-Disposition: inline; filename="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?="; size=488; creation-date="Mon, 05 Sep 2016 22:13:05 GMT"; modification-date="Mon, 05 Sep 2016 22:13:05 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABMAAAATCAYAAAByUDbMAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAYpJREFUeNpi/P//PwO1ACM2wf9njBWAVD4QBwCxApLUAyDeAMQTGU3O PkDRA3QUIxaD+oFUAREOaQQa2IDTMKBB84FUAgk+WwA0MBFmGBOaixJIDKYEoD6465igBjkge+3C rW94TUCTr4eGMdxl8TCZxMYHDIZR1xk2HPiA1SCQOEgepA4J5CMbFgAPhM1vwfTFW9+xGgYTh6lD 1s8IdKIAkH4PEz1w9jOYVpBiZ1CQZMMw7MHzXwwPnv0Esx2MeRESxmcYWYCUAbJiFAVYAMgCbJbA vPmAWjmACZqS4aHdOOs5wdgEBcWE5a8Y0HIGPAIOwETtjXkYJqIqxAAgeQM1ThTzkQ2biB5mC7a8 xZ7kgeICvMzoYTsRJaMDY3U9chIBpaMHz34xxPsKgwMcFIsLgckB5KL+YllkgyYAg6oQJW9Ck8h+ 5NgFhd3GAx/humAGI2cGIHYEGvYBW0YHGTgf2YX4MjkQF4IMwlkEIeXVfByGwsqzAwTLMywGg7wN cvED9AIR3TCAAAMAqh+p+YMVeBQAAAAASUVORK5CYII= --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_-- From nobody Mon Sep 5 17:04:44 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01E12B483; Mon, 5 Sep 2016 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZTPaMN2m5Up; Mon, 5 Sep 2016 17:04:32 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 779A912B47D; Mon, 5 Sep 2016 17:04:32 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id C5344B82B306B; Tue, 6 Sep 2016 00:04:27 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u8604UtR024579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 00:04:30 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u8604TS8022996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Sep 2016 00:04:29 GMT Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.189]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 5 Sep 2016 20:04:29 -0400 From: "Oya Luengo, Roberto (Nokia - US)" To: "Henderickx, Wim (Nokia - BE)" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSBy1swpGst67FakiOcHF6n6diEqBrOJIAgAA/vICAAB3QtQ== Date: Tue, 6 Sep 2016 00:04:28 +0000 Message-ID: References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B2441E96D09A4C36B7F4246AB2819156nokiacom_" MIME-Version: 1.0 Archived-At: Cc: "EXT - thomas.morin@orange.com" , "bess@ietf.org" , Wen Lin , "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 00:04:35 -0000 --_000_B2441E96D09A4C36B7F4246AB2819156nokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support On Sep 5, 2016, at 11:18 AM, Henderickx, Wim (Nokia - BE) > wrote: Support as co-author not aware of IPR related to this draft From: BESS > on behalf = of Wen Lin > Date: Monday 5 September 2016 at 16:29 To: "EXT - thomas.morin@orange.com" >, "bess@ietf.org" > Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" > Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Support as a co-author. I am unaware of any IPR related to this draft. Thanks, Wen On 8/30/16, 1:45 AM, "Thomas Morin" > wrote: Hello working group, This email starts a two-week poll on adopting draft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document. Please state on the list if you support adoption or not (in both cases, please also state the reasons). This poll runs until *September 14th*. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). **If you are listed as an author or contributor** of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The document won't progress without answers from all the authors and contributors. At this date, no IPR has been disclosed against this Document. If you are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thank you Martin & Thomas bess chairs [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-ac-df _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess --_000_B2441E96D09A4C36B7F4246AB2819156nokiacom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support

On Sep 5, 2016, at 11:18 AM, Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com> wrote:

Support as co-author not aware of IPR related to this draft

 

 

 

Support as a co-author.  I am unaware of any IPR related to this draf= t.

 

Thanks,

Wen

 

 

&= nbsp;

 

Hel= lo working group,

 

Thi= s email starts a two-week poll on adopting

dra= ft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document.<= /o:p>

 

Ple= ase state on the list if you support adoption or not (in both cases,

ple= ase also state the reasons).

 

Thi= s poll runs until *September 14th*.

 

We = are also polling for knowledge of any undisclosed IPR that applies to

thi= s document, to ensure that IPR has been disclosed in compliance with

IET= F IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

 

**I= f you are listed as an author or contributor** of this document

ple= ase respond to this email and indicate whether or not you are aware

of = any relevant undisclosed IPR. The document won't progress without

ans= wers from all the authors and contributors.

 

At = this date, no IPR has been disclosed against this Document.

 

If = you are not listed as an author or contributor, then please

exp= licitly respond only if you are aware of any IPR that has not yet

bee= n disclosed in conformance with IETF rules.

 

Tha= nk you

 

Mar= tin & Thomas

bes= s chairs

 

 

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ie= tf.org/mailman/listinfo/bess
--_000_B2441E96D09A4C36B7F4246AB2819156nokiacom_-- From nobody Mon Sep 5 20:44:45 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655D12B111; Mon, 5 Sep 2016 20:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 Ll18kfvNHwWH; Mon, 5 Sep 2016 20:44:41 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 88CE512B104; Mon, 5 Sep 2016 20:44:41 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 73AC9DA61E566; Tue, 6 Sep 2016 03:44:39 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u863idx6015126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 03:44:39 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u863idBs024157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Sep 2016 03:44:39 GMT Received: from SG70YWXCHHUB03.zap.alcatel-lucent.com (135.253.2.37) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Sep 2016 23:44:38 -0400 Received: from SG70XWXCHMBA02.zap.alcatel-lucent.com ([169.254.2.81]) by SG70YWXCHHUB03.zap.alcatel-lucent.com ([135.253.2.37]) with mapi id 14.03.0195.001; Tue, 6 Sep 2016 11:44:34 +0800 From: "Nagaraj, Kiran (Nokia - US)" To: "Henderickx, Wim (Nokia - BE)" , Wen Lin , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSApsT83h017F5+0q+m6TfdXZzG6Bpz2cAgACpJQCAAD+9gIABJGYw Date: Tue, 6 Sep 2016 03:44:34 +0000 Message-ID: References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: multipart/alternative; boundary="_000_E55424F3BF74B442930080C4B8471D8AFC9F56D5SG70XWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 03:44:44 -0000 --_000_E55424F3BF74B442930080C4B8471D8AFC9F56D5SG70XWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3Igbm90IGF3YXJlIG9mIElQUiByZWxhdGVkIHRvIHRoaXMgZHJh ZnQNClRoYW5rcw0KS2lyYW4NCg0KRnJvbTogSGVuZGVyaWNreCwgV2ltIChOb2tpYSAtIEJFKSBb bWFpbHRvOndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVy IDA1LCAyMDE2IDExOjE4IEFNDQpUbzogV2VuIExpbjsgRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5n ZS5jb207IGJlc3NAaWV0Zi5vcmcNCkNjOiBkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZkBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtiZXNzXSBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtcmFi YWRhbi1iZXNzLWV2cG4tYWMtZGYNCg0KU3VwcG9ydCBhcyBjby1hdXRob3Igbm90IGF3YXJlIG9m IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQNCg0KRnJvbTogQkVTUyA8YmVzcy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgV2VuIExp biA8d2xpbkBqdW5pcGVyLm5ldDxtYWlsdG86d2xpbkBqdW5pcGVyLm5ldD4+DQpEYXRlOiBNb25k YXkgNSBTZXB0ZW1iZXIgMjAxNiBhdCAxNjoyOQ0KVG86ICJFWFQgLSB0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbTxtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+IiA8dGhvbWFzLm1vcmluQG9y YW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPj4sICJiZXNzQGlldGYub3Jn PG1haWx0bzpiZXNzQGlldGYub3JnPiIgPGJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NAaWV0Zi5v cmc+Pg0KQ2M6ICJkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZkBpZXRmLm9yZzxtYWlsdG86 ZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGZAaWV0Zi5vcmc+IiA8ZHJhZnQtcmFiYWRhbi1i ZXNzLWV2cG4tYWMtZGZAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFj LWRmQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbYmVzc10gUG9sbCBmb3IgYWRvcHRpb246IGRy YWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmDQoNCg0KU3VwcG9ydCBhcyBhIGNvLWF1dGhvci4g IEkgYW0gdW5hd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCg0KVGhhbmtz LA0KV2VuDQoNCg0KDQpPbiA4LzMwLzE2LCAxOjQ1IEFNLCAiVGhvbWFzIE1vcmluIiA8dGhvbWFz Lm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPj4gd3JvdGU6 DQoNCkhlbGxvIHdvcmtpbmcgZ3JvdXAsDQoNClRoaXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsg cG9sbCBvbiBhZG9wdGluZw0KZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYtMDUgWzFdIGFz IGEgV29ya2luZyBHcm91cCBkb2N1bWVudC4NCg0KUGxlYXNlIHN0YXRlIG9uIHRoZSBsaXN0IGlm IHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gYm90aCBjYXNlcywNCnBsZWFzZSBhbHNv IHN0YXRlIHRoZSByZWFzb25zKS4NCg0KVGhpcyBwb2xsIHJ1bnMgdW50aWwgKlNlcHRlbWJlciAx NHRoKi4NCg0KV2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSB1bmRpc2Ns b3NlZCBJUFIgdGhhdCBhcHBsaWVzIHRvDQp0aGlzIGRvY3VtZW50LCB0byBlbnN1cmUgdGhhdCBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aA0KSUVURiBJUFIgcnVsZXMg KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoN CioqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yKiogb2YgdGhp cyBkb2N1bWVudA0KcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUgd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZQ0Kb2YgYW55IHJlbGV2YW50IHVuZGlzY2xvc2VkIElQ Ui4gVGhlIGRvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQNCmFuc3dlcnMgZnJvbSBhbGwg dGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycy4NCg0KQXQgdGhpcyBkYXRlLCBubyBJUFIgaGFz IGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBEb2N1bWVudC4NCg0KSWYgeW91IGFyZSBub3Qg bGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UNCmV4cGxpY2l0 bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3Qg eWV0DQpiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRo YW5rIHlvdQ0KDQpNYXJ0aW4gJiBUaG9tYXMNCmJlc3MgY2hhaXJzDQoNClsxXSBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZg0KDQo= --_000_E55424F3BF74B442930080C4B8471D8AFC9F56D5SG70XWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bh bjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQt d2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlN1cHBvcnQgYXMgY28tYXV0aG9yIG5vdCBhd2FyZSBvZiBJUFIgcmVsYXRlZCB0byB0aGlzIGRy YWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5LaXJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEhlbmRlcmlja3gsIFdpbSAo Tm9raWEgLSBCRSkgW21haWx0bzp3aW0uaGVuZGVyaWNreEBub2tpYS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTYgMTE6MTggQU08YnI+DQo8Yj5Ubzo8 L2I+IFdlbiBMaW47IEVYVCAtIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tOyBiZXNzQGlldGYub3Jn PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZkBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Jlc3NdIFBvbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC1y YWJhZGFuLWJlc3MtZXZwbi1hYy1kZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3VwcG9ydCBhcyBjby1h dXRob3Igbm90IGF3YXJlIG9mIElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJFU1MgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmciPmJlc3MtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBXZW4gTGluICZsdDs8YSBocmVmPSJtYWlsdG86d2xpbkBqdW5pcGVyLm5l dCI+d2xpbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSA1IFNl cHRlbWJlciAyMDE2IGF0IDE2OjI5PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtFWFQgLSA8YSBocmVm PSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBvcmFuZ2UuY29t PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj50 aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YmVz c0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpi ZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZkBpZXRmLm9yZyI+ ZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGZAaWV0Zi5vcmciPmRyYWZ0 LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtiZXNzXSBQb2xsIGZvciBhZG9wdGlvbjogZHJhZnQtcmFiYWRhbi1iZXNzLWV2 cG4tYWMtZGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4mbmJzcDsgSSBhbSB1bmF3YXJl IG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZW48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjpibGFjayI+T24gOC8zMC8xNiwgMTo0NSBBTSwgJnF1b3Q7VGhvbWFzIE1vcmluJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20iPnRob21hcy5tb3JpbkBv cmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+SGVsbG8gd29ya2luZyBncm91cCw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhpcyBlbWFp bCBzdGFydHMgYSB0d28td2VlayBwb2xsIG9uIGFkb3B0aW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5kcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1k Zi0wNSBbMV0gYXMgYSBXb3JraW5nIEdyb3VwIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5QbGVhc2Ugc3RhdGUgb24gdGhlIGxpc3Qg aWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiBib3RoIGNhc2VzLA0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5wbGVhc2UgYWxzbyBzdGF0 ZSB0aGUgcmVhc29ucykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPlRoaXMgcG9sbCBydW5zIHVudGlsICpTZXB0ZW1iZXIgMTR0aCouPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPldlIGFyZSBhbHNvIHBv bGxpbmcgZm9yIGtub3dsZWRnZSBvZiBhbnkgdW5kaXNjbG9zZWQgSVBSIHRoYXQgYXBwbGllcyB0 bw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj50aGlz IGRvY3VtZW50LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJs YWNrIj5JRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+KipJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0 b3IqKiBvZiB0aGlzIGRvY3VtZW50DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPnBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgYW5kIGluZGljYXRl IHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+b2YgYW55IHJlbGV2YW50IHVuZGlzY2xvc2VkIElQUi4g VGhlIGRvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+YW5zd2VycyBmcm9tIGFsbCB0aGUgYXV0aG9y cyBhbmQgY29udHJpYnV0b3JzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5BdCB0aGlzIGRhdGUsIG5vIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdh aW5zdCB0aGlzIERvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5JZiB5b3UgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB0aGVuIHBsZWFzZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj5leHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9m IGFueSBJUFIgdGhhdCBoYXMgbm90IHlldA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5iZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElF VEYgcnVsZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPlRoYW5rIHlvdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OmJsYWNrIj5NYXJ0aW4gJmFtcDsgVGhvbWFzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOmJsYWNrIj5iZXNzIGNoYWlyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGY8L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E55424F3BF74B442930080C4B8471D8AFC9F56D5SG70XWXCHMBA02z_-- From nobody Tue Sep 6 02:25:08 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF112B236; Tue, 6 Sep 2016 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.508, 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 tIok2UsHs1nC; Tue, 6 Sep 2016 02:25:05 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 11AAC12B2A9; Tue, 6 Sep 2016 02:25:04 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4B3737CC004; Tue, 6 Sep 2016 11:25:03 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 3F5697CC003; Tue, 6 Sep 2016 11:25:03 +0200 (CEST) Received: from [10.193.71.12] (10.193.71.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Tue, 6 Sep 2016 11:25:02 +0200 To: References: From: Thomas Morin Organization: Orange Message-ID: Date: Tue, 6 Sep 2016 11:25:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-dhjain-bess-bgp-l3vpn-yang@ietf.org, "dhjain@cisco.com" Subject: [bess] Adopted: draft-dhjain-bess-bgp-l3vpn-yang-02 ! (was Re: Call for adoption: draft-dhjain-bess-bgp-l3vpn-yang-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, 06 Sep 2016 09:25:07 -0000 Hi working group, draft-dhjain-bess-bgp-l3vpn-yang is adopted as a working group document. Can authors please repost as **draft-ietf-bess-l3vpn-yang-00** ? Thanks, -Thomas 2016-08-16, Thomas Morin: > Hello working group, > > This email starts a two-week poll on adopting > draft-dhjain-bess-bgp-l3vpn-yang [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 **August 30th**. > > *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-dhjain-bess-bgp-l3vpn-yang From vinod.prabhu@nokia.com Tue Sep 6 06:36:14 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25DD12B4A1; Tue, 6 Sep 2016 06:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKojc-W4n0Vs; Tue, 6 Sep 2016 06:36:09 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 E228812B50F; Tue, 6 Sep 2016 06:22:50 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 8479273F722D4; Tue, 6 Sep 2016 13:22:47 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u86DMnJY013968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 13:22:49 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u86DLifC026776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Sep 2016 13:22:49 GMT Received: from [135.121.197.231] (135.5.27.16) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 6 Sep 2016 09:22:22 -0400 Message-ID: <57CEC30D.2070302@nokia.com> Date: Tue, 6 Sep 2016 09:22:21 -0400 From: Vinod Prabhu User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Nagaraj, Kiran (Nokia - US)" , "Henderickx, Wim (Nokia - BE)" , Wen Lin , "EXT - thomas.morin@orange.com" , "bess@ietf.org" References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030603090508030701090905" X-Originating-IP: [135.5.27.16] Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 13:51:19 -0000 --------------030603090508030701090905 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Support as co-author. I'm not aware of any IPR related to this draft. Thanks, Vinod On 9/5/2016 11:44 PM, Nagaraj, Kiran (Nokia - US) wrote: > > Support as co-author not aware of IPR related to this draft > > Thanks > > Kiran > > *From:*Henderickx, Wim (Nokia - BE) [mailto:wim.henderickx@nokia.com] > *Sent:* Monday, September 05, 2016 11:18 AM > *To:* Wen Lin; EXT - thomas.morin@orange.com; bess@ietf.org > *Cc:* draft-rabadan-bess-evpn-ac-df@ietf.org > *Subject:* Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df > > Support as co-author not aware of IPR related to this draft > > *From: *BESS > on > behalf of Wen Lin > > *Date: *Monday 5 September 2016 at 16:29 > *To: *"EXT - thomas.morin@orange.com " > >, > "bess@ietf.org " > > *Cc: *"draft-rabadan-bess-evpn-ac-df@ietf.org > " > > > *Subject: *Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df > > Support as a co-author. I am unaware of any IPR related to this draft. > > Thanks, > > Wen > > On 8/30/16, 1:45 AM, "Thomas Morin" > wrote: > > Hello working group, > > This email starts a two-week poll on adopting > > draft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document. > > Please state on the list if you support adoption or not (in both > cases, > > please also state the reasons). > > This poll runs until *September 14th*. > > We are also polling for knowledge of any undisclosed IPR that > applies to > > this document, to ensure that IPR has been disclosed in compliance > with > > IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > **If you are listed as an author or contributor** of this document > > please respond to this email and indicate whether or not you are > aware > > of any relevant undisclosed IPR. The document won't progress without > > answers from all the authors and contributors. > > At this date, no IPR has been disclosed against this Document. > > If you are not listed as an author or contributor, then please > > explicitly respond only if you are aware of any IPR that has not yet > > been disclosed in conformance with IETF rules. > > Thank you > > Martin & Thomas > > bess chairs > > [1] https://datatracker.ietf.org/doc/draft-rabadan-bess-evpn-ac-df > --------------030603090508030701090905 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Support as co-author. I'm not aware of any IPR related to this draft.
Thanks,
Vinod

On 9/5/2016 11:44 PM, Nagaraj, Kiran (Nokia - US) wrote:

Support as co-author not aware of IPR related to this draft

Thanks

Kiran

 

From: Henderickx, Wim (Nokia - BE) [mailto:wim.henderickx@nokia.com]
Sent: Monday, September 05, 2016 11:18 AM
To: Wen Lin; EXT - thomas.morin@orange.com; bess@ietf.org
Cc: draft-rabadan-bess-evpn-ac-df@ietf.org
Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df

 

Support as co-author not aware of IPR related to this draft

 

From: BESS <bess-bounces@ietf.org> on behalf of Wen Lin <wlin@juniper.net>
Date: Monday 5 September 2016 at 16:29
To: "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>, "bess@ietf.org" <bess@ietf.org>
Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" <draft-rabadan-bess-evpn-ac-df@ietf.org>
Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df

 

 

Support as a co-author.  I am unaware of any IPR related to this draft.

 

Thanks,

Wen

 

 

 

On 8/30/16, 1:45 AM, "Thomas Morin" <thomas.morin@orange.com> wrote:

 

Hello working group,

 

This email starts a two-week poll on adopting

draft-rabadan-bess-evpn-ac-df-05 [1] as a Working Group document.

 

Please state on the list if you support adoption or not (in both cases,

please also state the reasons).

 

This poll runs until *September 14th*.

 

We are also polling for knowledge of any undisclosed IPR that applies to

this document, to ensure that IPR has been disclosed in compliance with

IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

 

**If you are listed as an author or contributor** of this document

please respond to this email and indicate whether or not you are aware

of any relevant undisclosed IPR. The document won't progress without

answers from all the authors and contributors.

 

At this date, no IPR has been disclosed against this Document.

 

If you are not listed as an author or contributor, then please

explicitly respond only if you are aware of any IPR that has not yet

been disclosed in conformance with IETF rules.

 

Thank you

 

Martin & Thomas

bess chairs

 

 


--------------030603090508030701090905-- From nobody Tue Sep 6 06:52:04 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046A812B0CD; Tue, 6 Sep 2016 06:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pntYrUrIX0iI; Tue, 6 Sep 2016 06:52:00 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 86E8012B1D0; Tue, 6 Sep 2016 06:50:36 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u86DjfsC006046; Tue, 6 Sep 2016 09:50:36 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 259xnwgvdy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Sep 2016 09:50:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u86DoYQA020625; Tue, 6 Sep 2016 09:50:34 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u86DoLtv020373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Sep 2016 09:50:29 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 6 Sep 2016 13:50:16 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.173]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 09:50:15 -0400 From: "UTTARO, JAMES" To: Wen Lin , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSBy1tlPCJWdFH906tson7HBxBSKBrOJIAgAFEMVA= Date: Tue, 6 Sep 2016 13:50:14 +0000 Message-ID: References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> In-Reply-To: <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.120] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F2B27BF6BMISOUT7MSGUSRCD_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-06_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609060214 Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 13:52:03 -0000 --_000_B17A6910EEDD1F45980687268941550F2B27BF6BMISOUT7MSGUSRCD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydA0KDQpKaW0gVXR0YXJvDQoNCkZyb206IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXZW4gTGluDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAw NSwgMjAxNiAxMDozMCBBTQ0KVG86IEVYVCAtIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tIDx0aG9t YXMubW9yaW5Ab3JhbmdlLmNvbT47IGJlc3NAaWV0Zi5vcmcNCkNjOiBkcmFmdC1yYWJhZGFuLWJl c3MtZXZwbi1hYy1kZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtiZXNzXSBQb2xsIGZvciBhZG9w dGlvbjogZHJhZnQtcmFiYWRhbi1iZXNzLWV2cG4tYWMtZGYNCg0KDQpTdXBwb3J0IGFzIGEgY28t YXV0aG9yLiAgSSBhbSB1bmF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0K DQpUaGFua3MsDQpXZW4NCg0KDQoNCk9uIDgvMzAvMTYsIDE6NDUgQU0sICJUaG9tYXMgTW9yaW4i IDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+ PiB3cm90ZToNCg0KSGVsbG8gd29ya2luZyBncm91cCwNCg0KVGhpcyBlbWFpbCBzdGFydHMgYSB0 d28td2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZi0w NSBbMV0gYXMgYSBXb3JraW5nIEdyb3VwIGRvY3VtZW50Lg0KDQpQbGVhc2Ugc3RhdGUgb24gdGhl IGxpc3QgaWYgeW91IHN1cHBvcnQgYWRvcHRpb24gb3Igbm90IChpbiBib3RoIGNhc2VzLA0KcGxl YXNlIGFsc28gc3RhdGUgdGhlIHJlYXNvbnMpLg0KDQpUaGlzIHBvbGwgcnVucyB1bnRpbCAqU2Vw dGVtYmVyIDE0dGgqLg0KDQpXZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55 IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFwcGxpZXMgdG8NCnRoaXMgZG9jdW1lbnQsIHRvIGVuc3Vy ZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoDQpJRVRGIElQ UiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh aWxzKS4NCg0KKipJZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3Iq KiBvZiB0aGlzIGRvY3VtZW50DQpwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRp Y2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlDQpvZiBhbnkgcmVsZXZhbnQgdW5kaXNj bG9zZWQgSVBSLiBUaGUgZG9jdW1lbnQgd29uJ3QgcHJvZ3Jlc3Mgd2l0aG91dA0KYW5zd2VycyBm cm9tIGFsbCB0aGUgYXV0aG9ycyBhbmQgY29udHJpYnV0b3JzLg0KDQpBdCB0aGlzIGRhdGUsIG5v IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWdhaW5zdCB0aGlzIERvY3VtZW50Lg0KDQpJZiB5b3Ug YXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZQ0K ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg aGFzIG5vdCB5ZXQNCmJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxl cy4NCg0KVGhhbmsgeW91DQoNCk1hcnRpbiAmIFRob21hcw0KYmVzcyBjaGFpcnMNCg0KWzFdIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFj LWRmDQoNCg== --_000_B17A6910EEDD1F45980687268941550F2B27BF6BMISOUT7MSGUSRCD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0 eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzQ0NTQ2QTsNCglmb250LXdlaWdodDpib2xkOw0KCWZvbnQtc3R5bGU6 aXRhbGljOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QSI+U3VwcG9ydDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM0NDU0NkEiPkppbSBVdHRhcm88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCRVNTIFttYWlsdG86YmVzcy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5XZW4gTGluPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgU2VwdGVtYmVyIDA1LCAyMDE2IDEwOjMwIEFNPGJyPg0KPGI+VG86PC9iPiBFWFQgLSB0 aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSAmbHQ7dGhvbWFzLm1vcmluQG9yYW5nZS5jb20mZ3Q7OyBi ZXNzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1k ZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Jlc3NdIFBvbGwgZm9yIGFkb3B0 aW9uOiBkcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdXBw b3J0IGFzIGEgY28tYXV0aG9yLiZuYnNwOyBJIGFtIHVuYXdhcmUgb2YgYW55IElQUiByZWxhdGVk IHRvIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5PbiA4LzMwLzE2LCAx OjQ1IEFNLCAmcXVvdDtUaG9tYXMgTW9yaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9t YXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90 ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0IiBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj5IZWxsbyB3b3JraW5nIGdyb3VwLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5UaGlzIGVtYWlsIHN0YXJ0cyBhIHR3by13ZWVrIHBv bGwgb24gYWRvcHRpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 YmxhY2siPmRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmLTA1IFsxXSBhcyBhIFdvcmtpbmcg R3JvdXAgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6YmxhY2siPlBsZWFzZSBzdGF0ZSBvbiB0aGUgbGlzdCBpZiB5b3Ugc3VwcG9ydCBhZG9wdGlv biBvciBub3QgKGluIGJvdGggY2FzZXMsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPnBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhpcyBwb2xsIHJ1 bnMgdW50aWwgKlNlcHRlbWJlciAxNHRoKi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+V2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9m IGFueSB1bmRpc2Nsb3NlZCBJUFIgdGhhdCBhcHBsaWVzIHRvDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPnRoaXMgZG9jdW1lbnQsIHRvIGVuc3VyZSB0 aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPklFVEYgSVBSIHJ1bGVzIChz ZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj4qKklmIHlvdSBh cmUgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvcioqIG9mIHRoaXMgZG9jdW1lbnQN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+cGxlYXNl IHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGFy ZSBhd2FyZQ0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNr Ij5vZiBhbnkgcmVsZXZhbnQgdW5kaXNjbG9zZWQgSVBSLiBUaGUgZG9jdW1lbnQgd29uJ3QgcHJv Z3Jlc3Mgd2l0aG91dA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OmJsYWNrIj5hbnN3ZXJzIGZyb20gYWxsIHRoZSBhdXRob3JzIGFuZCBjb250cmlidXRvcnMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkF0IHRoaXMg ZGF0ZSwgbm8gSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBhZ2FpbnN0IHRoaXMgRG9jdW1lbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPklmIHlvdSBh cmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmV4cGxpY2l0 bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3Qg eWV0DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmJl ZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+VGhhbmsgeW91PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPk1hcnRpbiAmYW1wOyBU aG9tYXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmJl c3MgY2hhaXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6Ymxh Y2siPlsxXSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y YWJhZGFuLWJlc3MtZXZwbi1hYy1kZiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1yYWJhZGFuLWJlc3MtZXZwbi1hYy1kZjwvYT48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B17A6910EEDD1F45980687268941550F2B27BF6BMISOUT7MSGUSRCD_-- From nobody Tue Sep 6 12:47:56 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276B812B287; Tue, 6 Sep 2016 12:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ULPZbMdmT2-n; Tue, 6 Sep 2016 12:47:53 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 6F36912B234; Tue, 6 Sep 2016 12:47:53 -0700 (PDT) X-AuditID: c6180641-e73ff70000000a0b-5b-57cec90351a2 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id C0.77.02571.309CEC75; Tue, 6 Sep 2016 15:47:50 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0301.000; Tue, 6 Sep 2016 15:47:49 -0400 From: Autumn Liu To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df Thread-Index: AQHSAprxqvulYvrW80GYoexh9vMr+KBqmJEAgACpJgCAAafZMA== Date: Tue, 6 Sep 2016 19:47:47 +0000 Message-ID: References: <3D34778C-5A92-4E89-8492-F08900B9400F@on.nokia.com> <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> In-Reply-To: <1B5ABC5B-664A-412A-BF5F-37FA06010471@juniper.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_E4F89EAEF1386F42AA8E6FB5C35399A622328151eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHW5ft5LlwgwePJCxWHJ/JbPGnrYfJ YsO+o2wOzB5Llvxk8mh5dpItgCmKyyYlNSezLLVI3y6BK+PD+jMsBfcqKvbfCmhg3FPaxcjB ISFgIvG3k6OLkYtDSGADo8S3rx3MEM4yRommc3fZuxg5OdgEtCT27X8HZosIJEic7jnHCGIz C4RLbLy1mhnEFhZwkTh4s5kZosZV4sPJvYwQtpPEy1WX2EBsFgEViZNrV7KC2LwCvhJnbyxn hFi2glFi3/lnYAlOAXuJSSfWsoDYjAKyEtMe3WeCWCYucevJfDBbQkBAYsme88wQtqjEy8f/ WCFsRYl9/dPZIerzJTb/mwu1TFDi5MwnLBMYRWYhGTULSdksJGWzgAHDLKApsX6XPkSJosSU 7ofsELaGROucuezI4gsY2VcxcpQWF+TkphsZbmIERtExCTbHHYx7ez0PMQpwMCrx8C6YfC5c iDWxrLgy9xCjBAezkgjvGYnz4UK8KYmVValF+fFFpTmpxYcYpTlYlMR59V8qhgsJpCeWpGan phakFsFkmTg4pRoYK5Zxf7sm/e5W02YOldmS6x/n3/qy/f129xC7LT/OX89jnW0hmnb0hIL6 THfLFtUzp8PmKiUpFH+Ibth1sMg2oVzb1lvr+iHf9yyf7J9I9bicNF170ZFfacrfII/JqX5z Jl86LPEwzarO94t1gPKjq2+T2SJsjX+//Kny97Zo0OKMU0nTwm8EKrEUZyQaajEXFScCAOrX bo6eAgAA Archived-At: Cc: "draft-rabadan-bess-evpn-ac-df@ietf.org" Subject: Re: [bess] Poll for adoption: draft-rabadan-bess-evpn-ac-df X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 19:47:55 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A622328151eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3IuIEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0 byB0aGlzIGRyYWZ0Lg0KDQotQXV0dW1uDQoNCkZyb206IFdlbiBMaW4gW21haWx0bzp3bGluQGp1 bmlwZXIubmV0XQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTYgNzozMCBBTQ0KVG86 IEVYVCAtIHRob21hcy5tb3JpbkBvcmFuZ2UuY29tOyBiZXNzQGlldGYub3JnDQpDYzogZHJhZnQt cmFiYWRhbi1iZXNzLWV2cG4tYWMtZGZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbYmVzc10gUG9s bCBmb3IgYWRvcHRpb246IGRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmDQoNCg0KU3VwcG9y dCBhcyBhIGNvLWF1dGhvci4gIEkgYW0gdW5hd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhp cyBkcmFmdC4NCg0KVGhhbmtzLA0KV2VuDQoNCg0KDQpPbiA4LzMwLzE2LCAxOjQ1IEFNLCAiVGhv bWFzIE1vcmluIiA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb208bWFpbHRvOnRob21hcy5tb3JpbkBv cmFuZ2UuY29tPj4gd3JvdGU6DQoNCkhlbGxvIHdvcmtpbmcgZ3JvdXAsDQoNClRoaXMgZW1haWwg c3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZw0KZHJhZnQtcmFiYWRhbi1iZXNzLWV2 cG4tYWMtZGYtMDUgWzFdIGFzIGEgV29ya2luZyBHcm91cCBkb2N1bWVudC4NCg0KUGxlYXNlIHN0 YXRlIG9uIHRoZSBsaXN0IGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gYm90aCBj YXNlcywNCnBsZWFzZSBhbHNvIHN0YXRlIHRoZSByZWFzb25zKS4NCg0KVGhpcyBwb2xsIHJ1bnMg dW50aWwgKlNlcHRlbWJlciAxNHRoKi4NCg0KV2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xl ZGdlIG9mIGFueSB1bmRpc2Nsb3NlZCBJUFIgdGhhdCBhcHBsaWVzIHRvDQp0aGlzIGRvY3VtZW50 LCB0byBlbnN1cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0 aA0KSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9y IG1vcmUgZGV0YWlscykuDQoNCioqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNv bnRyaWJ1dG9yKiogb2YgdGhpcyBkb2N1bWVudA0KcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCBhbmQgaW5kaWNhdGUgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZQ0Kb2YgYW55IHJlbGV2 YW50IHVuZGlzY2xvc2VkIElQUi4gVGhlIGRvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhvdXQN CmFuc3dlcnMgZnJvbSBhbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycy4NCg0KQXQgdGhp cyBkYXRlLCBubyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGFnYWluc3QgdGhpcyBEb2N1bWVudC4N Cg0KSWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhl biBwbGVhc2UNCmV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGhhcyBub3QgeWV0DQpiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRo IElFVEYgcnVsZXMuDQoNClRoYW5rIHlvdQ0KDQpNYXJ0aW4gJiBUaG9tYXMNCmJlc3MgY2hhaXJz DQoNClsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yYWJhZGFuLWJl c3MtZXZwbi1hYy1kZg0KDQo= --_000_E4F89EAEF1386F42AA8E6FB5C35399A622328151eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxl LXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0IGFzIGNvLWF1 dGhvci4gSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tQXV0dW1uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gV2VuIExpbiBbbWFpbHRvOndsaW5A anVuaXBlci5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBTZXB0ZW1iZXIgMDUsIDIw MTYgNzozMCBBTTxicj4NCjxiPlRvOjwvYj4gRVhUIC0gdGhvbWFzLm1vcmluQG9yYW5nZS5jb207 IGJlc3NAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFj LWRmQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmVzc10gUG9sbCBmb3IgYWRv cHRpb246IGRyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1cHBvcnQgYXMgYSBjby1hdXRob3IuJm5ic3A7IEkgYW0g dW5hd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2VuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6YmxhY2siPk9uIDgvMzAvMTYsIDE6NDUgQU0sICZxdW90O1Rob21hcyBNb3JpbiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj50aG9tYXMu bW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPkhlbGxvIHdvcmtpbmcgZ3Jv dXAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPlRo aXMgZW1haWwgc3RhcnRzIGEgdHdvLXdlZWsgcG9sbCBvbiBhZG9wdGluZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+ZHJhZnQtcmFiYWRhbi1iZXNzLWV2 cG4tYWMtZGYtMDUgWzFdIGFzIGEgV29ya2luZyBHcm91cCBkb2N1bWVudC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UGxlYXNlIHN0YXRlIG9uIHRo ZSBsaXN0IGlmIHlvdSBzdXBwb3J0IGFkb3B0aW9uIG9yIG5vdCAoaW4gYm90aCBjYXNlcywNCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+cGxlYXNlIGFs c28gc3RhdGUgdGhlIHJlYXNvbnMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOmJsYWNrIj5UaGlzIHBvbGwgcnVucyB1bnRpbCAqU2VwdGVtYmVyIDE0dGgqLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5XZSBhcmUg YWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IHVuZGlzY2xvc2VkIElQUiB0aGF0IGFw cGxpZXMgdG8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+dGhpcyBkb2N1bWVudCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGgNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjpibGFjayI+SUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPioqSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNv bnRyaWJ1dG9yKiogb2YgdGhpcyBkb2N1bWVudA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5wbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBp bmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPm9mIGFueSByZWxldmFudCB1bmRpc2Nsb3Nl ZCBJUFIuIFRoZSBkb2N1bWVudCB3b24ndCBwcm9ncmVzcyB3aXRob3V0DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPmFuc3dlcnMgZnJvbSBhbGwgdGhl IGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+QXQgdGhpcyBkYXRlLCBubyBJUFIgaGFzIGJlZW4gZGlzY2xv c2VkIGFnYWluc3QgdGhpcyBEb2N1bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+SWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv ciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjpibGFjayI+ZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBh d2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+YmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ug d2l0aCBJRVRGIHJ1bGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj5UaGFuayB5b3U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjpibGFjayI+TWFydGluICZhbXA7IFRob21hczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+YmVzcyBjaGFpcnM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFjLWRmIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhYmFkYW4tYmVzcy1ldnBuLWFj LWRmPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_E4F89EAEF1386F42AA8E6FB5C35399A622328151eusaamb103erics_-- From nobody Thu Sep 8 21:17:27 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A291A12B03C; Thu, 8 Sep 2016 21:17:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147339464265.21930.12885646412741024651.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2016 21:17:22 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-04.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, 09 Sep 2016 04:17:22 -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 : Interconnect Solution for EVPN Overlay networks Authors : Jorge Rabadan Senthil Sathappan Wim Henderickx Senad Palislamovic Ali Sajassi Dennis Cai Filename : draft-ietf-bess-dci-evpn-overlay-04.txt Pages : 24 Date : 2016-09-08 Abstract: This document describes how Network Virtualization Overlay networks (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-dci-evpn-overlay-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 13 10:39:27 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2790C12B478; Tue, 13 Sep 2016 10:39:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147378836215.23488.1062345725523731674.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 10:39:22 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l3vpn-yang-00.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 17:39:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Yang Data Model for BGP/MPLS L3 VPNs Authors : Dhanendra Jain Keyur Patel Patrice Brissette Zhenbin Li Shunwan Zhuang Xufeng Liu Jeffrey Haas Santosh Esale Bin Wen Filename : draft-ietf-bess-l3vpn-yang-00.txt Pages : 28 Date : 2016-09-13 Abstract: This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l3vpn-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 13 11:13:10 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C1712B4A7; Tue, 13 Sep 2016 11:13:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147379038634.23612.13534598596558239593.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 11:13:06 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-prefix-advertisement-03.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, 13 Sep 2016 18:13:07 -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 : IP Prefix Advertisement in EVPN Authors : Jorge Rabadan Wim Henderickx Senad Palislamovic Aldrin Isaac John E. Drake Wen Lin Ali Sajassi Filename : draft-ietf-bess-evpn-prefix-advertisement-03.txt Pages : 31 Date : 2016-09-13 Abstract: EVPN provides a flexible control plane that allows intra-subnet connectivity in an IP/MPLS and/or an NVO-based network. In NVO networks, there is also a need for a dynamic and efficient inter- subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and may not support their own routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route- type is used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-prefix-advertisement-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 19 23:34:27 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCE12B61E; Mon, 19 Sep 2016 23:34:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147435326307.31127.7078997741168483094.idtracker@ietfa.amsl.com> Date: Mon, 19 Sep 2016 23:34:23 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-usage-03.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, 20 Sep 2016 06:34:23 -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 : Usage and applicability of BGP MPLS based Ethernet VPN Authors : Jorge Rabadan Senad Palislamovic Wim Henderickx Ali Sajassi Keyur Patel Aldrin Isaac Filename : draft-ietf-bess-evpn-usage-03.txt Pages : 30 Date : 2016-09-19 Abstract: This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-usage-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-usage-03 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 Sep 20 10:25:39 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A252212B428 for ; Tue, 20 Sep 2016 10:25:35 -0700 (PDT) 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=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 Pe80A6JfbLTK for ; Tue, 20 Sep 2016 10:25:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0040.outbound.protection.outlook.com [104.47.40.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C57912B42B for ; Tue, 20 Sep 2016 10:25:33 -0700 (PDT) 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=udpNLr6ttdaiit0FMHCBI5KpN+HqcG75SSx/JPxVCSU=; b=JqwlHvpe6NxHOhLmDRQVcOEXPeKg7HGZQmBEl6BwgzWO5eQCQZu9bMJ8ZktLqVEkfdgXATAlrTlyBHcDzUhJTcor2qLCBb+hmo4I1uzkeiK11lgvtQAg2kUbhmxysS9Qoq3f4uR0jpKUd0PnCcs+sWk4p+YrL9zjv0aChpPzGdk= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0261.namprd18.prod.outlook.com (10.163.72.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.619.10; Tue, 20 Sep 2016 17:25: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.0619.016; Tue, 20 Sep 2016 17:25:30 +0000 From: Keyur Patel To: "Jeffrey (Zhaohui) Zhang" , Wen Lin , "'jackey.zhang@huawei.com" <'jackey.zhang@huawei.com>, Lizhenbin , "bess@ietf.org" , "Martin Vigoureux" Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHR97r0Jb/qcyltLUCBJZR5PfA+kaBhW96QgCEvmLCAAExT6A== Date: Tue, 20 Sep 2016 17:25:30 +0000 Message-ID: References: <57B308FA.4090201@nokia.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-originating-ip: [132.245.82.53] x-ms-office365-filtering-correlation-id: 53e36489-d23c-4482-9754-08d3e17b1f1e x-microsoft-exchange-diagnostics: 1; BY2PR18MB0261; 6:5QL6SQBb5UTIo3L9e+fp8z1ToHhwdv1cKh3RBqrBysKoGG1rLfEG+3pbvBhp0dd8XsTrp21eIM/Nz9jF4SLQ5+3Ii1QH7Qh86V1C4EXvQmyx0sSyOp8ZHZz+B+31jvKiDoTQWIg2fMyzXuCGCJyd4NF+Vi9/NwmNYF/5XK3rLFezSr38TEuNSIg8jMXrEcMG04NpjwC5l65dvqB0zFfnraZFCBWwQemiWOV9y9RkhJuCRMNZQo/g7Z6TqwsOazuhe0+EliALcNkoTx953Xm0WCG9cGVhHbIoss/rjc9xSeM4I2dYleD9RVbzEwqdkIff; 5:SFm0+A5phKKHEZqmNEVNPXTh4rEvg04LIsY9c4i6K9otMGULOSixDheJ7A4ohnl6gn/WTxldvG/VM7r5sZN2TZ5oYJ8clI/M8QsXGV9eLm24u8wlBpYgjUdpuqrBC1PHlyaSWRPS93uni0MucPxCyA==; 24:5DEz7vaeLnoHPrbWq3oZBtwEn0zKMWRBh29w3CG08EIPLEtMGm0RoPGIIBu9FE6K9UsbAUvx36dwhg8ymDJgvgyh9DtINQC1+PPwl2WP/9U=; 7:f1jMtdVVL4Y7RsnaL89yeAHOiX2wSXLUJnD7xEyEt261sVUhMGVYhAvZPg7hqWDbfD33IdkM3T03nh/DU4MoSPAdk2YOPpZiWPX2Qi28FHMWCko0ObFkpuwiC5epqitVGcGU0bG7rVaU5dGMMmNPcy8JXh4ZwmwFlSC4fso/cFJofQIV9N6lugzXBPgfOJrFUArcdI8tj02zhuYGznCKkvgU+NZbi1HbyUOVnoA3jM1EMet4x41WiAlfq4HW2cx3IYLhMa8n4hPvQyR+ZqmG1wHUaNJN8FYH+KviyO6v1Fp19T15kt8z5s173eA53cnK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0261; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6043046)(6042046); SRVR:BY2PR18MB0261; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0261; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377454003)(189002)(199003)(13464003)(66066001)(33656002)(16236675004)(15975445007)(2950100001)(15650500001)(19617315012)(2900100001)(68736007)(9686002)(7696004)(76576001)(77096005)(5660300001)(102836003)(586003)(8936002)(2906002)(6116002)(87936001)(81166006)(81156014)(19627405001)(3846002)(97736004)(7736002)(10400500002)(76176999)(5002640100001)(122556002)(50986999)(54356999)(11100500001)(107886002)(189998001)(105586002)(1941001)(74316002)(86362001)(106116001)(230783001)(99286002)(8666005)(7846002)(19625215002)(3280700002)(7906003)(19580395003)(3660700001)(92566002)(106356001)(5001770100001)(19580405001)(101416001)(2501003)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0261; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR18MB026241044C0B90E04B4DE770C1F70BY2PR18MB0262namp_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2016 17:25:30.7045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0261 Archived-At: Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 17:25:35 -0000 --_000_BY2PR18MB026241044C0B90E04B4DE770C1F70BY2PR18MB0262namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am not aware of any IPRs related to the draft. Apologies for the delayed response. Best Regards, Keyur > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux > Sent: Tuesday, August 16, 2016 8:37 AM > To: bess@ietf.org > Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org > Subject: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure- > updates-03 > > Hello working group, > > This email starts a two-week poll on adopting > draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group > Document. > > Please state on the list if you support adoption or not (in both cases, > please also state the reasons). > > This poll runs until *the 30th of August*. > > We are also polling for knowledge of any undisclosed IPR that applies > to this Document, to ensure that IPR has been disclosed in compliance > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more > details). > If you are listed as an Author or Contributor of this Document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers > from all the Authors and Contributors. > No IPR has been disclosed against this Document > > If you are not listed as an Author or Contributor, then please > explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules. > > Thank you > > Martin & Thomas > bess chairs > > [1] > https://datatracker.ietf.org/doc/draft-zzhang-bess-evpn-bum-procedure- > updates/ > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess --_000_BY2PR18MB026241044C0B90E04B4DE770C1F70BY2PR18MB0262namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPRs related to the draft.


Apologies for the delayed response.


Best Regards,

Keyur


> -----Original Message-----
> From: BESS [mailto:bess-bounc= es@ietf.org] On Behalf Of Martin Vigoureux
> Sent: Tuesday, August 16, 2016 8:37 AM
> To: bess@ietf.org
> Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org
> Subject: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedur= e-
> updates-03
>
> Hello working group,
>
> This email starts a two-week poll on adopting
> draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group=
> Document.
>
> Please state on the list if you support adoption or not (in both cases= ,
> please also state the reasons).
>
> This poll runs until *the 30th of August*.
>
> We are also polling for knowledge of any undisclosed IPR that applies<= br> > to this Document, to ensure that IPR has been disclosed in compliance<= br> > with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
> details).
> If you are listed as an Author or Contributor of this Document please<= br> > respond to this email and indicate whether or not you are aware of any=
> relevant undisclosed IPR. The Document won't progress without answers<= br> > from all the Authors and Contributors.
> No IPR has been disclosed against this Document
>
> If you are not listed as an Author or Contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet > been disclosed in conformance with IETF rules.
>
> Thank you
>
> Martin & Thomas
> bess chairs
>
> [1]
> https://datatracker.ietf.org/doc/draft-zzhang-bess-evpn-bum-procedure-<= br> > updates/
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.iet= f.org/mailman/listinfo/bess
--_000_BY2PR18MB026241044C0B90E04B4DE770C1F70BY2PR18MB0262namp_-- From nobody Fri Sep 23 03:05:56 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA412BC73; Fri, 23 Sep 2016 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1_u-t3m9ifDP; Fri, 23 Sep 2016 03:05:51 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A2912BCD6; Fri, 23 Sep 2016 03:05:50 -0700 (PDT) Received: from [192.168.0.200] (Lenovo-X1Carbon.win2004.cysol.co.jp [192.168.0.200]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id u8NA5YGs035140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 23 Sep 2016 19:05:34 +0900 (JST) (envelope-from glenn@cysols.com) To: "Jeffrey (Zhaohui) Zhang" , Benoit Claise , "EXT - thomas.morin@orange.com" References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> From: Glenn Mansfield Keeni Message-ID: <93a5d459-3271-b7ad-fadc-156576c60b65@cysols.com> Date: Fri, 23 Sep 2016 19:05:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Cc: "mib-doctors@ietf.org" , Martin Vigoureux , "ops-ads@ietf.org" , Mach Chen , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 10:05:55 -0000 Hi, Any update on the MIB drafts? Glenn On 2016/07/17 23:44, Glenn Mansfield Keeni wrote: > Jeffrey and team, > Any progress on the MIB matters > (draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt, > draft-ietf-bess-mvpn-mib-03.txt )? > > Glenn > On 2016/06/07 18:39, Glenn Mansfield Keeni wrote: >> Hi Jeffrey, >> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib >> document. It took me some time to do this review. But now here it >> is. A (near complete) review of >> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps. >> I understand that the Security Considerations section is TBD. >> >> Glenn >> >> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: >>> Hi Glenn, >>> >>>> -----Original Message----- >>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] >>>> Sent: Sunday, May 08, 2016 11:02 AM >>>> To: Jeffrey (Zhaohui) Zhang ; Benoit Claise >>>> ; EXT - thomas.morin@orange.com >>>> >>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>> Vigoureux >>>> ; bess@ietf.org; mib-doctors@ietf.org >>>> Subject: Re: [bess] MIBDoc review of >>>> draft-ietf-bess-l2l3-vpn-mcast-mib- >>>> 02.txt >>>> >>>> Jeffrey, >>>> > Thanks for your comments. I've addressed most of your comments >>>> > in the new revision: >>>> Thanks for your cooperation. I will need at least one more revision >>>> with the following comments/recommendations addressed before I will >>>> be able to complete the detailed review. In the following the numbers >>>> refer to the issue numbers in the initial review. The issues that are >>>> addressed and closed are not listed. For brevity, the issue >>>> descriptions have been trimmed. In case of doubts please look at the >>>> response mail appended below. >>>> Hope this helps. >>> >>> Thanks for your detailed comments/suggestions. I posted a new revision >>> with the following issues addressed. >>> >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt >>> >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04 >>> >>> Please see some notes below. >>> >>>> >>>> Glenn >>>> >>>> ------------------------------------------------------------------- >>>> >>>> Comments: >>>> >>>> 1.1 >>>> > I had thought this would be standard/obvious for all MIB objects - >>>> We will comeback to this time and again, whereever possible make >>>> matters explicit and clear. That will help. >>>> > Is it enough to say something similar? For example: >>>> > In particular, it describes common managed objects used >>>> > to configure and/or monitor both L2 and L3 VPN Multicast. >>>> That is better. >>> >>> I take it that this is already closed in -03 revision. >>> >>>> >>>> 2.2 >>>> > Having said that, I'll explain PMSI a bit further. >>>> PMSI explanation is good. >>>> Please use the same style/format for I-PMSI and S-PMSI. >>> >>> I think -03 revision already use the same style/format for I-PMSI and >>> S-PMSI? >>> >>>> >>>> 2.3 >>>> > No difference. I was using "Layer 3" or "L3" but it was pointed out >>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs and I >>>> > was advised to change it accordingly. Looks like I did not change >>>> all >>>> > the cases. >>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 >>>> VPN" so >>>> > I'll change it back. >>>> No problems. just make sure that the same expression/notation is used >>>> uniformly. >>> >>> I take it that this is also addressed in -03 already. >>> >>>> 3. >>>> > > > 3. Summary of MIB Module. >>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>> > > > structure of the MIB, short descriptions of the table(s) >>>> > > > including usage of the table(s) for management and/or by >>>> > > > other MIB(s). >>>> > >>>> > I had that, but have added one sentence about the only table. >>>> A sentence or two about the textual convention will be good. >>> >>> Added in -04. >>> >>>> > > > 4. MIB syntax checking: >>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>> 2>L2L3-VPN-MCAST-MIB.txt >>>> > >>>> > I used simpleweb's validation tool but looks like I did not use the >>>> > strictest level of validation. I've now fixed the following issues >>>> and >>>> > verified. >>>> Good. >>>> 5. >>>> > > > >>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>> > > > Wherever possible, provide references for objects used in >>>> > > > the MIB. The references will point to specific sections/ >>>> > > > sub-sections of the RFCs defining the protocol for which the >>>> > > > MIB is being designed. It will greatly improve the >>>> readability >>>> > > > of the document. >>>> > >>>> > Added. >>>> I would recommend using the REFERENCE clause as in rfs4382 and >>>> improve on it. >>>> Specifically, instead of keeping the reference in the DESCRIPTION >>>> clause move it to a separate REFERENCE clause. The addition of the >>>> section number is an improvement. It is friendlier to the reader. >>>> Note. Same comment for other OBJECTs too. >>> >>> Oh I missed that. All fixed. >>> >>>> 7.1 >>>> > > > 7.1 CONTACT-INFO >>>> > > > Following the conventions (including indentation style) >>>> will >>>> > > > improve the readability. (e.g. RFC4382, RFC5132). >>>> > > > Will be good if it does not overflow into the next page. >>>> > >>>> > Fixed. >>>> The format is OK. The Postal address etc., need not have been >>>> deleted. Please put the complete contact information as in the >>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). >>> >>> Fixed. >>> >>>> 7.3 >>>> > I kept "experimental 99" so that I could continue to use mib tools >>>> > to validate; but I added notes for the editor to replace them as you >>>> > indicated. >>>> Use of "experimental 99" is not recommended. >>> >>> Do you mean 99 is not a good number? What about 9999? As I explained, >>> I kept it so that we can use mib tools to validate, and I've added >>> detailed notes for the editor. >>> >>>> 8 >>>> > > > 8. Specific MO and TC related comments. >>>> > Are spaces allowed? I don't know so I used hyphen. For now I >>>> replace >>>> > with things like rsvpP2mp. >>>> Yes. Camelcase is an allowed practice. SMI does not mind it. >>> >>> Ok this is closed already then. >>> >>>> 8.2 >>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>> > The intent is to simply return the octet value of the flags >>>> > field, w/o listing individual bits like "Leaf Information Required". >>>> > More bits could be defined in the future but the MIB would not >>>> change. >>>> > >>>> > Is that OK? >>>> As far as possible, the meaning of the objects must be made clear. >>>> That will help implementors and operators- users of the MIB. >>> >>> I added the definition for one existing bit and reference to the IANA >>> registry being created for this flag field. >>> >>>> >>>> 8.3 >>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>> > Depending on the tunnel type, there could be different sizes. >>>> > Future tunnel types could have other sizes that not specified >>>> > today. I was thinking to just give a size >>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. >>>> > Is that ok? >>>> I see that you have changed the size upper limit to 50. >>>> If the size varies continuously from 0 to 50 the above description >>>> is correct. >>>> Please confirm, explain and cite appropriate reference. If the size >>>> may change in the future that must be stated too. >>> >>> I changed to discrete sizes for currently defined tunnel types. >>> >>>> >>>> 8.4 >>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>> > > > SYNTAX RowPointer >>>> > > > MAX-ACCESS read-only >>>> > > > STATUS current >>>> > > > DESCRIPTION >>>> > > > "If the tunnel has a corresponding interface, >>>> > > > this is the row pointer to the ifName table." >>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you >>>> > > > want to say this object points to the corresponding >>>> > > > row in the ifTable? >>>> > >>>> > Yes. Fixed. >>>> Not quite. >>>> What is ifName table ? ifName is a columnar object in the ifXTable. >>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row in >>>> the >>>> ifXTable table ? Please fix accordingly. >>> >>> You're right. Fixed. >>> >>>> >>>> 9. >>>> > > > 9. The Security Considerations section does not follow >>>> > > > the Security Guidelines for IETF MIB Modules >>>> > > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>> > > > Please fix. >>>> > >>>> > I was really hoping that it would not have to be that >>>> > tedious. SNMP/MIB secur >>>> ity should be no different from the >>>> > CLI security - once you secure the infrastructure >>>> > then what's more to do? >>>> > >>>> > I'll need more time to work on this. Let me try to address >>>> > the issues in the other mib first and come back to this. >>>> >>>> Please take your time. Looking at examples will help. And let me >>>> know where I can help. >>> >>> I will need to work on that later. >>> >>>> >>>> 10.1 >>>> > > > 10.1 Checking nits according to >>>> > > > http://www.ietf.org/id-info/checklist : >>>> > Should I break them into different lines or just keep them >>>> > as is? Any example of expected indentation if I break the >>>> > lines? >>>> No problems at all to break lines. >>>> l2L3VpnMcastGroups OBJECT IDENTIFIER >>>> ::= {l2L3VpnMcastConformance 1} >>>> Should do. >>> >>> Done. >>> >>>> >>>> 10.2 >>>> > > > 10.2 Checking references for intended status: Proposed Standard >>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line 76, >>>> > > > but not defined >>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other >>>> > I hope I understood and fixed it (removing the space in "RFC >>>> 7117"). >>>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] >>>> That is simpler to parse. >>> >>> I see some other documents do not have comma between multiple >>> references so I followed that. >>> >>>> >>>> > > > 11. There is another WIP MVPN-MIB in >>>> > > > draft-ietf-bess-mvpn-mib-02.txt >>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>> > > > Is there a good reason for not merging the 2 documents? >>>> > > > I have not seen any discussion or explanation on this. >>>> > > > I may have missed it. >>>> > > > Please clarify or, give some pointers. >>>> > >>>> > As mentioned in the introduction: >>>> > >>>> > this memo describes managed objects common to both VPLS >>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB >>>> > in the work and both would reference common >>>> >>>> > objects defined in this MIB. >>>> >>>> OK. So you are saying that this MIB contains core objects that >>>> will be used to manage implementations of various multicast VPN >>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if >>>> you spell it out at the beginning. >>> >>> Yes. I thought I did it already: >>> >>> 1. Introduction >>> >>> ... and this memo describes managed objects common to both VPLS >>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>> >>> Thanks! >>> Jeffrey >>> >>>> >>>> ---------------------------------------------------------------------- >>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: >>>>> Glenn, >>>>> >>>>> Thanks for your comments. I've addressed most of your comments in the >>>> new revision: >>>>> >>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- >>>> l2l3-vpn-mcast-mib-03.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- >>>> vpn-mcast-mib/ >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- >>>> mcast-mib-03 >>>>> Diff: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- >>>> vpn-mcast-mib-03 >>>>> >>>>> Please see below. >>>>> >>>>>> 1. Abstract: >>>>>> 1.1 A sentence on how the managed objects will be used by >>>>>> applications for operations, monitoring and management >>>>>> would be good. >>>>> >>>>> I had thought this would be standard/obvious for all MIB objects - the >>>> read-write ones are used to control how a device works, and the >>>> read-only >>>> ones are used for monitoring. Do I really need to say it explicitly? >>>>> >>>>> I see RFC 4382 has the following: >>>>> >>>>> This memo defines a portion of the Management Information Base >>>>> (MIB) >>>>> for use with network management protocols in the Internet >>>>> community. >>>>> In particular, it describes managed objects to configure and/or >>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private >>>>> Networks on a Multiprotocol Label Switching (MPLS) Label Switching >>>>> Router (LSR) supporting this feature. >>>>> >>>>> Is it enough to say something similar? For example: >>>>> >>>>> In particular, it describes common managed objects used to >>>> configure >>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>> >>>>>> >>>>>> 2. Introduction >>>>>> 2.1 Please give the full expansion of the abbreviations >>>>>> appearing for the first time. (PE, VPLS,..) >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 2.2 The terminology section is a bit terse. Explaining the >>>>>> terms that are used, nicely with reference to the protocol >>>>>> documents will improve readability. >>>>>> e.g. >>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels >>>>> >>>>> As the paragraph alluded to, this MIB needs to be understood in the >>>> general context of L2/L3 multicast VPN and providing good >>>> explanation of >>>> the terms is not attempted. The references for the terms are the the >>>> RFCs >>>> for the relevant technologies. >>>>> >>>>> Having said that, I'll explain PMSI a bit further. >>>>> >>>>>> 2.3 Is there a difference between >>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by >>>>>> RFC 7117 and RFC 6513/6514" >>>>>> used in the DESCRIPTION in the MODULE-IDENTITY >>>>>> and >>>>>> "multicast in BGP/MPLS L2 or IP VPN" >>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? >>>>>> If these are the same, it will be helpful to stick to the >>>>>> same expression. If these are not the same, the dictinction >>>>>> should be clarified. >>>>> >>>>> No difference. I was using "Layer 3" or "L3" but it was pointed out >>>>> that >>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was >>>> advised to change it accordingly. Looks like I did not change all the >>>> cases. >>>>> >>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so >>>> I'll change it back. >>>>> >>>>>> >>>>>> >>>>>> 3. Summary of MIB Module. >>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the >>>>>> structure of the MIB, short descriptions of the table(s) >>>>>> including usage of the table(s) for management and/or by >>>>>> other MIB(s). >>>>> >>>>> I had that, but have added one sentence about the only table. >>>>> >>>>>> >>>>>> MIB definitions: >>>>>> 4. MIB syntax checking: >>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB >>>>>> 2>L2L3-VPN-MCAST-MIB.txt >>>>> >>>>> I used simpleweb's validation tool but looks like I did not use the >>>> strictest level of validation. I've now fixed the following issues and >>>> verified. >>>>> >>>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named >>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named >>>> number `ldp-p2mp' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named >>>> number `pim-asm' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named >>>> number `pim-ssm' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named >>>> number `pim-bidir' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named >>>> number `ingress-replication' must not include a hyphen in SMIv2 >>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named >>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 >>>>> >>>>> See later question/comments below. >>>>> >>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current >>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module >>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: identifier >>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: identifier >>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: identifier >>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>> identifier >>>> `TruthValue' imported from module `SNMPv2-TC' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: >>>>>> identifier >>>> `RowStatus' imported from module `SNMPv2-TC' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>> identifier >>>> `TimeStamp' imported from module `SNMPv2-TC' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: >>>>>> identifier >>>> `TimeInterval' imported from module `SNMPv2-TC' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: >>>>>> identifier >>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never >>>> used >>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>> identifier >>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used >>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: >>>>>> identifier >>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used >>>>> >>>>> Removed the above unused imports. >>>>> >>>>>> >>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. >>>>>> Wherever possible, provide references for objects used in >>>>>> the MIB. The references will point to specific sections/ >>>>>> sub-sections of the RFCs defining the protocol for which the >>>>>> MIB is being designed. It will greatly improve the readability >>>>>> of the document. >>>>> >>>>> Added. >>>>> >>>>>> >>>>>> 6. IMPORTS clause >>>>>> MIB modules from which items are imported must be cited and >>>>>> included in the normative references. >>>>>> The conventional style is >>>>>> mplsStdMIB >>>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] >>>>> >>>>> Added. >>>>> >>>>>> >>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic >>>>>> errors.) >>>>>> 7.1 CONTACT-INFO >>>>>> Following the conventions (including indentation style) will >>>>>> improve the readability. (e.g. RFC4382, RFC5132). >>>>>> Will be good if it does not overflow into the next page. >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 >>>>>> sec 4.5 >>>>>> REVISION "200212132358Z" -- December 13, 2002 >>>>>> DESCRIPTION "Initial version, published as RFC yyyy." >>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this >>>>>> note: >>>>> >>>>> Fixed. >>>>> >>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 >>>>>> sec 4.5 i >>>>>> replace >>>>>> ::= { experimental 99 } -- number to be assigned >>>>>> by >>>>>> ::= { XXX } >>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>> note >>>>>> will be the subtree under which the module will be >>>>>> registered. >>>>>> >>>>> >>>>> I kept "experimental 99" so that I could continue to use mib tools to >>>> validate; but I added notes for the editor to replace them as you >>>> indicated. >>>>> >>>>>> >>>>>> 8. Specific MO and TC related comments. >>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "Types of provider tunnels used for multicast in >>>>>> BGP/MPLS L2 or IP VPN." >>>>>> SYNTAX INTEGER { unconfigured (0), >>>>>> rsvp-p2mp (1), >>>>>> ldp-p2mp (2), >>>>>> pim-asm (3), >>>>>> pim-ssm (4), >>>>>> pim-bidir (5), >>>>>> ingress-replication (6), >>>>>> ldp-mp2mp (7) >>>>>> >>>>>> o Would be nice to align the enumeration labels with the >>>>>> labels in the protocol document RFC 6514 unless there is >>>>>> a good reason for not doing so. (You will have to take >>>>>> care of the smi compilation errors too; '-' is not allowed ). >>>>> >>>>> Are spaces allowed? I don't know so I used hyphen. For now I replace >>>> with things like rsvpP2mp. >>>>> Or could/should I just remove the definitions, so that if a new >>>>> type is >>>> defined in the future there is no need to update the MIB? >>>>> >>>>>> >>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "An entry in this table corresponds to an PMSI attribute >>>>>> that is advertised/received on this router. >>>>>> For BGP-based signaling (for I-PMSI via auto-discovery >>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), >>>>>> they are just as signaled by BGP (RFC 6514 section 5, >>>>>> 'PMSI Tunnel attribute'). >>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>> they're derived from S-PMSI Join Message >>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. >>>>>> >>>>>> Note that BGP-based signaling may be used for >>>>>> PIM-MVPN as well." >>>>>> o Fix the ".." in "'UDP-based Protocol').." above. >>>>>> o Please give the reference for this Table. >>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? >>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? >>>>>> both? >>>>>> Any other pointers? >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>> SYNTAX OCTET STRING (SIZE (1)) >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>> For BGP-based I/S-PMSI signaling, this is the Flags >>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>> I/S-PMSI A-D route." >>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } >>>>>> o Please confirm that the above is a complete enumeration of the >>>>>> types of signalling. >>>>>> o RFC 6514 Sec.5 says that the Flags field indicates >>>>>> "Leaf Information Required". That is useful information. >>>>>> Please include in the description. >>>>> >>>>> The intent is to simply return the octet value of the flags field, w/o >>>> listing individual bits like "Leaf Information Required". More bits >>>> could >>>> be defined in the future but the MIB would not change. >>>>> >>>>> Is that OK? >>>>> >>>>>> >>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>> four or sixteen octets of this attribute are filled >>>>>> with >>>>>> the provider tunnel group address (IPv4 or IPv6).. >>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel >>>> Identifier >>>>>> Field in PMSI Tunnel Attribute of the corresponding >>>>>> I/S- >>>> PMSI >>>>>> A-D route." >>>>>> o Check the size specifications. The specs above say it can be >>>>>> all sizes 0..37. That is not clear from the DESCRIPTION clause. >>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. >>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel >>>> Identifiers >>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress Replication,MP2MP. >>>>>> It appears that the sizes (range) for each case will be >>>>>> different. >>>>>> Please clarify that, and if there are discrete sizes, specify >>>>>> accordingly. >>>>> >>>>> Depending on the tunnel type, there could be different sizes. Future >>>> tunnel types could have other sizes that not specified today. I was >>>> thinking to just give a size range so that it is flexible. Is that ok? >>>>> >>>>>> >>>>>> >>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>> SYNTAX RowPointer >>>>>> MAX-ACCESS read-only >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "If the tunnel exists in some MIB table, this is the >>>>>> row pointer to it." >>>>>> o "some MIB table" : specify which MIB table. >>>>> >>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be >>>> whatever table that a tunnel may be put into. >>>>> >>>>>> o In what case will the tunnel exist and in what case will it >>>>>> not? >>>>> >>>>> If a device supports mplsTunnelTable and the tunnel is represented >>>>> there, >>>> then it exists. >>>>> >>>>>> o What will be the behaviour if the above condition is not >>>> satisfied? >>>>> >>>>> A null pointer should be given. >>>>> >>>>>> >>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>> SYNTAX RowPointer >>>>>> MAX-ACCESS read-only >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "If the tunnel has a corresponding interface, this is the >>>>>> row pointer to the ifName table." >>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want to say >>>>>> this object points to the corresponding row in the ifTable? >>>>> >>>>> Yes. Fixed. >>>>> >>>>>> o In what case does the TunnelIf exist and in what case will it >>>> not? >>>>> >>>>> Some tunnels may not have a corresponding interface. >>>>> >>>>>> o What will be expected if the tunnel does not have a >>>> corresponding >>>>>> interface? >>>>> >>>>> Null row pointer. >>>>> >>>>>> >>>>>> 9. The Security Considerations section does not follow the Security >>>>>> Guidelines for IETF MIB Modules >>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. >>>>>> Please fix. >>>>> >>>>> I was really hoping that it would not have to be that tedious. >>>>> SNMP/MIB >>>> security should be no different from the CLI security - once you secure >>>> the infrastructure then what's more to do? >>>>> >>>>> I'll need more time to work on this. Let me try to address the >>>>> issues in >>>> the other mib first and come back to this. >>>>> >>>>>> >>>>>> >>>>>> 10.ID-nits >>>>>> 10.1 Checking nits according to >>>>>> http://www.ietf.org/id-info/checklist : >>>>>> >>>>>> ------------------------------------------------------------------ >>>> --------- >>>>>> >>>>>> ** There are 4 instances of too long lines in the document, the >>>> longest one >>>>>> being 3 characters in excess of 72. >>>>> >>>>> I fixed some but there still three too long lines: >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeType >>>>> L2L3VpnMcastProviderTunnelType, >>>>> >>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= >>>>> {l2L3VpnMcastConformance >>>> 1} >>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= >>>>> {l2L3VpnMcastConformance >>>> 2} >>>>> >>>>> Should I break them into different lines or just keep them as is? Any >>>> example of expected indentation if I break the lines? >>>>> >>>>>> >>>>>> 10.2 Checking references for intended status: Proposed Standard >>>>>> >>>>>> ------------------------------------------------------------------ >>>> --------- >>>>>> >>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but >>>>>> not >>>>>> defined >>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other >>>>>> documents >>>> tha...' >>>>> >>>>> I hope I understood and fixed it (removing the space in "RFC 7117"). >>>>> >>>>>> >>>>>> 11. There is another WIP MVPN-MIB in draft-ietf-bess-mvpn-mib-02.txt >>>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. >>>>>> Is there a good reason for not merging the 2 documents? I have >>>>>> not >>>> seen >>>>>> any discussion or explanation on this. I may have missed it. >>>> Please >>>>>> clarify or, give some pointers. >>>>> >>>>> As mentioned in the introduction: >>>>> >>>>> this memo describes managed objects common to both VPLS >>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. >>>>> >>>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the work >>>> and both would reference common objects defined in this MIB. >>>>> >>>>> Thanks! >>>>> Jeffrey >>>>> >>>>>> -----Original Message----- >>>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn >>>>>> Mansfield >>>>>> Keeni >>>>>> Sent: Tuesday, April 12, 2016 2:28 AM >>>>>> To: Benoit Claise ; EXT - thomas.morin@orange.com >>>>>> >>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>> Martin >>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>> >>>>>> Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- >>>> 02.txt >>>>>> >>>>>> Hi, >>>>>> I have been asked to do a MIB Doctors review of >>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. >>>>>> My knowledge of L2L3VPN Multicast is limited to the reading >>>>>> of this document and browsing through the documents referred >>>>>> to in the draft and bess-wg mailing list archives.( read "shallow"). >>>>>> So some of the doubts and questions may sound trivial or >>>>>> strange. Please bear with me and help me help you make >>>>>> this into a better document :-) >>>>>> >>>>>> The comments are attached. >>>>>> >>>>>> Glenn >>>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> BESS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> >>> >>> >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From nobody Fri Sep 30 09:06:53 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EA712B407; Fri, 30 Sep 2016 09:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316] 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 YZ1Kgz9arWUo; Fri, 30 Sep 2016 09:06:44 -0700 (PDT) Received: from mailout2-trp.thomsonreuters.com (mailout2-trp.thomsonreuters.com [163.231.6.26]) (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 217BF12B402; Fri, 30 Sep 2016 09:06:42 -0700 (PDT) Received: from trpusmneagrly02.int.westgroup.com (relay2 [163.231.22.113]) by mailout2-trp.thomsonreuters.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8UG6fDs015058 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 30 Sep 2016 16:06:41 GMT Received: from EAGE-ERFPHUB06.ERF.thomson.com (c068swu.ten.thomsonreuters.com [10.176.13.5]) by trpusmneagrly02.int.westgroup.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8UG6dq0023747; Fri, 30 Sep 2016 16:06:40 GMT Received: from C111NTDEMBX52.ERF.thomson.com ([fe80::258d:aef3:9aa7:4f92]) by EAGE-ERFPHUB06.ERF.thomson.com ([fe80::5082:a4a:fee9:2e9b%13]) with mapi id 14.03.0235.001; Fri, 30 Sep 2016 11:05:39 -0500 From: To: Thread-Topic: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 Thread-Index: AQHR97sHHolpNcZOKUiDVS9AesG7WaCRmU6ggADeAfA= Date: Fri, 30 Sep 2016 16:05:39 +0000 Message-ID: <4A496052E7B7E84A9324854763C616FA2E72DE2C@C111NTDEMBX52.ERF.thomson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.30.9] x-tm-as-product-ver: SMEX-11.0.0.4255-8.000.1202-22610.000 x-tm-as-result: No--41.604200-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: bess@ietf.org, draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org Subject: Re: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-updates-03 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 16:06:51 -0000 Support Arkadiy Gulko -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux Sent: Tuesday, August 16, 2016 8:37 AM To: bess@ietf.org Cc: draft-zzhang-bess-evpn-bum-procedure-updates@ietf.org Subject: [bess] Poll for adoption: draft-zzhang-bess-evpn-bum-procedure-upd= ates-03 Hello working group, This email starts a two-week poll on adopting draft-zzhang-bess-evpn-bum-procedure-updates-03 [1] as a Working Group Docu= ment. Please state on the list if you support adoption or not (in both cases, ple= ase also state the reasons). This poll runs until *the 30th of August*. We are also polling for knowledge of any undisclosed IPR that applies to th= is Document, to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or Contributor of this Document please respo= nd to this email and indicate whether or not you are aware of any relevant = undisclosed IPR. The Document won't progress without answers from all the A= uthors and Contributors. No IPR has been disclosed against this Document If you are not listed as an Author or Contributor, then please explicitly r= espond 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dzzhang-2Dbess-2Devpn-2Dbum-2Dprocedure-2Dupdates_&d=3DCwICAg&c= =3D4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=3DehSnYXpW1Q0q-mKIFgK7W4u1= 2zTey2bOkBFtIeYOKk4&m=3DXiwx2KbAivF52D3S04U-Gs9g-52KWrEBFx9rfKrD0sw&s=3DpVc= _nWhDZlVE7ZcTfqlWrD4M_oiwP9EvBQCnhpkLLzc&e=3D=20 _______________________________________________ BESS mailing list BESS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_bess&d=3DCwICAg&c=3D4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r= =3DehSnYXpW1Q0q-mKIFgK7W4u12zTey2bOkBFtIeYOKk4&m=3DXiwx2KbAivF52D3S04U-Gs9g= -52KWrEBFx9rfKrD0sw&s=3DvHCEI0SbhId50-KVxyYFR7ejuJ6mOrL460yi7GBpYWU&e=3D=20