From nobody Wed Jun 1 00:27: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 0DBD712B038 for ; Wed, 1 Jun 2016 00:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OFylX8XndeN7 for ; Wed, 1 Jun 2016 00:27:04 -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 08030128E19 for ; Wed, 1 Jun 2016 00:27:03 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 000092B7455FA for ; Wed, 1 Jun 2016 07:26:59 +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 u517R1q1029697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 1 Jun 2016 07:27:01 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 u517Qs7I021304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Jun 2016 09:27:01 +0200 Received: from [135.224.208.165] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Jun 2016 09:26:51 +0200 Message-ID: <574E8E3A.1030300@alcatel-lucent.com> Date: Wed, 1 Jun 2016 09:26:50 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <572B2655.3020605@alcatel-lucent.com> <57440B67.7070005@alcatel-lucent.com> In-Reply-To: <57440B67.7070005@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-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: Wed, 01 Jun 2016 07:27:07 -0000 WG, we have now received an answer from all the authors and to their knowledge there is no undisclosed IPR that relates to this draft. Sami, please update the draft and make sure that *all* the authors are identified on the submission page, with their latest address, before submitting the draft to publication (the draft alias is incomplete/incorrect). And please get back to the WG with a synthesis of the changes brought to the draft. -m Le 24/05/2016 10:05, Martin Vigoureux a écrit : > WG, Authors, > > we are past the deadline for this WG LC. > I am still waiting for statements from authors. > In the meantime could you update the draft to reflect the necessary > changes which were identified as part of the WG LC. > In doing so, could you trim the list of authors to max 5 on the first > page and make sure the e-mail addresses are all correct. > > Beyond that we are ready to go as we have knowledge of implementations. > > Thank you > -m > > Le 05/05/2016 12:54, EXT Martin Vigoureux a écrit : >> Hello Working Group, >> >> Please read carefully, this e-mail contains new elements compared to >> other WG LCs. >> >> This email starts a Working Group Last Call on >> draft-ietf-bess-evpn-vpws-03 [1]. >> >> ¤ Please read the document if you haven't read the most recent >> version yet, and send your comments to the list, no later than >> *20th of May*. >> Note that this is *not only* a call for comments on the document, but >> also a call for support (or not) publishing this document as a Proposed >> Standard RFC. >> >> ¤ We are also polling for knowledge of any undisclosed IPR that applies >> to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed >> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >> for more details) prior to moving forward. >> If you are listed as a document 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. >> Two IPR disclosures exist against previous revisions of this document >> [2]. >> >> ¤ We are also polling for knowledge of implementations of part or all of >> what this document specifies. This information is expected as per [3]. >> Please inform the mailing list, the chairs, or only one of the chairs. >> >> ¤ Finally, if someone wishes to volunteer to be Document Shepherd for >> this document, please let us know. >> >> Thank you >> M&T >> >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ >> [2] >> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws >> >> >> [2] >> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >> >> _______________________________________________ >> 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 Wed Jun 1 00:30:11 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 5E52412B038; Wed, 1 Jun 2016 00:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 PRvSE2vWeh3Z; Wed, 1 Jun 2016 00:30:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F887128E19; Wed, 1 Jun 2016 00:30:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLE41393; Wed, 01 Jun 2016 07:30:00 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 1 Jun 2016 08:29:59 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Wed, 1 Jun 2016 15:29:45 +0800 From: Mach Chen To: Glenn Mansfield Keeni , Benoit Claise , "thomas.morin@orange.com" Thread-Topic: MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt Thread-Index: AQHRlTmGDHBP+/aDVkWEHjJ7RACieZ/UgMDw Date: Wed, 1 Jun 2016 07:29:45 +0000 Message-ID: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <570DC523.3040907@cysols.com> In-Reply-To: <570DC523.3040907@cysols.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.574E8EF9.0032, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3ada6b75958f90a5447364c7c0924716 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 07:30:10 -0000 Hi authors, I saw the discussions between you and Glenn about l2l3 mvpn mib and you hav= e already submitted the 02 version to address the comments.=20 But I did not see any response to the below mvpn mib review and comments(ma= ybe I missed something), given that we have plan to progress the mvpn-mib a= nd l2l3-mvpn-mib documents together, what's your plan about this document? Best regards, Mach > -----Original Message----- > From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] > Sent: Wednesday, April 13, 2016 12:04 PM > To: Benoit Claise; thomas.morin@orange.com > Cc: ops-ads@ietf.org; Martin Vigoureux; Mach Chen; Jeffrey (Zhaohui) Zhan= g; > bess@ietf.org > Subject: MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt >=20 > Hi, > I have been asked to do a MIB Doctors review of > draft-ietf-bess-mvpn-mib-02.txt. >=20 > The comments are attached. > You will note that this is preliminary review. There are some generic com= ments > which apply to all the scalars and tables. Please take care of those and = then we > will get onto the next phase. >=20 > Hope this helps. >=20 >=20 > Glenn From nobody Wed Jun 1 07:38:37 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 7476D12D51A for ; Wed, 1 Jun 2016 07:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCdgKAwBKXnz for ; Wed, 1 Jun 2016 07:38:34 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (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 3DDB012D1BC for ; Wed, 1 Jun 2016 07:38:34 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id f144so4104585pfa.2 for ; Wed, 01 Jun 2016 07:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YrLzNOHwouShWYKjcypexpMbfJrGayH7ODx2exSnmMo=; b=pBkIE4/L5D3kgh3SHklYUpyTc0vVT5WKOFBsbrOwDrNLDR4jMyMeCEF1gY3hvVCXJV IA3yMutVtHfsn8T40aY49YZ15xd9UVLffet6kUDHaMB+ZEia7N3EnnWqHbKoTAIWtnYb fVeb1Pv8PwWsnvpVba1RyHLa3C3VcqyvjFsfehOZYMwUl1FEe4mlTKIgfTRZYXChACaS 0i/Ao6v3gWvvbrk0wq873KAFmrzJab35+HX3bRqlLtLb042U9g6gaCwt0Ue8aecG5XEG DWQgShwXs19lEVNrPfTuSaNel+i89dJKyPav9TNTLqxPrLbKvt190T9NVIX9sW7TplII scLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YrLzNOHwouShWYKjcypexpMbfJrGayH7ODx2exSnmMo=; b=TDarRowCwagxV4XU4+YV558kX9fHEBdkQJi6crS5cw7xX2nbHLxy1SmZrjRVyrSYNL OoOm0kdL6CFBDUvXYr2p2Ajx88n0nrlHY4Gj/55rvxDJfNgWcLfXOqvMFdo13ZI+gZ1U uvi+MZFi6kavsn1/ATWMhLHdgo8/VFrmGS49mdMo1Ra2085vrY0OVSGbOd3byg2o60lP tuSGDi9NEgFP2KLW2FZ4D5tP+/c+Y8vtdI2A/PtEHXHhpp0BWha6NuzniSfOpPg4W0y9 SyDJzbbzKHQMdD77jivXkEGNt73D7NEZWWyUb2iHx6QsOCSsRYrN5z2aQ8Jfi2ITGshi w07Q== X-Gm-Message-State: ALyK8tLkYUnbWFaY06KKkg/12d3IpXGgS07tJ5GRw8vWEsITdsLtD65b+tWhMzV8NZgG1Q== X-Received: by 10.98.27.215 with SMTP id b206mr9433829pfb.61.1464791913739; Wed, 01 Jun 2016 07:38:33 -0700 (PDT) Received: from [30.41.60.243] ([172.56.17.232]) by smtp.gmail.com with ESMTPSA id o87sm48732408pfa.75.2016.06.01.07.38.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 07:38:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Sami Boutros X-Mailer: iPhone Mail (12B466) In-Reply-To: <574E8E3A.1030300@alcatel-lucent.com> Date: Wed, 1 Jun 2016 07:38:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97B253A7-CF9D-4628-9365-EEA86D94F33B@gmail.com> References: <572B2655.3020605@alcatel-lucent.com> <57440B67.7070005@alcatel-lucent.com> <574E8E3A.1030300@alcatel-lucent.com> To: Martin Vigoureux Archived-At: Cc: "" Subject: Re: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-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: Wed, 01 Jun 2016 14:38:36 -0000 Sure Martin, Will do. Sami Sent from my iPhone > On Jun 1, 2016, at 12:26 AM, Martin Vigoureux = wrote: >=20 > WG, >=20 > we have now received an answer from all the authors and to their knowledge= there is no undisclosed IPR that relates to this draft. >=20 > Sami, please update the draft and make sure that *all* the authors are ide= ntified on the submission page, with their latest address, before submitting= the draft to publication (the draft alias is incomplete/incorrect). >=20 > And please get back to the WG with a synthesis of the changes brought to t= he draft. >=20 > -m >=20 > Le 24/05/2016 10:05, Martin Vigoureux a =C3=A9crit : >> WG, Authors, >>=20 >> we are past the deadline for this WG LC. >> I am still waiting for statements from authors. >> In the meantime could you update the draft to reflect the necessary >> changes which were identified as part of the WG LC. >> In doing so, could you trim the list of authors to max 5 on the first >> page and make sure the e-mail addresses are all correct. >>=20 >> Beyond that we are ready to go as we have knowledge of implementations. >>=20 >> Thank you >> -m >>=20 >> Le 05/05/2016 12:54, EXT Martin Vigoureux a =C3=A9crit : >>> Hello Working Group, >>>=20 >>> Please read carefully, this e-mail contains new elements compared to >>> other WG LCs. >>>=20 >>> This email starts a Working Group Last Call on >>> draft-ietf-bess-evpn-vpws-03 [1]. >>>=20 >>> =C2=A4 Please read the document if you haven't read the most recent >>> version yet, and send your comments to the list, no later than >>> *20th of May*. >>> Note that this is *not only* a call for comments on the document, but >>> also a call for support (or not) publishing this document as a Proposed >>> Standard RFC. >>>=20 >>> =C2=A4 We are also polling for knowledge of any undisclosed IPR that app= lies >>> to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed >>> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 >>> for more details) prior to moving forward. >>> If you are listed as a document 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. >>> Two IPR disclosures exist against previous revisions of this document >>> [2]. >>>=20 >>> =C2=A4 We are also polling for knowledge of implementations of part or a= ll of >>> what this document specifies. This information is expected as per [3]. >>> Please inform the mailing list, the chairs, or only one of the chairs. >>>=20 >>> =C2=A4 Finally, if someone wishes to volunteer to be Document Shepherd f= or >>> this document, please let us know. >>>=20 >>> Thank you >>> M&T >>>=20 >>>=20 >>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ >>> [2] >>> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf-= bess-evpn-vpws >>>=20 >>>=20 >>> [2] >>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >>>=20 >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Jun 2 02:17:03 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 2D6EA12B029 for ; Thu, 2 Jun 2016 02:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vYBRFiaBOn1Z for ; Thu, 2 Jun 2016 02:16:45 -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 5E40312B02D for ; Thu, 2 Jun 2016 02:16:37 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 90DCF8BB3477F; Thu, 2 Jun 2016 09:16:34 +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 u529GZic019659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Jun 2016 09:16:36 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 u529GZuK021713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jun 2016 09:16:35 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.191]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 2 Jun 2016 05:16:35 -0400 From: "Dolganow, Andrew (Nokia - SG)" To: "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02 Thread-Index: AQHRu0FebVA/eSCYZUqNSSINE8i08J/V6Gmg Date: Thu, 2 Jun 2016 09:16:35 +0000 Message-ID: References: <574C626E.2070801@alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-dolganow-bess-mvpn-expl-track@tools.ietf.org" , "Vigoureux, Martin \(Nokia - FR\)" , Eric C Rosen Subject: Re: [bess] Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02 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, 02 Jun 2016 09:16:53 -0000 All, Nokia (Alcatel-Lucent) may have IPR that applies to some parts of the draft= . I am following up with our IPR to see whether disclosures were done in th= e past.=20 Andrew Sent from my iPhone > On May 31, 2016, at 9:36 PM, Eric C Rosen wrote: >=20 > I am not aware of any undisclosed IPR applying to this document. >=20 >=20 >> On 5/30/2016 11:55 AM, Martin Vigoureux wrote: >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >> draft-dolganow-bess-mvpn-expl-track-02 [1] as a Working Group Document. >>=20 >> Please state on the list if you support adoption or not (in both cases, = please also state the reasons). >>=20 >> This poll runs until *the 13th of June*. >>=20 >> 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 >>=20 >> If you are not listed as an author or contributor, then please explicitl= y respond only if you are aware of any IPR that has not yet been disclosed = in conformance with IETF rules. >>=20 >> Thank you >>=20 >> Martin & Thomas >> bess chairs >>=20 >> [1] https://datatracker.ietf.org/doc/draft-dolganow-bess-mvpn-expl-track >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Thu Jun 2 07:50: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 0CE7612D1D8 for ; Thu, 2 Jun 2016 07:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 6362EF3Mf5kh for ; Thu, 2 Jun 2016 07:50:42 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 5C3D312D0ED for ; Thu, 2 Jun 2016 07:50:42 -0700 (PDT) X-AuditID: 60721c4b-317ff70000009513-2e-575047bdf2d6 Received: from VAADCEX14.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 77.C4.38163.DB740575; Thu, 2 Jun 2016 10:50:39 -0400 (EDT) Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX14.cable.comcast.com (147.191.102.81) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 2 Jun 2016 10:50:36 -0400 Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1130.005; Thu, 2 Jun 2016 10:50:36 -0400 From: "Walker, Jason" To: "Tapraj Singh (tapsingh)" , "Shah, Himanshu" , Luay Jalil , Thomas Morin Thread-Topic: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang Thread-Index: AQHRpg/CJUDKb6mTykitYHVlzzYLZ5+qZ0AAgABKIgCAACAVAIAfWScAgAxFbtA= Date: Thu, 2 Jun 2016 14:50:36 +0000 Message-ID: <623141ade6184cc5944ff3c7a3adf0d5@VAADCEX15.cable.comcast.com> References: <572A0497.5080506@orange.com> <40746B2300A8FC4AB04EE722A593182BABDF9729@ONWVEXCHMB04.ciena.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsWSUOxpobvfPSDcYMpxLYsVx2cyW+ya8ZjN YtfG1YwWny4tZrd4/biF3WLDvqNsDmweZ2/+Y/GY8nsjq8fOWXfZPZYs+cnk0fLsJJvHl8uf 2QLYorhsUlJzMstSi/TtErgyNvffZSlYIVEx+ctu5gbGNSJdjJwcEgImEq+7u5i7GLk4hARm MkkcfrSIFcLZzygxf/VnNgjnBKPEgwMzgRwODjYBc4ldh51A4iICSxglHvcdYgUZxSxQLDHx 1W4WEFtYwFHi5PRWZhBbRMBJ4tTsO2wQtp/Em13/mUBsFgEVic6e20wgM3kFvCS2PMiF2PWH UaKtfQFYDaeAvsT7H//A5jAKiEl8P7WGCWKXuMStJ/OZIF4QkFiy5zwzhC0q8fLxP1YI20Bi 69J9LBC2vMSRCf9YIHp1JBbs/sQGYWtLLFv4GqyXV0BQ4uTMJ1D14hKHj+xgncAoMQvJullI 2mchaZ+FpH0BI8sqRrmyxMSU5NyM/NISA0O95MSknFS95Pzc5MTiEhC9iREU1UUy3jsY1/10 P8QowMGoxMNrbhUQLsSaWFZcmXuIUYKDWUmEV8EFKMSbklhZlVqUH19UmpNafIhRmoNFSZy3 94dtuJBAemJJanZqakFqEUyWiYNTqoEx2ltgrpqdrajigcXzTsw8k3CyoSt+4btyy3MlK/gs vpXeMXUP25H574LDLZ+Z/UfSL09I39+bVbqwps5s9fd9syLEaj8fzd+VNDs64mbKN6bfu88s qHYzenxCUtEpjbOu2vWuQvOSrSvnbrw4V0XO7taFbVfv3+I9qnLlw/35V+7tMObKLf4fpcRS nJFoqMVcVJwIAMFM7W/mAgAA Archived-At: Cc: BESS , "draft-shah-bess-l2vpn-yang@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang 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, 02 Jun 2016 14:50:45 -0000 Not aware of any relevant IPR -----Original Message----- From: Tapraj Singh (tapsingh) [mailto:tapsingh@cisco.com]=20 Sent: Wednesday, May 25, 2016 11:27 AM To: Shah, Himanshu ; Luay Jalil ; Tho= mas Morin Cc: BESS ; draft-shah-bess-l2vpn-yang@tools.ietf.org Subject: Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang Resending due to mail delivery messages Support as co-author Not aware of any relevant IPR Thanks, Tapraj On 5/5/16, 9:43 AM, "Tapraj Singh (tapsingh)" wrote: >As a co-author, I support this draft. > > >Thanks >Tapraj > >On 5/5/16, 7:48 AM, "BESS on behalf of Shah, Himanshu" > wrote: > >>Support as co-author. >>I am not aware of any IPR that applies to this draft. >> >>Himanshu using iPad (so excuse the auto-corrects...)=20 >>________________________________________ >>From: BESS [bess-bounces@ietf.org] On Behalf Of Luay Jalil=20 >>[luayjalil@gmail.com] >>Sent: Thursday, May 05, 2016 6:23 AM >>To: Thomas Morin >>Cc: BESS; draft-shah-bess-l2vpn-yang@tools.ietf.org >>Subject: Re: [bess] Poll for adoption: draft-shah-bess-l2vpn-yang >> >>Resending due to mail delivery messages >> >>Support as co-author >> >>Not aware of any relevant IPR >> >>Thanks, >>Luay >> >>On May 4, 2016 9:18 AM, "Thomas Morin" >>> wrote: >>Hello working group, >> >>This email starts a two-week poll on adopting=20 >>draft-shah-bess-l2vpn-yang [1] as a working group document. >> >>Please state on the list if you support adoption or not (in both=20 >>cases, please also state the reasons). >> >>This poll runs until *May 25th*. >> >>This call runs in parallel with the adoption call on=20 >>draft-brissette-bess-evpn-yang hence the extended period. >> >> >>We are *coincidentally* also polling for knowledge of any other IPR=20 >>that applies to this draft, to ensure that IPR has been disclosed in=20 >>compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for=20 >>more details). >> >>=3D=3D> *If* you are listed as a document author or contributor please=20 >>respond to this email and indicate whether or not you are aware of any=20 >>relevant IPR. >> >>The draft will not be adopted until a response has been received from=20 >>each author and contributor. >> >>If you are not listed as an author or contributor, then please=20 >>explicitly respond only if you are aware of any IPR that has not yet=20 >>been disclosed in conformance with IETF rules. >> >>Thank you, >> >>Martin & Thomas >>bess chairs >> >>[1] https://datatracker.ietf.org/doc/draft-shah-bess-l2vpn-yang >> >>_______________________________________________ >>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 Jun 3 05:38:11 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 ECCA012D63B for ; Fri, 3 Jun 2016 05:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.426, 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 XGb-zNTe_wPq for ; Fri, 3 Jun 2016 05:38:08 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id E986E12D120 for ; Fri, 3 Jun 2016 05:38:07 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40472E30083; Fri, 3 Jun 2016 14:38:07 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 27F93E30082; Fri, 3 Jun 2016 14:38:07 +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.266.1; Fri, 3 Jun 2016 14:38:05 +0200 To: References: <572A0497.5080506@orange.com> From: Thomas Morin Organization: Orange Message-ID: <4bc73e4f-9b3b-dac2-67cd-6034271df2e3@orange.com> Date: Fri, 3 Jun 2016 14:38:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <572A0497.5080506@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-shah-bess-l2vpn-yang@tools.ietf.org Subject: [bess] draft-shah-bess-l2vpn-yang is adopted (was Re: Poll for adoption: draft-shah-bess-l2vpn-yang) 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, 03 Jun 2016 12:38:10 -0000 Hi everyone, We've just received the last pending answers on the reminder IPR question. We have consensus for this draft to become a BESS WG document. Authors can you please repost as draft-ietf-bess-l2vpn-yang ? You can include the agreed changes in -00, in particular the ones that are small. You can also cover them in next revision. Additionally, we encourage you to trim the list of authors right now, because with 20 co-authors (!) you are beating records, and well beyond the recommended limit of 5 authors. One option you can consider is keep only editors in the list of authors and list everyone else in a "Contributors" section. Best, -Thomas 2016-05-04, Thomas Morin: > Hello working group, > > This email starts a two-week poll on adopting > draft-shah-bess-l2vpn-yang [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 *May 25th*. > > This call runs in parallel with the adoption call on > draft-brissette-bess-evpn-yang hence the extended period. > > > We are *coincidentally* also polling for knowledge of any other > 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-shah-bess-l2vpn-yang From nobody Sun Jun 5 06:21:41 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 CC0A412B02A; Sun, 5 Jun 2016 06:21:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160605132138.22904.71899.idtracker@ietfa.amsl.com> Date: Sun, 05 Jun 2016 06:21:38 -0700 Archived-At: Subject: [bess] The BESS WG has placed draft-dolganow-bess-mvpn-expl-track in state "Call For Adoption By WG Issued" X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 13:21:39 -0000 The BESS WG has placed draft-dolganow-bess-mvpn-expl-track in state Call For Adoption By WG Issued (entered by Martin Vigoureux) The document is available at https://datatracker.ietf.org/doc/draft-dolganow-bess-mvpn-expl-track/ From nobody Mon Jun 6 08:44:09 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 D618B12D7F2; Mon, 6 Jun 2016 08:44:08 -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 5XbHE5XbKPyk; Mon, 6 Jun 2016 08:44:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFAE12B048; Mon, 6 Jun 2016 08:44:06 -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=3gfZhyqpLErYcSKdU7TFpR8q4iLBaVN3IMEYepsqDxc=; b=REQdLqkprgik/xpG/OdpU8xr+yUOsLb0H+CPI8ZTLeDuEiIqo6+xXk00BPrn9QBAuCfjztmvW5dCE/Nvg8uMhCjw+RiWh0p8bQ6fcM2MMeDLKy00YvLzcZoaArZDaoPf0OGeymf9T1mW68dzJ0d30oT0k3AYQ+ofFeINYP7SCOg= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1716.namprd05.prod.outlook.com (10.163.120.19) with Microsoft SMTP Server (TLS) id 15.1.511.8; Mon, 6 Jun 2016 15:44:05 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0511.010; Mon, 6 Jun 2016 15:44:05 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Mach Chen , Glenn Mansfield Keeni , Benoit Claise , "EXT - thomas.morin@orange.com" Thread-Topic: MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt Thread-Index: AQHRu9dwB1nsj+PRyUKPSWnDiksWhp/cnGMg Date: Mon, 6 Jun 2016 15:44:05 +0000 Message-ID: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <570DC523.3040907@cysols.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=zzhang@juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: c744eb89-5dce-43df-2d57-08d38e21644a x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1716; 5:YdkqKIi0exZl4VOnlZK1Gj+eKYGB9pNWytSKZdrnMeToTNHFTMGmFHyGI30ZkkFWPvFqgKbsXVJCqpzIXJE4eHpwsbn6Ix/vU5pKity8ANT2fEywbT6wKy3UQBK8PL/sFRZYhFSZFxp1B0dkIrrgRw==; 24:/9UCnhVmNwgVdgMDPrxyx9tZ8RDeH00pZgBcIGYJ8GpetnGYNWCXrPN2xhSe9o/iQtMpufJSA0+4I3F2uCYBrIKPgtxZmB2Lb3xzbm6ppZk=; 7:bFZX3b0OuqOVXTe2ZQSeAKC4cfCpIzN3FdQqTnbPr/gB6nlInf8D0PBAHyV7hZ0lOXScb6rTL1HiME73SYgQnnnDm2E8Xg5BHviy29m70rsukNZM5Uo2Q6IyP+as39YWhCaZPZtt864/n+fuO7wKRvhhfvBsEhrcftt+aQXfxrbt8zstThEul+LHca3RyIgClG5ORkmxedaqg3ddS0BzWDNyxsoID9o8YSNQLwWdt7Y= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1716; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(95692535739014)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1716; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1716; x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(129404003)(199003)(43544003)(13464003)(189002)(377454003)(74316001)(8936002)(105586002)(81166006)(81156014)(8676002)(11100500001)(99286002)(9686002)(106116001)(76576001)(33656002)(230783001)(106356001)(5890100001)(10400500002)(68736007)(122556002)(5004730100002)(3660700001)(3280700002)(5003600100002)(4326007)(66066001)(586003)(5002640100001)(15975445007)(189998001)(87936001)(54356999)(76176999)(92566002)(50986999)(3846002)(93886004)(101416001)(5008740100001)(6116002)(102836003)(97736004)(5001770100001)(19580395003)(19580405001)(2900100001)(2950100001)(77096005)(2906002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1716; H:BLUPR0501MB1715.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:23 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: 06 Jun 2016 15:44:05.6082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1716 Archived-At: Cc: "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.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, 06 Jun 2016 15:44:09 -0000 Mach, Glenn, I've addressed most of the comments from Glenn on the l2l3 mvpn mib and had= started on addressing some comments on mvpn mib, but I've been side tracke= d and am making very slow progress. I will try to pick it up again soon. Thanks. Jeffrey > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Wednesday, June 01, 2016 3:30 AM > To: Glenn Mansfield Keeni ; Benoit Claise > ; EXT - thomas.morin@orange.com > > Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; Marti= n > Vigoureux ; bess@ietf.org > Subject: Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt >=20 > Hi authors, >=20 > I saw the discussions between you and Glenn about l2l3 mvpn mib and you > have already submitted the 02 version to address the comments. >=20 > But I did not see any response to the below mvpn mib review and > comments(maybe I missed something), given that we have plan to progress > the mvpn-mib and l2l3-mvpn-mib documents together, what's your plan about > this document? >=20 > Best regards, > Mach >=20 > > -----Original Message----- > > From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] > > Sent: Wednesday, April 13, 2016 12:04 PM > > To: Benoit Claise; thomas.morin@orange.com > > Cc: ops-ads@ietf.org; Martin Vigoureux; Mach Chen; Jeffrey (Zhaohui) > Zhang; > > bess@ietf.org > > Subject: MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt > > > > Hi, > > I have been asked to do a MIB Doctors review of > > draft-ietf-bess-mvpn-mib-02.txt. > > > > The comments are attached. > > You will note that this is preliminary review. There are some generic > comments > > which apply to all the scalars and tables. Please take care of those an= d > then we > > will get onto the next phase. > > > > Hope this helps. > > > > > > Glenn >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jun 6 09:51: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 42CAB12D150; Mon, 6 Jun 2016 09:51:36 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606165136.20846.84109.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 09:51:36 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-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: Mon, 06 Jun 2016 16:51:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : VPWS support in EVPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jeff Tantsura Dirk Steinberg Thomas Beckhaus Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-04.txt Pages : 14 Date : 2016-06-06 Abstract: This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-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 Mon Jun 6 09:57:17 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 1019812D84E for ; Mon, 6 Jun 2016 09:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 kLPjFOAbAjXk for ; Mon, 6 Jun 2016 09:57:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1971212D52D for ; Mon, 6 Jun 2016 09:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18298; q=dns/txt; s=iport; t=1465232233; x=1466441833; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6OpJn1XAfzVpVggVPp0rLwlCLVfQSgMNH8TuNpl194U=; b=lBuR2x/vhyKwE5mgSzeFn1A8FXJMNRsV9VcmMKTpm1XLiT9is2RP0gzy pSY6xIYM4rDxb4dqnllztZUAlw5I7ufeXRQOtz+nnEEcIjSDqva0uYunc SITmZxs94phvAPTHoZySdoFrK4jsrLyAwA7zQqFIrSjk1a3MFNeY8EN42 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgBCqlVX/51dJa1agztWbw4GulSBe?= =?us-ascii?q?hcLhXACHIEXOBQBAQEBAQEBZSeERQEBAQQBAQEaBhE5ARcEAgEIEQQBAQECAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBEhSIGw6pd5ECAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA?= =?us-ascii?q?YhwgQOEEhEBHBcVglWCWQWYSAGGAogjgWmEUIMshTmPWQEeNoNubohkNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,428,1459814400"; d="scan'208";a="112286768" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 16:57:12 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u56GvCUS029090 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 16:57:12 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 12:57:11 -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.1104.009; Mon, 6 Jun 2016 12:57:11 -0400 From: "Ali Sajassi (sajassi)" To: "Ali Sajassi (sajassi)" , "thomas.morin@orange.com" , "Jeffrey (Zhaohui) Zhang" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaME/U9KT8MU0ut9l7k3idEc58OWnfAgAhLYwCAAYwoAIBC0CQAgBXcMACARGjgAIAS+kOAgBUQT4A= Date: Mon, 6 Jun 2016 16:57:11 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] WG Last Call on 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: Mon, 06 Jun 2016 16:57:16 -0000 DQpIaSBUaG9tYXMsDQoNCklzIHRoZXJlIGFueXRoaW5nIGVsc2UgeW91IG5lZWQgZnJvbSBtZSBv ciBvdGhlciBjby1hdXRob3JzIHRvIHByb2dyZXNzDQp0aGlzIGRhZnQ/IFRoZSBXRyBMQyB3YXMg Y29tcGxldGVkIGJlZm9yZSBsYXN0IElFVEYuDQoNClJlZ2FyZHMsDQpBbGkgDQoNCk9uIDUvMjQv MTYsIDEyOjE4IEFNLCAiQWxpIFNhamFzc2kgKHNhamFzc2kpIiA8c2FqYXNzaUBjaXNjby5jb20+ IHdyb3RlOg0KDQo+DQo+SGkgVGhvbWFzLA0KPg0KPkNhbiB5b3UgcGxlYXNlIHByb2dyZXNzIHRo aXMgZHJhZnQuIFRoZSBXRyBMQyB3YXMgY29tcGxldGVkIG9uIDMvMjkgYW5kDQo+YWxsIGNvbW1l bnRzIGV4Y2VwdCBhIHNpbmdsZSBvcHRpb25hbCBjb21tZW50IHdlcmUgYWRkcmVzc2VkIGJlZm9y ZSB0aGUNCj5sYXN0IElFVEYuIFRoZSBzaW5nbGUgb3B0aW9uYWwgY29tbWVudCB3YXMgYWRkcmVz c2VkIGNvdXBsZSBvZiB3ZWVrcyBhZ28NCj5hbmQgdGhlIGRyYWZ0IHdhcyByZS1wdWJsaXNoZWQg dGhlbi4NCj4NCj5SZWdhcmRzLA0KPkFsaQ0KPg0KPg0KPk9uIDUvMTEvMTYsIDEwOjMwIFBNLCAi QkVTUyBvbiBiZWhhbGYgb2YgQWxpIFNhamFzc2kgKHNhamFzc2kpIg0KPjxiZXNzLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNhamFzc2lAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+DQo+ PkhpIFRob21hcywNCj4+DQo+PkkganVzdCBtYWRlIHRoZSBmaW5hbCBlZGl0cyB0byBldnBuLWV0 cmVlIGRyYWZ0IGFuZCBwdWJsaXNoZWQgaXQgYXMNCj4+cmV2MDUuDQo+Pg0KPj5SZWdhcmRzLA0K Pj5BbGkNCj4+DQo+Pk9uIDMvMjkvMTYsIDI6NDkgQU0sICJ0aG9tYXMubW9yaW5Ab3JhbmdlLmNv bSIgPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPg0KPj53cm90ZToNCj4+DQo+Pj5IaSBldmVyeW9u ZSwNCj4+Pg0KPj4+VGhpcyBXRyBMYXN0IENhbGwgaXMgbm93IGNsb3NlZCBhbmQgdGhlIGRvY3Vt ZW50IHdpbGwgbW92ZSB0byB0aGUgbmV4dA0KPj4+c3RlcHMgdG93YXJkIHB1YmxpY2F0aW9uLg0K Pj4+DQo+Pj5UaGUgbW9kaWZpY2F0aW9uIG1lbnRpb25lZCBiZWxvdyB3aWxsIGJlIGluY29ycG9y YXRlZCBpbiBuZXh0IHJlbGVhc2UuDQo+Pj4NCj4+PkJlc3QsDQo+Pj4NCj4+Pi1UaG9tYXMNCj4+ Pg0KPj4+DQo+Pj4NCj4+PjIwMTYtMDMtMTUsIEFsaSBTYWphc3NpIChzYWphc3NpKToNCj4+Pj4N Cj4+Pj4gSmVmZnJleSwNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24gMi8xLzE2LCAyOjQxIFBN LCAiSmVmZnJleSAoWmhhb2h1aSkgWmhhbmciIDx6emhhbmdAanVuaXBlci5uZXQ+DQo+Pj4+d3Jv dGU6DQo+Pj4+DQo+Pj4+PiBBbGksDQo+Pj4+Pg0KPj4+Pj4gT25lIG1vcmUgcXVlc3Rpb24gYWJv dXQgUEJCLUVWUE4uDQo+Pj4+Pg0KPj4+Pj4gRm9yIHRoZSByZWd1bGFyIEVWUE4sIHNlY3Rpb24g My4zLjIgdGFsa3MgYWJvdXQgYSBzaXR1YXRpb24gd2hlcmUgdGhlDQo+Pj4+PiBvbmx5IHRyYWZm aWMgaXMgQlVNLiBUaGVyZSBpcyBubyBuZWVkIGZvciBtYWMgbGVhcm5pbmcgaW4gdGhhdA0KPj4+ Pj5zaXR1YXRpb24uDQo+Pj4+Pg0KPj4+Pj4gRm9yIFBCQi1FVlBOLCBJIGFzc3VtZSB0aGlzIGlz IGFsc28gcG9zc2libGUuIFdpdGggdGhpcywgdGhlcmUgaXMgbm8NCj4+Pj4+bmVlZA0KPj4+Pj4g dG8gYWR2ZXJ0aXNlIHBlci1FUyBCLW1hYyBhZGRyZXNzZXMgLSBhIHNpbmdsZSBwYWlyIG9mIGds b2JhbA0KPj4+Pj5yb290L2xlYWYNCj4+Pj4+IEItbWFjIGFkZHJlc3NlcyBhcmUgZW5vdWdoLg0K Pj4+Pj4NCj4+Pj4+IFBlcmhhcHMgdGhpcyBjYW4gYmUgbWVudGlvbmVkIGZvciBwYXJpdHkvY29t cGxldGVuZXNzLiBPZiBjb3Vyc2UsDQo+Pj4+PnRoaXMNCj4+Pj4+aXMNCj4+Pj4+IG5vdCBhIGJp ZyBkZWFsIGFuZCBlaXRoZXIgd2F5IGl0J3MgZmluZSAtIGJ1dCBJIGRvIHdhbnQgdG8gYXNrIHRv DQo+Pj4+PmNvbmZpcm0NCj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcuDQo+Pj4+DQo+Pj4+IFdl4oCZ bGwgZG8uDQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+Pj4gQWxpDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4g SmVmZnJleQ0KPj4+Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+ IEZyb206IEFsaSBTYWphc3NpIChzYWphc3NpKSBbbWFpbHRvOnNhamFzc2lAY2lzY28uY29tXQ0K Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDEsIDIwMTYgMjowNCBBTQ0KPj4+Pj4+IFRv OiBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyA8enpoYW5nQGp1bmlwZXIubmV0PjsgRVhUIC0NCj4+ Pj4+PiB0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSA8dGhvbWFzLm1vcmluQG9yYW5nZS5jb20+OyBC RVNTDQo+Pj4+Pj48YmVzc0BpZXRmLm9yZz47DQo+Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4t ZXRyZWVAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW2Jlc3NdIFdHIExhc3Qg Q2FsbCBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0KPj4+Pj4+DQo+Pj4+Pj4gSGkgSmVm ZnJleSwNCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gWW91ciBjb21tZW50 cyBoZWxwcyB0aWdodGVuIHRoZSBkcmFmdCBzb21lDQo+Pj4+Pj5tb3JlLg0KPj4+Pj4+IEkNCj4+ Pj4+PiBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IGFuZCB3aWxsIHB1Ymxpc2ggaXQgbmV4dCAocmV2 MDQpLiBNYWpvcml0eSBvZg0KPj4+Pj4+dGhlDQo+Pj4+Pj4gY29tbWVudHMgd2VyZSBlZGl0b3Jp YWwgaW4gbmF0dXJlIGZvciBiZXR0ZXIgY2xhcmlmaWNhdGlvbnMuIFNpbmNlDQo+Pj4+Pj50aGUN Cj4+Pj4+PiBleGlzdGluZyBkcmFmdCAocmV2MDMpIHJlZmxlY3RzIHRoZSBjb25zZW5zdXMgcmVn YXJkaW5nIG91ciBzZXZlcmFsDQo+Pj4+Pj4gcm91bmRzDQo+Pj4+Pj4gb2YgZGlzY3Vzc2lvbnMg d2hlcmUgd2UgaGF2ZSB0YWtlbiBjYXJlIG9mIHRoZSB0ZWNobmljYWwgaXRlbXMsIGl0DQo+Pj4+ Pj5pcw0KPj4+Pj4+IGNvbnNpc3RlbnQgd2l0aCBvdXIgZXhwZWN0YXRpb24gb2Ygbm90IHNlZWlu ZyBhbnkgbWFqb3IgaXNzdWUgZHVyaW5nDQo+Pj4+Pj50aGUNCj4+Pj4+PiBMQy4gUGxlYXNlIHJl ZmVyIHRvIG15IHJlcGxpZXMgaW4gbGluZS4NCj4+Pj4+Pg0KPj4+Pj4+IENoZWVycywNCj4+Pj4+ PiBBbGkNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gT24gMS8yNy8xNiwgNToyNiBQTSwgIkJFU1Mg b24gYmVoYWxmIG9mIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIg0KPj4+Pj4+IDxiZXNzLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHp6aGFuZ0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4+ Pj4NCj4+Pj4+Pj4gSSB3YXMgaW52b2x2ZWQgaW4gcmVsZXZhbnQgZGlzY3Vzc2lvbnMsIGFuZCBo YXZlIHJldmlld2VkIG9uY2UgbW9yZQ0KPj4+Pj4+PmZvcg0KPj4+Pj4+PiB0aGlzIExDLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBJIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9uLCBidXQgd2l0aCB0aGUgZm9s bG93aW5nDQo+Pj4+Pj4+cXVlc3Rpb25zL2NvbW1lbnRzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAyLjEg U2NlbmFyaW8gMTogTGVhZiBPUiBSb290IHNpdGUocykgcGVyIFBFDQo+Pj4+Pj4+DQo+Pj4+Pj4+ ICAgIC4uLiBJZiB0aGUgbnVtYmVyIG9mIEVWSXMgaXMgdmVyeSBsYXJnZQ0KPj4+Pj4+PiAgICAo ZS5nLiwgbW9yZSB0aGFuIDMySyBvciA2NEspLCB0aGVuIFJUIHR5cGUgMCBhcyBkZWZpbmVkIGlu DQo+Pj4+Pj4+W1JGQzQzNjBdDQo+Pj4+Pj4+ICAgIFNIT1VMRCBiZSB1c2VkOyBvdGhlcndpc2Us IFJUIHR5cGUgMiBpcyBzdWZmaWNpZW50Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSRkMgNzE1MyBzaG91 bGQgYmUgcmVmZXJlbmNlZCBmb3IgIlR5cGUgMiIuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IERv bmUuDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWRkaXRpb25hbGx5LCB3aHkgaXMgMzJLIG1l bnRpb25lZD8gSSBjYW4gdW5kZXJzdGFuZCB0aGUgNjRrIHBhcnQuDQo+Pj4+Pj4NCj4+Pj4+PiBS ZW1vdmVkIDMySyBzaW5jZSB0aGUgZXhhbXBsZSBpcyBjbGVhciBlbm91Z2ggd2l0aCA2NEsNCj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAuLi4gdGhlIE1QTFMtZW5jYXBzdWxhdGVkIGZyYW1l cyBNVVNUIGJlIHRhZ2dlZCB3aXRoIGFuDQo+Pj4+Pj4+ICAgIGluZGljYXRpb24gb2Ygd2hldGhl ciB0aGV5IG9yaWdpbmF0ZWQgZnJvbSBhIExlYWYgQUMgb3Igbm90Lg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBQZXJoYXBzIGNoYW5nZSB0aGUgbGFzdCBsaW5lIHRvICJpbmRpY2F0aW9uIGlmIHRoZXkgb3Jp Z2luYXRlZCBmcm9tDQo+Pj4+Pj4+YQ0KPj4+Pj4+PiBMZWFmIEFDIj8gUGFja2V0cyBmcm9tIGEg cm9vdCBBQyBhcmUgbm90IHRhZ2dlZCB3aXRoIGEgbGVhZg0KPj4+Pj4+PmluZGljYXRpb24uDQo+ Pj4+Pj4NCj4+Pj4+PiBPSy4gQmV0dGVyIHlldC4gSXQgc2hvdWxkIHNheSDCs2luZGljYXRpb24g d2hlbiB0aGV5IG9yaWdpbmF0ZWQgZnJvbQ0KPj4+Pj4+YQ0KPj4+Pj4+IGxlYWYNCj4+Pj4+PiBB Q8KyLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIE90aGVyIG1lY2hhbmlzbXMgZm9yIGlk ZW50aWZ5aW5nIHdoZXRoZXIgYW4gZWdyZXNzIEFDIGlzIGEgcm9vdA0KPj4+Pj4+Pm9yDQo+Pj4+ Pj4+ICAgIGxlYWYgaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBTaG91bGQgImVncmVzcyIgYmUgImluZ3Jlc3MiIGluIHRoZSBhYm92ZSBwYXJh Z3JhcGg/IE9yIHNpbXBseQ0KPj4+Pj4+PnJlbW92ZWQ/DQo+Pj4+Pj4NCj4+Pj4+PiBOaWNlIGNh dGNoISBJdCBpcyDCs2luZ3Jlc3PCsi4gSXQgaXMgbm93IGNvcnJlY3RlZC4NCj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAuLi4gVGhpcyBMZWFmIE1QTFMgbGFiZWwgaXMgYWR2ZXJ0aXNlZCB0 byBvdGhlciBQRSBkZXZpY2VzLA0KPj4+Pj4+PiAgICB1c2luZyBhIG5ldyBFVlBOIEV4dGVuZGVk IENvbW11bml0eSBjYWxsZWQgRS1UUkVFIEV4dGVuZGVkDQo+Pj4+Pj4+Q29tbXVuaXR5DQo+Pj4+ Pj4+ICAgIChzZWN0aW9uIDUuMSkgYWxvbmcgd2l0aCBhbiBFdGhlcm5ldCBBLUQgcGVyIEVTIHJv dXRlIHdpdGggRVNJDQo+Pj4+Pj4+b2YNCj4+Pj4+Pj4gICAgemVybyBhbmQgYSBzZXQgb2YgUm91 dGUgVGFyZ2V0cyAoUlRzKSBjb3JyZXNwb25kaW5nIHRvIGFsbCB0aGUNCj4+Pj4+Pj5sZWFmDQo+ Pj4+Pj4+ICAgIEFDcyBvbiB0aGUgUEUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFBlcmhhcHMgY2hhbmdl IHRoZSBsYXN0IHNlbnRlbmNlIHRvICIuLi4gY29ycmVzcG9uZGluZyB0byBhbGwgRVZJcw0KPj4+ Pj4+PnRoYXQNCj4+Pj4+Pj4gaGF2ZSBsZWFmIHNpdGVzIG9uIHRoZSBQRS4iDQo+Pj4+Pj4NCj4+ Pj4+PiBUaGUgc2Vjb25kIHRvIGxhc3Qgc2VudGVuY2Ugb2Ygc2VjdGlvbiAzLjIuMSBzYXlzIHRo ZSBzYW1lIHRoaW5nLiBJDQo+Pj4+Pj4gY2hhbmdlZCB0aGlzIHNlbnRlbmNlIGFuZCByZW1vdmVk IHRoZSAybmQgdG8gbGFzdCBzZW50ZW5jZS4NCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAzLjIu MyBCVU0gdHJhZmZpYyBvcmlnaW5hdGVkIGZyb20gYSBtdWx0aS1ob21lZCBzaXRlIG9uIGEgbGVh ZiBBQw0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICBJbiB0aGlzIHNjZW5hcmlvLCBpdCBpcyBhc3N1bWVk IHRoYXQgYSBtdWx0aS1ob21lZCBFdGhlcm5ldA0KPj4+Pj4+PlNlZ21lbnQNCj4+Pj4+Pj4gICAg KEVTKSBjYW4gaGF2ZSBhIG1peGVkIG9mIGJvdGggbGVhZiBhbmQgcm9vdCBBQ3Mgd2l0aCBlYWNo IEFDDQo+Pj4+Pj4+ICAgIGRlc2lnbmF0aW5nIGEgc3VibmV0IChlLmcuLCBhIFZMQU4pLg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBJIHVuZGVyc3RhbmQgdGhhdCBkaWZmZXJlbnQgVkxBTnMgb24gdGhlIHNh bWUgRVMgY291bGQgYmUgcm9vdHMgb3INCj4+Pj4+Pj4gbGVhdmVzLiBJIHN1cHBvc2UgaXQncyBt b3JlIGltcG9ydGFudCB0byBzYXkgdGhhdCBmb3IgdGhlIHNhbWUNCj4+Pj4+Pj52bGFuLA0KPj4+ Pj4+PiBkaWZmZXJlbnQgUEVzIG9uIHRoZSBzYW1lIEVTIG11c3QgaGF2ZSB0aGUgc2FtZSByb290 L2xlYWYNCj4+Pj4+Pj5kZXNpZ25hdGlvbi4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYXTCuXMgZ2l2ZW4u DQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUGVyaGFwcyB0aGUgZmlyc3Qgc2VudGVuY2UgY291 bGQgYmUgcmV3b3JkZWQgYXMgdGhlIGZvbGxvd2luZyB0bw0KPj4+Pj4+IGNhcHR1cmUNCj4+Pj4+ Pj4gdGhlIGFib3ZlIHBvaW50Og0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICBXaGlsZSBkaWZmZXJlbnQg QUNzIChWTEFOcykgb24gdGhlIHNhbWUgRVMgY291bGQgaGF2ZSBkaWZmZXJlbnQNCj4+Pj4+Pj4g ICAgcm9vdC9sZWFmIGRlc2lnbmF0aW9uIChzb21lIGJlaW5nIHJvb3RzIGFuZCBzb21lIGJlaW5n IGxlYXZlcyksDQo+Pj4+Pj4+ICAgIHRoZSBzYW1lIFZMQU4gZG9lcyBoYXZlIHRoZSBzYW1lIHJv b3QvbGVhZiBkZXNpZ25hdGlvbiBvbiBhbGwNCj4+Pj4+Pj4gICAgUEVzIG9uIHRoZSBzYW1lIEVT Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhdMK5cyBmaW5lLiBJdCBtYWtlcyBpdCBtb3JlIGNsZWFyLg0K Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciB0aGUgZm9sbG93aW5nOg0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICAuLi4gdGhlIFBFcyB3aXRoIExlYWYgc2l0ZXMgcGVyZm9ybSBNQUMgbGVhcm5pbmcg aW4gdGhlDQo+Pj4+Pj4+ICAgIGRhdGEtcGF0aCBvdmVyIHRoZWlyIEV0aGVybmV0IFNlZ21lbnRz LCBhbmQgYWR2ZXJ0aXNlDQo+Pj4+Pj4+cmVhY2hhYmlsaXR5DQo+Pj4+Pj4gaW4NCj4+Pj4+Pj4g ICAgRVZQTiBNQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZXMgd2hpY2ggYXJlIGltcG9ydGVkIG9ubHkg YnkgUEVzDQo+Pj4+Pj4+d2l0aA0KPj4+Pj4+PmF0DQo+Pj4+Pj4+ICAgIGxlYXN0IG9uZSBSb290 IHNpdGUgaW4gdGhlIEVWSS4gQSBQRSB3aXRoIG9ubHkgTGVhZiBzaXRlcyB3aWxsDQo+Pj4+Pj4+ bm90DQo+Pj4+Pj4+ICAgIGltcG9ydCB0aGVzZSByb3V0ZXMuIFBFcyB3aXRoIFJvb3QgYW5kL29y IExlYWYgc2l0ZXMgbWF5IHVzZSB0aGUNCj4+Pj4+Pj4gICAgRXRoZXJuZXQgQS1EIHJvdXRlcyBm b3IgYWxpYXNpbmcgKGluIHRoZSBjYXNlIG9mIG11bHRpLWhvbWVkDQo+Pj4+Pj4+ICAgIHNlZ21l bnRzKSBhbmQgZm9yIG1hc3MgTUFDIHdpdGhkcmF3YWwgcGVyIFtSRkMgNzQzMl0uDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFRoZSBhYm92ZSBzZWVtcyB0byBjb250cmFkaWN0IHdpdGggdGhlIHJlY29tbWVu ZGF0aW9uIGluIFNlY3Rpb24NCj4+Pj4+Pj4yLjIuDQo+Pj4+Pj4gSWYNCj4+Pj4+Pj4gdGhlIGNv bnRleHQgaXMgdGhlIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMSB0aGVuIHRoYXQn cw0KPj4+Pj4+PmZpbmUsDQo+Pj4+Pj4+IGJ1dCB0aGUgdGV4dCBkb2VzIG5vdCBoYXZlIGEgY2xl YXIgY29udGV4dC4NCj4+Pj4+Pg0KPj4+Pj4+IEFncmVlZC4gVXBkYXRlZCB0aGUgc2VjdGlvbiB0 byBpbmRpY2F0ZSB0aGUgY29udGV4dCBpcyBzZWN0aW9uIDIuMS4NCj4+Pj4+Pg0KPj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+PiAzLjMuMiBFLVRyZWUgd2l0aG91dCBNQUMgTGVhcm5pbmcNCj4+Pj4+ Pj4NCj4+Pj4+Pj4gICAgVGhlIFBFcyBpbXBsZW1lbnRpbmcgYW4gRS1UcmVlIHNlcnZpY2UgbmVl ZCBub3QgcGVyZm9ybSBNQUMNCj4+Pj4+Pj5sZWFybmluZw0KPj4+Pj4+PiAgICB3aGVuIHRoZSB0 cmFmZmljIGZsb3dzIGJldHdlZW4gUm9vdCBhbmQgTGVhZiBzaXRlcyBhcmUgbXVsdGljYXN0DQo+ Pj4+Pj4+b3INCj4+Pj4+Pj4gICAgYnJvYWRjYXN0Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJIHN1cHBv c2UgYW4gIm9ubHkiIHdvcmQgc2hvdWxkIGJlIGFkZGVkIGF0IHRoZSBlbmQgb2YgdGhlIGFib3Zl DQo+Pj4+Pj4gc2VudGVuY2UuDQo+Pj4+Pj4NCj4+Pj4+PiBBZ3JlZWQuDQo+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgVGhlIGZpZWxkcyBvZiB0aGUgSU1FVCByb3V0ZSBhcmUg cG9wdWxhdGVkIHBlciB0aGUgcHJvY2VkdXJlcw0KPj4+Pj4+IGRlZmluZWQNCj4+Pj4+Pj4gICAg aW4gW1JGQzc0MzJdLCBhbmQgdGhlIHJvdXRlIGltcG9ydCBydWxlcyBhcmUgYXMgZGVzY3JpYmVk IGluDQo+Pj4+Pj4gcHJldmlvdXMNCj4+Pj4+Pj4gICAgc2VjdGlvbnMuDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IFRoZSByb3V0ZSBpbXBvcnQgcnVsZXMgZGVzY3JpYmVkIGluIHByZXZpb3VzIHNlY3Rpb25z IGFyZSBmb3IgTUFDDQo+Pj4+Pj4gcm91dGVzLA0KPj4+Pj4+PiBub3QgSU1FVCByb3V0ZXMuIEFk ZGl0aW9uYWxseSwgdGhvc2UgcnVsZXMgbWF5IG5vdCBiZSByZWNvbW1lbmRlZCwNCj4+Pj4+Pj5z bw0KPj4+Pj4+PiBtaWdodCBhcyB3ZWxsIGRlbGV0ZSB0aGUgbGFzdCBzZW50ZW5jZS4NCj4+Pj4+ Pg0KPj4+Pj4+IENoYW5nZWQgdGhlIGxhc3Qgc2VudGVuY2UgdG8gwrPFoCwgYW5kIHRoZSBtdWx0 aWNhc3QgdHVubmVsIHNldHVwDQo+Pj4+Pj5jcml0ZXJpYQ0KPj4+Pj4+IGFyZSBhcyBkZXNjcmli ZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24uwrINCj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBT ZWN0aW9uIDMuMy4xIHRhbGtzIGFib3V0IEJVTSBwcm9jZWR1cmVzLiBUaGF0IGlzIG5vdCBzcGVj aWZpYyB0bw0KPj4+Pj4+PjMuMy4xDQo+Pj4+Pj4+IHRob3VnaC4gUGVyaGFwcyBleHRyYWN0IHRo YXQgb3V0IHRvIGEgc2VwYXJhdGUgc2VjdGlvbiwgYW5kIHJlbW92ZQ0KPj4+Pj4+PnRoZQ0KPj4+ Pj4+PiBCVU0gdGV4dCBmcm9tIDMuMy4yIGFzIHdlbGwuDQo+Pj4+Pj4NCj4+Pj4+PiBJIHRoaW5r IGl0IGlzIE9LLg0KPj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFRoZSBFLVRSRUUgRXh0ZW5k ZWQgQ29tbXVuaXR5IGlzIGVuY29kZWQgYXMgYW4gOC1vY3RldCB2YWx1ZSBhcw0KPj4+Pj4+PiAg ICBmb2xsb3dzOg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyDQo+Pj4+Pj4+Mw0KPj4+Pj4+PiAgICAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5DQo+Pj4+Pj4+MCAxDQo+Pj4+Pj4+DQo+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+Pj4+Pj4gICAgICAg IHwgVHlwZT0weDA2ICAgICB8IFN1Yi1UeXBlPTB4MDQgfCBGbGFncygxIE9jdGV0KXwNCj4+Pj4+ PiB8DQo+Pj4+Pj4+DQo+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+Pj4+Pj4gICAgICAgIHwgIFJlc2VydmVk PTAgICB8ICAgICAgICAgICBMZWFmIExhYmVsDQo+Pj4+Pj4gfA0KPj4+Pj4+Pg0KPj4+Pj4+ICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgYXNzdW1lIHRoZSBvY3RlY3QgYWZ0ZXIgdGhlIGZs YWdzIG9jdGV0IGlzIGFsc28gcmVzZXJ2ZWQ9MC4NCj4+Pj4+Pj5CZXR0ZXINCj4+Pj4+PiBtYXJr DQo+Pj4+Pj4+IGl0IGFzICJSZXNlcnZlZD0wIi4NCj4+Pj4+Pg0KPj4+Pj4+IEFncmVlZC4NCj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXaGVuIGl0IGlzIHVzZWQgd2l0aCBFdGhlcm5ldCBBLUQg cGVyIEVTIHJvdXRlLCB0aGUgbGVhZiBmbGFnDQo+Pj4+Pj4+U0hPVUxEDQo+Pj4+Pj4+YmUNCj4+ Pj4+Pj4gc2V0IHRvIDAgYnV0IGlnbm9yZWQgYnkgdGhlIHJlY2VpdmluZyByb3V0ZXJzLiBUaGVy ZWZvcmUsIHdoeSBub3QNCj4+Pj4+Pj5zZXQNCj4+Pj4+PiBpdA0KPj4+Pj4+PiB0byAxIHRvIGJl IGNvbnNpc3RlbnQgdGhlIE1BQy9JUCByb3V0ZSBjYXNlPw0KPj4+Pj4+DQo+Pj4+Pj4gQmVjYXVz ZSB0aGUgZmxhZyBpcyB1c2VkIGZvciBrbm93biB1bmljYXN0IHRyYWZmaWMgYW5kIExlYWYgbGFi ZWwNCj4+Pj4+PmZvcg0KPj4+Pj4+IEJVTQ0KPj4+Pj4+IHRyYWZmaWMuIFdlIGRvbsK5dCB3YW50 IHRvIG1peCB0aGUgdHdvLg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+IEFsaQ0KPj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcy4NCj4+Pj4+Pj4gSmVmZnJleQ0KPj4+Pj4+Pg0K Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206IEJFU1Mg W21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMNCj4+Pj4+ Pj4+TW9yaW4NCj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTksIDIwMTYgMzo1MSBB TQ0KPj4+Pj4+Pj4gVG86IEJFU1MgPGJlc3NAaWV0Zi5vcmc+Ow0KPj4+Pj4+Pj5kcmFmdC1pZXRm LWJlc3MtZXZwbi1ldHJlZUB0b29scy5pZXRmLm9yZw0KPj4+Pj4+Pj4gU3ViamVjdDogW2Jlc3Nd IFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhpcyBlbWFp bCBzdGFydHMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbg0KPj4+Pj4+Pj4gZHJhZnQtaWV0 Zi1iZXNzLWV2cG4tZXRyZWUgWzFdIHdoaWNoIGlzIGNvbnNpZGVyZWQgbWF0dXJlIGFuZA0KPj4+ Pj4+Pj5yZWFkeQ0KPj4+Pj4+IGZvcg0KPj4+Pj4+Pj4gYSBmaW5hbCB3b3JraW5nIGdyb3VwIHJl dmlldy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQgaWYgeW91 IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQNCj4+Pj4+Pj4+dmVyc2lvbg0KPj4+Pj4+IHll dA0KPj4+Pj4+Pj4gKC0wMyksIGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QsIG5v IGxhdGVyIHRoYW4gKkZlYnJ1YXJ5DQo+Pj4+Pj4gdGhlDQo+Pj4+Pj4+PiAybmQqICgyMDE2LTAy LTAyKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIGlzIG5vdCBvbmx5IGEgY2FsbCBmb3IgY29t bWVudHMgb24gdGhlIGRvY3VtZW50LCBidXQgYWxzbyBhDQo+Pj4+Pj4+PmNhbGwNCj4+Pj4+PiBv Zg0KPj4+Pj4+Pj4gc3VwcG9ydCBmb3IgaXRzIHB1YmxpY2F0aW9uLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+ICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBv ZiBhbnkgSVBSDQo+Pj4+Pj4+PnRoYXQNCj4+Pj4+Pj4+IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1i ZXNzLWV2cG4tZXRyZWUsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbg0KPj4+Pj4+Pj4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwg NDg3OSwNCj4+Pj4+PiAzNjY5DQo+Pj4+Pj4+PiBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAqSWYqIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yIG9mDQo+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJl ZSBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZA0KPj4+Pj4+Pj5pbmRpY2F0ZQ0KPj4+ Pj4+Pj4gd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rIHlvdSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaG9tYXMv TWFydGluDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IEJF U1MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBCRVNTQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCj4+Pj4+Pj4NCj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQkVT UyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gQkVTU0BpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCj4+Pj4+DQo+Pj4+DQo+Pj4NCj4+Pg0K Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj5fDQo+Pj5fDQo+Pj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+DQo+Pj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4+PmNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+Pj5wYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6DQo+Pj5yZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN Cj4+PmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcw0KPj4+ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KPj4+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUNCj4+Pm91IGZhbHNpZmllLiBNZXJjaS4N Cj4+Pg0KPj4+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCj4+PmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQo+Pj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4+PklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4+PmRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+PkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0KPj4+ YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+Pj5UaGFuayB5b3UuDQo+Pj4N Cj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PkJFU1MgbWFpbGluZyBsaXN0DQo+PkJFU1NAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQo+DQoNCg== From nobody Mon Jun 6 10:12:07 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 E849412D0C8; Mon, 6 Jun 2016 10:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 RSH3fLy0vvue; Mon, 6 Jun 2016 10:11:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A73412D135; Mon, 6 Jun 2016 10:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9447; q=dns/txt; s=iport; t=1465233119; x=1466442719; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zxfYYzn/WD/b2qcUFgRbecwR7991SXfCQS/B29BRZLE=; b=KAET/bROzBPOZavsyjpAuwMtDii8+O4tpfsJIP3IcBIg5jDKh96G3Upw 9dt+gVXelClh+1P8aET6uCzbXqqG76919QqEZjBv7TFGbbGbAASmIhG6c WSi8k6HmN7q2aU6c3KCckAZTuiIj1P0iakMYuin72onjMLkP0WAEaM9Ty 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgAqrlVX/4MNJK1bgm5NVm8OBrVXh?= =?us-ascii?q?H2BeiKFcAKBMzgUAQEBAQEBAWUnhEUBAQEEgQkCAQgRAwECKAcyFAkIAgQBEog?= =?us-ascii?q?VAxcOuw4BAQEBAQEBAQEBAQEBAQEBAQEaBYp0gkOBTxEBPIU6BY4eiioBhgKII?= =?us-ascii?q?4FphFCIZY9ZAR42g25uAYhjNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,428,1459814400"; d="scan'208,217";a="281660352" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jun 2016 17:11:58 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u56HBw0w003955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 17:11:58 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 13:11:57 -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.1104.009; Mon, 6 Jun 2016 13:11:57 -0400 From: "Ali Sajassi (sajassi)" To: "Ali Sajassi (sajassi)" , John E Drake , Thomas Morin , IDR , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Rabadan, Jorge (Nokia - US)" , "draft-ietf-idr-tunnel-encap@tools.ietf.org" Thread-Topic: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8AgAAObQCAE5+SgIAAQjEAgAiAQYCAFRg5AA== Date: Mon, 6 Jun 2016 17:11:57 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: multipart/alternative; boundary="_000_D37AFB0E1A944Csajassiciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 06 Jun 2016 17:12:02 -0000 --_000_D37AFB0E1A944Csajassiciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, I updated and checked-in a new rev of this draft couple of weeks ago to add= ress the comments that came up on this email thread - the main changes were= outlined in my previous email. Can you please progress this draft for its = LC. If there is any issue preventing the progress of this draft, would you = let us know. Regards, Ali From: Cisco Employee > Date: Tuesday, May 24, 2016 at 12:04 AM To: John E Drake >, Thomas Mo= rin >, IDR >, BESS >, "d= raft-ietf-bess-evpn-overlay@tools.ietf.org" >, "Rabadan, Jorge (Nokia - US)" = >, "draft-ietf-idr-= tunnel-encap@tools.ietf.org" > Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-e= ncaps Resent-From: >, Cisco= Employee > Resent-To: Cisco Employee >, >, >, >,= >, >, > Resent-Date: Tuesday, May 24, 2016 at 12:05 AM Folks, I have updated and published rev03 of even-overlay draft. https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ The main changes are: 1. section 10.2 - DCI using ASBR 2. The setting of Ethernet tag and VNI fields - there were some inconsis= tencies in different sections. Section 5.1.3 captures the setting of these = fields for different type of services in pretty good details. All other sec= tions were cleaned up and now refer to section 5.1.3. Thomas, The draft is ready for its long-overdue WG LC considering how long its has = been around and its multi-vendor implementation status. Regards, Ali --_000_D37AFB0E1A944Csajassiciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8952DB7AAC24A04C9ADF5E961512C770@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Thomas,

I updated and checked-in a new rev of this draft couple of weeks ago t= o address the comments that came up on this email thread – the main c= hanges were outlined in my previous email. Can you please progress this dra= ft for its LC. If there is any issue preventing the progress of this draft, would you let us know.

Regards,
Ali

From: Cisco Employee <sajassi@cisco.com>
Date: Tuesday, May 24, 2016 at 12:0= 4 AM
To: John E Drake <jdrake@juniper.net>, Thomas Morin <thomas.morin@orange.com>, IDR &= lt;idr@ietf.org>, BESS <bess@ietf.org>, "draft-ietf-bess-evp= n-overlay@tools.ietf.org" <draft-ietf-bess-evpn-overlay@tools.ietf.org&= gt;, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "draft-ietf-idr-tunnel-encap@tools.ie= tf.org" <draft-ietf-idr-tunnel-encap@tools.ietf.org>
Subject: Re: [Idr] draft-ietf-bess-= evpn-overlay vs. draft-ietf-idr-tunnel-encaps
Resent-From: <alias-bounces@ietf.org>, Cisco Employee <= sajassi@cisco.com>
Resent-To: Cisco Employee <sajassi@cisco.com>, <jdrake@juniper.net>, <nabil.n.bitar@verizon.com>, <uttaro@att.com>, <wim.henderickx@alcatel-lucent= .com>, <aisaac@juniper.net<= /a>>, <draft= -ietf-bess-evpn-overlay@ietf.org>
Resent-Date: Tuesday, May 24, 2016 = at 12:05 AM


Folks,

I have updated and published rev03 of even-overlay draft. 

The main changes are:
  1. section 10.2 – DCI using ASBR
  2. The setting of Ethernet tag= and VNI fields – there were some inconsistencies in different sectio= ns. Section 5.1.3 captures the setting of these fields for different type o= f services in pretty good details. All other sections were cleaned up and n= ow refer to section 5.1.3.

Thomas,
The draft is ready for its long-overdue WG LC considering how long its= has been around and its multi-vendor implementation status. 

Regards,
Ali
 --_000_D37AFB0E1A944Csajassiciscocom_-- From nobody Tue Jun 7 01:08:35 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 8C5BE12D192 for ; Tue, 7 Jun 2016 01:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LZ8Y6VDT-NHH for ; Tue, 7 Jun 2016 01:08:32 -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 7C2F112D159 for ; Tue, 7 Jun 2016 01:08:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DF097A2E5059A for ; Tue, 7 Jun 2016 08:08:28 +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 u5788TVJ010133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Jun 2016 08:08:30 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5787qYD009664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Jun 2016 10:08:29 +0200 Received: from [135.224.200.167] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Jun 2016 10:08:22 +0200 Message-ID: <575680F5.2030101@alcatel-lucent.com> Date: Tue, 7 Jun 2016 10:08:21 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 07 Jun 2016 08:08:34 -0000 Hi, We are fine with keeping 5512 as the Normative reference for now. We would think it wise if the editors can add an Informative reference to draft-ietf-idr-tunnel-encaps (with some text indicating that both specs provide the required support for the procedures). The ideal situation would be that tunnel-encaps progresses fast enough so that in the last stages before publishing evpn-overlay we can be in a situation to make tunnel-encaps the Normative reference. RFC 4897 would facilitate that by the way. If the WG has specific opinions on that matter, they are welcome. We take good note of the shepherd suggestion. We'll confirm who will shepherd the document after WG LC (we'll also call for volunteers during WG Last Call). Reviews are highly welcome anyway, in particular from people close to the topic or implementations, and ideally from more than one person, the best time being now or at least before the WG LC ends. We'll start the WG LC in a couple of days. Martin & Thomas Le 24/05/2016 15:39, John E Drake a écrit : > Hi, > > Ali and I decided to keep the normative reference to RFC 5512 rather > than changing it to Eric’s tunnel encapsulation draft because the > normative reference pre-dates Eric’s draft and because our draft does > not use any of the new capabilities introduced in Eric’s draft. > > Ali and I would also like to request that Jorge be the document shepherd > for this draft. > > Yours Irrespectively, > > John > > *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > *Sent:* Tuesday, May 24, 2016 3:05 AM > *To:* John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; > draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - > US); draft-ietf-idr-tunnel-encap@tools.ietf.org > *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. > draft-ietf-idr-tunnel-encaps > > Folks, > > I have updated and published rev03 of even-overlay draft. > > https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ > > The main changes are: > > 1. section 10.2 – DCI using ASBR > 2. The setting of Ethernet tag and VNI fields – there were some > inconsistencies in different sections. Section 5.1.3 captures the > setting of these fields for different type of services in pretty > good details. All other sections were cleaned up and now refer to > section 5.1.3. > > Thomas, > > The draft is ready for its long-overdue WG LC considering how long its > has been around and its multi-vendor implementation status. > > Regards, > > Ali > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > From nobody Tue Jun 7 02:39:37 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 B21F212D563; Tue, 7 Jun 2016 02:39:32 -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 PyvQhgLS2cbh; Tue, 7 Jun 2016 02:39:28 -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 A6BA112D0CF; Tue, 7 Jun 2016 02:39:27 -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 u579dEtf016068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2016 18:39:15 +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: Date: Tue, 7 Jun 2016 18:39:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------3B67671C878F662B3E729FE6" Archived-At: Cc: "mib-doctors@ietf.org" , Mach Chen , Martin Vigoureux , "bess@ietf.org" , "ops-ads@ietf.org" Subject: [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: Tue, 07 Jun 2016 09:39:33 -0000 This is a multi-part message in MIME format. --------------3B67671C878F662B3E729FE6 Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 >>> > > --------------3B67671C878F662B3E729FE6 Content-Type: text/plain; charset=UTF-8; name="Review-draft-ietf-bess-l2l3-vpn-mcast-mib-04-20160607.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="Review-draft-ietf-bess-l2l3-vpn-mcast-mib-04-20160607.txt" MC4gQWJzdHJhY3QuCjAuMS4KPiAgaXQgZGVzY3JpYmVzIGNvbW1vbiBtYW5hZ2VkIG9iamVj dHMgdXNlZCB0byBjb25maWd1cmUKICAgYW5kL29yIG1vbml0b3IgYm90aCBMMiBhbmQgTDMg VlBOIE11bHRpY2FzdC4KClRoZXJlIGFyZSBubyB3cml0YWJsZSBNT3MgaW4gdGhpcyBNSUIu IFNvIGl0IGRvZXMgbm90IGxvb2sgCmFzIHRob3VnaCB0aGlzIE1JQiB3aWxsIGJlIHVzZWQg Zm9yIGNvbmZpZ3VyYXRpb24gZGlyZWN0bHkuIApUaGUgdXNlIGNhc2Ugc2NlbmFyaW8gZm9y IG1vbml0b3JpbmcgaXMgbm90IGNsZWFyLCBlaXRoZXIuIApJdCBhcHBlYXJzIHRoYXQgdGhl IE1JQiBtb2R1bGUocykgaW4gdGhpcyBkb2N1bWVudCB3aWxsIGJlIAp1c2VkIGJ5IG90aGVy IG1vZHVsZXMgd2hpY2ggYXJlIGRlc2lnbmVkIGZvciBtb25pdG9yaW5nIGFuZC8Kb3IgY29u ZmlndXJpbmcgTDIgYW5kIEwzIFZQTiBNdWx0aWNhc3QuIFBsZWFzZSByZS1leGFtaW5lIHRo ZQp3b3JkaW5nLgoKMS4gIEludHJvZHVjdGlvbgoKMS4xCiAgIFdvdWxkIGJlIHZlcnkgbmlj ZSBpZiBhIHNob3J0IGV4cGxhbmF0aW9ucyBvZiBNVlBOIGFuZCAKICAgTDIgVlBOIE11bHRp Y2FzdCB3ZXJlIGdpdmVuLiBXaXRoIGVtcGhhc2lzIG9uIHRoZSBvcGVyYXRpb25hbCAKICAg YXNwZWN0cy4gICAgCjEuMgogICBzL3JlZmVycmVkIHRvIE1WUE4gYW5kIEwyIFZQTiBNdWx0 aWNhc3QgcmVzcGVjdGl2ZWx5LwogICAgIHJlZmVycmVkIHRvIGFzIE1WUE4gYW5kIEwyIFZQ TiBNdWx0aWNhc3QscmVzcGVjdGl2ZWx5LwoKMS4zCiAgIHMvTVZQTiBbUkZDNjUxM10gW1JG QzY1MTRdL01WUE4gW1JGQzY1MTNdLFtSRkM2NTE0XS8uCgoxLjQgLi4uLiB0aGVyZSBhcmUg MiB0eXBlcyBvZiBQTVNJcyAuLgoKPiAgIG8gSS1QTVNJOiBJbmNsdXNpdmUgUE1TSSAtIHRv IGFsbCBQRXMgaW4gdGhlIHNhbWUgVlBOLgo+ICAgbyBTLVBNU0k6IFNlbGVjdGl2ZSBQTVNJ IC0gdG8gc29tZSBvZiB0aGUgUEVzIGluIHRoZSBzYW1lIFZQTi4KICAgCiAgIHBsZWFzZSBt YWtlIHRoZXNlIGV4cGxhbmF0aW9ucyBtb3JlIGdlbnRsZShjb21wbGV0ZSkgdG8gdGhlIHJl YWRlci4gCiAgIEFsc28sIGdpdmUgdGhlIHJlZmVyZW5jZXMgd2hlcmUgdGhlc2UgdGVybXMg YXJlIGRlZmluZWQuCgoKMy4gIFN1bW1hcnkgb2YgTUlCIE1vZHVsZQozLjEgCj4gICBBdHRy aWJ1dGVzIChQVEFzKSBhZHZlcnRpc2VkL3JlY2VpdmVkIGluIEkvUy1QU01JIEF1dG8tRGlz Y292ZXJ5IAogICAgVHlwbzogSS9TLVBNU0ksICAoc2VlIDMuMyBiZWxvdykuCgozLjIgc29t ZSBtb3JlIHRleHQgbGlrZSB0aGUgZm9sbG93aW5nIHdpbGwgYmUgZ29vZC4gCiAgICBMMkwz LVZQTi1NQ0FTVC1NSUIgY29udGFpbnMgCiAgICBvIGEgVGV4dHVhbCBDb252ZW50aW9uIEwy TDNWcG5NY2FzdFByb3ZpZGVyVHVubmVsVHlwZSB0aGF0IHByb3ZpZGVzIAogICAgICBhbiBl bnVtZXJhdGlvbiBvZiB0aGUgIHByb3ZpZGVyIHR1bm5lbCB0eXBlcyBhbmQsCiAgICBvIGEg dGFibGUgbDJMM1Zwbk1jYXN0UG1zaVR1bm5lbEF0dHJpYnV0ZVRhYmxlLiBUaGUgdGFibGUg aW5kZXggaXMgCiAgICAgIGNvbXBvc2VkIG9mIG11bHRpcGxlIGF0dHJpYnV0ZXMgdGhhdCBk ZXBlbmQgb24gdGhlIHR1bm5lbCB0eXBlIGFuZCAKICAgICAgdW5pcXVlbHkgaWRlbnRpZnkg YSB0dW5uZWwuIFRoaXMgdGFibGUgd2lsbCBiZSB1c2VkIHRvIC4uLiBtb25pdG9yIAogICAg ICB0aGUgdHVubmVscyBzdXBwb3J0ZWQgYnkgdGhlIHN5c3RlbSBhdCBhIGdpdmVuIHBvaW50 IG9mIHRpbWUgKD8pIAogICAgICBJdCBtYXkgYWxzbyBiZSB1c2VkIGluIGNvbmp1bmN0aW9u IHdpdGggWFhYWC1taWIgdG8gb2J0YWluIHRoZSAKICAgICAgb3RoZXIgZGV0YWlscyBvZiBh IHR1bm5lbCBieSBmb2xsb3dpbmcgdGhlIHJvdyBwb2ludGVyIG9mIHRoZSAKICAgICAgY29y cmVzcG9uZGluZyB0dW5uZWwncyByb3cgaW4gdGhpcyB0YWJsZS4KICAgIFsgUGxlYXNlIHRy ZWF0IHRoZSBhYm92ZSBhcyBhIHRlbXBsYXRlIGFuZCBtb2RpZnkgdGhlIHRleHQgYXMgCiAg ICAgIGFwcHJvcHJpYXRlIC4uXSAKCjMuMyBTaW5jZSB0aGlzIHdpbGwgYmVjb21lIGEgc3Rh bmRhcmQgZG9jdW1lbnQsIHBsZWFzZSB0YWtlIGNhcmUgb2YgCiAgICBkZWZpbml0aW9ucyBh bmQgbm90YXRpb25zIHVzZWQgaW4gdGhlIGRvY3VtZW50LgogICAgVGhlIG5vdGF0aW9uIEkv Uy1QTVNJIGlzIG5vdCBkZWZpbmVkLiBJZiB5b3UgbXVzdCB1c2UgYSBuZXcgCiAgICB0ZXJt L25vdGF0aW9uLCAgZGVmaW5lIGl0IGJlZm9yZSB1c2UuIAoKNC4gIERlZmluaXRpb25zCgo+ ICBJTVBPUlRTCj4gICAgTU9EVUxFLUlERU5USVRZLCBPQkpFQ1QtVFlQRSwgZXhwZXJpbWVu dGFsCjQuMSBTaW5jZSB0aGlzIGlzIG5vdCBhIEV4cGVyaW1lbnRhbCBNSUIgZG8gbm90IGlt cG9ydCB1c2UgZXhwZXJpbWVudGFsLgogICAgSXQgaXMgZ29vZCBwcmFjdGljZSB0byBrZWVw IHRoZSBkcmFmdCBpbiB0aGUgYXMgImNsb3NlIHRvIGZpbmFsIGZvcm0iCiAgICBhcyBwb3Nz aWJsZS4gKFNlZSBiZWxvdykKNC4yIAo+ICAgTEFTVC1VUERBVEVEICIyMDEzMTAxNDEyMDBa IiAgLS0gT2N0b2JlciAxNCwgMjAxMwogICAgUGxlYXNlIHVwZGF0ZSB0aGlzIGRhdGUuCgo0 LjMKPiAgIERFU0NSSVBUSU9OCj4gICAgIlRoaXMgTUlCIGNvbnRhaW5zIGNvbW1vbiBtYW5h Z2VkIG9iamVjdCBkZWZpbml0aW9ucyBmb3IKPiAgICAgbXVsdGljYXN0IGluIExheWVyIDIg YW5kIExheWVyIDMgVlBOcywgZGVmaW5lZCBieQo+ICAgICBbUkZDNzExN10gYW5kIFtSRkM2 NTEzXSBbUkZDNjUxNF0gcmVzcGVjdGl2ZWx5LgogICAgV291bGQgYmUgZ29vZCBpZiB5b3Ug Y291bGQgcmVhcnJhbmdlIHRoZSB0ZXh0LiBTb21ldGhpbmcgbGlrZQogICAgICJUaGlzIE1J QiBtb2R1bGUgd2lsbCBiZSB1c2VkIGZvciBtYW5hZ2luZyBtdWx0aWNhc3QgaW4gTGF5ZXIg MiAKICAgICAgVlBOcyBbUkZDNzExN10gYW5kIExheWVyIDMgVlBOcyBbUkZDNjUxM10sIFtS RkM2NTE0XS4gCiAgICBPciwgZXZlbiBiZXR0ZXIgCiAgICAgIlRoaXMgTUlCIG1vZHVsZSB3 aWxsIGJlIHVzZWQgYnkgb3RoZXIgTUlCIG1vZHVsZXMgZGVzaWduZWQgZm9yIAogICAgICBt YW5hZ2luZyBtdWx0aWNhc3QgaW4gTGF5ZXIgMiBWUE5zIFtSRkM3MTE3XSBhbmQgTGF5ZXIg MyBWUE5zIAogICAgICBbUkZDNjUxM10sIFtSRkM2NTE0XQogICAgT3IsIGEgY29tYmluYXRp b24gb2YgYm90aCwgZGVwZW5kaW5nIG9uIHRoZSBlbnZpc2FnZWQgdXNlIGNhc2UgCiAgICBz Y2VuYXJpb3MuCiAKCjQuNAo+ICAgIDo6PSB7IGV4cGVyaW1lbnRhbCA5OTkgfQogICAgUGxl YXNlIAogICAgICBvIFJlcGxhY2UgImV4cGVyaW1lbnRhbCIgYnkgdGhlIGJyYW5jaCB3aGVy ZSB0aGlzIG1pYiBtb2R1bGUgd2lsbCAKICAgICAgICBiZSBhbmNob3JlZDsgdGhhdCBpcyBh IGRlY2lzaW9uIHRoYXQgdGhlIFdHIHdpbGwgdGFrZSwgcHJvYmFibHkuCiAgICAgIG8gSW1w b3J0IHRoZSBicmFuY2ggaW4gdGhlIElNUE9SVFMgc3RhdGVtZW50IAogICAgICBbIEluIHRo ZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24gYSBicmFuY2ggaW4gdGhlIG1pYi0yIHN1 YnRyZWUgCiAgICAgICAgaXMgcmVxdWVzdGVkLiBJbiB0aGF0IGNhc2UgdGhpcyBtdXN0IGJl IAogICAgICAgICA6Oj0geyBtaWItMiBYWFggfQogICAgICBdCgogICAgQXMgZmFyIGFzIGNv bXBpbGluZyB0aGUgbWliIGlzIGNvbmNlcm5lZCwgb25lIHdheSB0byBkbyBpdCBpcwogICAg ICAtIGV4dHJhY3QgdGhlIG1pYiwKICAgICAgICBlZGl0IGl0IGluIHdoYXQgZXZlciB3YXkg eW91IGNob3NlLCB1c2UgZXhwZXJpbWVudGFsIC4uLgo0LjUgCj4gICAtLSBQbGVhc2UgYWxz byByZW1vdmUgdGhlICIsIGV4cGVyaW1lbnRhbCIgdGV4dCBmcm9tIGVhcmxpZXIKPiAgIC0t IElNUE9SVFMgc2VjdGlvbi4KICAgIFJlbW92ZSB0aGVzZSBpbnN0cnVjdGlvbnMuCgo0LjUu Mgo+ICAtLSBUZXh1YWwgY29udmVudGlvbgogICBUeXBvOiAtLSBUZXh0dWFsIGNvbnZlbnRp b24KCjQuNgo+IEwyTDNWcG5NY2FzdFByb3ZpZGVyVHVubmVsVHlwZSA6Oj0gVEVYVFVBTC1D T05WRU5USU9OCj4gICBERVNDUklQVElPTgo+ICAgICAgICJUeXBlcyBvZiBwcm92aWRlciB0 dW5uZWxzIHVzZWQgZm9yIG11bHRpY2FzdCBpbgo+ICAgICAgICBCR1AvTVBMUyBMMiBvciBM MyBWUE4uIEFkZGl0aW9uYWwgdHlwZXMgbWF5IGJlIGRlZmluZWQKPiAgICAgICAgaW4gZnV0 dXJlIFJGQ3MsIGFuZCB0aG9zZSB3aWxsIGJlIGFsbG93ZWQgYXMKPiAgICAgICAgdmFsaWQg dHlwZXMgZm9yIEwyTDNWcG5NY2FzdFByb3ZpZGVyVHVubmVsVHlwZS4iCiAgICBUaGUgcGFy dCAKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBZGRpdGlvbmFsIHR5cGVzIG1h eSBiZSBkZWZpbmVkCj4gICAgICAgIGluIGZ1dHVyZSBSRkNzLCBhbmQgdGhvc2Ugd2lsbCBi ZSBhbGxvd2VkIGFzCj4gICAgICAgIHZhbGlkIHR5cGVzIGZvciBMMkwzVnBuTWNhc3RQcm92 aWRlclR1bm5lbFR5cGUuIgogICAgbWF5IGJlIGRlbGV0ZWQuCgo0LjcKPiAtLSBUb3AgbGV2 ZWwgY29tcG9uZW50cyBvZiB0aGlzIE1JQi4KPiAtLSB0YWJsZXMsIHNjYWxhcnMsIGNvbmZv cm1hbmNlIGluZm9ybWF0aW9uCj4KPiBsMkwzVnBuTWNhc3RPYmplY3RzICAgICBPQkpFQ1Qg SURFTlRJRklFUiA6Oj0geyBsMkwzVnBuTWNhc3RNSUIgMSB9Cj4gbDJMM1Zwbk1jYXN0Q29u Zm9ybWFuY2UgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgbDJMM1Zwbk1jYXN0TUlCIDIgfQog IGwyTDNWcG5NY2FzdFN0YXRlcyAgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgbDJMM1Zwbk1j YXN0T2JqZWN0cyAxIH0KPgo+ICAtLSBUYWJsZSBvZiBQTVNJIFR1bm5lbCBBdHRyaWJ1dGVz Cj4KPiBsMkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlVGFibGUgT0JKRUNULVRZUEUK CnNob3VsZCBiZQoKICAtLSBUb3AgbGV2ZWwgY29tcG9uZW50cyBvZiB0aGlzIE1JQi4KIAog IGwyTDNWcG5NY2FzdE9iamVjdHMgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGwyTDNW cG5NY2FzdE1JQiAxIH0KICBsMkwzVnBuTWNhc3RDb25mb3JtYW5jZSBPQkpFQ1QgSURFTlRJ RklFUiA6Oj0geyBsMkwzVnBuTWNhc3RNSUIgMiB9CiAgbDJMM1Zwbk1jYXN0U3RhdGVzICAg ICAgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgbDJMM1Zwbk1jYXN0T2JqZWN0cyAxIH0KIAog IC0tIHRhYmxlcywgc2NhbGFycywgY29uZm9ybWFuY2UgaW5mb3JtYXRpb24KICAtLSBUYWJs ZSBvZiBQTVNJIFR1bm5lbCBBdHRyaWJ1dGVzCiAKICBsMkwzVnBuTWNhc3RQbXNpVHVubmVs QXR0cmlidXRlVGFibGUgT0JKRUNULVRZUEUKCjQuOAo+IGwyTDNWcG5NY2FzdFBtc2lUdW5u ZWxBdHRyaWJ1dGVUYWJsZSBPQkpFQ1QtVFlQRQo+ICAgIFNZTlRBWCAgICAgICAgU0VRVUVO Q0UgT0YgTDJMM1Zwbk1jYXN0UG1zaVR1bm5lbEF0dHJpYnV0ZUVudHJ5Cj4gICAgTUFYLUFD Q0VTUyAgICBub3QtYWNjZXNzaWJsZQo+ICAgIFNUQVRVUyAgICAgICAgY3VycmVudAo+ICAg IERFU0NSSVBUSU9OCj4gICAgICAgICJUaGlzIHRhYmxlIGlzIGZvciBQTVNJIFR1bm5lbCBB dHRyaWJ1dGVzIChQVEFzKQo+ICAgICAgICAgYWR2ZXJ0aXNlZC9yZWNlaXZlZCBpbiBJL1Mt UFNNSSBBdXRvLURpc2NvdmVyeSByb3V0ZXMuCj4gICAgICAgICBUaGUgZW50cmllcyBtYXkg YmUgcmVmZXJyZWQgdG8gYnkgSS1QTVNJIG9yIFMtUE1TSSB0YWJsZQo+ICAgICAgICAgZW50 cmllcyBkZWZpbmVkIGluIG90aGVyIE1JQnMsIGUuZy4gbXZwbk1JQiBpbgo+ICAgICAgICAg W0ktRC5pZXRmLWJlc3MtbXZwbi1taWJdLiIKCiAgSXQgd291bGQgc2VlbSB0aGF0IGVhY2gg cm93IGluIHRoaXMgdGFibGUgaXMgYW4gaW5kZXggZm9yIGEgUFRBIAogIGFuZCBtYXkgY29u dGFpbiBwb2ludGVycyB0byByb3dzIGluIHRhYmxlcyBvZiBvdGhlciBNSUIgbW9kdWxlcyAg CiAgd2hpY2ggbWF5IGNvbnRhaW4gbW9yZSBkZXRhaWxzIGZvciB0aGUgUFRBLiBJcyB0aGF0 IGNvcnJlY3Q/CiAgUGxlYXNlIHJld29yZCB0aGUgREVTQ1JJUFRJT04gYWNvcmRpbmdseS4g IAogIEFsc28gc2VlIGNvbW1lbnRzIGluIDQuMTUKCgo0LjkKPiBsMkwzVnBuTWNhc3RQbXNp VHVubmVsQXR0cmlidXRlRW50cnkgT0JKRUNULVRZUEUKPiAgICAgICAgIkFuIGVudHJ5IGlu IHRoaXMgdGFibGUgY29ycmVzcG9uZHMgdG8gYSBQVEEKPiAgICAgICAgIHRoYXQgaXMgYWR2 ZXJ0aXNlZC9yZWNlaXZlZCBvbiB0aGlzIHJvdXRlci4KICBXZSBhcmUgaW4gdGhlIGRlc2Ny aXB0aW9uIG9mICJsMkwzVnBuTWNhc3RQbXNpVHVubmVsQXR0cmlidXRlRW50cnkiCiAgc28g ImVudHJ5IGluIHRoaXMgdGFibGUiIGRvZXMgbm90IGZpdCBpbiB3ZWxsLgogIEEgcmV3b3Jk aW5nIGxpa2UgCiAgICAgICAgICJBIGNvbmNlcHR1YWwgcm93IGNvcnJlc3BvbmRpbmcgdG8g YSBQVEEKICAgICAgICAgIHRoYXQgaXMgYWR2ZXJ0aXNlZC9yZWNlaXZlZCBvbiB0aGlzIHJv dXRlci4gCiAgICAgICAgICAuLi4uCiAgd291bGQgYmUgYmV0dGVyLgoKNC4xMAo+ICAgICAg ICAgRm9yIEJHUC1iYXNlZCBzaWduYWxpbmcgKGZvciBJLVBNU0kgdmlhIGF1dG8tZGlzY292 ZXJ5Cj4gICAgICAgICBwcm9jZWR1cmUsIG9yIGZvciBTLVBNU0kgdmlhIFMtUE1TSSBBLUQg cm91dGVzKSwKPiAgICAgICAgIHRoZXkgYXJlIGp1c3QgYXMgc2lnbmFsZWQgYnkgQkdQLgo+ ICAgICAgICAgRm9yIFVEUC1iYXNlZCBTLVBNU0kgc2lnbmFsaW5nIGZvciBQSU0tTVZQTiwK PiAgICAgICAgIHRoZXkncmUgZGVyaXZlZCBmcm9tIHRoZSBTLVBNU0kgSm9pbiBNZXNzYWdl LgoKPiAgICAgICAgIE5vdGUgdGhhdCBCR1AtYmFzZWQgc2lnbmFsaW5nIG1heSBiZSB1c2Vk IGZvcgo+ICAgICAgICAgUElNLU1WUE4gYXMgd2VsbC4iCiAgIElzIHRoZSBzaWduYWxpbmcg bWVjaGFuaXNtIGltcG9ydGFudCBoZXJlPyBJZiBpdCBpc24ndCB0aGVuIHRoZSAKICAgYWJv dmUgcGFydCBvZiB0aGUgZGVzY3JpcHRpb24gaXMgcmVkdW5kYW50LiAKNC4xMC0yIAogIFBJ TS1NVlBOIGFwcGVhcnMgZm9yIHRoZSBmaXJzdCB0aW1lLiAKNC4xMC0zIAogIHRoZSBwaHJh c2UgVURQLWJhc2VkIFMtUE1TSSBhcHBlYXJzIGhlcmUgZm9yIHRoZSBmaXJzdCB0aW1lLiAK ICBTb21ld2hlcmUgZWFybGllciBpdCBzaG91bGQgYmUgbWFkZSBjbGVhciB0aGF0IFVEUCB0 b28gbWF5IGJlIHVzZWQgCiAgaW4gc2lnbmFsaW5nLgoKNC4xMQogIGwyTDNWcG5NY2FzdFBt c2lUdW5uZWxBdHRyaWJ1dGVGbGFncyBPQkpFQ1QtVFlQRQo+ICAgICAgICAgIkZvciBVRFAt YmFzZWQgUy1QTVNJIHNpZ25hbGluZyBmb3IgUElNLU1WUE4sIHRoaXMgaXMgMC4KICAgICAi dGhpcyIgaXMgdW5jbGVhci4gCiAgICAgU29tZXRoaW5nIGxpa2UgInRoZSB2YWx1ZSBvZiB0 aGlzIG9iamVjdCBpcyAwIiAgd2lsbCBiZSBiZXR0ZXIuIAo+ICAgICAgICAgIE1vcmUgYml0 cyBtYXkgYmUgZGVmaW5lZCBpbiB0aGUgZnV0dXJlIGFuZAo+ICAgICAgICAgIHRoZXkgd2ls bCBiZSByZWdpc3RlcmVkIGluIElBTkEgUmVnaXN0cnkgeHh4eC4iCiAgVGhpcyBwYXJ0IGlz IHByb2JhYmx5IHJlZHVuZGFudC4KCjQuMTIKPiAgIC0tIFJGQyBFZC4gcmVwbGFjZSB4eHh4 IHdpdGggdGhlIGFjdHVhbCByZWdpc3RyeSBuYW1lCj4gICAtLSB0aGF0IGlzIGJlaW5nIGNy ZWF0ZWQgdmlhIFtJLUQuaWV0Zi1iZXNzLW12cG4tbWliXQo+ICAgLS0gYW5kIHJlbW92ZSB0 aGlzIG5vdGUuCgogIExvb2sgYXQgdGhlIGNvbW1lbnRzIGluIDYuMAoKNC4xMwogIGwyTDNW cG5NY2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVUeXBlIE9CSkVDVC1UWVBFCj4gICAgREVTQ1JJ UFRJT04KPiAgICAgICAgIkFzIGRlZmluZWQgZm9yIEwyTDNWcG5NY2FzdFByb3ZpZGVyVHVu bmVsVHlwZS4KPiAgICAgICAgIEZvciBVRFAtYmFzZWQgUy1QTVNJIHNpZ25hbGluZyBmb3Ig UElNLU1WUE4sCj4gICAgICAgICB0aGlzIGlzIHBpbS1hc20gKDMpLCBwaW0tc3NtICg0KSwg b3IgcGltLWJpZGlyICg1KS4KPiAgICAgICAgIEZvciBCR1AtYmFzZWQgSS9TLVBNU0kgc2ln bmFsaW5nLCB0aGlzIGlzIHRoZSBUdW5uZWwgVHlwZQo+ICAgICAgICAgZmllbGQgaW4gUE1T SSBUdW5uZWwgQXR0cmlidXRlIG9mIHRoZSBjb3JyZXNwb25kaW5nCj4gICAgICAgICBJL1Mt UE1TSSBBLUQgb3IgTGVhZiBBLUQgcm91dGUuIgogIG8gRG9lcyB0aGlzIGRlc2NyaXB0aW9u IGNvdmVyIGFsbCB0aGUgdHlwZXM/IElmIG5vdCwgdGhlbiBjb3ZlciBhbGwgdGhlIAogICAg dHlwZXMgdW5sZXNzIHRoZXJlIGlzIGEgZ29vZCByZWFzb24gdG8gZm9jdXMgb25seSBvbiB0 aGUgYWJvdmUgdHlwZXMuCiAgbyBJL1MtUE1TSTogdW5leHBsYWluZWQgbm90YXRpb24uCgo0 LjE0CgogIGwyTDNWcG5NY2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVJZCBPQkpFQ1QtVFlQRQo+ ICAgIFNZTlRBWCAgICAgICAgT0NURVQgU1RSSU5HICggU0laRSAoMHw0fDh8MTJ8MTd8MjR8 MjkpICkKICBJdCBhcHBlYXJzIHRoYXQgeW91IGFsc28gYWxsb3cgc2l6ZXMgIjE2IiBhbmQg IjMyIjsgdGhlc2UgbXVzdCBiZSBpbmNsdWRlZC4KCj4gICAgICAgICAgICBJUHY0L0lQdjYg ICAgIGwyTDNWcG5NY2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVUeXBlCiAgUGxlYXNlIGluZGlj YXRlIHRoYXQgdGhlIGZpcnN0IGNvbHVtbiBnaXZlcyB0aGUgc2l6ZSAKPiAgICAgICAgICAg ICAgIDgvMzIgICAgICAgcGltQXNtCj4gICAgICAgICAgICAgICA4LzMyICAgICAgIHBpbVNz bQo+ICAgICAgICAgICAgICAgOC8zMiAgICAgICBwaW1CaWRpcgo+ICAgICAgICAgICAgICAg NC8xNiAgICAgICBpbmdyZXNzUmVwbGljYXRpb24KCj4gICAgICAgICBGb3IgVURQLWJhc2Vk IFMtUE1TSSBzaWduYWxpbmcgZm9yIFBJTS1NVlBOLCB0aGUgZmlyc3QKPiAgICAgICAgIDgg b3IgMzIgb2N0ZXRzIG9mIHRoaXMgYXR0cmlidXRlIGFyZSBmaWxsZWQgd2l0aAo+ICAgICAg ICAgdGhlIHByb3ZpZGVyIHR1bm5lbCAoc291cmNlLCBncm91cCkgSVB2NC9JUHY2IGFkZHJl c3Nlcy4KPiAgICAgICAgIEZvciBCR1AtYmFzZWQgSS9TLVBNU0kgc2lnbmFsaW5nLCB0aGlz IGlzIHRoZSBUdW5uZWwKPiAgICAgICAgIElkZW50aWZpZXIgZmllbGQgaW4gUE1TSSBUdW5u ZWwgQXR0cmlidXRlIG9mIHRoZQo+ICAgICAgICAgY29ycmVzcG9uZGluZyBJL1MtUE1TSSBB LUQgcm91dGUuIgoKICBBIG1vcmUgZ2VuZXJvdXMgZGVzY3JpcHRpb24gb2YgdGhlIEF0dHJp YnV0ZUlEIHdvdWxkIGJlIGdvb2QuIEFsbCB0aGUgCiAgY2FzZXMgbXVzdCBiZSBjb3ZlcmVk LiBTZWN0aW9uIDUgb2YgUkZDIDY1MTQgZG9lcyBpdCBuaWNlbHkuIEEgc2ltcGxlIAogIHN1 bW1hcnkgd291bGQgYmUgdmVyeSBuaWNlLiAgCiAgCjQuMTUKICBsMkwzVnBuTWNhc3RQbXNp VHVubmVsUG9pbnRlciBPQkpFQ1QtVFlQRQo+ICAgIFNZTlRBWCAgICAgICAgUm93UG9pbnRl cgo+ICAgIERFU0NSSVBUSU9OCj4gICAgICAgICJJZiB0aGUgdHVubmVsIGV4aXN0cyBpbiBz b21lIE1JQiB0YWJsZSwgZS5nLiBtcGxzVHVubmVsVGFibGUKPiAgICAgICAgIFtSRkMzODEy XSwgdGhpcyBpcyB0aGUgcm93IHBvaW50ZXIgdG8gaXQuIE90aGVyd2lzZSwgdGhlCj4gICAg ICAgICBwb2ludGVyIGlzIG51bGwuIgogIEkgYW0gaGF2aW5nIHByb2JsZW1zIHVuZGVyc3Rh bmRpbmcgdGhpcy4gV2lsbCBoZWxwIGlmIHlvdSBjYW4gZ2l2ZQogIGEgdXNlIGNhc2Ugb2Yg aG93IHRoaXMgd2lsbCBiZSB1c2VkLiBBcyBvZiBub3cgdGhlIGludGVudCBpcyB1bmNsZWFy LgogIEEgUm93UG9pbnRlciBjYW5ub3QgYmUgcG9pbnRpbmcgdG8gInNvbWUgTUlCIHRhYmxl Ii4gSXQgbXVzdCBiZSAKICBwb2ludGVyIHRvIGEgc3BlY2lmaWMgcm93IGluIGEgc3BlY2lm aWMgdGFibGUuIElmIHRoaXMgaXMgYSBwb2ludGVyIHRvCiAgYSByb3cgaW4gdGhlIG1wbHNU dW5uZWxUYWJsZSBzcGVsbCBpdCBvdXQgY2xlYXJseSBhbmQgdW5hbWJpZ3VvdXNseS4gCgo0 LjE2CiAgbDJMM1Zwbk1jYXN0UG1zaVR1bm5lbElmIE9CSkVDVC1UWVBFCiAgICAgREVTQ1JJ UFRJT04KPiAgICAgICAgIklmIHRoZSB0dW5uZWwgaGFzIGEgY29ycmVzcG9uZGluZyBpbnRl cmZhY2UsIHRoaXMgaXMgdGhlCj4gICAgICAgICByb3cgcG9pbnRlciB0byBpZlhUYWJsZS4g T3RoZXJ3aXNlLCB0aGUgcG9pbnRlciBpcyBudWxsLiIKICBUaGlzIGRlc2NyaXB0aW9uIGlz IGJldHRlci4gIFdvdWxkIGJlIGV2ZW4gYmV0dGVyIHdpdGggCiAgICAgICAgICJJZiB0aGUg dHVubmVsIGhhcyBhIGNvcnJlc3BvbmRpbmcgZW50cnkgaW4gdGhlIGlmWFRhYmxlLCAKICAg ICAgICAgIHRoaXMgb2JqZWN0IHdpbGwgcG9pbnQgdG8gdGhlIHJvdyBwZXJ0YWluaW5nIHRv IHRoZSBlbnRyeSAuLi4uLiAKIAoKNC4xNwogIGwyTDNWcG5NY2FzdE9wdGlvbmFsR3JvdXAg ICAgT0JKRUNULUdST1VQCj4gICAgIERFU0NSSVBUSU9OCj4gICAgICAgICAiU3VwcG9ydCBv ZiB0aGVzZSBvYmplY3QgaXMgbm90IHJlcXVpcmVkLiIKICAgICAgICAgICBTdXBwb3J0IG9m IHRoZXNlIG9iamVjdHMgaXMgbm90IHJlcXVpcmVkLgoKNS4wCj41LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMKICAgVEJEIAoKNi4wCj42LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKPiAg SUFOQSBpcyByZXF1ZXN0ZWQgdG8gcm9vdCBNSUIgb2JqZWN0cyBpbiB0aGUgTUlCIG1vZHVs ZSBjb250YWluZWQgaW4KPiAgdGhpcyBkb2N1bWVudCB1bmRlciB0aGUgbWliLTIgc3VidHJl ZS4KICAgCiAgIFBsZWFzZSBOb3RlOgogICBUbyBtYWtlIHRoZSBMMkwzVnBuTWNhc3RQcm92 aWRlclR1bm5lbFR5cGUgVEMgbWFpbnRhaW5hYmxlIHlvdSBuZWVkIHRvIAogICBwdXQgdGhl IGRlZmluaXRpb25zIGluIGEgc2VwYXJhdGUgTUlCIG1vZHVsZS4gVGhhdCB3b3VsZCBtZWFu IGEgCiAgIHNlcGFyYXRlICBicmFuY2ggaW4gdGhlIG1pYi0yIHN1YnRyZWUuIFRoZW4gdGhl IG1haW50ZW5hbmNlIG9mIHRoZSAKICAgVEMgY2FuIGJlIGNhcnJpZWQgb3V0IGJ5IHNvbWUg ZW50aXR5ICggSUFOQSBvciwgc29tZSBXRyBvciwgd2hvZXZlciBpcwogICByZXNwb25zaWJs ZSBmb3IgbWFpbnRhaW5pbmcgdGhlIFRDKSBpbmRlcGVuZGVudCBvZiBvdGhlciBNSUIgb2Jq ZWN0cy4gCiAgIElmIHRoYXQgaXMgdGhlIGludGVudCB5b3Ugd2lsbCBuZWVkIHRvIGRlZmlu ZSAyIG1pYiBtb2R1bGVzIGFuZCB5b3Ugd2lsbCAKICAgbmVlZCB0byByZXF1ZXN0IDIgYnJh bmNoZXMgaW4gdGhlIG1pYi0yIHN1YnRyZWUtIG9uZSBmb3IgdGhlIG1vZHVsZSAKICAgY29u dGFpbmluZyB0aGUgTDJMM1Zwbk1jYXN0UHJvdmlkZXJUdW5uZWxUeXBlIFRDIGFuZCBhbm90 aGVyIGZvciB0aGUgCiAgIG1vZHVsZSBjb250YWluaW5nIHRoZSBsMkwzVnBuTWNhc3RQbXNp VHVubmVsQXR0cmlidXRlVGFibGUuIAoK --------------3B67671C878F662B3E729FE6-- From nobody Tue Jun 7 09:04:27 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 BB79C12D791 for ; Tue, 7 Jun 2016 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 74b8Pca2NXpc for ; Tue, 7 Jun 2016 09:04:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0CD12D79A for ; Tue, 7 Jun 2016 09:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3683; q=dns/txt; s=iport; t=1465315458; x=1466525058; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=45zhhQo6T6OTkGeQ3U3KyiBM7eOnazgD70ZNEwD6ZeI=; b=cvH8TysvD2rmwnMVttDD9tTMp32dcwQP/0Qqt3axdbqlElgThUPNB6Z8 0qVUaBM0ALrAxkLP2yIZiZmlLvhxAdKw6hP41aC42Pjju5y7/+5xQYULa Ak9lB5Fepm8CnbXJOczfIhRVck8WbC4roY43a1TEAIQ8j38AgBrdI0TiH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6AQAM8FZX/4MNJK1dgz1WfQa6ZIF5F?= =?us-ascii?q?wuFcQKBPjgUAQEBAQEBAWUnhEUBAQEEAQEBGlEGBRACAQgRBAEBKAcnCxQJCAI?= =?us-ascii?q?EAQ0FFIgbDrxUAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWKdIoaBY4eii0BhgOII?= =?us-ascii?q?48gj14BHjaDbm6JEH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,434,1459814400"; d="scan'208";a="112516337" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2016 16:04:17 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u57G4HWW006791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jun 2016 16:04:17 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 12:04:17 -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.1104.009; Tue, 7 Jun 2016 12:04:17 -0400 From: "Ali Sajassi (sajassi)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8AgAAObQCAE5+SgIAAQjEAgAj1lYCAAG49AIAVpCKAgAAP+YA= Date: Tue, 7 Jun 2016 16:04:16 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> In-Reply-To: <575680F5.2030101@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.3.39] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ali Sajassi \(sajassi\)" Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 07 Jun 2016 16:04:26 -0000 Hi Martin, We=B9ll also add idr-tunnel-encaps a Informative reference. With respect to Tunnel Encap Extended Community (which is the only part of idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself references RFC 5512. During the course of WG LC and RFC editorship of evpn-overlay draft, if we see that idr-tunnel-encap is progressing fast, then we can drop the reference to RFC 5512 and make the reference to idr-tunnel-encap Normative. Otherwise, we=B9ll keep both references with RFC 5512 as Normative and idr-tunnel-encap as Informative. Regards, Ali On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" wrote: >Hi, > >We are fine with keeping 5512 as the Normative reference for now. >We would think it wise if the editors can add an Informative reference >to draft-ietf-idr-tunnel-encaps (with some text indicating that both >specs provide the required support for the procedures). >The ideal situation would be that tunnel-encaps progresses fast enough >so that in the last stages before publishing evpn-overlay we can be in a >situation to make tunnel-encaps the Normative reference. RFC 4897 would >facilitate that by the way. > >If the WG has specific opinions on that matter, they are welcome. > >We take good note of the shepherd suggestion. We'll confirm who will >shepherd the document after WG LC (we'll also call for volunteers during >WG Last Call). > >Reviews are highly welcome anyway, in particular from people >close to the topic or implementations, and ideally from more than one >person, the best time being now or at least before the WG LC ends. > >We'll start the WG LC in a couple of days. > >Martin & Thomas > > >Le 24/05/2016 15:39, John E Drake a =E9crit : >> Hi, >> >> Ali and I decided to keep the normative reference to RFC 5512 rather >> than changing it to Eric=B9s tunnel encapsulation draft because the >> normative reference pre-dates Eric=B9s draft and because our draft does >> not use any of the new capabilities introduced in Eric=B9s draft. >> >> Ali and I would also like to request that Jorge be the document shepherd >> for this draft. >> >> Yours Irrespectively, >> >> John >> >> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >> *Sent:* Tuesday, May 24, 2016 3:05 AM >> *To:* John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; >> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - >> US); draft-ietf-idr-tunnel-encap@tools.ietf.org >> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. >> draft-ietf-idr-tunnel-encaps >> >> Folks, >> >> I have updated and published rev03 of even-overlay draft. >> >> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ >> >> The main changes are: >> >> 1. section 10.2 =AD DCI using ASBR >> 2. The setting of Ethernet tag and VNI fields =AD there were some >> inconsistencies in different sections. Section 5.1.3 captures the >> setting of these fields for different type of services in pretty >> good details. All other sections were cleaned up and now refer to >> section 5.1.3. >> >> Thomas, >> >> The draft is ready for its long-overdue WG LC considering how long its >> has been around and its multi-vendor implementation status. >> >> Regards, >> >> Ali >> >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jun 7 10:41:11 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 CC77612D5D1 for ; Tue, 7 Jun 2016 10:41:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 MZyxakn8Sw2j for ; Tue, 7 Jun 2016 10:41:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A9712D185 for ; Tue, 7 Jun 2016 10:41:07 -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=FuiIL21f9DhYFQg7772/KbU29g7qp5mSOAm7DXbQsBA=; b=HPZHMBZ2iJAbfYXemYKLnURnunpfOwpr83XUE0RF6lAS57uYhl150aabLONtv2hSvPCbQhH51rih8u1TU1Krd62uVQTD0K4PuZtFHqm8SBEffLExdWXw6foJm4zy/CtsKksbQi/3e4VdoLFsFTJpfT9pcp/TwnoY1siHy4yD3kc= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.511.8; Tue, 7 Jun 2016 17:41:04 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0511.010; Tue, 7 Jun 2016 17:41:04 +0000 From: John E Drake To: "Ali Sajassi (sajassi)" , Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznCAE6UwgIAAQX5QgAj2SYCAAGyekIAVpcGAgACE+ACAABr4QA== Date: Tue, 7 Jun 2016 17:41:04 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.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=jdrake@juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: 202bcfdb-e8e7-492f-41d4-08d38efae665 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:qu4vxRaSUQvbDZzVoAfVKT7oBb/PFpzUJsYm5d7Ggo11EuYBmx2PwWchzDDkbiSEzX7jlOTAWEtYXK0R5TK9vDXsNiPMPJ10O+ayn5mMw03w6tblIGyhMS6tdBhMrPYNmd99EytC2XjjdfyKXsbkog==; 24:2ch4KOV2m6dO2GZdetjAjRNp0uu5u+L6gMinZOPIbqMW7BhiRU8ggYU48vLSuKCKdTh8g8+GQx8V/bEPxXQYtS5ylMjL3D/8OzKQLj/8Jos=; 7:rsaOJzmfR6Nru7RHa0UK8lX9vCPpLoM98e4ibdFyJqXvyYjs+AIGpRhlcbSWgXCW905pNZ7g+caaLGE1MHqVB6nf/vOjFqJtmbr1awaMvWpUDalKlmsvuCJ23GyJHakh+arZzOrV3MoYhbmZM5gjHrwOe4PYzLPNKqGSb8Vo7bqEkY/qSftlvE8v5lr918uvOPpvw+1CtIiuDr8DTTT0CzmWnkA2ZjSucb2ikDDYTSM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(95692535739014)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(377454003)(13464003)(52314003)(189002)(24454002)(76176999)(2950100001)(2906002)(54356999)(2900100001)(50986999)(19580395003)(19580405001)(122556002)(8676002)(66066001)(33656002)(81156014)(15975445007)(3660700001)(92566002)(5003600100002)(3280700002)(189998001)(10400500002)(8936002)(86362001)(99286002)(106116001)(3846002)(107886002)(2501003)(9686002)(74316001)(81166006)(87936001)(76576001)(5004730100002)(97736004)(6116002)(102836003)(101416001)(68736007)(93886004)(586003)(5002640100001)(105586002)(77096005)(5008740100001)(230783001)(106356001)(11100500001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 17:41:04.6798 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 07 Jun 2016 17:41:10 -0000 This sounds like a plan. Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Ali Sajassi (sajas= si) > Sent: Tuesday, June 07, 2016 12:04 PM > To: Martin Vigoureux; bess@ietf.org > Cc: Ali Sajassi (sajassi) > Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr= -tunnel-encaps >=20 >=20 > Hi Martin, >=20 > We=B9ll also add idr-tunnel-encaps a Informative reference. With respect = to Tunnel Encap > Extended Community (which is the only part of idr-tunnel-encap used by ev= pn-overlay > draft), idr-tunel-encap draft itself references RFC 5512. >=20 > During the course of WG LC and RFC editorship of evpn-overlay draft, if w= e see that idr- > tunnel-encap is progressing fast, then we can drop the reference to RFC 5= 512 and make the > reference to idr-tunnel-encap Normative. Otherwise, we=B9ll keep both ref= erences with RFC > 5512 as Normative and idr-tunnel-encap as Informative. >=20 > Regards, > Ali >=20 > On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" > wrote: >=20 > >Hi, > > > >We are fine with keeping 5512 as the Normative reference for now. > >We would think it wise if the editors can add an Informative reference > >to draft-ietf-idr-tunnel-encaps (with some text indicating that both > >specs provide the required support for the procedures). > >The ideal situation would be that tunnel-encaps progresses fast enough > >so that in the last stages before publishing evpn-overlay we can be in > >a situation to make tunnel-encaps the Normative reference. RFC 4897 > >would facilitate that by the way. > > > >If the WG has specific opinions on that matter, they are welcome. > > > >We take good note of the shepherd suggestion. We'll confirm who will > >shepherd the document after WG LC (we'll also call for volunteers > >during WG Last Call). > > > >Reviews are highly welcome anyway, in particular from people close to > >the topic or implementations, and ideally from more than one person, > >the best time being now or at least before the WG LC ends. > > > >We'll start the WG LC in a couple of days. > > > >Martin & Thomas > > > > > >Le 24/05/2016 15:39, John E Drake a =E9crit : > >> Hi, > >> > >> Ali and I decided to keep the normative reference to RFC 5512 rather > >> than changing it to Eric=B9s tunnel encapsulation draft because the > >> normative reference pre-dates Eric=B9s draft and because our draft doe= s > >> not use any of the new capabilities introduced in Eric=B9s draft. > >> > >> Ali and I would also like to request that Jorge be the document > >> shepherd for this draft. > >> > >> Yours Irrespectively, > >> > >> John > >> > >> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > >> *Sent:* Tuesday, May 24, 2016 3:05 AM > >> *To:* John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; > >> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - > >> US); draft-ietf-idr-tunnel-encap@tools.ietf.org > >> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. > >> draft-ietf-idr-tunnel-encaps > >> > >> Folks, > >> > >> I have updated and published rev03 of even-overlay draft. > >> > >> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ > >> > >> The main changes are: > >> > >> 1. section 10.2 =AD DCI using ASBR > >> 2. The setting of Ethernet tag and VNI fields =AD there were some > >> inconsistencies in different sections. Section 5.1.3 captures the > >> setting of these fields for different type of services in pretty > >> good details. All other sections were cleaned up and now refer to > >> section 5.1.3. > >> > >> Thomas, > >> > >> The draft is ready for its long-overdue WG LC considering how long > >> its has been around and its multi-vendor implementation status. > >> > >> Regards, > >> > >> Ali > >> > >> > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jun 7 14:42:45 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 9D4D212B00D; Tue, 7 Jun 2016 14:42:40 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607214240.13676.71646.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 14:42:40 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-05.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:42:40 -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 : VPWS support in EVPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jeff Tantsura Dirk Steinberg Thomas Beckhaus Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-05.txt Pages : 14 Date : 2016-06-07 Abstract: This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 14:52:34 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 CA47112B015; Tue, 7 Jun 2016 14:52:29 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607215229.13740.1933.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2016 14:52:29 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-vpws-06.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, 07 Jun 2016 21:52:30 -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 : VPWS support in EVPN Authors : Sami Boutros Ali Sajassi Samer Salam John Drake Jeff Tantsura Dirk Steinberg Thomas Beckhaus Jorge Rabadan Filename : draft-ietf-bess-evpn-vpws-06.txt Pages : 13 Date : 2016-06-07 Abstract: This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of PW signaling, and provides fast protection convergence upon node or link failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-vpws-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 7 23:19:32 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2584D12B043 for ; Tue, 7 Jun 2016 23:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AUycssyysc2S for ; Tue, 7 Jun 2016 23:19:28 -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 BDD9C12D137 for ; Tue, 7 Jun 2016 23:19:27 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BBCD95FB533E8; Wed, 8 Jun 2016 06:19:22 +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 u586JPTI032681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2016 06:19:25 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u586JOIm004434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jun 2016 08:19:24 +0200 Received: from [135.224.200.76] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Jun 2016 08:19:24 +0200 Message-ID: <5757B8E6.3070106@alcatel-lucent.com> Date: Wed, 8 Jun 2016 08:19:18 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Ali Sajassi (sajassi)" , "bess@ietf.org" References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 06:19:31 -0000 Thank you Ali Le 07/06/2016 18:04, Ali Sajassi (sajassi) a écrit : > > Hi Martin, > > We¹ll also add idr-tunnel-encaps a Informative reference. With respect to > Tunnel Encap Extended Community (which is the only part of > idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself > references RFC 5512. > > During the course of WG LC and RFC editorship of evpn-overlay draft, if we > see that idr-tunnel-encap is progressing fast, then we can drop the > reference to RFC 5512 and make the reference to idr-tunnel-encap > Normative. Otherwise, we¹ll keep both references with RFC 5512 as > Normative and idr-tunnel-encap as Informative. > > Regards, > Ali > > On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >> Hi, >> >> We are fine with keeping 5512 as the Normative reference for now. >> We would think it wise if the editors can add an Informative reference >> to draft-ietf-idr-tunnel-encaps (with some text indicating that both >> specs provide the required support for the procedures). >> The ideal situation would be that tunnel-encaps progresses fast enough >> so that in the last stages before publishing evpn-overlay we can be in a >> situation to make tunnel-encaps the Normative reference. RFC 4897 would >> facilitate that by the way. >> >> If the WG has specific opinions on that matter, they are welcome. >> >> We take good note of the shepherd suggestion. We'll confirm who will >> shepherd the document after WG LC (we'll also call for volunteers during >> WG Last Call). >> >> Reviews are highly welcome anyway, in particular from people >> close to the topic or implementations, and ideally from more than one >> person, the best time being now or at least before the WG LC ends. >> >> We'll start the WG LC in a couple of days. >> >> Martin & Thomas >> >> >> Le 24/05/2016 15:39, John E Drake a écrit : >>> Hi, >>> >>> Ali and I decided to keep the normative reference to RFC 5512 rather >>> than changing it to Eric¹s tunnel encapsulation draft because the >>> normative reference pre-dates Eric¹s draft and because our draft does >>> not use any of the new capabilities introduced in Eric¹s draft. >>> >>> Ali and I would also like to request that Jorge be the document shepherd >>> for this draft. >>> >>> Yours Irrespectively, >>> >>> John >>> >>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>> *Sent:* Tuesday, May 24, 2016 3:05 AM >>> *To:* John E Drake; EXT - thomas.morin@orange.com; IDR; BESS; >>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - >>> US); draft-ietf-idr-tunnel-encap@tools.ietf.org >>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. >>> draft-ietf-idr-tunnel-encaps >>> >>> Folks, >>> >>> I have updated and published rev03 of even-overlay draft. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ >>> >>> The main changes are: >>> >>> 1. section 10.2 ­ DCI using ASBR >>> 2. The setting of Ethernet tag and VNI fields ­ there were some >>> inconsistencies in different sections. Section 5.1.3 captures the >>> setting of these fields for different type of services in pretty >>> good details. All other sections were cleaned up and now refer to >>> section 5.1.3. >>> >>> Thomas, >>> >>> The draft is ready for its long-overdue WG LC considering how long its >>> has been around and its multi-vendor implementation status. >>> >>> Regards, >>> >>> Ali >>> >>> >>> >>> _______________________________________________ >>> 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 Wed Jun 8 03:13: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 20E8E12D1B3 for ; Wed, 8 Jun 2016 03:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 S7JB8Tzsp_68 for ; Wed, 8 Jun 2016 03:12:56 -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 524A612B02F for ; Wed, 8 Jun 2016 03:12:56 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 08E5B5D862F; Wed, 8 Jun 2016 12:12:55 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 0020A5D84F1; Wed, 8 Jun 2016 12:12:54 +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.266.1; Wed, 8 Jun 2016 12:12:54 +0200 To: "Ali Sajassi (sajassi)" , "Jeffrey (Zhaohui) Zhang" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" References: <569DF8F7.2000703@orange.com> <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> From: Thomas Morin Organization: Orange Message-ID: <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> Date: Wed, 8 Jun 2016 12:12:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [bess] WG Last Call on 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: Wed, 08 Jun 2016 10:12:59 -0000 Hi Ali, I haven't started yet the shepherd write-up, but it's on my todo list. I will do a shepherd review along with the write-up, which may lead to resolving points with authors, but I can't tell before I get to do it. One thing that can be useful to collect right now is any information you may have on existing implementations (although this draft was WGLC'd before we setup BESS one-implementation policy, this question has been part of shepherd write-up question, even if its not considered a gating criteria). Thanks in advance, -Thomas 2016-06-06, Ali Sajassi (sajassi): > > Is there anything else you need from me or other co-authors to progress > this daft? The WG LC was completed before last IETF. > > Regards, > Ali > > On 5/24/16, 12:18 AM, "Ali Sajassi (sajassi)" wrote: > >> >> Hi Thomas, >> >> Can you please progress this draft. The WG LC was completed on 3/29 and >> all comments except a single optional comment were addressed before the >> last IETF. The single optional comment was addressed couple of weeks ago >> and the draft was re-published then. >> >> Regards, >> Ali >> >> >> On 5/11/16, 10:30 PM, "BESS on behalf of Ali Sajassi (sajassi)" >> wrote: >> >>> >>> Hi Thomas, >>> >>> I just made the final edits to evpn-etree draft and published it as >>> rev05. >>> >>> Regards, >>> Ali >>> >>> On 3/29/16, 2:49 AM, "thomas.morin@orange.com" >>> wrote: >>> >>>> Hi everyone, >>>> >>>> This WG Last Call is now closed and the document will move to the next >>>> steps toward publication. >>>> >>>> The modification mentioned below will be incorporated in next release. >>>> >>>> Best, >>>> >>>> -Thomas >>>> >>>> >>>> >>>> 2016-03-15, Ali Sajassi (sajassi): >>>>> >>>>> Jeffrey, >>>>> >>>>> >>>>> >>>>> On 2/1/16, 2:41 PM, "Jeffrey (Zhaohui) Zhang" >>>>> wrote: >>>>> >>>>>> Ali, >>>>>> >>>>>> One more question about PBB-EVPN. >>>>>> >>>>>> For the regular EVPN, section 3.3.2 talks about a situation where the >>>>>> only traffic is BUM. There is no need for mac learning in that >>>>>> situation. >>>>>> >>>>>> For PBB-EVPN, I assume this is also possible. With this, there is no >>>>>> need >>>>>> to advertise per-ES B-mac addresses - a single pair of global >>>>>> root/leaf >>>>>> B-mac addresses are enough. >>>>>> >>>>>> Perhaps this can be mentioned for parity/completeness. Of course, >>>>>> this >>>>>> is >>>>>> not a big deal and either way it's fine - but I do want to ask to >>>>>> confirm >>>>>> my understanding. >>>>> >>>>> We’ll do. >>>>> >>>>> Cheers, >>>>> Ali >>>>> >>>>>> >>>>>> Jeffrey >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>>>>>> Sent: Monday, February 01, 2016 2:04 AM >>>>>>> To: Jeffrey (Zhaohui) Zhang ; EXT - >>>>>>> thomas.morin@orange.com ; BESS >>>>>>> ; >>>>>>> draft-ietf-bess-evpn-etree@tools.ietf.org >>>>>>> Subject: Re: [bess] WG Last Call on draft-ietf-bess-evpn-etree >>>>>>> >>>>>>> Hi Jeffrey, >>>>>>> >>>>>>> Thanks for the review. Your comments helps tighten the draft some >>>>>>> more. >>>>>>> I >>>>>>> have updated the draft and will publish it next (rev04). Majority of >>>>>>> the >>>>>>> comments were editorial in nature for better clarifications. Since >>>>>>> the >>>>>>> existing draft (rev03) reflects the consensus regarding our several >>>>>>> rounds >>>>>>> of discussions where we have taken care of the technical items, it >>>>>>> is >>>>>>> consistent with our expectation of not seeing any major issue during >>>>>>> the >>>>>>> LC. Please refer to my replies in line. >>>>>>> >>>>>>> Cheers, >>>>>>> Ali >>>>>>> >>>>>>> >>>>>>> On 1/27/16, 5:26 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" >>>>>>> wrote: >>>>>>> >>>>>>>> I was involved in relevant discussions, and have reviewed once more >>>>>>>> for >>>>>>>> this LC. >>>>>>>> >>>>>>>> I support the publication, but with the following >>>>>>>> questions/comments. >>>>>>>> >>>>>>>> 2.1 Scenario 1: Leaf OR Root site(s) per PE >>>>>>>> >>>>>>>> ... If the number of EVIs is very large >>>>>>>> (e.g., more than 32K or 64K), then RT type 0 as defined in >>>>>>>> [RFC4360] >>>>>>>> SHOULD be used; otherwise, RT type 2 is sufficient. >>>>>>>> >>>>>>>> RFC 7153 should be referenced for "Type 2". >>>>>>> >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>>> >>>>>>>> Additionally, why is 32K mentioned? I can understand the 64k part. >>>>>>> >>>>>>> Removed 32K since the example is clear enough with 64K >>>>>>> >>>>>>>> >>>>>>>> ... the MPLS-encapsulated frames MUST be tagged with an >>>>>>>> indication of whether they originated from a Leaf AC or not. >>>>>>>> >>>>>>>> Perhaps change the last line to "indication if they originated from >>>>>>>> a >>>>>>>> Leaf AC"? Packets from a root AC are not tagged with a leaf >>>>>>>> indication. >>>>>>> >>>>>>> OK. Better yet. It should say ³indication when they originated from >>>>>>> a >>>>>>> leaf >>>>>>> AC². >>>>>>> >>>>>>>> >>>>>>>> Other mechanisms for identifying whether an egress AC is a root >>>>>>>> or >>>>>>>> leaf is beyond the scope of this document. >>>>>>>> >>>>>>>> Should "egress" be "ingress" in the above paragraph? Or simply >>>>>>>> removed? >>>>>>> >>>>>>> Nice catch! It is ³ingress². It is now corrected. >>>>>>> >>>>>>>> >>>>>>>> ... This Leaf MPLS 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 the >>>>>>>> leaf >>>>>>>> ACs on the PE. >>>>>>>> >>>>>>>> Perhaps change the last sentence to "... corresponding to all EVIs >>>>>>>> that >>>>>>>> have leaf sites on the PE." >>>>>>> >>>>>>> The second to last sentence of section 3.2.1 says the same thing. I >>>>>>> changed this sentence and removed the 2nd to last sentence. >>>>>>> >>>>>>>> >>>>>>>> 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC >>>>>>>> >>>>>>>> In this scenario, it is assumed that a multi-homed Ethernet >>>>>>>> Segment >>>>>>>> (ES) can have a mixed of both leaf and root ACs with each AC >>>>>>>> designating a subnet (e.g., a VLAN). >>>>>>>> >>>>>>>> I understand that different VLANs on the same ES could be roots or >>>>>>>> leaves. I suppose it's more important to say that for the same >>>>>>>> vlan, >>>>>>>> different PEs on the same ES must have the same root/leaf >>>>>>>> designation. >>>>>>> >>>>>>> That¹s given. >>>>>>> >>>>>>>> >>>>>>>> Perhaps the first sentence could be reworded as the following to >>>>>>> capture >>>>>>>> the above point: >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> That¹s fine. It makes it more clear. >>>>>>> >>>>>>>> >>>>>>>> For the following: >>>>>>>> >>>>>>>> ... the PEs with Leaf sites perform MAC learning in the >>>>>>>> data-path over their Ethernet Segments, and advertise >>>>>>>> reachability >>>>>>> in >>>>>>>> EVPN MAC Advertisement routes which are imported only by PEs >>>>>>>> with >>>>>>>> at >>>>>>>> least one Root site in the EVI. 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 [RFC 7432]. >>>>>>>> >>>>>>>> The above seems to contradict with the recommendation in Section >>>>>>>> 2.2. >>>>>>> If >>>>>>>> the context is the scenario described in section 2.1 then that's >>>>>>>> fine, >>>>>>>> but the text does not have a clear context. >>>>>>> >>>>>>> Agreed. Updated the section to indicate the context is section 2.1. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 multicast >>>>>>>> or >>>>>>>> broadcast. >>>>>>>> >>>>>>>> I suppose an "only" word should be added at the end of the above >>>>>>> sentence. >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The fields of the IMET route are populated per the procedures >>>>>>> defined >>>>>>>> in [RFC7432], and the route import rules are as described in >>>>>>> previous >>>>>>>> sections. >>>>>>>> >>>>>>>> The route import rules described in previous sections are for MAC >>>>>>> routes, >>>>>>>> not IMET routes. Additionally, those rules may not be recommended, >>>>>>>> so >>>>>>>> might as well delete the last sentence. >>>>>>> >>>>>>> Changed the last sentence to ³Š, and the multicast tunnel setup >>>>>>> criteria >>>>>>> are as described in the previous section.² >>>>>>> >>>>>>>> >>>>>>>> Section 3.3.1 talks about BUM procedures. That is not specific to >>>>>>>> 3.3.1 >>>>>>>> though. Perhaps extract that out to a separate section, and remove >>>>>>>> the >>>>>>>> BUM text from 3.3.2 as well. >>>>>>> >>>>>>> I think it is OK. >>>>>>> >>>>>>>> >>>>>>>> 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=0x06 | Sub-Type=0x04 | Flags(1 Octet)| >>>>>>> | >>>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> | Reserved=0 | Leaf Label >>>>>>> | >>>>>>>> >>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>> >>>>>>>> I assume the octect after the flags octet is also reserved=0. >>>>>>>> Better >>>>>>> mark >>>>>>>> it as "Reserved=0". >>>>>>> >>>>>>> Agreed. >>>>>>> >>>>>>>> >>>>>>>> When it is used with Ethernet A-D per ES route, the leaf flag >>>>>>>> SHOULD >>>>>>>> be >>>>>>>> set to 0 but ignored by the receiving routers. Therefore, why not >>>>>>>> set >>>>>>> it >>>>>>>> to 1 to be consistent the MAC/IP route case? >>>>>>> >>>>>>> Because the flag is used for known unicast traffic and Leaf label >>>>>>> for >>>>>>> BUM >>>>>>> traffic. We don¹t want to mix the two. >>>>>>> >>>>>>> Cheers, >>>>>>> Ali >>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> Jeffrey >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas >>>>>>>>> Morin >>>>>>>>> Sent: Tuesday, January 19, 2016 3:51 AM >>>>>>>>> To: BESS ; >>>>>>>>> draft-ietf-bess-evpn-etree@tools.ietf.org >>>>>>>>> Subject: [bess] WG Last Call on draft-ietf-bess-evpn-etree >>>>>>>>> >>>>>>>>> Hello Working Group, >>>>>>>>> >>>>>>>>> This email starts a Working Group Last Call on >>>>>>>>> draft-ietf-bess-evpn-etree [1] which is considered mature and >>>>>>>>> ready >>>>>>> for >>>>>>>>> a final working group review. >>>>>>>>> >>>>>>>>> Please read the document if you haven't read the most recent >>>>>>>>> version >>>>>>> yet >>>>>>>>> (-03), and send your comments to the list, no later than *February >>>>>>> the >>>>>>>>> 2nd* (2016-02-02). >>>>>>>>> >>>>>>>>> This is not only a call for comments on the document, but also a >>>>>>>>> call >>>>>>> of >>>>>>>>> support for its publication. >>>>>>>>> >>>>>>>>> *Coincidentally*, we are also polling for knowledge of any IPR >>>>>>>>> that >>>>>>>>> applies to draft-ietf-bess-evpn-etree, 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 of >>>>>>>>> draft-ietf-bess-evpn-etree please respond to this email and >>>>>>>>> indicate >>>>>>>>> whether or not you are aware of any relevant IPR. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> Thomas/Martin >>>>>>>>> >>>>>>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-etree >>>>>>>>> From nobody Wed Jun 8 09:39:13 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 1FF8A12DA12 for ; Wed, 8 Jun 2016 09:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 nivMH-e6o-Ym for ; Wed, 8 Jun 2016 09:39:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0B712D98C for ; Wed, 8 Jun 2016 09:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19366; q=dns/txt; s=iport; t=1465403945; x=1466613545; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4n8InZlM05ngl65fas1WP/B12wZfqxJsiJbFIfqyPo8=; b=WnAtOyNANkeLQp3o3A1QB7DZyJ/1jMJUmqPBGBB6BmoSP0RIvlinyE0t eSTzJUFc9Ej/Mcqym793XmwNguKDEkSQvcI3uVPKr7k4RAIFnTgih1mEh 5xZ0mH2HU+sL3LN5zH8zrIV13dbTa0/YwAoNrrLyyD8Wb1bqjXV4jJ43L c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCASVhX/4cNJK1egz5WfQa7BoF5F?= =?us-ascii?q?wuFcQIcgSM4FAEBAQEBAQFlJ4RFAQEBBAEBARoGETkBFwQCAQgRBAEBAQICIwM?= =?us-ascii?q?CAgIlCxQBCAgCBAESFIgbDqxMkSIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBi?= =?us-ascii?q?HCBA4QSEQEzgmqCWQWYTwGGAogjgWmEUoMshTiPYAEeNoNubohaNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,440,1459814400"; d="scan'208";a="111172675" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jun 2016 16:39:04 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u58Gd3CV007443 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jun 2016 16:39:03 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 8 Jun 2016 12:39:02 -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.1104.009; Wed, 8 Jun 2016 12:39:03 -0400 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "Jeffrey (Zhaohui) Zhang" , BESS , "draft-ietf-bess-evpn-etree@tools.ietf.org" Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaME/U9KT8MU0ut9l7k3idEc58OWnfAgAhLYwCAAYwoAIBC0CQAgBXcMACARGjgAIAS+kOAgBUQT4CAAyi9AP//9ucA Date: Wed, 8 Jun 2016 16:39:03 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> In-Reply-To: <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.128.2.139] Content-Type: text/plain; charset="utf-8" Content-ID: <3905F9AE2D957D4E823BF8AF026E1F01@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] WG Last Call on 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: Wed, 08 Jun 2016 16:39:08 -0000 DQpIaSBUaG9tYXMsDQoNCkkgYW5kIG90aGVyIGNvLWF1dGhvcnMgd2lsbCBiZSBsb29raW5nIGZv cndhcmQgdG8gcmVjZWl2aW5nIHlvdXIgd3JpdGUtdXANCmFuZCBhbnN3ZXIgdGhlIHF1ZXN0aW9u IHJlZ2FyZGluZyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbi4gRnJvbSBteSBzaWRlLCBJDQpoYXZl IHRoZSBpbmZvIGFuZCBJIGFtIHN1cmUgaXQgaXMgdGhlIHNhbWUgZm9yIG90aGVyIGNvLWF1dGhv cnMuIFRoYW5rcw0KZm9yIGdpdmluZyB0aGUgaGVhZHMtdXAgc2luY2Ugc29tZSBjby1hdXRob3Jz IG5lZWQgdG8gY2hlY2sgd2l0aCB0aGVpcg0KUExNcyBiZWZvcmUgbWFraW5nIHB1YmxpYyBzdGF0 ZW1lbnQgcmVnYXJkaW5nIHRoZWlyIGltcGxlbWVudGF0aW9uLg0KDQpSZWdhcmRzLA0KQWxpDQoN Ck9uIDYvOC8xNiwgMzoxMiBBTSwgIkJFU1Mgb24gYmVoYWxmIG9mIFRob21hcyBNb3JpbiINCjxi ZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRob21hcy5tb3JpbkBvcmFuZ2UuY29t PiB3cm90ZToNCg0KPkhpIEFsaSwNCj4NCj5JIGhhdmVuJ3Qgc3RhcnRlZCB5ZXQgdGhlIHNoZXBo ZXJkIHdyaXRlLXVwLCBidXQgaXQncyBvbiBteSB0b2RvIGxpc3QuDQo+DQo+SSB3aWxsIGRvIGEg c2hlcGhlcmQgcmV2aWV3IGFsb25nIHdpdGggdGhlIHdyaXRlLXVwLCB3aGljaCBtYXkgbGVhZCB0 bw0KPnJlc29sdmluZyBwb2ludHMgd2l0aCBhdXRob3JzLCBidXQgSSBjYW4ndCB0ZWxsIGJlZm9y ZSBJIGdldCB0byBkbyBpdC4NCj4NCj5PbmUgdGhpbmcgdGhhdCBjYW4gYmUgdXNlZnVsIHRvIGNv bGxlY3QgcmlnaHQgbm93IGlzIGFueSBpbmZvcm1hdGlvbiB5b3UNCj5tYXkgaGF2ZSBvbiBleGlz dGluZyBpbXBsZW1lbnRhdGlvbnMgKGFsdGhvdWdoIHRoaXMgZHJhZnQgd2FzIFdHTEMnZA0KPmJl Zm9yZSB3ZSBzZXR1cCBCRVNTIG9uZS1pbXBsZW1lbnRhdGlvbiBwb2xpY3ksIHRoaXMgcXVlc3Rp b24gaGFzIGJlZW4NCj5wYXJ0IG9mIHNoZXBoZXJkIHdyaXRlLXVwIHF1ZXN0aW9uLCBldmVuIGlm IGl0cyBub3QgY29uc2lkZXJlZCBhIGdhdGluZw0KPmNyaXRlcmlhKS4NCj4NCj5UaGFua3MgaW4g YWR2YW5jZSwNCj4NCj4tVGhvbWFzDQo+DQo+DQo+MjAxNi0wNi0wNiwgQWxpIFNhamFzc2kgKHNh amFzc2kpOg0KPj4NCj4+IElzIHRoZXJlIGFueXRoaW5nIGVsc2UgeW91IG5lZWQgZnJvbSBtZSBv ciBvdGhlciBjby1hdXRob3JzIHRvIHByb2dyZXNzDQo+PiB0aGlzIGRhZnQ/IFRoZSBXRyBMQyB3 YXMgY29tcGxldGVkIGJlZm9yZSBsYXN0IElFVEYuDQo+Pg0KPj4gUmVnYXJkcywNCj4+IEFsaQ0K Pj4NCj4+IE9uIDUvMjQvMTYsIDEyOjE4IEFNLCAiQWxpIFNhamFzc2kgKHNhamFzc2kpIiA8c2Fq YXNzaUBjaXNjby5jb20+IHdyb3RlOg0KPj4NCj4+Pg0KPj4+IEhpIFRob21hcywNCj4+Pg0KPj4+ IENhbiB5b3UgcGxlYXNlIHByb2dyZXNzIHRoaXMgZHJhZnQuIFRoZSBXRyBMQyB3YXMgY29tcGxl dGVkIG9uIDMvMjkgYW5kDQo+Pj4gYWxsIGNvbW1lbnRzIGV4Y2VwdCBhIHNpbmdsZSBvcHRpb25h bCBjb21tZW50IHdlcmUgYWRkcmVzc2VkIGJlZm9yZSB0aGUNCj4+PiBsYXN0IElFVEYuIFRoZSBz aW5nbGUgb3B0aW9uYWwgY29tbWVudCB3YXMgYWRkcmVzc2VkIGNvdXBsZSBvZiB3ZWVrcw0KPj4+ YWdvDQo+Pj4gYW5kIHRoZSBkcmFmdCB3YXMgcmUtcHVibGlzaGVkIHRoZW4uDQo+Pj4NCj4+PiBS ZWdhcmRzLA0KPj4+IEFsaQ0KPj4+DQo+Pj4NCj4+PiBPbiA1LzExLzE2LCAxMDozMCBQTSwgIkJF U1Mgb24gYmVoYWxmIG9mIEFsaSBTYWphc3NpIChzYWphc3NpKSINCj4+PiA8YmVzcy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBzYWphc3NpQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4NCj4+ Pj4NCj4+Pj4gSGkgVGhvbWFzLA0KPj4+Pg0KPj4+PiBJIGp1c3QgbWFkZSB0aGUgZmluYWwgZWRp dHMgdG8gZXZwbi1ldHJlZSBkcmFmdCBhbmQgcHVibGlzaGVkIGl0IGFzDQo+Pj4+IHJldjA1Lg0K Pj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBBbGkNCj4+Pj4NCj4+Pj4gT24gMy8yOS8xNiwgMjo0 OSBBTSwgInRob21hcy5tb3JpbkBvcmFuZ2UuY29tIg0KPj4+Pjx0aG9tYXMubW9yaW5Ab3Jhbmdl LmNvbT4NCj4+Pj4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBIaSBldmVyeW9uZSwNCj4+Pj4+DQo+Pj4+ PiBUaGlzIFdHIExhc3QgQ2FsbCBpcyBub3cgY2xvc2VkIGFuZCB0aGUgZG9jdW1lbnQgd2lsbCBt b3ZlIHRvIHRoZQ0KPj4+Pj5uZXh0DQo+Pj4+PiBzdGVwcyB0b3dhcmQgcHVibGljYXRpb24uDQo+ Pj4+Pg0KPj4+Pj4gVGhlIG1vZGlmaWNhdGlvbiBtZW50aW9uZWQgYmVsb3cgd2lsbCBiZSBpbmNv cnBvcmF0ZWQgaW4gbmV4dA0KPj4+Pj5yZWxlYXNlLg0KPj4+Pj4NCj4+Pj4+IEJlc3QsDQo+Pj4+ Pg0KPj4+Pj4gLVRob21hcw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gMjAxNi0wMy0xNSwg QWxpIFNhamFzc2kgKHNhamFzc2kpOg0KPj4+Pj4+DQo+Pj4+Pj4gSmVmZnJleSwNCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiAyLzEvMTYsIDI6NDEgUE0sICJKZWZmcmV5IChaaGFv aHVpKSBaaGFuZyIgPHp6aGFuZ0BqdW5pcGVyLm5ldD4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pg0K Pj4+Pj4+PiBBbGksDQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IFBC Qi1FVlBOLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb3IgdGhlIHJlZ3VsYXIgRVZQTiwgc2VjdGlvbiAz LjMuMiB0YWxrcyBhYm91dCBhIHNpdHVhdGlvbiB3aGVyZQ0KPj4+Pj4+PnRoZQ0KPj4+Pj4+PiBv bmx5IHRyYWZmaWMgaXMgQlVNLiBUaGVyZSBpcyBubyBuZWVkIGZvciBtYWMgbGVhcm5pbmcgaW4g dGhhdA0KPj4+Pj4+PiBzaXR1YXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEZvciBQQkItRVZQTiwg SSBhc3N1bWUgdGhpcyBpcyBhbHNvIHBvc3NpYmxlLiBXaXRoIHRoaXMsIHRoZXJlIGlzDQo+Pj4+ Pj4+bm8NCj4+Pj4+Pj4gbmVlZA0KPj4+Pj4+PiB0byBhZHZlcnRpc2UgcGVyLUVTIEItbWFjIGFk ZHJlc3NlcyAtIGEgc2luZ2xlIHBhaXIgb2YgZ2xvYmFsDQo+Pj4+Pj4+IHJvb3QvbGVhZg0KPj4+ Pj4+PiBCLW1hYyBhZGRyZXNzZXMgYXJlIGVub3VnaC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUGVyaGFw cyB0aGlzIGNhbiBiZSBtZW50aW9uZWQgZm9yIHBhcml0eS9jb21wbGV0ZW5lc3MuIE9mIGNvdXJz ZSwNCj4+Pj4+Pj4gdGhpcw0KPj4+Pj4+PiBpcw0KPj4+Pj4+PiBub3QgYSBiaWcgZGVhbCBhbmQg ZWl0aGVyIHdheSBpdCdzIGZpbmUgLSBidXQgSSBkbyB3YW50IHRvIGFzayB0bw0KPj4+Pj4+PiBj b25maXJtDQo+Pj4+Pj4+IG15IHVuZGVyc3RhbmRpbmcuDQo+Pj4+Pj4NCj4+Pj4+PiBXZeKAmWxs IGRvLg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+IEFsaQ0KPj4+Pj4+DQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEplZmZyZXkNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+PiBGcm9tOiBBbGkgU2FqYXNzaSAoc2FqYXNzaSkgW21haWx0bzpzYWph c3NpQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDEsIDIwMTYg MjowNCBBTQ0KPj4+Pj4+Pj4gVG86IEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIDx6emhhbmdAanVu aXBlci5uZXQ+OyBFWFQgLQ0KPj4+Pj4+Pj4gdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gPHRob21h cy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUw0KPj4+Pj4+Pj4gPGJlc3NAaWV0Zi5vcmc+Ow0KPj4+ Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWVAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+ IFN1YmplY3Q6IFJlOiBbYmVzc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtYmVzcy1ldnBu LWV0cmVlDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSGkgSmVmZnJleSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFlvdXIgY29tbWVudHMgaGVscHMgdGlnaHRlbiB0aGUg ZHJhZnQgc29tZQ0KPj4+Pj4+Pj4gbW9yZS4NCj4+Pj4+Pj4+IEkNCj4+Pj4+Pj4+IGhhdmUgdXBk YXRlZCB0aGUgZHJhZnQgYW5kIHdpbGwgcHVibGlzaCBpdCBuZXh0IChyZXYwNCkuIE1ham9yaXR5 DQo+Pj4+Pj4+Pm9mDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+IGNvbW1lbnRzIHdlcmUgZWRpdG9y aWFsIGluIG5hdHVyZSBmb3IgYmV0dGVyIGNsYXJpZmljYXRpb25zLiBTaW5jZQ0KPj4+Pj4+Pj4g dGhlDQo+Pj4+Pj4+PiBleGlzdGluZyBkcmFmdCAocmV2MDMpIHJlZmxlY3RzIHRoZSBjb25zZW5z dXMgcmVnYXJkaW5nIG91cg0KPj4+Pj4+Pj5zZXZlcmFsDQo+Pj4+Pj4+PiByb3VuZHMNCj4+Pj4+ Pj4+IG9mIGRpc2N1c3Npb25zIHdoZXJlIHdlIGhhdmUgdGFrZW4gY2FyZSBvZiB0aGUgdGVjaG5p Y2FsIGl0ZW1zLCBpdA0KPj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+IGNvbnNpc3RlbnQgd2l0aCBvdXIg ZXhwZWN0YXRpb24gb2Ygbm90IHNlZWluZyBhbnkgbWFqb3IgaXNzdWUNCj4+Pj4+Pj4+ZHVyaW5n DQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+IExDLiBQbGVhc2UgcmVmZXIgdG8gbXkgcmVwbGllcyBp biBsaW5lLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+IEFsaQ0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPbiAxLzI3LzE2LCA1OjI2IFBNLCAiQkVTUyBvbiBiZWhh bGYgb2YgSmVmZnJleSAoWmhhb2h1aSkgWmhhbmciDQo+Pj4+Pj4+PiA8YmVzcy1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiB6emhhbmdAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBJIHdhcyBpbnZvbHZlZCBpbiByZWxldmFudCBkaXNjdXNzaW9ucywgYW5kIGhh dmUgcmV2aWV3ZWQgb25jZQ0KPj4+Pj4+Pj4+bW9yZQ0KPj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4+ IHRoaXMgTEMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHN1cHBvcnQgdGhlIHB1YmxpY2F0aW9u LCBidXQgd2l0aCB0aGUgZm9sbG93aW5nDQo+Pj4+Pj4+Pj4gcXVlc3Rpb25zL2NvbW1lbnRzLg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gMi4xIFNjZW5hcmlvIDE6IExlYWYgT1IgUm9vdCBzaXRlKHMp IHBlciBQRQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgLi4uIElmIHRoZSBudW1iZXIgb2YgRVZJ cyBpcyB2ZXJ5IGxhcmdlDQo+Pj4+Pj4+Pj4gICAgKGUuZy4sIG1vcmUgdGhhbiAzMksgb3IgNjRL KSwgdGhlbiBSVCB0eXBlIDAgYXMgZGVmaW5lZCBpbg0KPj4+Pj4+Pj4+IFtSRkM0MzYwXQ0KPj4+ Pj4+Pj4+ICAgIFNIT1VMRCBiZSB1c2VkOyBvdGhlcndpc2UsIFJUIHR5cGUgMiBpcyBzdWZmaWNp ZW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gUkZDIDcxNTMgc2hvdWxkIGJlIHJlZmVyZW5jZWQg Zm9yICJUeXBlIDIiLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBEb25lLg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFkZGl0aW9uYWxseSwgd2h5IGlzIDMySyBtZW50aW9u ZWQ/IEkgY2FuIHVuZGVyc3RhbmQgdGhlIDY0aw0KPj4+Pj4+Pj4+cGFydC4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBSZW1vdmVkIDMySyBzaW5jZSB0aGUgZXhhbXBsZSBpcyBjbGVhciBlbm91Z2ggd2l0 aCA2NEsNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAuLi4gdGhlIE1QTFMtZW5j YXBzdWxhdGVkIGZyYW1lcyBNVVNUIGJlIHRhZ2dlZCB3aXRoIGFuDQo+Pj4+Pj4+Pj4gICAgaW5k aWNhdGlvbiBvZiB3aGV0aGVyIHRoZXkgb3JpZ2luYXRlZCBmcm9tIGEgTGVhZiBBQyBvciBub3Qu DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBQZXJoYXBzIGNoYW5nZSB0aGUgbGFzdCBsaW5lIHRvICJp bmRpY2F0aW9uIGlmIHRoZXkgb3JpZ2luYXRlZA0KPj4+Pj4+Pj4+ZnJvbQ0KPj4+Pj4+Pj4+IGEN Cj4+Pj4+Pj4+PiBMZWFmIEFDIj8gUGFja2V0cyBmcm9tIGEgcm9vdCBBQyBhcmUgbm90IHRhZ2dl ZCB3aXRoIGEgbGVhZg0KPj4+Pj4+Pj4+IGluZGljYXRpb24uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g T0suIEJldHRlciB5ZXQuIEl0IHNob3VsZCBzYXkgwrNpbmRpY2F0aW9uIHdoZW4gdGhleSBvcmln aW5hdGVkDQo+Pj4+Pj4+PmZyb20NCj4+Pj4+Pj4+IGENCj4+Pj4+Pj4+IGxlYWYNCj4+Pj4+Pj4+ IEFDwrIuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgT3RoZXIgbWVjaGFuaXNt cyBmb3IgaWRlbnRpZnlpbmcgd2hldGhlciBhbiBlZ3Jlc3MgQUMgaXMgYQ0KPj4+Pj4+Pj4+cm9v dA0KPj4+Pj4+Pj4+IG9yDQo+Pj4+Pj4+Pj4gICAgbGVhZiBpcyBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgZG9jdW1lbnQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBTaG91bGQgImVncmVzcyIgYmUg ImluZ3Jlc3MiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGg/IE9yIHNpbXBseQ0KPj4+Pj4+Pj4+IHJl bW92ZWQ/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTmljZSBjYXRjaCEgSXQgaXMgwrNpbmdyZXNzwrIu IEl0IGlzIG5vdyBjb3JyZWN0ZWQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAg Li4uIFRoaXMgTGVhZiBNUExTIGxhYmVsIGlzIGFkdmVydGlzZWQgdG8gb3RoZXIgUEUgZGV2aWNl cywNCj4+Pj4+Pj4+PiAgICB1c2luZyBhIG5ldyBFVlBOIEV4dGVuZGVkIENvbW11bml0eSBjYWxs ZWQgRS1UUkVFIEV4dGVuZGVkDQo+Pj4+Pj4+Pj4gQ29tbXVuaXR5DQo+Pj4+Pj4+Pj4gICAgKHNl Y3Rpb24gNS4xKSBhbG9uZyB3aXRoIGFuIEV0aGVybmV0IEEtRCBwZXIgRVMgcm91dGUgd2l0aCBF U0kNCj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+ICAgIHplcm8gYW5kIGEgc2V0IG9mIFJvdXRlIFRh cmdldHMgKFJUcykgY29ycmVzcG9uZGluZyB0byBhbGwgdGhlDQo+Pj4+Pj4+Pj4gbGVhZg0KPj4+ Pj4+Pj4+ICAgIEFDcyBvbiB0aGUgUEUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBQZXJoYXBzIGNo YW5nZSB0aGUgbGFzdCBzZW50ZW5jZSB0byAiLi4uIGNvcnJlc3BvbmRpbmcgdG8gYWxsDQo+Pj4+ Pj4+Pj5FVklzDQo+Pj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+Pj4+IGhhdmUgbGVhZiBzaXRlcyBvbiB0 aGUgUEUuIg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoZSBzZWNvbmQgdG8gbGFzdCBzZW50ZW5jZSBv ZiBzZWN0aW9uIDMuMi4xIHNheXMgdGhlIHNhbWUgdGhpbmcuDQo+Pj4+Pj4+PkkNCj4+Pj4+Pj4+ IGNoYW5nZWQgdGhpcyBzZW50ZW5jZSBhbmQgcmVtb3ZlZCB0aGUgMm5kIHRvIGxhc3Qgc2VudGVu Y2UuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gMy4yLjMgQlVNIHRyYWZmaWMgb3Jp Z2luYXRlZCBmcm9tIGEgbXVsdGktaG9tZWQgc2l0ZSBvbiBhIGxlYWYgQUMNCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+ICAgIEluIHRoaXMgc2NlbmFyaW8sIGl0IGlzIGFzc3VtZWQgdGhhdCBhIG11bHRp LWhvbWVkIEV0aGVybmV0DQo+Pj4+Pj4+Pj4gU2VnbWVudA0KPj4+Pj4+Pj4+ICAgIChFUykgY2Fu IGhhdmUgYSBtaXhlZCBvZiBib3RoIGxlYWYgYW5kIHJvb3QgQUNzIHdpdGggZWFjaCBBQw0KPj4+ Pj4+Pj4+ICAgIGRlc2lnbmF0aW5nIGEgc3VibmV0IChlLmcuLCBhIFZMQU4pLg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gSSB1bmRlcnN0YW5kIHRoYXQgZGlmZmVyZW50IFZMQU5zIG9uIHRoZSBzYW1l IEVTIGNvdWxkIGJlIHJvb3RzDQo+Pj4+Pj4+Pj5vcg0KPj4+Pj4+Pj4+IGxlYXZlcy4gSSBzdXBw b3NlIGl0J3MgbW9yZSBpbXBvcnRhbnQgdG8gc2F5IHRoYXQgZm9yIHRoZSBzYW1lDQo+Pj4+Pj4+ Pj4gdmxhbiwNCj4+Pj4+Pj4+PiBkaWZmZXJlbnQgUEVzIG9uIHRoZSBzYW1lIEVTIG11c3QgaGF2 ZSB0aGUgc2FtZSByb290L2xlYWYNCj4+Pj4+Pj4+PiBkZXNpZ25hdGlvbi4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBUaGF0wrlzIGdpdmVuLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFBl cmhhcHMgdGhlIGZpcnN0IHNlbnRlbmNlIGNvdWxkIGJlIHJld29yZGVkIGFzIHRoZSBmb2xsb3dp bmcgdG8NCj4+Pj4+Pj4+IGNhcHR1cmUNCj4+Pj4+Pj4+PiB0aGUgYWJvdmUgcG9pbnQ6DQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiAgICBXaGlsZSBkaWZmZXJlbnQgQUNzIChWTEFOcykgb24gdGhlIHNh bWUgRVMgY291bGQgaGF2ZQ0KPj4+Pj4+Pj4+ZGlmZmVyZW50DQo+Pj4+Pj4+Pj4gICAgcm9vdC9s ZWFmIGRlc2lnbmF0aW9uIChzb21lIGJlaW5nIHJvb3RzIGFuZCBzb21lIGJlaW5nDQo+Pj4+Pj4+ Pj5sZWF2ZXMpLA0KPj4+Pj4+Pj4+ICAgIHRoZSBzYW1lIFZMQU4gZG9lcyBoYXZlIHRoZSBzYW1l IHJvb3QvbGVhZiBkZXNpZ25hdGlvbiBvbiBhbGwNCj4+Pj4+Pj4+PiAgICBQRXMgb24gdGhlIHNh bWUgRVMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhhdMK5cyBmaW5lLiBJdCBtYWtlcyBpdCBtb3Jl IGNsZWFyLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZvciB0aGUgZm9sbG93aW5n Og0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgLi4uIHRoZSBQRXMgd2l0aCBMZWFmIHNpdGVzIHBl cmZvcm0gTUFDIGxlYXJuaW5nIGluIHRoZQ0KPj4+Pj4+Pj4+ICAgIGRhdGEtcGF0aCBvdmVyIHRo ZWlyIEV0aGVybmV0IFNlZ21lbnRzLCBhbmQgYWR2ZXJ0aXNlDQo+Pj4+Pj4+Pj4gcmVhY2hhYmls aXR5DQo+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4+ICAgIEVWUE4gTUFDIEFkdmVydGlzZW1lbnQgcm91 dGVzIHdoaWNoIGFyZSBpbXBvcnRlZCBvbmx5IGJ5IFBFcw0KPj4+Pj4+Pj4+IHdpdGgNCj4+Pj4+ Pj4+PiBhdA0KPj4+Pj4+Pj4+ICAgIGxlYXN0IG9uZSBSb290IHNpdGUgaW4gdGhlIEVWSS4gQSBQ RSB3aXRoIG9ubHkgTGVhZiBzaXRlcyB3aWxsDQo+Pj4+Pj4+Pj4gbm90DQo+Pj4+Pj4+Pj4gICAg aW1wb3J0IHRoZXNlIHJvdXRlcy4gUEVzIHdpdGggUm9vdCBhbmQvb3IgTGVhZiBzaXRlcyBtYXkg dXNlDQo+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+PiAgICBFdGhlcm5ldCBBLUQgcm91dGVzIGZvciBh bGlhc2luZyAoaW4gdGhlIGNhc2Ugb2YgbXVsdGktaG9tZWQNCj4+Pj4+Pj4+PiAgICBzZWdtZW50 cykgYW5kIGZvciBtYXNzIE1BQyB3aXRoZHJhd2FsIHBlciBbUkZDIDc0MzJdLg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4gVGhlIGFib3ZlIHNlZW1zIHRvIGNvbnRyYWRpY3Qgd2l0aCB0aGUgcmVjb21t ZW5kYXRpb24gaW4gU2VjdGlvbg0KPj4+Pj4+Pj4+IDIuMi4NCj4+Pj4+Pj4+IElmDQo+Pj4+Pj4+ Pj4gdGhlIGNvbnRleHQgaXMgdGhlIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIuMSB0 aGVuIHRoYXQncw0KPj4+Pj4+Pj4+IGZpbmUsDQo+Pj4+Pj4+Pj4gYnV0IHRoZSB0ZXh0IGRvZXMg bm90IGhhdmUgYSBjbGVhciBjb250ZXh0Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFncmVlZC4gVXBk YXRlZCB0aGUgc2VjdGlvbiB0byBpbmRpY2F0ZSB0aGUgY29udGV4dCBpcyBzZWN0aW9uDQo+Pj4+ Pj4+PjIuMS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IDMuMy4y IEUtVHJlZSB3aXRob3V0IE1BQyBMZWFybmluZw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICAgVGhl IFBFcyBpbXBsZW1lbnRpbmcgYW4gRS1UcmVlIHNlcnZpY2UgbmVlZCBub3QgcGVyZm9ybSBNQUMN Cj4+Pj4+Pj4+PiBsZWFybmluZw0KPj4+Pj4+Pj4+ICAgIHdoZW4gdGhlIHRyYWZmaWMgZmxvd3Mg YmV0d2VlbiBSb290IGFuZCBMZWFmIHNpdGVzIGFyZQ0KPj4+Pj4+Pj4+bXVsdGljYXN0DQo+Pj4+ Pj4+Pj4gb3INCj4+Pj4+Pj4+PiAgICBicm9hZGNhc3QuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJ IHN1cHBvc2UgYW4gIm9ubHkiIHdvcmQgc2hvdWxkIGJlIGFkZGVkIGF0IHRoZSBlbmQgb2YgdGhl IGFib3ZlDQo+Pj4+Pj4+PiBzZW50ZW5jZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBZ3JlZWQuDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICBUaGUgZmllbGRzIG9m IHRoZSBJTUVUIHJvdXRlIGFyZSBwb3B1bGF0ZWQgcGVyIHRoZSBwcm9jZWR1cmVzDQo+Pj4+Pj4+ PiBkZWZpbmVkDQo+Pj4+Pj4+Pj4gICAgaW4gW1JGQzc0MzJdLCBhbmQgdGhlIHJvdXRlIGltcG9y dCBydWxlcyBhcmUgYXMgZGVzY3JpYmVkIGluDQo+Pj4+Pj4+PiBwcmV2aW91cw0KPj4+Pj4+Pj4+ ICAgIHNlY3Rpb25zLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIHJvdXRlIGltcG9ydCBydWxl cyBkZXNjcmliZWQgaW4gcHJldmlvdXMgc2VjdGlvbnMgYXJlIGZvciBNQUMNCj4+Pj4+Pj4+IHJv dXRlcywNCj4+Pj4+Pj4+PiBub3QgSU1FVCByb3V0ZXMuIEFkZGl0aW9uYWxseSwgdGhvc2UgcnVs ZXMgbWF5IG5vdCBiZQ0KPj4+Pj4+Pj4+cmVjb21tZW5kZWQsDQo+Pj4+Pj4+Pj4gc28NCj4+Pj4+ Pj4+PiBtaWdodCBhcyB3ZWxsIGRlbGV0ZSB0aGUgbGFzdCBzZW50ZW5jZS4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBDaGFuZ2VkIHRoZSBsYXN0IHNlbnRlbmNlIHRvIMKzxaAsIGFuZCB0aGUgbXVsdGlj YXN0IHR1bm5lbCBzZXR1cA0KPj4+Pj4+Pj4gY3JpdGVyaWENCj4+Pj4+Pj4+IGFyZSBhcyBkZXNj cmliZWQgaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24uwrINCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBTZWN0aW9uIDMuMy4xIHRhbGtzIGFib3V0IEJVTSBwcm9jZWR1cmVzLiBUaGF0IGlz IG5vdCBzcGVjaWZpYyB0bw0KPj4+Pj4+Pj4+IDMuMy4xDQo+Pj4+Pj4+Pj4gdGhvdWdoLiBQZXJo YXBzIGV4dHJhY3QgdGhhdCBvdXQgdG8gYSBzZXBhcmF0ZSBzZWN0aW9uLCBhbmQNCj4+Pj4+Pj4+ PnJlbW92ZQ0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+IEJVTSB0ZXh0IGZyb20gMy4zLjIgYXMg d2VsbC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIHRoaW5rIGl0IGlzIE9LLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgIFRoZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5IGlzIGVu Y29kZWQgYXMgYW4gOC1vY3RldCB2YWx1ZQ0KPj4+Pj4+Pj4+YXMNCj4+Pj4+Pj4+PiAgICBmb2xs b3dzOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyDQo+Pj4+Pj4+Pj4gMw0KPj4+Pj4+Pj4+ICAg ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNw0KPj4+Pj4+Pj4+OCA5DQo+Pj4+Pj4+Pj4gMCAxDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+Pj4+Pj4+Pj4gICAgICAgIHwgVHlwZT0weDA2ICAgICB8IFN1Yi1UeXBlPTB4MDQg fCBGbGFncygxIE9jdGV0KXwNCj4+Pj4+Pj4+IHwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4+Pj4+Pj4+PiAgICAgICAgfCAgUmVzZXJ2ZWQ9MCAgIHwgICAgICAgICAgIExlYWYgTGFi ZWwNCj4+Pj4+Pj4+IHwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IEkgYXNzdW1lIHRoZSBvY3RlY3QgYWZ0ZXIgdGhlIGZsYWdzIG9jdGV0IGlzIGFs c28gcmVzZXJ2ZWQ9MC4NCj4+Pj4+Pj4+PiBCZXR0ZXINCj4+Pj4+Pj4+IG1hcmsNCj4+Pj4+Pj4+ PiBpdCBhcyAiUmVzZXJ2ZWQ9MCIuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQWdyZWVkLg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFdoZW4gaXQgaXMgdXNlZCB3aXRoIEV0aGVybmV0IEEt RCBwZXIgRVMgcm91dGUsIHRoZSBsZWFmIGZsYWcNCj4+Pj4+Pj4+PiBTSE9VTEQNCj4+Pj4+Pj4+ PiBiZQ0KPj4+Pj4+Pj4+IHNldCB0byAwIGJ1dCBpZ25vcmVkIGJ5IHRoZSByZWNlaXZpbmcgcm91 dGVycy4gVGhlcmVmb3JlLCB3aHkgbm90DQo+Pj4+Pj4+Pj4gc2V0DQo+Pj4+Pj4+PiBpdA0KPj4+ Pj4+Pj4+IHRvIDEgdG8gYmUgY29uc2lzdGVudCB0aGUgTUFDL0lQIHJvdXRlIGNhc2U/DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gQmVjYXVzZSB0aGUgZmxhZyBpcyB1c2VkIGZvciBrbm93biB1bmljYXN0 IHRyYWZmaWMgYW5kIExlYWYgbGFiZWwNCj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4gQlVNDQo+Pj4+ Pj4+PiB0cmFmZmljLiBXZSBkb27CuXQgd2FudCB0byBtaXggdGhlIHR3by4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+PiBBbGkNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBUaGFua3MuDQo+Pj4+Pj4+Pj4gSmVmZnJleQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+IEZyb206IEJFU1MgW21haWx0bzpi ZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMNCj4+Pj4+Pj4+Pj4gTW9y aW4NCj4+Pj4+Pj4+Pj4gU2VudDogVHVlc2RheSwgSmFudWFyeSAxOSwgMjAxNiAzOjUxIEFNDQo+ Pj4+Pj4+Pj4+IFRvOiBCRVNTIDxiZXNzQGlldGYub3JnPjsNCj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0 Zi1iZXNzLWV2cG4tZXRyZWVAdG9vbHMuaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gU3ViamVjdDogW2Jl c3NdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBIZWxsbyBXb3JraW5nIEdyb3VwLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+Pj4+Pj4+ Pj4+IGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlIFsxXSB3aGljaCBpcyBjb25zaWRlcmVkIG1h dHVyZSBhbmQNCj4+Pj4+Pj4+Pj4gcmVhZHkNCj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4+PiBhIGZp bmFsIHdvcmtpbmcgZ3JvdXAgcmV2aWV3Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBQbGVhc2Ug cmVhZCB0aGUgZG9jdW1lbnQgaWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQNCj4+ Pj4+Pj4+Pj4gdmVyc2lvbg0KPj4+Pj4+Pj4geWV0DQo+Pj4+Pj4+Pj4+ICgtMDMpLCBhbmQgc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuDQo+Pj4+Pj4+Pj4+KkZl YnJ1YXJ5DQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4gMm5kKiAoMjAxNi0wMi0wMikuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRoaXMgaXMgbm90IG9ubHkgYSBjYWxsIGZvciBjb21tZW50cyBv biB0aGUgZG9jdW1lbnQsIGJ1dCBhbHNvIGENCj4+Pj4+Pj4+Pj4gY2FsbA0KPj4+Pj4+Pj4gb2YN Cj4+Pj4+Pj4+Pj4gc3VwcG9ydCBmb3IgaXRzIHB1YmxpY2F0aW9uLg0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+PiAqQ29pbmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVk Z2Ugb2YgYW55IElQUg0KPj4+Pj4+Pj4+PiB0aGF0DQo+Pj4+Pj4+Pj4+IGFwcGxpZXMgdG8gZHJh ZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMNCj4+Pj4+Pj4+ Pj5iZWVuDQo+Pj4+Pj4+Pj4+IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXMgKHNlZSBSRkNzIDM5NzksDQo+Pj4+Pj4+Pj4+NDg3OSwNCj4+Pj4+Pj4+IDM2NjkNCj4+ Pj4+Pj4+Pj4gYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+ICpJZiogeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0 b3Igb2YNCj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUgcGxlYXNlIHJlc3Bv bmQgdG8gdGhpcyBlbWFpbCBhbmQNCj4+Pj4+Pj4+Pj4gaW5kaWNhdGUNCj4+Pj4+Pj4+Pj4gd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+PiBUaGFuayB5b3UsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRob21hcy9N YXJ0aW4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlDQo+Pj4+Pj4+Pj4+DQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5CRVNTIG1haWxp bmcgbGlzdA0KPkJFU1NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Jlc3MNCg0K From nobody Wed Jun 8 18:40:41 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 1348412D8ED; Wed, 8 Jun 2016 18:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.628 X-Spam-Level: X-Spam-Status: No, score=-105.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqfn59e1ef_s; Wed, 8 Jun 2016 18:40:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2AC12D8F2; Wed, 8 Jun 2016 18:40:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9EB63B80B28; Wed, 8 Jun 2016 18:40:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160609014010.9EB63B80B28@rfc-editor.org> Date: Wed, 8 Jun 2016 18:40:10 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7902 on Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags 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, 09 Jun 2016 01:40:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7902 Title: Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags Author: E. Rosen, T. Morin Status: Standards Track Stream: IETF Date: June 2016 Mailbox: erosen@juniper.net, thomas.morin@orange.com Pages: 7 Characters: 14332 Updates: RFC 6514 I-D Tag: draft-ietf-bess-pta-flags-03.txt URL: https://www.rfc-editor.org/info/rfc7902 DOI: http://dx.doi.org/10.17487/RFC7902 The BGP-based control procedures for Multicast Virtual Private Networks (MVPNs) make use of a BGP attribute known as the "P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI) Tunnel" attribute. This document updates RFC 6514. This document is a product of the BGP Enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 9 07:33: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 6CF6712D66E for ; Thu, 9 Jun 2016 07:33:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hmbhG8Ef-u8h for ; Thu, 9 Jun 2016 07:33:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7EA12B018 for ; Thu, 9 Jun 2016 07:33:48 -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=E/5xYl7n1zlGjMC5wMzioaw8A6St+eYHxASQEJKnUOs=; b=jFB5CDLVNlfklsek5vLYCHDqdeho56tnm9205EgZGod8Gr5q0o3jGNliqKOKW6tZaoxi0m+TgwI9s+C90D/FVrusJxmfI65IdCA7YGwCEBXj5QtqRiAiLZ+KYyh5OI8b/dVW4fEiaqXzUpXJot4wltPWkOIoNSDkwgJIacOHJxk= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.517.8; Thu, 9 Jun 2016 14:33:21 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0511.010; Thu, 9 Jun 2016 14:33:19 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , BESS Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaME/U9KT8MU0ut9l7k3idEc58OWnfAgAhLYwCAAYwoAIBC0CQAgBXcMACARGjgAIAS+kOAgBUQT4CAAuWvAIABzO2A Date: Thu, 9 Jun 2016 14:33:19 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> In-Reply-To: <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-originating-ip: [66.129.241.13] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 2a431751-b2b3-4976-acb0-08d390730076 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 6:tqAK2qUrUjuoDLzbzVaPtgeivCwW86VTpefWK9n3CaIQu30eberXf0C+XDgAsKQzFoXpEsYpyaOuUTrpioMgju8iUqSDjfxsC6iLMTXwBV0zemu7kalKh+EPYxAQsMt9l4OBtZb1kYwzvr/RdgvszjBk9+GuHCAU6bwSvMNBO0LEl1aq+hy4HXVTo1D04/9tVopzlyp9FNT60S7noRnOlmMQacuLRGf49mNFenGZjxyvmcJD/pJF78jyhlfAF/wxBipwlSWRS2XvT8g2DN+wdeYumQfOmusoLStmzRMQmgE4N/j26nS9isgyGniQ/AJ8WfcYVDt4WVH8nABcNZOIMw==; 5:3IhUsO3hQH2rt5kE+8of5/31u4sJv0wWpZ77cBxMbTo3nzPQYnMR5LjqiG4eJOKzkVKrxH0THW2I4u6TwwOFGEnuMWGt+Z86a2g+tur+wNwrIyROcuPPFImgVSGBiXI/gMky2nXTRblhhd+5OS974w==; 24:jI+zvpAwuFSRh3jwRhL0rKLoTjkpJyejxzIzenlSqw8dSQ5ghOLR8Ha7eq5iPiV+723EeoK7t3kzjEcBNwW614peSWqzh2hvUv21FoxT478=; 7:Ea12dq/+6gdohXvowX2CECwtX3F8xssItihNmrQ52JkW+ao7N7N1YwmphJZZdipynVHTTipP81ULDYfsD/eTOlEowIVs6JVhA/Ncx1ILhQlZiYtdj2O3gtEDwReA3xexRsRbZuby0YBvwTIz65mhtOF4rQtRVIBsLIuxJlSQqtyDut16xi1zKXHstZNOA45ewnD1ivw3LMREWGwvfSBe+yXCZpUpjzrPcLehU/Ei9Uk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(100405760836317)(95692535739014)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51874003)(189002)(51914003)(24454002)(377454003)(53754006)(377424004)(199003)(106116001)(74316001)(122556002)(76176999)(54356999)(50986999)(68736007)(19580405001)(5002640100001)(10400500002)(77096005)(92566002)(106356001)(8936002)(2906002)(5001770100001)(19580395003)(101416001)(107886002)(33656002)(4326007)(5008740100001)(4001430100002)(99286002)(105586002)(97736004)(230783001)(9686002)(5003600100002)(15975445007)(93886004)(3280700002)(189998001)(8676002)(3660700001)(87936001)(81156014)(81166006)(2950100001)(3846002)(6116002)(2900100001)(76576001)(102836003)(586003)(66066001)(86362001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 14:33:19.1538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710 Archived-At: Cc: Disha Chopra , Wen Lin Subject: Re: [bess] WG Last Call on 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, 09 Jun 2016 14:33:51 -0000 VGhvbWFzLA0KDQpFLVRSRUUgZm9yIEVWUE4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZS0wNSkgd2lsbCBiZSBHQSB0aGlzIHllYXIuICBSb290 IG9yIGxlYWYgcm9sZSBjYW4gYmUgZGVmaW5lZCBvbiBhIHBvcnQgb3IgVkxBTiBiYXNpcywgYW5k IFNpbmdsZS1BY3RpdmUgYW5kIEFsbC1BY3RpdmUgbXVsdGktaG9taW5nIGFyZSBzdXBwb3J0ZWQu ICBFLVRSRUUgZm9yIFBCQi1FVlBOIGlzIG9uIHRoZSByb2FkbWFwLg0KDQpZb3VycyBJcnJlc3Bl Y3RpdmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMg TW9yaW4NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDA4LCAyMDE2IDY6MTMgQU0NCj4gVG86IEFs aSBTYWphc3NpIChzYWphc3NpKTsgSmVmZnJleSAoWmhhb2h1aSkgWmhhbmc7IEJFU1M7IGRyYWZ0 LWlldGYtYmVzcy1ldnBuLQ0KPiBldHJlZUB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W2Jlc3NdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0KPiANCj4g SGkgQWxpLA0KPiANCj4gSSBoYXZlbid0IHN0YXJ0ZWQgeWV0IHRoZSBzaGVwaGVyZCB3cml0ZS11 cCwgYnV0IGl0J3Mgb24gbXkgdG9kbyBsaXN0Lg0KPiANCj4gSSB3aWxsIGRvIGEgc2hlcGhlcmQg cmV2aWV3IGFsb25nIHdpdGggdGhlIHdyaXRlLXVwLCB3aGljaCBtYXkgbGVhZCB0byByZXNvbHZp bmcgcG9pbnRzIHdpdGgNCj4gYXV0aG9ycywgYnV0IEkgY2FuJ3QgdGVsbCBiZWZvcmUgSSBnZXQg dG8gZG8gaXQuDQo+IA0KPiBPbmUgdGhpbmcgdGhhdCBjYW4gYmUgdXNlZnVsIHRvIGNvbGxlY3Qg cmlnaHQgbm93IGlzIGFueSBpbmZvcm1hdGlvbiB5b3UgbWF5IGhhdmUgb24NCj4gZXhpc3Rpbmcg aW1wbGVtZW50YXRpb25zIChhbHRob3VnaCB0aGlzIGRyYWZ0IHdhcyBXR0xDJ2QgYmVmb3JlIHdl IHNldHVwIEJFU1Mgb25lLQ0KPiBpbXBsZW1lbnRhdGlvbiBwb2xpY3ksIHRoaXMgcXVlc3Rpb24g aGFzIGJlZW4gcGFydCBvZiBzaGVwaGVyZCB3cml0ZS11cCBxdWVzdGlvbiwgZXZlbiBpZg0KPiBp dHMgbm90IGNvbnNpZGVyZWQgYSBnYXRpbmcgY3JpdGVyaWEpLg0KPiANCj4gVGhhbmtzIGluIGFk dmFuY2UsDQo+IA0KPiAtVGhvbWFzDQo+IA0KPiANCj4gMjAxNi0wNi0wNiwgQWxpIFNhamFzc2kg KHNhamFzc2kpOg0KPiA+DQo+ID4gSXMgdGhlcmUgYW55dGhpbmcgZWxzZSB5b3UgbmVlZCBmcm9t IG1lIG9yIG90aGVyIGNvLWF1dGhvcnMgdG8NCj4gPiBwcm9ncmVzcyB0aGlzIGRhZnQ/IFRoZSBX RyBMQyB3YXMgY29tcGxldGVkIGJlZm9yZSBsYXN0IElFVEYuDQo+ID4NCj4gPiBSZWdhcmRzLA0K PiA+IEFsaQ0KPiA+DQo+ID4gT24gNS8yNC8xNiwgMTI6MTggQU0sICJBbGkgU2FqYXNzaSAoc2Fq YXNzaSkiIDxzYWphc3NpQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4gPj4NCj4gPj4gSGkgVGhv bWFzLA0KPiA+Pg0KPiA+PiBDYW4geW91IHBsZWFzZSBwcm9ncmVzcyB0aGlzIGRyYWZ0LiBUaGUg V0cgTEMgd2FzIGNvbXBsZXRlZCBvbiAzLzI5DQo+ID4+IGFuZCBhbGwgY29tbWVudHMgZXhjZXB0 IGEgc2luZ2xlIG9wdGlvbmFsIGNvbW1lbnQgd2VyZSBhZGRyZXNzZWQNCj4gPj4gYmVmb3JlIHRo ZSBsYXN0IElFVEYuIFRoZSBzaW5nbGUgb3B0aW9uYWwgY29tbWVudCB3YXMgYWRkcmVzc2VkDQo+ ID4+IGNvdXBsZSBvZiB3ZWVrcyBhZ28gYW5kIHRoZSBkcmFmdCB3YXMgcmUtcHVibGlzaGVkIHRo ZW4uDQo+ID4+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+IEFsaQ0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiA1 LzExLzE2LCAxMDozMCBQTSwgIkJFU1Mgb24gYmVoYWxmIG9mIEFsaSBTYWphc3NpIChzYWphc3Np KSINCj4gPj4gPGJlc3MtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygc2FqYXNzaUBjaXNj by5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEhpIFRob21hcywNCj4gPj4+DQo+ID4+ PiBJIGp1c3QgbWFkZSB0aGUgZmluYWwgZWRpdHMgdG8gZXZwbi1ldHJlZSBkcmFmdCBhbmQgcHVi bGlzaGVkIGl0IGFzDQo+ID4+PiByZXYwNS4NCj4gPj4+DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4g QWxpDQo+ID4+Pg0KPiA+Pj4gT24gMy8yOS8xNiwgMjo0OSBBTSwgInRob21hcy5tb3JpbkBvcmFu Z2UuY29tIg0KPiA+Pj4gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPg0KPiA+Pj4gd3JvdGU6DQo+ ID4+Pg0KPiA+Pj4+IEhpIGV2ZXJ5b25lLA0KPiA+Pj4+DQo+ID4+Pj4gVGhpcyBXRyBMYXN0IENh bGwgaXMgbm93IGNsb3NlZCBhbmQgdGhlIGRvY3VtZW50IHdpbGwgbW92ZSB0byB0aGUNCj4gPj4+ PiBuZXh0IHN0ZXBzIHRvd2FyZCBwdWJsaWNhdGlvbi4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSBtb2Rp ZmljYXRpb24gbWVudGlvbmVkIGJlbG93IHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGluIG5leHQgcmVs ZWFzZS4NCj4gPj4+Pg0KPiA+Pj4+IEJlc3QsDQo+ID4+Pj4NCj4gPj4+PiAtVGhvbWFzDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gMjAxNi0wMy0xNSwgQWxpIFNhamFzc2kgKHNhamFz c2kpOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBKZWZmcmV5LA0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBPbiAyLzEvMTYsIDI6NDEgUE0sICJKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyIg PHp6aGFuZ0BqdW5pcGVyLm5ldD4NCj4gPj4+Pj4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+PiBB bGksDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT25lIG1vcmUgcXVlc3Rpb24gYWJvdXQgUEJCLUVWUE4u DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gRm9yIHRoZSByZWd1bGFyIEVWUE4sIHNlY3Rpb24gMy4zLjIg dGFsa3MgYWJvdXQgYSBzaXR1YXRpb24gd2hlcmUNCj4gPj4+Pj4+IHRoZSBvbmx5IHRyYWZmaWMg aXMgQlVNLiBUaGVyZSBpcyBubyBuZWVkIGZvciBtYWMgbGVhcm5pbmcgaW4NCj4gPj4+Pj4+IHRo YXQgc2l0dWF0aW9uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEZvciBQQkItRVZQTiwgSSBhc3N1bWUg dGhpcyBpcyBhbHNvIHBvc3NpYmxlLiBXaXRoIHRoaXMsIHRoZXJlIGlzDQo+ID4+Pj4+PiBubyBu ZWVkIHRvIGFkdmVydGlzZSBwZXItRVMgQi1tYWMgYWRkcmVzc2VzIC0gYSBzaW5nbGUgcGFpciBv Zg0KPiA+Pj4+Pj4gZ2xvYmFsIHJvb3QvbGVhZiBCLW1hYyBhZGRyZXNzZXMgYXJlIGVub3VnaC4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBQZXJoYXBzIHRoaXMgY2FuIGJlIG1lbnRpb25lZCBmb3IgcGFy aXR5L2NvbXBsZXRlbmVzcy4gT2YgY291cnNlLA0KPiA+Pj4+Pj4gdGhpcyBpcyBub3QgYSBiaWcg ZGVhbCBhbmQgZWl0aGVyIHdheSBpdCdzIGZpbmUgLSBidXQgSSBkbyB3YW50DQo+ID4+Pj4+PiB0 byBhc2sgdG8gY29uZmlybSBteSB1bmRlcnN0YW5kaW5nLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBXZeKA mWxsIGRvLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+IEFsaQ0KPiA+Pj4+Pg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+IEplZmZyZXkNCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+PiBGcm9tOiBBbGkgU2FqYXNzaSAoc2FqYXNzaSkg W21haWx0bzpzYWphc3NpQGNpc2NvLmNvbV0NCj4gPj4+Pj4+PiBTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDAxLCAyMDE2IDI6MDQgQU0NCj4gPj4+Pj4+PiBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhh bmcgPHp6aGFuZ0BqdW5pcGVyLm5ldD47IEVYVCAtDQo+ID4+Pj4+Pj4gdGhvbWFzLm1vcmluQG9y YW5nZS5jb20gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsgQkVTUw0KPiA+Pj4+Pj4+IDxiZXNz QGlldGYub3JnPjsgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWVAdG9vbHMuaWV0Zi5vcmcNCj4g Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW2Jlc3NdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWJl c3MtZXZwbi1ldHJlZQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSGkgSmVmZnJleSwNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gWW91ciBjb21tZW50cyBoZWxwcyB0 aWdodGVuIHRoZSBkcmFmdA0KPiA+Pj4+Pj4+IHNvbWUgbW9yZS4NCj4gPj4+Pj4+PiBJDQo+ID4+ Pj4+Pj4gaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCBhbmQgd2lsbCBwdWJsaXNoIGl0IG5leHQgKHJl djA0KS4NCj4gPj4+Pj4+PiBNYWpvcml0eSBvZiB0aGUgY29tbWVudHMgd2VyZSBlZGl0b3JpYWwg aW4gbmF0dXJlIGZvciBiZXR0ZXINCj4gPj4+Pj4+PiBjbGFyaWZpY2F0aW9ucy4gU2luY2UgdGhl IGV4aXN0aW5nIGRyYWZ0IChyZXYwMykgcmVmbGVjdHMgdGhlDQo+ID4+Pj4+Pj4gY29uc2Vuc3Vz IHJlZ2FyZGluZyBvdXIgc2V2ZXJhbCByb3VuZHMgb2YgZGlzY3Vzc2lvbnMgd2hlcmUgd2UNCj4g Pj4+Pj4+PiBoYXZlIHRha2VuIGNhcmUgb2YgdGhlIHRlY2huaWNhbCBpdGVtcywgaXQgaXMgY29u c2lzdGVudCB3aXRoDQo+ID4+Pj4+Pj4gb3VyIGV4cGVjdGF0aW9uIG9mIG5vdCBzZWVpbmcgYW55 IG1ham9yIGlzc3VlIGR1cmluZyB0aGUgTEMuDQo+ID4+Pj4+Pj4gUGxlYXNlIHJlZmVyIHRvIG15 IHJlcGxpZXMgaW4gbGluZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IENoZWVycywNCj4gPj4+Pj4+ PiBBbGkNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMS8yNy8xNiwgNToyNiBQ TSwgIkJFU1Mgb24gYmVoYWxmIG9mIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIg0KPiA+Pj4+Pj4+ IDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHp6aGFuZ0BqdW5pcGVyLm5ldD4g d3JvdGU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSSB3YXMgaW52b2x2ZWQgaW4gcmVsZXZhbnQg ZGlzY3Vzc2lvbnMsIGFuZCBoYXZlIHJldmlld2VkIG9uY2UNCj4gPj4+Pj4+Pj4gbW9yZSBmb3Ig dGhpcyBMQy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSSBzdXBwb3J0IHRoZSBwdWJsaWNhdGlv biwgYnV0IHdpdGggdGhlIGZvbGxvd2luZw0KPiA+Pj4+Pj4+PiBxdWVzdGlvbnMvY29tbWVudHMu DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IDIuMSBTY2VuYXJpbyAxOiBMZWFmIE9SIFJvb3Qgc2l0 ZShzKSBwZXIgUEUNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gICAgLi4uIElmIHRoZSBudW1iZXIg b2YgRVZJcyBpcyB2ZXJ5IGxhcmdlDQo+ID4+Pj4+Pj4+ICAgIChlLmcuLCBtb3JlIHRoYW4gMzJL IG9yIDY0SyksIHRoZW4gUlQgdHlwZSAwIGFzIGRlZmluZWQgaW4NCj4gPj4+Pj4+Pj4gW1JGQzQz NjBdDQo+ID4+Pj4+Pj4+ICAgIFNIT1VMRCBiZSB1c2VkOyBvdGhlcndpc2UsIFJUIHR5cGUgMiBp cyBzdWZmaWNpZW50Lg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBSRkMgNzE1MyBzaG91bGQgYmUg cmVmZXJlbmNlZCBmb3IgIlR5cGUgMiIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ IERvbmUuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gQWRkaXRpb25hbGx5LCB3 aHkgaXMgMzJLIG1lbnRpb25lZD8gSSBjYW4gdW5kZXJzdGFuZCB0aGUgNjRrIHBhcnQuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+PiBSZW1vdmVkIDMySyBzaW5jZSB0aGUgZXhhbXBsZSBpcyBjbGVhciBl bm91Z2ggd2l0aCA2NEsNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAgICAuLi4g dGhlIE1QTFMtZW5jYXBzdWxhdGVkIGZyYW1lcyBNVVNUIGJlIHRhZ2dlZCB3aXRoIGFuDQo+ID4+ Pj4+Pj4+ICAgIGluZGljYXRpb24gb2Ygd2hldGhlciB0aGV5IG9yaWdpbmF0ZWQgZnJvbSBhIExl YWYgQUMgb3Igbm90Lg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBQZXJoYXBzIGNoYW5nZSB0aGUg bGFzdCBsaW5lIHRvICJpbmRpY2F0aW9uIGlmIHRoZXkgb3JpZ2luYXRlZA0KPiA+Pj4+Pj4+PiBm cm9tIGEgTGVhZiBBQyI/IFBhY2tldHMgZnJvbSBhIHJvb3QgQUMgYXJlIG5vdCB0YWdnZWQgd2l0 aCBhDQo+ID4+Pj4+Pj4+IGxlYWYgaW5kaWNhdGlvbi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE9L LiBCZXR0ZXIgeWV0LiBJdCBzaG91bGQgc2F5IMKzaW5kaWNhdGlvbiB3aGVuIHRoZXkgb3JpZ2lu YXRlZA0KPiA+Pj4+Pj4+IGZyb20gYSBsZWFmIEFDwrIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4gICAgT3RoZXIgbWVjaGFuaXNtcyBmb3IgaWRlbnRpZnlpbmcgd2hldGhlciBh biBlZ3Jlc3MgQUMgaXMgYQ0KPiA+Pj4+Pj4+PiByb290IG9yDQo+ID4+Pj4+Pj4+ICAgIGxlYWYg aXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+PiBTaG91bGQgImVncmVzcyIgYmUgImluZ3Jlc3MiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGg/ IE9yIHNpbXBseQ0KPiA+Pj4+Pj4+PiByZW1vdmVkPw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gTmlj ZSBjYXRjaCEgSXQgaXMgwrNpbmdyZXNzwrIuIEl0IGlzIG5vdyBjb3JyZWN0ZWQuDQo+ID4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gICAgLi4uIFRoaXMgTGVhZiBNUExTIGxhYmVsIGlz IGFkdmVydGlzZWQgdG8gb3RoZXIgUEUgZGV2aWNlcywNCj4gPj4+Pj4+Pj4gICAgdXNpbmcgYSBu ZXcgRVZQTiBFeHRlbmRlZCBDb21tdW5pdHkgY2FsbGVkIEUtVFJFRSBFeHRlbmRlZA0KPiA+Pj4+ Pj4+PiBDb21tdW5pdHkNCj4gPj4+Pj4+Pj4gICAgKHNlY3Rpb24gNS4xKSBhbG9uZyB3aXRoIGFu IEV0aGVybmV0IEEtRCBwZXIgRVMgcm91dGUgd2l0aA0KPiA+Pj4+Pj4+PiBFU0kgb2YNCj4gPj4+ Pj4+Pj4gICAgemVybyBhbmQgYSBzZXQgb2YgUm91dGUgVGFyZ2V0cyAoUlRzKSBjb3JyZXNwb25k aW5nIHRvIGFsbA0KPiA+Pj4+Pj4+PiB0aGUgbGVhZg0KPiA+Pj4+Pj4+PiAgICBBQ3Mgb24gdGhl IFBFLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBQZXJoYXBzIGNoYW5nZSB0aGUgbGFzdCBzZW50 ZW5jZSB0byAiLi4uIGNvcnJlc3BvbmRpbmcgdG8gYWxsDQo+ID4+Pj4+Pj4+IEVWSXMgdGhhdCBo YXZlIGxlYWYgc2l0ZXMgb24gdGhlIFBFLiINCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFRoZSBzZWNv bmQgdG8gbGFzdCBzZW50ZW5jZSBvZiBzZWN0aW9uIDMuMi4xIHNheXMgdGhlIHNhbWUNCj4gPj4+ Pj4+PiB0aGluZy4gSSBjaGFuZ2VkIHRoaXMgc2VudGVuY2UgYW5kIHJlbW92ZWQgdGhlIDJuZCB0 byBsYXN0IHNlbnRlbmNlLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IDMuMi4z IEJVTSB0cmFmZmljIG9yaWdpbmF0ZWQgZnJvbSBhIG11bHRpLWhvbWVkIHNpdGUgb24gYSBsZWFm DQo+ID4+Pj4+Pj4+IEFDDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAgIEluIHRoaXMgc2NlbmFy aW8sIGl0IGlzIGFzc3VtZWQgdGhhdCBhIG11bHRpLWhvbWVkIEV0aGVybmV0DQo+ID4+Pj4+Pj4+ IFNlZ21lbnQNCj4gPj4+Pj4+Pj4gICAgKEVTKSBjYW4gaGF2ZSBhIG1peGVkIG9mIGJvdGggbGVh ZiBhbmQgcm9vdCBBQ3Mgd2l0aCBlYWNoIEFDDQo+ID4+Pj4+Pj4+ICAgIGRlc2lnbmF0aW5nIGEg c3VibmV0IChlLmcuLCBhIFZMQU4pLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBJIHVuZGVyc3Rh bmQgdGhhdCBkaWZmZXJlbnQgVkxBTnMgb24gdGhlIHNhbWUgRVMgY291bGQgYmUgcm9vdHMNCj4g Pj4+Pj4+Pj4gb3IgbGVhdmVzLiBJIHN1cHBvc2UgaXQncyBtb3JlIGltcG9ydGFudCB0byBzYXkg dGhhdCBmb3IgdGhlDQo+ID4+Pj4+Pj4+IHNhbWUgdmxhbiwgZGlmZmVyZW50IFBFcyBvbiB0aGUg c2FtZSBFUyBtdXN0IGhhdmUgdGhlIHNhbWUNCj4gPj4+Pj4+Pj4gcm9vdC9sZWFmIGRlc2lnbmF0 aW9uLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhhdMK5cyBnaXZlbi4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBQZXJoYXBzIHRoZSBmaXJzdCBzZW50ZW5jZSBjb3VsZCBiZSBy ZXdvcmRlZCBhcyB0aGUgZm9sbG93aW5nDQo+ID4+Pj4+Pj4+IHRvDQo+ID4+Pj4+Pj4gY2FwdHVy ZQ0KPiA+Pj4+Pj4+PiB0aGUgYWJvdmUgcG9pbnQ6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAg IFdoaWxlIGRpZmZlcmVudCBBQ3MgKFZMQU5zKSBvbiB0aGUgc2FtZSBFUyBjb3VsZCBoYXZlIGRp ZmZlcmVudA0KPiA+Pj4+Pj4+PiAgICByb290L2xlYWYgZGVzaWduYXRpb24gKHNvbWUgYmVpbmcg cm9vdHMgYW5kIHNvbWUgYmVpbmcgbGVhdmVzKSwNCj4gPj4+Pj4+Pj4gICAgdGhlIHNhbWUgVkxB TiBkb2VzIGhhdmUgdGhlIHNhbWUgcm9vdC9sZWFmIGRlc2lnbmF0aW9uIG9uIGFsbA0KPiA+Pj4+ Pj4+PiAgICBQRXMgb24gdGhlIHNhbWUgRVMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGF0wrlz IGZpbmUuIEl0IG1ha2VzIGl0IG1vcmUgY2xlYXIuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4gRm9yIHRoZSBmb2xsb3dpbmc6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAgIC4u LiB0aGUgUEVzIHdpdGggTGVhZiBzaXRlcyBwZXJmb3JtIE1BQyBsZWFybmluZyBpbiB0aGUNCj4g Pj4+Pj4+Pj4gICAgZGF0YS1wYXRoIG92ZXIgdGhlaXIgRXRoZXJuZXQgU2VnbWVudHMsIGFuZCBh ZHZlcnRpc2UNCj4gPj4+Pj4+Pj4gcmVhY2hhYmlsaXR5DQo+ID4+Pj4+Pj4gaW4NCj4gPj4+Pj4+ Pj4gICAgRVZQTiBNQUMgQWR2ZXJ0aXNlbWVudCByb3V0ZXMgd2hpY2ggYXJlIGltcG9ydGVkIG9u bHkgYnkgUEVzDQo+ID4+Pj4+Pj4+IHdpdGggYXQNCj4gPj4+Pj4+Pj4gICAgbGVhc3Qgb25lIFJv b3Qgc2l0ZSBpbiB0aGUgRVZJLiBBIFBFIHdpdGggb25seSBMZWFmIHNpdGVzDQo+ID4+Pj4+Pj4+ IHdpbGwgbm90DQo+ID4+Pj4+Pj4+ICAgIGltcG9ydCB0aGVzZSByb3V0ZXMuIFBFcyB3aXRoIFJv b3QgYW5kL29yIExlYWYgc2l0ZXMgbWF5IHVzZSB0aGUNCj4gPj4+Pj4+Pj4gICAgRXRoZXJuZXQg QS1EIHJvdXRlcyBmb3IgYWxpYXNpbmcgKGluIHRoZSBjYXNlIG9mIG11bHRpLWhvbWVkDQo+ID4+ Pj4+Pj4+ICAgIHNlZ21lbnRzKSBhbmQgZm9yIG1hc3MgTUFDIHdpdGhkcmF3YWwgcGVyIFtSRkMg NzQzMl0uDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRoZSBhYm92ZSBzZWVtcyB0byBjb250cmFk aWN0IHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIGluDQo+ID4+Pj4+Pj4+IFNlY3Rpb24gMi4yLg0K PiA+Pj4+Pj4+IElmDQo+ID4+Pj4+Pj4+IHRoZSBjb250ZXh0IGlzIHRoZSBzY2VuYXJpbyBkZXNj cmliZWQgaW4gc2VjdGlvbiAyLjEgdGhlbg0KPiA+Pj4+Pj4+PiB0aGF0J3MgZmluZSwgYnV0IHRo ZSB0ZXh0IGRvZXMgbm90IGhhdmUgYSBjbGVhciBjb250ZXh0Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+ Pj4gQWdyZWVkLiBVcGRhdGVkIHRoZSBzZWN0aW9uIHRvIGluZGljYXRlIHRoZSBjb250ZXh0IGlz IHNlY3Rpb24gMi4xLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+IDMuMy4yIEUtVHJlZSB3aXRob3V0IE1BQyBMZWFybmluZw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+PiAgICBUaGUgUEVzIGltcGxlbWVudGluZyBhbiBFLVRyZWUgc2VydmljZSBuZWVkIG5vdCBw ZXJmb3JtIE1BQw0KPiA+Pj4+Pj4+PiBsZWFybmluZw0KPiA+Pj4+Pj4+PiAgICB3aGVuIHRoZSB0 cmFmZmljIGZsb3dzIGJldHdlZW4gUm9vdCBhbmQgTGVhZiBzaXRlcyBhcmUNCj4gPj4+Pj4+Pj4g bXVsdGljYXN0IG9yDQo+ID4+Pj4+Pj4+ICAgIGJyb2FkY2FzdC4NCj4gPj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4gSSBzdXBwb3NlIGFuICJvbmx5IiB3b3JkIHNob3VsZCBiZSBhZGRlZCBhdCB0aGUgZW5k IG9mIHRoZQ0KPiA+Pj4+Pj4+PiBhYm92ZQ0KPiA+Pj4+Pj4+IHNlbnRlbmNlLg0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4gQWdyZWVkLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+ICAgIFRoZSBmaWVsZHMgb2YgdGhlIElNRVQgcm91dGUgYXJlIHBvcHVsYXRlZCBw ZXIgdGhlDQo+ID4+Pj4+Pj4+IHByb2NlZHVyZXMNCj4gPj4+Pj4+PiBkZWZpbmVkDQo+ID4+Pj4+ Pj4+ICAgIGluIFtSRkM3NDMyXSwgYW5kIHRoZSByb3V0ZSBpbXBvcnQgcnVsZXMgYXJlIGFzIGRl c2NyaWJlZCBpbg0KPiA+Pj4+Pj4+IHByZXZpb3VzDQo+ID4+Pj4+Pj4+ICAgIHNlY3Rpb25zLg0K PiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGUgcm91dGUgaW1wb3J0IHJ1bGVzIGRlc2NyaWJlZCBp biBwcmV2aW91cyBzZWN0aW9ucyBhcmUgZm9yDQo+ID4+Pj4+Pj4+IE1BQw0KPiA+Pj4+Pj4+IHJv dXRlcywNCj4gPj4+Pj4+Pj4gbm90IElNRVQgcm91dGVzLiBBZGRpdGlvbmFsbHksIHRob3NlIHJ1 bGVzIG1heSBub3QgYmUNCj4gPj4+Pj4+Pj4gcmVjb21tZW5kZWQsIHNvIG1pZ2h0IGFzIHdlbGwg ZGVsZXRlIHRoZSBsYXN0IHNlbnRlbmNlLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQ2hhbmdlZCB0 aGUgbGFzdCBzZW50ZW5jZSB0byDCs8WgLCBhbmQgdGhlIG11bHRpY2FzdCB0dW5uZWwgc2V0dXAN Cj4gPj4+Pj4+PiBjcml0ZXJpYSBhcmUgYXMgZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0 aW9uLsKyDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gU2VjdGlvbiAzLjMuMSB0 YWxrcyBhYm91dCBCVU0gcHJvY2VkdXJlcy4gVGhhdCBpcyBub3Qgc3BlY2lmaWMNCj4gPj4+Pj4+ Pj4gdG8NCj4gPj4+Pj4+Pj4gMy4zLjENCj4gPj4+Pj4+Pj4gdGhvdWdoLiBQZXJoYXBzIGV4dHJh Y3QgdGhhdCBvdXQgdG8gYSBzZXBhcmF0ZSBzZWN0aW9uLCBhbmQNCj4gPj4+Pj4+Pj4gcmVtb3Zl IHRoZSBCVU0gdGV4dCBmcm9tIDMuMy4yIGFzIHdlbGwuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJ IHRoaW5rIGl0IGlzIE9LLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAgIFRo ZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5IGlzIGVuY29kZWQgYXMgYW4gOC1vY3RldCB2YWx1 ZSBhcw0KPiA+Pj4+Pj4+PiAgICBmb2xsb3dzOg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+PiAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy DQo+ID4+Pj4+Pj4+IDMNCj4gPj4+Pj4+Pj4gICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3DQo+ID4+Pj4+Pj4+IDggOQ0KPiA+Pj4+ Pj4+PiAwIDENCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+Pj4+Pj4+PiAgICAg ICAgfCBUeXBlPTB4MDYgICAgIHwgU3ViLVR5cGU9MHgwNCB8IEZsYWdzKDEgT2N0ZXQpfA0KPiA+ Pj4+Pj4+IHwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+PiArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+Pj4+Pj4+PiAgICAg ICAgfCAgUmVzZXJ2ZWQ9MCAgIHwgICAgICAgICAgIExlYWYgTGFiZWwNCj4gPj4+Pj4+PiB8DQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gSSBh c3N1bWUgdGhlIG9jdGVjdCBhZnRlciB0aGUgZmxhZ3Mgb2N0ZXQgaXMgYWxzbyByZXNlcnZlZD0w Lg0KPiA+Pj4+Pj4+PiBCZXR0ZXINCj4gPj4+Pj4+PiBtYXJrDQo+ID4+Pj4+Pj4+IGl0IGFzICJS ZXNlcnZlZD0wIi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFncmVlZC4NCj4gPj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBXaGVuIGl0IGlzIHVzZWQgd2l0aCBFdGhlcm5ldCBBLUQgcGVy IEVTIHJvdXRlLCB0aGUgbGVhZiBmbGFnDQo+ID4+Pj4+Pj4+IFNIT1VMRCBiZSBzZXQgdG8gMCBi dXQgaWdub3JlZCBieSB0aGUgcmVjZWl2aW5nIHJvdXRlcnMuDQo+ID4+Pj4+Pj4+IFRoZXJlZm9y ZSwgd2h5IG5vdCBzZXQNCj4gPj4+Pj4+PiBpdA0KPiA+Pj4+Pj4+PiB0byAxIHRvIGJlIGNvbnNp c3RlbnQgdGhlIE1BQy9JUCByb3V0ZSBjYXNlPw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQmVjYXVz ZSB0aGUgZmxhZyBpcyB1c2VkIGZvciBrbm93biB1bmljYXN0IHRyYWZmaWMgYW5kIExlYWYNCj4g Pj4+Pj4+PiBsYWJlbCBmb3IgQlVNIHRyYWZmaWMuIFdlIGRvbsK5dCB3YW50IHRvIG1peCB0aGUg dHdvLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+Pj4+IEFsaQ0KPiA+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IFRoYW5rcy4NCj4gPj4+Pj4+Pj4gSmVmZnJleQ0K PiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ Pj4+Pj4+IEZyb206IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBUaG9tYXMNCj4gPj4+Pj4+Pj4+IE1vcmluDQo+ID4+Pj4+Pj4+PiBTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDE5LCAyMDE2IDM6NTEgQU0NCj4gPj4+Pj4+Pj4+IFRvOiBCRVNTIDxiZXNzQGll dGYub3JnPjsNCj4gPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlQHRvb2xzLmll dGYub3JnDQo+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBbYmVzc10gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0 LWlldGYtYmVzcy1ldnBuLWV0cmVlDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gSGVsbG8gV29y a2luZyBHcm91cCwNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBUaGlzIGVtYWlsIHN0YXJ0cyBh IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+ID4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJlc3Mt ZXZwbi1ldHJlZSBbMV0gd2hpY2ggaXMgY29uc2lkZXJlZCBtYXR1cmUgYW5kDQo+ID4+Pj4+Pj4+ PiByZWFkeQ0KPiA+Pj4+Pj4+IGZvcg0KPiA+Pj4+Pj4+Pj4gYSBmaW5hbCB3b3JraW5nIGdyb3Vw IHJldmlldy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBQbGVhc2UgcmVhZCB0aGUgZG9jdW1l bnQgaWYgeW91IGhhdmVuJ3QgcmVhZCB0aGUgbW9zdCByZWNlbnQNCj4gPj4+Pj4+Pj4+IHZlcnNp b24NCj4gPj4+Pj4+PiB5ZXQNCj4gPj4+Pj4+Pj4+ICgtMDMpLCBhbmQgc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoZSBsaXN0LCBubyBsYXRlciB0aGFuDQo+ID4+Pj4+Pj4+PiAqRmVicnVhcnkNCj4g Pj4+Pj4+PiB0aGUNCj4gPj4+Pj4+Pj4+IDJuZCogKDIwMTYtMDItMDIpLg0KPiA+Pj4+Pj4+Pj4N Cj4gPj4+Pj4+Pj4+IFRoaXMgaXMgbm90IG9ubHkgYSBjYWxsIGZvciBjb21tZW50cyBvbiB0aGUg ZG9jdW1lbnQsIGJ1dCBhbHNvDQo+ID4+Pj4+Pj4+PiBhIGNhbGwNCj4gPj4+Pj4+PiBvZg0KPiA+ Pj4+Pj4+Pj4gc3VwcG9ydCBmb3IgaXRzIHB1YmxpY2F0aW9uLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+ICpDb2luY2lkZW50YWxseSosIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSDQo+ID4+Pj4+Pj4+PiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1iZXNz LWV2cG4tZXRyZWUsIHRvIGVuc3VyZSB0aGF0IElQUg0KPiA+Pj4+Pj4+Pj4gaGFzIGJlZW4gZGlz Y2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MNCj4gPj4+ Pj4+Pj4+IDM5NzksIDQ4NzksDQo+ID4+Pj4+Pj4gMzY2OQ0KPiA+Pj4+Pj4+Pj4gYW5kIDUzNzgg Zm9yIG1vcmUgZGV0YWlscykuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gKklmKiB5b3UgYXJl IGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBvZg0KPiA+Pj4+Pj4+ Pj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCBhbmQNCj4gPj4+Pj4+Pj4+IGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUg b2YgYW55IHJlbGV2YW50IElQUi4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBUaGFuayB5b3Us DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVGhvbWFzL01hcnRpbg0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+IFsxXQ0KPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUNCj4gPj4+Pj4+Pj4+DQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBCRVNTIG1haWxpbmcg bGlzdA0KPiBCRVNTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYmVzcw0K From nobody Thu Jun 9 20:56: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 4D64812DA68 for ; Thu, 9 Jun 2016 20:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pMR-Aj7h12Dj for ; Thu, 9 Jun 2016 20:56:38 -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 C506812D8C9 for ; Thu, 9 Jun 2016 20:56:37 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 1CC561C2B7FF3; Fri, 10 Jun 2016 03:56:35 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5A3uZ29014118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 03:56:35 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5A3uZTL020733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jun 2016 05:56:35 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 10 Jun 2016 05:56:34 +0200 From: "Henderickx, Wim (Nokia - BE)" To: John E Drake , "EXT - thomas.morin@orange.com" , BESS Thread-Topic: [bess] WG Last Call on draft-ietf-bess-evpn-etree Thread-Index: AQHRUpaME/U9KT8MU0ut9l7k3idEc58OWnfAgAhLYwCAAYwoAIBC0CQAgBXcMACARGjgAIAS+kOAgBUQT4CAAsQoAIAB2xeAgABFxoA= Date: Fri, 10 Jun 2016 03:56:34 +0000 Message-ID: References: <569DF8F7.2000703@orange.com> <13131_1459244945_56FA4F91_13131_9249_1_56FA4F90.300@orange.com> <3e6894f8-3e59-c3c0-739f-2613122aac96@orange.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Disha Chopra , Wen Lin Subject: Re: [bess] WG Last Call on 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, 10 Jun 2016 03:56:41 -0000 V2Ugd2lsbCByZWxlYXNlIG91ciBjb2RlIG5leHQgeWVhciBpbi1saW5lIHdpdGggdGhlIGRyYWZ0 DQoNCg0KDQoNCk9uIDA5LzA2LzE2IDE2OjMzLCAiQkVTUyBvbiBiZWhhbGYgb2YgSm9obiBFIERy YWtlIiA8YmVzcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqZHJha2VAanVuaXBlci5u ZXQ+IHdyb3RlOg0KDQo+VGhvbWFzLA0KPg0KPkUtVFJFRSBmb3IgRVZQTiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlLTA1KSB3aWxsIGJlIEdB IHRoaXMgeWVhci4gIFJvb3Qgb3IgbGVhZiByb2xlIGNhbiBiZSBkZWZpbmVkIG9uIGEgcG9ydCBv ciBWTEFOIGJhc2lzLCBhbmQgU2luZ2xlLUFjdGl2ZSBhbmQgQWxsLUFjdGl2ZSBtdWx0aS1ob21p bmcgYXJlIHN1cHBvcnRlZC4gIEUtVFJFRSBmb3IgUEJCLUVWUE4gaXMgb24gdGhlIHJvYWRtYXAu DQo+DQo+WW91cnMgSXJyZXNwZWN0aXZlbHksDQo+DQo+Sm9obg0KPg0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBUaG9tYXMgTW9yaW4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAw OCwgMjAxNiA2OjEzIEFNDQo+PiBUbzogQWxpIFNhamFzc2kgKHNhamFzc2kpOyBKZWZmcmV5ICha aGFvaHVpKSBaaGFuZzsgQkVTUzsgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tDQo+PiBldHJlZUB0b29s cy5pZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtiZXNzXSBXRyBMYXN0IENhbGwgb24gZHJhZnQt aWV0Zi1iZXNzLWV2cG4tZXRyZWUNCj4+IA0KPj4gSGkgQWxpLA0KPj4gDQo+PiBJIGhhdmVuJ3Qg c3RhcnRlZCB5ZXQgdGhlIHNoZXBoZXJkIHdyaXRlLXVwLCBidXQgaXQncyBvbiBteSB0b2RvIGxp c3QuDQo+PiANCj4+IEkgd2lsbCBkbyBhIHNoZXBoZXJkIHJldmlldyBhbG9uZyB3aXRoIHRoZSB3 cml0ZS11cCwgd2hpY2ggbWF5IGxlYWQgdG8gcmVzb2x2aW5nIHBvaW50cyB3aXRoDQo+PiBhdXRo b3JzLCBidXQgSSBjYW4ndCB0ZWxsIGJlZm9yZSBJIGdldCB0byBkbyBpdC4NCj4+IA0KPj4gT25l IHRoaW5nIHRoYXQgY2FuIGJlIHVzZWZ1bCB0byBjb2xsZWN0IHJpZ2h0IG5vdyBpcyBhbnkgaW5m b3JtYXRpb24geW91IG1heSBoYXZlIG9uDQo+PiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgKGFs dGhvdWdoIHRoaXMgZHJhZnQgd2FzIFdHTEMnZCBiZWZvcmUgd2Ugc2V0dXAgQkVTUyBvbmUtDQo+ PiBpbXBsZW1lbnRhdGlvbiBwb2xpY3ksIHRoaXMgcXVlc3Rpb24gaGFzIGJlZW4gcGFydCBvZiBz aGVwaGVyZCB3cml0ZS11cCBxdWVzdGlvbiwgZXZlbiBpZg0KPj4gaXRzIG5vdCBjb25zaWRlcmVk IGEgZ2F0aW5nIGNyaXRlcmlhKS4NCj4+IA0KPj4gVGhhbmtzIGluIGFkdmFuY2UsDQo+PiANCj4+ IC1UaG9tYXMNCj4+IA0KPj4gDQo+PiAyMDE2LTA2LTA2LCBBbGkgU2FqYXNzaSAoc2FqYXNzaSk6 DQo+PiA+DQo+PiA+IElzIHRoZXJlIGFueXRoaW5nIGVsc2UgeW91IG5lZWQgZnJvbSBtZSBvciBv dGhlciBjby1hdXRob3JzIHRvDQo+PiA+IHByb2dyZXNzIHRoaXMgZGFmdD8gVGhlIFdHIExDIHdh cyBjb21wbGV0ZWQgYmVmb3JlIGxhc3QgSUVURi4NCj4+ID4NCj4+ID4gUmVnYXJkcywNCj4+ID4g QWxpDQo+PiA+DQo+PiA+IE9uIDUvMjQvMTYsIDEyOjE4IEFNLCAiQWxpIFNhamFzc2kgKHNhamFz c2kpIiA8c2FqYXNzaUBjaXNjby5jb20+IHdyb3RlOg0KPj4gPg0KPj4gPj4NCj4+ID4+IEhpIFRo b21hcywNCj4+ID4+DQo+PiA+PiBDYW4geW91IHBsZWFzZSBwcm9ncmVzcyB0aGlzIGRyYWZ0LiBU aGUgV0cgTEMgd2FzIGNvbXBsZXRlZCBvbiAzLzI5DQo+PiA+PiBhbmQgYWxsIGNvbW1lbnRzIGV4 Y2VwdCBhIHNpbmdsZSBvcHRpb25hbCBjb21tZW50IHdlcmUgYWRkcmVzc2VkDQo+PiA+PiBiZWZv cmUgdGhlIGxhc3QgSUVURi4gVGhlIHNpbmdsZSBvcHRpb25hbCBjb21tZW50IHdhcyBhZGRyZXNz ZWQNCj4+ID4+IGNvdXBsZSBvZiB3ZWVrcyBhZ28gYW5kIHRoZSBkcmFmdCB3YXMgcmUtcHVibGlz aGVkIHRoZW4uDQo+PiA+Pg0KPj4gPj4gUmVnYXJkcywNCj4+ID4+IEFsaQ0KPj4gPj4NCj4+ID4+ DQo+PiA+PiBPbiA1LzExLzE2LCAxMDozMCBQTSwgIkJFU1Mgb24gYmVoYWxmIG9mIEFsaSBTYWph c3NpIChzYWphc3NpKSINCj4+ID4+IDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHNhamFzc2lAY2lzY28uY29tPiB3cm90ZToNCj4+ID4+DQo+PiA+Pj4NCj4+ID4+PiBIaSBUaG9t YXMsDQo+PiA+Pj4NCj4+ID4+PiBJIGp1c3QgbWFkZSB0aGUgZmluYWwgZWRpdHMgdG8gZXZwbi1l dHJlZSBkcmFmdCBhbmQgcHVibGlzaGVkIGl0IGFzDQo+PiA+Pj4gcmV2MDUuDQo+PiA+Pj4NCj4+ ID4+PiBSZWdhcmRzLA0KPj4gPj4+IEFsaQ0KPj4gPj4+DQo+PiA+Pj4gT24gMy8yOS8xNiwgMjo0 OSBBTSwgInRob21hcy5tb3JpbkBvcmFuZ2UuY29tIg0KPj4gPj4+IDx0aG9tYXMubW9yaW5Ab3Jh bmdlLmNvbT4NCj4+ID4+PiB3cm90ZToNCj4+ID4+Pg0KPj4gPj4+PiBIaSBldmVyeW9uZSwNCj4+ ID4+Pj4NCj4+ID4+Pj4gVGhpcyBXRyBMYXN0IENhbGwgaXMgbm93IGNsb3NlZCBhbmQgdGhlIGRv Y3VtZW50IHdpbGwgbW92ZSB0byB0aGUNCj4+ID4+Pj4gbmV4dCBzdGVwcyB0b3dhcmQgcHVibGlj YXRpb24uDQo+PiA+Pj4+DQo+PiA+Pj4+IFRoZSBtb2RpZmljYXRpb24gbWVudGlvbmVkIGJlbG93 IHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGluIG5leHQgcmVsZWFzZS4NCj4+ID4+Pj4NCj4+ID4+Pj4g QmVzdCwNCj4+ID4+Pj4NCj4+ID4+Pj4gLVRob21hcw0KPj4gPj4+Pg0KPj4gPj4+Pg0KPj4gPj4+ Pg0KPj4gPj4+PiAyMDE2LTAzLTE1LCBBbGkgU2FqYXNzaSAoc2FqYXNzaSk6DQo+PiA+Pj4+Pg0K Pj4gPj4+Pj4gSmVmZnJleSwNCj4+ID4+Pj4+DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4NCj4+ID4+Pj4+ IE9uIDIvMS8xNiwgMjo0MSBQTSwgIkplZmZyZXkgKFpoYW9odWkpIFpoYW5nIiA8enpoYW5nQGp1 bmlwZXIubmV0Pg0KPj4gPj4+Pj4gd3JvdGU6DQo+PiA+Pj4+Pg0KPj4gPj4+Pj4+IEFsaSwNCj4+ ID4+Pj4+Pg0KPj4gPj4+Pj4+IE9uZSBtb3JlIHF1ZXN0aW9uIGFib3V0IFBCQi1FVlBOLg0KPj4g Pj4+Pj4+DQo+PiA+Pj4+Pj4gRm9yIHRoZSByZWd1bGFyIEVWUE4sIHNlY3Rpb24gMy4zLjIgdGFs a3MgYWJvdXQgYSBzaXR1YXRpb24gd2hlcmUNCj4+ID4+Pj4+PiB0aGUgb25seSB0cmFmZmljIGlz IEJVTS4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgbWFjIGxlYXJuaW5nIGluDQo+PiA+Pj4+Pj4gdGhh dCBzaXR1YXRpb24uDQo+PiA+Pj4+Pj4NCj4+ID4+Pj4+PiBGb3IgUEJCLUVWUE4sIEkgYXNzdW1l IHRoaXMgaXMgYWxzbyBwb3NzaWJsZS4gV2l0aCB0aGlzLCB0aGVyZSBpcw0KPj4gPj4+Pj4+IG5v IG5lZWQgdG8gYWR2ZXJ0aXNlIHBlci1FUyBCLW1hYyBhZGRyZXNzZXMgLSBhIHNpbmdsZSBwYWly IG9mDQo+PiA+Pj4+Pj4gZ2xvYmFsIHJvb3QvbGVhZiBCLW1hYyBhZGRyZXNzZXMgYXJlIGVub3Vn aC4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IFBlcmhhcHMgdGhpcyBjYW4gYmUgbWVudGlvbmVkIGZv ciBwYXJpdHkvY29tcGxldGVuZXNzLiBPZiBjb3Vyc2UsDQo+PiA+Pj4+Pj4gdGhpcyBpcyBub3Qg YSBiaWcgZGVhbCBhbmQgZWl0aGVyIHdheSBpdCdzIGZpbmUgLSBidXQgSSBkbyB3YW50DQo+PiA+ Pj4+Pj4gdG8gYXNrIHRvIGNvbmZpcm0gbXkgdW5kZXJzdGFuZGluZy4NCj4+ID4+Pj4+DQo+PiA+ Pj4+PiBXZeKAmWxsIGRvLg0KPj4gPj4+Pj4NCj4+ID4+Pj4+IENoZWVycywNCj4+ID4+Pj4+IEFs aQ0KPj4gPj4+Pj4NCj4+ID4+Pj4+Pg0KPj4gPj4+Pj4+IEplZmZyZXkNCj4+ID4+Pj4+Pg0KPj4g Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4+Pj4+PiBGcm9tOiBBbGkg U2FqYXNzaSAoc2FqYXNzaSkgW21haWx0bzpzYWphc3NpQGNpc2NvLmNvbV0NCj4+ID4+Pj4+Pj4g U2VudDogTW9uZGF5LCBGZWJydWFyeSAwMSwgMjAxNiAyOjA0IEFNDQo+PiA+Pj4+Pj4+IFRvOiBK ZWZmcmV5IChaaGFvaHVpKSBaaGFuZyA8enpoYW5nQGp1bmlwZXIubmV0PjsgRVhUIC0NCj4+ID4+ Pj4+Pj4gdGhvbWFzLm1vcmluQG9yYW5nZS5jb20gPHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPjsg QkVTUw0KPj4gPj4+Pj4+PiA8YmVzc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0 cmVlQHRvb2xzLmlldGYub3JnDQo+PiA+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbYmVzc10gV0cgTGFz dCBDYWxsIG9uIGRyYWZ0LWlldGYtYmVzcy1ldnBuLWV0cmVlDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+IEhpIEplZmZyZXksDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHJl dmlldy4gWW91ciBjb21tZW50cyBoZWxwcyB0aWdodGVuIHRoZSBkcmFmdA0KPj4gPj4+Pj4+PiBz b21lIG1vcmUuDQo+PiA+Pj4+Pj4+IEkNCj4+ID4+Pj4+Pj4gaGF2ZSB1cGRhdGVkIHRoZSBkcmFm dCBhbmQgd2lsbCBwdWJsaXNoIGl0IG5leHQgKHJldjA0KS4NCj4+ID4+Pj4+Pj4gTWFqb3JpdHkg b2YgdGhlIGNvbW1lbnRzIHdlcmUgZWRpdG9yaWFsIGluIG5hdHVyZSBmb3IgYmV0dGVyDQo+PiA+ Pj4+Pj4+IGNsYXJpZmljYXRpb25zLiBTaW5jZSB0aGUgZXhpc3RpbmcgZHJhZnQgKHJldjAzKSBy ZWZsZWN0cyB0aGUNCj4+ID4+Pj4+Pj4gY29uc2Vuc3VzIHJlZ2FyZGluZyBvdXIgc2V2ZXJhbCBy b3VuZHMgb2YgZGlzY3Vzc2lvbnMgd2hlcmUgd2UNCj4+ID4+Pj4+Pj4gaGF2ZSB0YWtlbiBjYXJl IG9mIHRoZSB0ZWNobmljYWwgaXRlbXMsIGl0IGlzIGNvbnNpc3RlbnQgd2l0aA0KPj4gPj4+Pj4+ PiBvdXIgZXhwZWN0YXRpb24gb2Ygbm90IHNlZWluZyBhbnkgbWFqb3IgaXNzdWUgZHVyaW5nIHRo ZSBMQy4NCj4+ID4+Pj4+Pj4gUGxlYXNlIHJlZmVyIHRvIG15IHJlcGxpZXMgaW4gbGluZS4NCj4+ ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4gQ2hlZXJzLA0KPj4gPj4+Pj4+PiBBbGkNCj4+ID4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4gT24gMS8yNy8xNiwgNToyNiBQTSwgIkJFU1Mgb24gYmVo YWxmIG9mIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIg0KPj4gPj4+Pj4+PiA8YmVzcy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiB6emhhbmdAanVuaXBlci5uZXQ+IHdyb3RlOg0KPj4gPj4+ Pj4+Pg0KPj4gPj4+Pj4+Pj4gSSB3YXMgaW52b2x2ZWQgaW4gcmVsZXZhbnQgZGlzY3Vzc2lvbnMs IGFuZCBoYXZlIHJldmlld2VkIG9uY2UNCj4+ID4+Pj4+Pj4+IG1vcmUgZm9yIHRoaXMgTEMuDQo+ PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gSSBzdXBwb3J0IHRoZSBwdWJsaWNhdGlvbiwgYnV0IHdp dGggdGhlIGZvbGxvd2luZw0KPj4gPj4+Pj4+Pj4gcXVlc3Rpb25zL2NvbW1lbnRzLg0KPj4gPj4+ Pj4+Pj4NCj4+ID4+Pj4+Pj4+IDIuMSBTY2VuYXJpbyAxOiBMZWFmIE9SIFJvb3Qgc2l0ZShzKSBw ZXIgUEUNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiAgICAuLi4gSWYgdGhlIG51bWJlciBvZiBF VklzIGlzIHZlcnkgbGFyZ2UNCj4+ID4+Pj4+Pj4+ICAgIChlLmcuLCBtb3JlIHRoYW4gMzJLIG9y IDY0SyksIHRoZW4gUlQgdHlwZSAwIGFzIGRlZmluZWQgaW4NCj4+ID4+Pj4+Pj4+IFtSRkM0MzYw XQ0KPj4gPj4+Pj4+Pj4gICAgU0hPVUxEIGJlIHVzZWQ7IG90aGVyd2lzZSwgUlQgdHlwZSAyIGlz IHN1ZmZpY2llbnQuDQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gUkZDIDcxNTMgc2hvdWxkIGJl IHJlZmVyZW5jZWQgZm9yICJUeXBlIDIiLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+Pg0KPj4gPj4+ Pj4+PiBEb25lLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IEFkZGl0aW9u YWxseSwgd2h5IGlzIDMySyBtZW50aW9uZWQ/IEkgY2FuIHVuZGVyc3RhbmQgdGhlIDY0ayBwYXJ0 Lg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBSZW1vdmVkIDMySyBzaW5jZSB0aGUgZXhhbXBsZSBp cyBjbGVhciBlbm91Z2ggd2l0aCA2NEsNCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+ Pj4+PiAgICAuLi4gdGhlIE1QTFMtZW5jYXBzdWxhdGVkIGZyYW1lcyBNVVNUIGJlIHRhZ2dlZCB3 aXRoIGFuDQo+PiA+Pj4+Pj4+PiAgICBpbmRpY2F0aW9uIG9mIHdoZXRoZXIgdGhleSBvcmlnaW5h dGVkIGZyb20gYSBMZWFmIEFDIG9yIG5vdC4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBQZXJo YXBzIGNoYW5nZSB0aGUgbGFzdCBsaW5lIHRvICJpbmRpY2F0aW9uIGlmIHRoZXkgb3JpZ2luYXRl ZA0KPj4gPj4+Pj4+Pj4gZnJvbSBhIExlYWYgQUMiPyBQYWNrZXRzIGZyb20gYSByb290IEFDIGFy ZSBub3QgdGFnZ2VkIHdpdGggYQ0KPj4gPj4+Pj4+Pj4gbGVhZiBpbmRpY2F0aW9uLg0KPj4gPj4+ Pj4+Pg0KPj4gPj4+Pj4+PiBPSy4gQmV0dGVyIHlldC4gSXQgc2hvdWxkIHNheSDCs2luZGljYXRp b24gd2hlbiB0aGV5IG9yaWdpbmF0ZWQNCj4+ID4+Pj4+Pj4gZnJvbSBhIGxlYWYgQUPCsi4NCj4+ ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiAgICBPdGhlciBtZWNoYW5pc21zIGZv ciBpZGVudGlmeWluZyB3aGV0aGVyIGFuIGVncmVzcyBBQyBpcyBhDQo+PiA+Pj4+Pj4+PiByb290 IG9yDQo+PiA+Pj4+Pj4+PiAgICBsZWFmIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBTaG91bGQgImVncmVzcyIgYmUgImluZ3Jl c3MiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGg/IE9yIHNpbXBseQ0KPj4gPj4+Pj4+Pj4gcmVtb3Zl ZD8NCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4gTmljZSBjYXRjaCEgSXQgaXMgwrNpbmdyZXNzwrIu IEl0IGlzIG5vdyBjb3JyZWN0ZWQuDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+ Pj4gICAgLi4uIFRoaXMgTGVhZiBNUExTIGxhYmVsIGlzIGFkdmVydGlzZWQgdG8gb3RoZXIgUEUg ZGV2aWNlcywNCj4+ID4+Pj4+Pj4+ICAgIHVzaW5nIGEgbmV3IEVWUE4gRXh0ZW5kZWQgQ29tbXVu aXR5IGNhbGxlZCBFLVRSRUUgRXh0ZW5kZWQNCj4+ID4+Pj4+Pj4+IENvbW11bml0eQ0KPj4gPj4+ Pj4+Pj4gICAgKHNlY3Rpb24gNS4xKSBhbG9uZyB3aXRoIGFuIEV0aGVybmV0IEEtRCBwZXIgRVMg cm91dGUgd2l0aA0KPj4gPj4+Pj4+Pj4gRVNJIG9mDQo+PiA+Pj4+Pj4+PiAgICB6ZXJvIGFuZCBh IHNldCBvZiBSb3V0ZSBUYXJnZXRzIChSVHMpIGNvcnJlc3BvbmRpbmcgdG8gYWxsDQo+PiA+Pj4+ Pj4+PiB0aGUgbGVhZg0KPj4gPj4+Pj4+Pj4gICAgQUNzIG9uIHRoZSBQRS4NCj4+ID4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+PiBQZXJoYXBzIGNoYW5nZSB0aGUgbGFzdCBzZW50ZW5jZSB0byAiLi4uIGNv cnJlc3BvbmRpbmcgdG8gYWxsDQo+PiA+Pj4+Pj4+PiBFVklzIHRoYXQgaGF2ZSBsZWFmIHNpdGVz IG9uIHRoZSBQRS4iDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+IFRoZSBzZWNvbmQgdG8gbGFzdCBz ZW50ZW5jZSBvZiBzZWN0aW9uIDMuMi4xIHNheXMgdGhlIHNhbWUNCj4+ID4+Pj4+Pj4gdGhpbmcu IEkgY2hhbmdlZCB0aGlzIHNlbnRlbmNlIGFuZCByZW1vdmVkIHRoZSAybmQgdG8gbGFzdCBzZW50 ZW5jZS4NCj4+ID4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiAzLjIuMyBCVU0gdHJh ZmZpYyBvcmlnaW5hdGVkIGZyb20gYSBtdWx0aS1ob21lZCBzaXRlIG9uIGEgbGVhZg0KPj4gPj4+ Pj4+Pj4gQUMNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiAgICBJbiB0aGlzIHNjZW5hcmlvLCBp dCBpcyBhc3N1bWVkIHRoYXQgYSBtdWx0aS1ob21lZCBFdGhlcm5ldA0KPj4gPj4+Pj4+Pj4gU2Vn bWVudA0KPj4gPj4+Pj4+Pj4gICAgKEVTKSBjYW4gaGF2ZSBhIG1peGVkIG9mIGJvdGggbGVhZiBh bmQgcm9vdCBBQ3Mgd2l0aCBlYWNoIEFDDQo+PiA+Pj4+Pj4+PiAgICBkZXNpZ25hdGluZyBhIHN1 Ym5ldCAoZS5nLiwgYSBWTEFOKS4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBJIHVuZGVyc3Rh bmQgdGhhdCBkaWZmZXJlbnQgVkxBTnMgb24gdGhlIHNhbWUgRVMgY291bGQgYmUgcm9vdHMNCj4+ ID4+Pj4+Pj4+IG9yIGxlYXZlcy4gSSBzdXBwb3NlIGl0J3MgbW9yZSBpbXBvcnRhbnQgdG8gc2F5 IHRoYXQgZm9yIHRoZQ0KPj4gPj4+Pj4+Pj4gc2FtZSB2bGFuLCBkaWZmZXJlbnQgUEVzIG9uIHRo ZSBzYW1lIEVTIG11c3QgaGF2ZSB0aGUgc2FtZQ0KPj4gPj4+Pj4+Pj4gcm9vdC9sZWFmIGRlc2ln bmF0aW9uLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBUaGF0wrlzIGdpdmVuLg0KPj4gPj4+Pj4+ Pg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IFBlcmhhcHMgdGhlIGZpcnN0IHNlbnRlbmNlIGNv dWxkIGJlIHJld29yZGVkIGFzIHRoZSBmb2xsb3dpbmcNCj4+ID4+Pj4+Pj4+IHRvDQo+PiA+Pj4+ Pj4+IGNhcHR1cmUNCj4+ID4+Pj4+Pj4+IHRoZSBhYm92ZSBwb2ludDoNCj4+ID4+Pj4+Pj4+DQo+ PiA+Pj4+Pj4+PiAgICBXaGlsZSBkaWZmZXJlbnQgQUNzIChWTEFOcykgb24gdGhlIHNhbWUgRVMg Y291bGQgaGF2ZSBkaWZmZXJlbnQNCj4+ID4+Pj4+Pj4+ICAgIHJvb3QvbGVhZiBkZXNpZ25hdGlv biAoc29tZSBiZWluZyByb290cyBhbmQgc29tZSBiZWluZyBsZWF2ZXMpLA0KPj4gPj4+Pj4+Pj4g ICAgdGhlIHNhbWUgVkxBTiBkb2VzIGhhdmUgdGhlIHNhbWUgcm9vdC9sZWFmIGRlc2lnbmF0aW9u IG9uIGFsbA0KPj4gPj4+Pj4+Pj4gICAgUEVzIG9uIHRoZSBzYW1lIEVTLg0KPj4gPj4+Pj4+Pg0K Pj4gPj4+Pj4+PiBUaGF0wrlzIGZpbmUuIEl0IG1ha2VzIGl0IG1vcmUgY2xlYXIuDQo+PiA+Pj4+ Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gRm9yIHRoZSBmb2xsb3dpbmc6DQo+PiA+Pj4+ Pj4+Pg0KPj4gPj4+Pj4+Pj4gICAgLi4uIHRoZSBQRXMgd2l0aCBMZWFmIHNpdGVzIHBlcmZvcm0g TUFDIGxlYXJuaW5nIGluIHRoZQ0KPj4gPj4+Pj4+Pj4gICAgZGF0YS1wYXRoIG92ZXIgdGhlaXIg RXRoZXJuZXQgU2VnbWVudHMsIGFuZCBhZHZlcnRpc2UNCj4+ID4+Pj4+Pj4+IHJlYWNoYWJpbGl0 eQ0KPj4gPj4+Pj4+PiBpbg0KPj4gPj4+Pj4+Pj4gICAgRVZQTiBNQUMgQWR2ZXJ0aXNlbWVudCBy b3V0ZXMgd2hpY2ggYXJlIGltcG9ydGVkIG9ubHkgYnkgUEVzDQo+PiA+Pj4+Pj4+PiB3aXRoIGF0 DQo+PiA+Pj4+Pj4+PiAgICBsZWFzdCBvbmUgUm9vdCBzaXRlIGluIHRoZSBFVkkuIEEgUEUgd2l0 aCBvbmx5IExlYWYgc2l0ZXMNCj4+ID4+Pj4+Pj4+IHdpbGwgbm90DQo+PiA+Pj4+Pj4+PiAgICBp bXBvcnQgdGhlc2Ugcm91dGVzLiBQRXMgd2l0aCBSb290IGFuZC9vciBMZWFmIHNpdGVzIG1heSB1 c2UgdGhlDQo+PiA+Pj4+Pj4+PiAgICBFdGhlcm5ldCBBLUQgcm91dGVzIGZvciBhbGlhc2luZyAo aW4gdGhlIGNhc2Ugb2YgbXVsdGktaG9tZWQNCj4+ID4+Pj4+Pj4+ICAgIHNlZ21lbnRzKSBhbmQg Zm9yIG1hc3MgTUFDIHdpdGhkcmF3YWwgcGVyIFtSRkMgNzQzMl0uDQo+PiA+Pj4+Pj4+Pg0KPj4g Pj4+Pj4+Pj4gVGhlIGFib3ZlIHNlZW1zIHRvIGNvbnRyYWRpY3Qgd2l0aCB0aGUgcmVjb21tZW5k YXRpb24gaW4NCj4+ID4+Pj4+Pj4+IFNlY3Rpb24gMi4yLg0KPj4gPj4+Pj4+PiBJZg0KPj4gPj4+ Pj4+Pj4gdGhlIGNvbnRleHQgaXMgdGhlIHNjZW5hcmlvIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDIu MSB0aGVuDQo+PiA+Pj4+Pj4+PiB0aGF0J3MgZmluZSwgYnV0IHRoZSB0ZXh0IGRvZXMgbm90IGhh dmUgYSBjbGVhciBjb250ZXh0Lg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBBZ3JlZWQuIFVwZGF0 ZWQgdGhlIHNlY3Rpb24gdG8gaW5kaWNhdGUgdGhlIGNvbnRleHQgaXMgc2VjdGlvbiAyLjEuDQo+ PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IDMuMy4yIEUt VHJlZSB3aXRob3V0IE1BQyBMZWFybmluZw0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+ICAgIFRo ZSBQRXMgaW1wbGVtZW50aW5nIGFuIEUtVHJlZSBzZXJ2aWNlIG5lZWQgbm90IHBlcmZvcm0gTUFD DQo+PiA+Pj4+Pj4+PiBsZWFybmluZw0KPj4gPj4+Pj4+Pj4gICAgd2hlbiB0aGUgdHJhZmZpYyBm bG93cyBiZXR3ZWVuIFJvb3QgYW5kIExlYWYgc2l0ZXMgYXJlDQo+PiA+Pj4+Pj4+PiBtdWx0aWNh c3Qgb3INCj4+ID4+Pj4+Pj4+ICAgIGJyb2FkY2FzdC4NCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+ PiBJIHN1cHBvc2UgYW4gIm9ubHkiIHdvcmQgc2hvdWxkIGJlIGFkZGVkIGF0IHRoZSBlbmQgb2Yg dGhlDQo+PiA+Pj4+Pj4+PiBhYm92ZQ0KPj4gPj4+Pj4+PiBzZW50ZW5jZS4NCj4+ID4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4gQWdyZWVkLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+ DQo+PiA+Pj4+Pj4+PiAgICBUaGUgZmllbGRzIG9mIHRoZSBJTUVUIHJvdXRlIGFyZSBwb3B1bGF0 ZWQgcGVyIHRoZQ0KPj4gPj4+Pj4+Pj4gcHJvY2VkdXJlcw0KPj4gPj4+Pj4+PiBkZWZpbmVkDQo+ PiA+Pj4+Pj4+PiAgICBpbiBbUkZDNzQzMl0sIGFuZCB0aGUgcm91dGUgaW1wb3J0IHJ1bGVzIGFy ZSBhcyBkZXNjcmliZWQgaW4NCj4+ID4+Pj4+Pj4gcHJldmlvdXMNCj4+ID4+Pj4+Pj4+ICAgIHNl Y3Rpb25zLg0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+IFRoZSByb3V0ZSBpbXBvcnQgcnVsZXMg ZGVzY3JpYmVkIGluIHByZXZpb3VzIHNlY3Rpb25zIGFyZSBmb3INCj4+ID4+Pj4+Pj4+IE1BQw0K Pj4gPj4+Pj4+PiByb3V0ZXMsDQo+PiA+Pj4+Pj4+PiBub3QgSU1FVCByb3V0ZXMuIEFkZGl0aW9u YWxseSwgdGhvc2UgcnVsZXMgbWF5IG5vdCBiZQ0KPj4gPj4+Pj4+Pj4gcmVjb21tZW5kZWQsIHNv IG1pZ2h0IGFzIHdlbGwgZGVsZXRlIHRoZSBsYXN0IHNlbnRlbmNlLg0KPj4gPj4+Pj4+Pg0KPj4g Pj4+Pj4+PiBDaGFuZ2VkIHRoZSBsYXN0IHNlbnRlbmNlIHRvIMKzxaAsIGFuZCB0aGUgbXVsdGlj YXN0IHR1bm5lbCBzZXR1cA0KPj4gPj4+Pj4+PiBjcml0ZXJpYSBhcmUgYXMgZGVzY3JpYmVkIGlu IHRoZSBwcmV2aW91cyBzZWN0aW9uLsKyDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+ Pj4+Pj4gU2VjdGlvbiAzLjMuMSB0YWxrcyBhYm91dCBCVU0gcHJvY2VkdXJlcy4gVGhhdCBpcyBu b3Qgc3BlY2lmaWMNCj4+ID4+Pj4+Pj4+IHRvDQo+PiA+Pj4+Pj4+PiAzLjMuMQ0KPj4gPj4+Pj4+ Pj4gdGhvdWdoLiBQZXJoYXBzIGV4dHJhY3QgdGhhdCBvdXQgdG8gYSBzZXBhcmF0ZSBzZWN0aW9u LCBhbmQNCj4+ID4+Pj4+Pj4+IHJlbW92ZSB0aGUgQlVNIHRleHQgZnJvbSAzLjMuMiBhcyB3ZWxs Lg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBJIHRoaW5rIGl0IGlzIE9LLg0KPj4gPj4+Pj4+Pg0K Pj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+ICAgIFRoZSBFLVRSRUUgRXh0ZW5kZWQgQ29tbXVuaXR5 IGlzIGVuY29kZWQgYXMgYW4gOC1vY3RldCB2YWx1ZSBhcw0KPj4gPj4+Pj4+Pj4gICAgZm9sbG93 czoNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gICAgICAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KPj4gPj4+Pj4+Pj4gMw0KPj4gPj4+ Pj4+Pj4gICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3DQo+PiA+Pj4+Pj4+PiA4IDkNCj4+ID4+Pj4+Pj4+IDAgMQ0KPj4gPj4+Pj4+ Pj4NCj4+ID4+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4+ID4+Pj4+Pj4+ICAgICAgICB8IFR5cGU9MHgwNiAg ICAgfCBTdWItVHlwZT0weDA0IHwgRmxhZ3MoMSBPY3RldCl8DQo+PiA+Pj4+Pj4+IHwNCj4+ID4+ Pj4+Pj4+DQo+PiA+Pj4+Pj4+ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+PiA+Pj4+Pj4+PiAgICAgICAgfCAgUmVzZXJ2 ZWQ9MCAgIHwgICAgICAgICAgIExlYWYgTGFiZWwNCj4+ID4+Pj4+Pj4gfA0KPj4gPj4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4gKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCj4+ID4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+PiBJIGFzc3VtZSB0 aGUgb2N0ZWN0IGFmdGVyIHRoZSBmbGFncyBvY3RldCBpcyBhbHNvIHJlc2VydmVkPTAuDQo+PiA+ Pj4+Pj4+PiBCZXR0ZXINCj4+ID4+Pj4+Pj4gbWFyaw0KPj4gPj4+Pj4+Pj4gaXQgYXMgIlJlc2Vy dmVkPTAiLg0KPj4gPj4+Pj4+Pg0KPj4gPj4+Pj4+PiBBZ3JlZWQuDQo+PiA+Pj4+Pj4+DQo+PiA+ Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gV2hlbiBpdCBpcyB1c2VkIHdpdGggRXRoZXJuZXQgQS1EIHBl ciBFUyByb3V0ZSwgdGhlIGxlYWYgZmxhZw0KPj4gPj4+Pj4+Pj4gU0hPVUxEIGJlIHNldCB0byAw IGJ1dCBpZ25vcmVkIGJ5IHRoZSByZWNlaXZpbmcgcm91dGVycy4NCj4+ID4+Pj4+Pj4+IFRoZXJl Zm9yZSwgd2h5IG5vdCBzZXQNCj4+ID4+Pj4+Pj4gaXQNCj4+ID4+Pj4+Pj4+IHRvIDEgdG8gYmUg Y29uc2lzdGVudCB0aGUgTUFDL0lQIHJvdXRlIGNhc2U/DQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+ IEJlY2F1c2UgdGhlIGZsYWcgaXMgdXNlZCBmb3Iga25vd24gdW5pY2FzdCB0cmFmZmljIGFuZCBM ZWFmDQo+PiA+Pj4+Pj4+IGxhYmVsIGZvciBCVU0gdHJhZmZpYy4gV2UgZG9uwrl0IHdhbnQgdG8g bWl4IHRoZSB0d28uDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+IENoZWVycywNCj4+ID4+Pj4+Pj4g QWxpDQo+PiA+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pg0KPj4gPj4+Pj4+Pj4gVGhhbmtzLg0KPj4gPj4+ Pj4+Pj4gSmVmZnJleQ0KPj4gPj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPj4+Pj4+Pj4+IEZyb206IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMNCj4+ID4+Pj4+Pj4+PiBNb3Jpbg0KPj4gPj4+ Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTksIDIwMTYgMzo1MSBBTQ0KPj4gPj4+Pj4+ Pj4+IFRvOiBCRVNTIDxiZXNzQGlldGYub3JnPjsNCj4+ID4+Pj4+Pj4+PiBkcmFmdC1pZXRmLWJl c3MtZXZwbi1ldHJlZUB0b29scy5pZXRmLm9yZw0KPj4gPj4+Pj4+Pj4+IFN1YmplY3Q6IFtiZXNz XSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUNCj4+ID4+Pj4+Pj4+ Pg0KPj4gPj4+Pj4+Pj4+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+ Pj4+Pj4+PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uDQo+ PiA+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUgWzFdIHdoaWNoIGlzIGNvbnNp ZGVyZWQgbWF0dXJlIGFuZA0KPj4gPj4+Pj4+Pj4+IHJlYWR5DQo+PiA+Pj4+Pj4+IGZvcg0KPj4g Pj4+Pj4+Pj4+IGEgZmluYWwgd29ya2luZyBncm91cCByZXZpZXcuDQo+PiA+Pj4+Pj4+Pj4NCj4+ ID4+Pj4+Pj4+PiBQbGVhc2UgcmVhZCB0aGUgZG9jdW1lbnQgaWYgeW91IGhhdmVuJ3QgcmVhZCB0 aGUgbW9zdCByZWNlbnQNCj4+ID4+Pj4+Pj4+PiB2ZXJzaW9uDQo+PiA+Pj4+Pj4+IHlldA0KPj4g Pj4+Pj4+Pj4+ICgtMDMpLCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBubyBs YXRlciB0aGFuDQo+PiA+Pj4+Pj4+Pj4gKkZlYnJ1YXJ5DQo+PiA+Pj4+Pj4+IHRoZQ0KPj4gPj4+ Pj4+Pj4+IDJuZCogKDIwMTYtMDItMDIpLg0KPj4gPj4+Pj4+Pj4+DQo+PiA+Pj4+Pj4+Pj4gVGhp cyBpcyBub3Qgb25seSBhIGNhbGwgZm9yIGNvbW1lbnRzIG9uIHRoZSBkb2N1bWVudCwgYnV0IGFs c28NCj4+ID4+Pj4+Pj4+PiBhIGNhbGwNCj4+ID4+Pj4+Pj4gb2YNCj4+ID4+Pj4+Pj4+PiBzdXBw b3J0IGZvciBpdHMgcHVibGljYXRpb24uDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAqQ29p bmNpZGVudGFsbHkqLCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQ Ug0KPj4gPj4+Pj4+Pj4+IHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJl ZSwgdG8gZW5zdXJlIHRoYXQgSVBSDQo+PiA+Pj4+Pj4+Pj4gaGFzIGJlZW4gZGlzY2xvc2VkIGlu IGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MNCj4+ID4+Pj4+Pj4+PiAz OTc5LCA0ODc5LA0KPj4gPj4+Pj4+PiAzNjY5DQo+PiA+Pj4+Pj4+Pj4gYW5kIDUzNzggZm9yIG1v cmUgZGV0YWlscykuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiAqSWYqIHlvdSBhcmUgbGlz dGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIG9mDQo+PiA+Pj4+Pj4+Pj4g ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tZXRyZWUgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBh bmQNCj4+ID4+Pj4+Pj4+PiBpbmRpY2F0ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudCBJUFIuDQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBUaGFuayB5b3Us DQo+PiA+Pj4+Pj4+Pj4NCj4+ID4+Pj4+Pj4+PiBUaG9tYXMvTWFydGluDQo+PiA+Pj4+Pj4+Pj4N Cj4+ID4+Pj4+Pj4+PiBbMV0NCj4+ID4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWJlc3MtZXZwbi1ldHJlZQ0KPj4gPj4+Pj4+Pj4+DQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBCRVNT IG1haWxpbmcgbGlzdA0KPj4gQkVTU0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iZXNzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5CRVNTIG1haWxpbmcgbGlzdA0KPkJFU1NAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg== From nobody Thu Jun 9 22:50:20 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1A12D0C7; Thu, 9 Jun 2016 22:50:17 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610055017.16867.58164.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 22:50:17 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-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, 10 Jun 2016 05:50:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : A Network Virtualization Overlay Solution using EVPN Authors : Ali Sajassi John Drake Nabil Bitar R. Shekhar James Uttaro Wim Henderickx Filename : draft-ietf-bess-evpn-overlay-04.txt Pages : 27 Date : 2016-06-09 Abstract: This document describes how Ethernet VPN (EVPN) [RFC7432] can be used as an Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-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 Thu Jun 9 22:53:20 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1612B01C; Thu, 9 Jun 2016 22:53: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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610055319.16803.33553.idtracker@ietfa.amsl.com> Date: Thu, 09 Jun 2016 22:53:19 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-etree-06.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, 10 Jun 2016 05:53:20 -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-06.txt Pages : 17 Date : 2016-06-09 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. 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 13:03:12 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 77A8312D8F8 for ; Fri, 10 Jun 2016 13:03:06 -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 4m6V8sxh1E4E for ; Fri, 10 Jun 2016 13:03:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E7A12D8E7 for ; Fri, 10 Jun 2016 13:03:02 -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=bb9I90GGPerT0pgN2qeQocyp3+Z8kr9KNB4JuSYkpgI=; b=kqymjNdmuIkcgtvHsQKKJnNUUmgZNMPw1s6WEiDoi3w7wi2IHJSxacNIrbAtfnQQUDlK4iTNv9Vc1nz7IsXCVbfpRmB66jlyDvMb+QxIOlrg9NyIxkqUoOuEAnarEXeB533y/PufC+4azhS4eEA6OHfl4yaQuf344OuAZqQOM/Q= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1716.namprd05.prod.outlook.com (10.163.120.19) with Microsoft SMTP Server (TLS) id 15.1.511.8; Fri, 10 Jun 2016 20:03:00 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0517.009; Fri, 10 Jun 2016 20:03:00 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "bess@ietf.org" Thread-Topic: Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AdHDTr6Q1IW0rlKIThic0r80jZklFg== Date: Fri, 10 Jun 2016 20:03:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 32f1ae62-c240-44e1-d09d-08d3916a39a8 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1716; 5:Z6Adcmp6RznhNZTJhvdWf/yJjJBv7IMjLicIf+ElOuOz/DPBfa2N/y8wzV0OBqy4dxwx5zdowzTa8lDqZVARiU21mO1lQHsg1qgxdsn4JbNYtPFaSd+lYOYWY5gDhLqjqwG/zshv6rzXW1i5aezhvg==; 24:9a9ShPvPpOiB1QzR/5DMRIMSIPD/niHmqKUKK7QFv0siwfZ+VX5Fg9UA3aUvHEM5RePGhQu0diG+opwyWJ9usgZCw9YiTAYuCnynBZZndwg=; 7:GZz5rZkJtv6TTuRnPEpz4NCAZ/diBUCPaPFuMHpAGw7peTbkq7iTJEnwpemwJ5NWfnZiD8JONPaC+vZMXx2jy+u/6vp6WsKZUGBZyutho8rh9LyHXk+y/Yu7oRcJd9VW2NWDy7eTr3stRbViltETb/eslr5fwyYbPmLJDNT6fpqNJIcBjXULeXmx/7fE732k8SaWdk3FOgJRghWA22QnUA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1716; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1716; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1716; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(189998001)(54356999)(230783001)(110136002)(8936002)(2351001)(2900100001)(33656002)(74316001)(107886002)(2501003)(101416001)(76576001)(229853001)(9686002)(50986999)(97736004)(102836003)(3846002)(586003)(105586002)(106356001)(68736007)(99286002)(3660700001)(15975445007)(87936001)(1730700003)(8676002)(5003600100002)(92566002)(66066001)(3280700002)(10400500002)(122556002)(5008740100001)(450100001)(81166006)(11100500001)(5004730100002)(81156014)(2906002)(5640700001)(77096005)(6116002)(5002640100001)(19580395003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1716; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 20:03:00.7891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1716 Archived-At: Subject: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B 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, 10 Jun 2016 20:03:06 -0000 I want to bring up an old discussion about the following: In summary, it can be seen that aliasing (and backup path) functionality should work as is for inter-AS option B without requiring any addition functionality in ASBRs or PEs. However, the mass-withdraw functionality falls back from per-ES mode to per-EVI mode for inter-AS option B - i.e., PEs receiving mass-withdraw route from the same AS use Ether A-D per ES route; whereas, PEs receiving mass-withdraw route from different AS use Ether A-D per EVI route. There have been lot of discussions on this - offline and in Yokohama (https= ://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). The above text= does not reflect the consensus among some of us and in particular does not= reflect what was presented in Yokohama. There are two issues with inter-as option B as currently specified in RFC 7= 432. A minor issue is that mass-withdraw degrades from per ES to from per (ES, E= VI) (with the clarification in this overlay draft), which would not exist i= f the main issue is resolved as presented in Yokohama. The main one is the following requirement in RFC 7432: Note that the Ethernet A-D per EVI route may be received by a remote PE before it receives the set of Ethernet A-D per ES routes. Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. Basically, the per-EVI A-D routes cannot be used before the corresponding p= er-ES A-D routes are received and associated. Either that requirement must = be removed, or there must be a way to associate the per-ES routes and per-E= VI routes from the same PE. There is an easy solution to the latter, which was presented in Yokohama (h= ttps://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). That does = require a beefed up requirement: the routes from the same PE MUST have the = same global admin field in the RDs. That should be reasonable, and RFC alre= ady uses RECOMMEND keyword: 7.9. Route Distinguisher Assignment per MAC-VRF The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF that is advertising the NLRI. An RD MUST be assigned for a given MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on a PE. It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE. Notice the "RECOMMEND" in the above paragraph. 8.4.1. Constructing Ethernet A-D per EVPN Instance Route ... The Route Distinguisher (RD) MUST be set per Section 7.9. 8.2.1. Constructing Ethernet A-D per Ethernet Segment Route ... The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE. As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the problems = are solved. While RFC 7432 did not use MUST, I doubt there is any implement= ation not using a Type 1 RD for the per-EVI route. Jeffrey From nobody Mon Jun 13 05:25: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 3426512D621 for ; Mon, 13 Jun 2016 05:25:44 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VPMhNmlJothC for ; Mon, 13 Jun 2016 05:25:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB23512B01D for ; Mon, 13 Jun 2016 05:25:41 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8402032483E; Mon, 13 Jun 2016 14:25:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.3]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5C20A35C069; Mon, 13 Jun 2016 14:25:39 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.3) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 13 Jun 2016 14:25:39 +0200 From: To: BESS Organization: Orange Message-ID: <21327_1465820739_575EA643_21327_4044_5_0939dd8f-9715-7994-124b-f945085c7312@orange.com> Date: Mon, 13 Jun 2016 14:25:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.3] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.13.93616 Archived-At: Cc: "draft-ietf-bess-evpn-overlay@tools.ietf.org" Subject: [bess] WG Last Call (including implem status & shepherd) for 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: Mon, 13 Jun 2016 12:25:44 -0000 Hello Working Group, (Please read carefully, this e-mail contains new elements compared to WG LCs we were doing in a still recent past.) This email starts a Working Group Last Call on draft-ietf-bess-evpn-overlay [1]. * Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *27th of June*. Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC. * We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-overlay-04, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward. If you are listed as a document 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. * We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [2]. Please inform the mailing list, the chairs, or only one of the chairs. * Finally, if you want to volunteer to be Document Shepherd for this document, please let us know. Thank you, Thomas/Martin [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Mon Jun 13 08:49:16 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3BD12D549 for ; Mon, 13 Jun 2016 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.426, 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 OLodgxXX59kh for ; Mon, 13 Jun 2016 08:49:13 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id CD86C12D112 for ; Mon, 13 Jun 2016 08:49:12 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 24A79E30090 for ; Mon, 13 Jun 2016 17:49:12 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id BB700E30088 for ; Mon, 13 Jun 2016 17:49: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.266.1; Mon, 13 Jun 2016 17:49:11 +0200 From: Thomas Morin To: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> Organization: Orange Message-ID: <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com> Date: Mon, 13 Jun 2016 17:49:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 13 Jun 2016 15:49:15 -0000 Hi Ali, The changes in -04 look good. I would have one suggestion: say explicitly that the "use the label as the VNI" behavior is the same as what the tunnel encap says. This could be done by adding something like the following to section 5.1.3 : Note that the procedure defined here to use the MPLS Label field to carry the VNI in the presence of a Tunnel Encapsulation Extended Community specifying the use of a VNI, is aligned with the procedures described in [tunnel-encap] (Section "Use of Virtual Network Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation " for "Labeled Address Families"). Best, -Thomas Le 07/06/2016 à 18:04, Ali Sajassi (sajassi) a écrit : > Hi Martin, > > We¹ll also add idr-tunnel-encaps a Informative reference. With respect to > Tunnel Encap Extended Community (which is the only part of > idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft itself > references RFC 5512. > > During the course of WG LC and RFC editorship of evpn-overlay draft, if we > see that idr-tunnel-encap is progressing fast, then we can drop the > reference to RFC 5512 and make the reference to idr-tunnel-encap > Normative. Otherwise, we¹ll keep both references with RFC 5512 as > Normative and idr-tunnel-encap as Informative. > > Regards, > Ali > > On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >> Hi, >> >> We are fine with keeping 5512 as the Normative reference for now. >> We would think it wise if the editors can add an Informative reference >> to draft-ietf-idr-tunnel-encaps (with some text indicating that both >> specs provide the required support for the procedures). >> The ideal situation would be that tunnel-encaps progresses fast enough >> so that in the last stages before publishing evpn-overlay we can be in a >> situation to make tunnel-encaps the Normative reference. RFC 4897 would >> facilitate that by the way. >> >> If the WG has specific opinions on that matter, they are welcome. >> >> We take good note of the shepherd suggestion. We'll confirm who will >> shepherd the document after WG LC (we'll also call for volunteers during >> WG Last Call). >> >> Reviews are highly welcome anyway, in particular from people >> close to the topic or implementations, and ideally from more than one >> person, the best time being now or at least before the WG LC ends. >> >> We'll start the WG LC in a couple of days. >> >> Martin & Thomas >> >> >> Le 24/05/2016 15:39, John E Drake a écrit : >>> Hi, >>> >>> Ali and I decided to keep the normative reference to RFC 5512 rather >>> than changing it to Eric¹s tunnel encapsulation draft because the >>> normative reference pre-dates Eric¹s draft and because our draft does >>> not use any of the new capabilities introduced in Eric¹s draft. >>> >>> Ali and I would also like to request that Jorge be the document shepherd >>> for this draft. >>> >>> Yours Irrespectively, >>> >>> John >>> >>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>> *Sent:* Tuesday, May 24, 2016 3:05 AM >>> *To:* John E Drake; EXT -thomas.morin@orange.com; IDR; BESS; >>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - >>> US);draft-ietf-idr-tunnel-encap@tools.ietf.org >>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. >>> draft-ietf-idr-tunnel-encaps >>> >>> Folks, >>> >>> I have updated and published rev03 of even-overlay draft. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ >>> >>> The main changes are: >>> >>> 1. section 10.2 ­ DCI using ASBR >>> 2. The setting of Ethernet tag and VNI fields ­ there were some >>> inconsistencies in different sections. Section 5.1.3 captures the >>> setting of these fields for different type of services in pretty >>> good details. All other sections were cleaned up and now refer to >>> section 5.1.3. >>> >>> Thomas, >>> >>> The draft is ready for its long-overdue WG LC considering how long its >>> has been around and its multi-vendor implementation status. >>> >>> Regards, >>> >>> Ali >>> From nobody Mon Jun 13 12:26:20 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 B351112D960 for ; Mon, 13 Jun 2016 12:26:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xmZCkbVy6j7q for ; Mon, 13 Jun 2016 12:26:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186F012D944 for ; Mon, 13 Jun 2016 12:26:16 -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=lgofaVO7RFpZxtVo7vnpVVbCf4u27GdB7qaOKcDGMnE=; b=VG15KNqG+skxij+tTTpjwK3NGZAmMaCyNHg4na1MwQfsknCpwu8n7w3xse4Sx29qGejjbQaImDce1xndSwnOpCzKdtH+HZWyz7w0IN+86ooHZGzo2HlYvd4Qg5UmUhiEbJuhJENjJI6M/kJyOACbSJgYriJSEPXmkI3pJNBjJ7A= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) with Microsoft SMTP Server (TLS) id 15.1.511.8; Mon, 13 Jun 2016 19:25:59 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0511.014; Mon, 13 Jun 2016 19:25:59 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi+6xGM0bynWeUeGN93K6stLXZ+pFtLwgAAZ14CAABtMwIAAAw6AgAD40oCAAALOkIAAmFwAgAAIznCAE6UwgIAAQX5QgAj2SYCAAGyekIAVpcGAgACE+ACACWnGgIAAPBDw Date: Mon, 13 Jun 2016 19:25:58 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com> In-Reply-To: <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 723d4e80-6e48-4fd6-27c3-08d393c08c91 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1709; 5:WzuE6G99QJLpDSWE16pUTUzzw5KUiNEPOQd+XrbB592cyy7kyyNL6Ei+6HQrsK6AtSxhEenxaU9sui5ozfF/kE/6sVeGPNIwP56Or4kHZ+8xXdpNlxQk9FvKuX+UJvj+qdA5ZbXVLZHSZtTfTqnSyg==; 24:JODLXFY5ChTeoZqKe1AdesdFSZGq/A8372rpvwrVUFb9UykafoejfouOChdmC95mRlHYqkMuRUC5FqulvMKpR7KTZhd7TRGGfi2MKZ/QXkE=; 7:Weml/xY+ILtWRMdBuwTgVcUKR+1t19P8/UwTlE4LSde13ui6hKGN5Gf8aBWVIXR1dkXdSl5z1bLT4spzq8PAKVWukmmEUW4NpZ4Z2S1XA1ehP9U/fonAKQbCFQeaDGJ0R8cjjNq85hJPILhsRn41O2gnWa5ONtz9iXyk718NC2oH2HJiejcuELAwNIU3myJTHhmkEFKxBckUa7YY7cUZHg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1709; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(95692535739014)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1709; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1709; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(52314003)(13464003)(24454002)(199003)(189002)(377454003)(3280700002)(3660700001)(68736007)(8936002)(77096005)(586003)(102836003)(3846002)(10400500002)(19580405001)(19580395003)(5002640100001)(6116002)(97736004)(5008740100001)(9686002)(107886002)(66066001)(189998001)(106116001)(5001770100001)(92566002)(99286002)(2950100001)(2501003)(15975445007)(11100500001)(5004730100002)(93886004)(2900100001)(105586002)(106356001)(87936001)(33656002)(76576001)(230783001)(76176999)(54356999)(50986999)(2906002)(122556002)(8676002)(81156014)(81166006)(5003600100002)(101416001)(86362001)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1709; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 19:25:58.8511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1709 Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 13 Jun 2016 19:26:19 -0000 VGhvbWFzLA0KDQpJIGNvbXBsZXRlbHkgYWdyZWUuICBUaGlzIGlzIGFuIGV4Y2VsbGVudCB3YXkg dG8gcHJvdmlkZSBsaW5rYWdlIHdpdGggdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQuIA0KDQpZb3Vy cyBJcnJlc3BlY3RpdmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEJFU1MgW21haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBUaG9tYXMgTW9yaW4NCj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDE2IDExOjQ5IEFNDQo+ IFRvOiBiZXNzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbYmVzc10gW0lkcl0gZHJhZnQtaWV0 Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4gZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcw0KPiAN Cj4gSGkgQWxpLA0KPiANCj4gVGhlIGNoYW5nZXMgaW4gLTA0IGxvb2sgZ29vZC4NCj4gDQo+IEkg d291bGQgaGF2ZSBvbmUgc3VnZ2VzdGlvbjogc2F5IGV4cGxpY2l0bHkgdGhhdCB0aGUgInVzZSB0 aGUgbGFiZWwgYXMgdGhlIFZOSSIgYmVoYXZpb3IgaXMNCj4gdGhlIHNhbWUgYXMgd2hhdCB0aGUg dHVubmVsIGVuY2FwIHNheXMuDQo+IA0KPiBUaGlzIGNvdWxkIGJlIGRvbmUgYnkgYWRkaW5nIHNv bWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcgdG8gc2VjdGlvbg0KPiA1LjEuMyA6DQo+IA0KPiBO b3RlIHRoYXQgdGhlIHByb2NlZHVyZSBkZWZpbmVkIGhlcmUgdG8gdXNlIHRoZSBNUExTIExhYmVs IGZpZWxkIHRvIGNhcnJ5IHRoZSBWTkkgaW4gdGhlDQo+IHByZXNlbmNlDQo+ICAgICBvZiBhIFR1 bm5lbCBFbmNhcHN1bGF0aW9uIEV4dGVuZGVkIENvbW11bml0eSBzcGVjaWZ5aW5nIHRoZSB1c2Ug b2YgYSBWTkksIGlzDQo+ICAgICBhbGlnbmVkIHdpdGggdGhlIHByb2NlZHVyZXMgZGVzY3JpYmVk IGluIFt0dW5uZWwtZW5jYXBdIChTZWN0aW9uICJVc2Ugb2YgVmlydHVhbCBOZXR3b3JrDQo+ICAg ICBJZGVudGlmaWVycyBhbmQgRW1iZWRkZWQgTGFiZWxzIHdoZW4gSW1wb3NpbmcgYSBUdW5uZWwg RW5jYXBzdWxhdGlvbiAiIGZvciAiTGFiZWxlZA0KPiBBZGRyZXNzIEZhbWlsaWVzIikuDQo+IA0K PiBCZXN0LA0KPiANCj4gLVRob21hcw0KPiANCj4gDQo+IA0KPiBMZSAwNy8wNi8yMDE2IMOgIDE4 OjA0LCBBbGkgU2FqYXNzaSAoc2FqYXNzaSkgYSDDqWNyaXQgOg0KPiA+IEhpIE1hcnRpbiwNCj4g Pg0KPiA+IFdlwrlsbCBhbHNvIGFkZCBpZHItdHVubmVsLWVuY2FwcyBhIEluZm9ybWF0aXZlIHJl ZmVyZW5jZS4gV2l0aCByZXNwZWN0DQo+ID4gdG8gVHVubmVsIEVuY2FwIEV4dGVuZGVkIENvbW11 bml0eSAod2hpY2ggaXMgdGhlIG9ubHkgcGFydCBvZg0KPiA+IGlkci10dW5uZWwtZW5jYXAgdXNl ZCBieSBldnBuLW92ZXJsYXkgZHJhZnQpLCBpZHItdHVuZWwtZW5jYXAgZHJhZnQNCj4gPiBpdHNl bGYgcmVmZXJlbmNlcyBSRkMgNTUxMi4NCj4gPg0KPiA+IER1cmluZyB0aGUgY291cnNlIG9mIFdH IExDIGFuZCBSRkMgZWRpdG9yc2hpcCBvZiBldnBuLW92ZXJsYXkgZHJhZnQsDQo+ID4gaWYgd2Ug c2VlIHRoYXQgaWRyLXR1bm5lbC1lbmNhcCBpcyBwcm9ncmVzc2luZyBmYXN0LCB0aGVuIHdlIGNh biBkcm9wDQo+ID4gdGhlIHJlZmVyZW5jZSB0byBSRkMgNTUxMiBhbmQgbWFrZSB0aGUgcmVmZXJl bmNlIHRvIGlkci10dW5uZWwtZW5jYXANCj4gPiBOb3JtYXRpdmUuIE90aGVyd2lzZSwgd2XCuWxs IGtlZXAgYm90aCByZWZlcmVuY2VzIHdpdGggUkZDIDU1MTIgYXMNCj4gPiBOb3JtYXRpdmUgYW5k IGlkci10dW5uZWwtZW5jYXAgYXMgSW5mb3JtYXRpdmUuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+ IEFsaQ0KPiA+DQo+ID4gT24gNi83LzE2LCAxOjA4IEFNLCAiQkVTUyBvbiBiZWhhbGYgb2YgTWFy dGluIFZpZ291cmV1eCINCj4gPiA8YmVzcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBt YXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbT4gIHdyb3RlOg0KPiA+DQo+ID4+IEhpLA0KPiA+Pg0K PiA+PiBXZSBhcmUgZmluZSB3aXRoIGtlZXBpbmcgNTUxMiBhcyB0aGUgTm9ybWF0aXZlIHJlZmVy ZW5jZSBmb3Igbm93Lg0KPiA+PiBXZSB3b3VsZCB0aGluayBpdCB3aXNlIGlmIHRoZSBlZGl0b3Jz IGNhbiBhZGQgYW4gSW5mb3JtYXRpdmUNCj4gPj4gcmVmZXJlbmNlIHRvIGRyYWZ0LWlldGYtaWRy LXR1bm5lbC1lbmNhcHMgKHdpdGggc29tZSB0ZXh0IGluZGljYXRpbmcNCj4gPj4gdGhhdCBib3Ro IHNwZWNzIHByb3ZpZGUgdGhlIHJlcXVpcmVkIHN1cHBvcnQgZm9yIHRoZSBwcm9jZWR1cmVzKS4N Cj4gPj4gVGhlIGlkZWFsIHNpdHVhdGlvbiB3b3VsZCBiZSB0aGF0IHR1bm5lbC1lbmNhcHMgcHJv Z3Jlc3NlcyBmYXN0DQo+ID4+IGVub3VnaCBzbyB0aGF0IGluIHRoZSBsYXN0IHN0YWdlcyBiZWZv cmUgcHVibGlzaGluZyBldnBuLW92ZXJsYXkgd2UNCj4gPj4gY2FuIGJlIGluIGEgc2l0dWF0aW9u IHRvIG1ha2UgdHVubmVsLWVuY2FwcyB0aGUgTm9ybWF0aXZlIHJlZmVyZW5jZS4NCj4gPj4gUkZD IDQ4OTcgd291bGQgZmFjaWxpdGF0ZSB0aGF0IGJ5IHRoZSB3YXkuDQo+ID4+DQo+ID4+IElmIHRo ZSBXRyBoYXMgc3BlY2lmaWMgb3BpbmlvbnMgb24gdGhhdCBtYXR0ZXIsIHRoZXkgYXJlIHdlbGNv bWUuDQo+ID4+DQo+ID4+IFdlIHRha2UgZ29vZCBub3RlIG9mIHRoZSBzaGVwaGVyZCBzdWdnZXN0 aW9uLiBXZSdsbCBjb25maXJtIHdobyB3aWxsDQo+ID4+IHNoZXBoZXJkIHRoZSBkb2N1bWVudCBh ZnRlciBXRyBMQyAod2UnbGwgYWxzbyBjYWxsIGZvciB2b2x1bnRlZXJzDQo+ID4+IGR1cmluZyBX RyBMYXN0IENhbGwpLg0KPiA+Pg0KPiA+PiBSZXZpZXdzIGFyZSBoaWdobHkgd2VsY29tZSBhbnl3 YXksIGluIHBhcnRpY3VsYXIgZnJvbSBwZW9wbGUgY2xvc2UgdG8NCj4gPj4gdGhlIHRvcGljIG9y IGltcGxlbWVudGF0aW9ucywgYW5kIGlkZWFsbHkgZnJvbSBtb3JlIHRoYW4gb25lIHBlcnNvbiwN Cj4gPj4gdGhlIGJlc3QgdGltZSBiZWluZyBub3cgb3IgYXQgbGVhc3QgYmVmb3JlIHRoZSBXRyBM QyBlbmRzLg0KPiA+Pg0KPiA+PiBXZSdsbCBzdGFydCB0aGUgV0cgTEMgaW4gYSBjb3VwbGUgb2Yg ZGF5cy4NCj4gPj4NCj4gPj4gTWFydGluICYgVGhvbWFzDQo+ID4+DQo+ID4+DQo+ID4+IExlIDI0 LzA1LzIwMTYgMTU6MzksIEpvaG4gRSBEcmFrZSBhIMOpY3JpdCA6DQo+ID4+PiBIaSwNCj4gPj4+ DQo+ID4+PiBBbGkgYW5kIEkgZGVjaWRlZCB0byBrZWVwIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNl IHRvIFJGQyA1NTEyIHJhdGhlcg0KPiA+Pj4gdGhhbiBjaGFuZ2luZyBpdCB0byBFcmljwrlzIHR1 bm5lbCBlbmNhcHN1bGF0aW9uIGRyYWZ0IGJlY2F1c2UgdGhlDQo+ID4+PiBub3JtYXRpdmUgcmVm ZXJlbmNlIHByZS1kYXRlcyBFcmljwrlzIGRyYWZ0IGFuZCBiZWNhdXNlIG91ciBkcmFmdA0KPiA+ Pj4gZG9lcyBub3QgdXNlIGFueSBvZiB0aGUgbmV3IGNhcGFiaWxpdGllcyBpbnRyb2R1Y2VkIGlu IEVyaWPCuXMgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gQWxpIGFuZCBJIHdvdWxkIGFsc28gbGlrZSB0 byByZXF1ZXN0IHRoYXQgSm9yZ2UgYmUgdGhlIGRvY3VtZW50DQo+ID4+PiBzaGVwaGVyZCBmb3Ig dGhpcyBkcmFmdC4NCj4gPj4+DQo+ID4+PiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPj4+DQo+ ID4+PiBKb2huDQo+ID4+Pg0KPiA+Pj4gKkZyb206KkFsaSBTYWphc3NpIChzYWphc3NpKSBbbWFp bHRvOnNhamFzc2lAY2lzY28uY29tXQ0KPiA+Pj4gKlNlbnQ6KiBUdWVzZGF5LCBNYXkgMjQsIDIw MTYgMzowNSBBTQ0KPiA+Pj4gKlRvOiogSm9obiBFIERyYWtlOyBFWFQgLXRob21hcy5tb3JpbkBv cmFuZ2UuY29tOyBJRFI7IEJFU1M7DQo+ID4+PiBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5 QHRvb2xzLmlldGYub3JnOyBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLQ0KPiA+Pj4gVVMpO2RyYWZ0 LWlldGYtaWRyLXR1bm5lbC1lbmNhcEB0b29scy5pZXRmLm9yZw0KPiA+Pj4gKlN1YmplY3Q6KiBS ZTogW0lkcl0gZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB2cy4NCj4gPj4+IGRyYWZ0LWll dGYtaWRyLXR1bm5lbC1lbmNhcHMNCj4gPj4+DQo+ID4+PiBGb2xrcywNCj4gPj4+DQo+ID4+PiBJ IGhhdmUgdXBkYXRlZCBhbmQgcHVibGlzaGVkIHJldjAzIG9mIGV2ZW4tb3ZlcmxheSBkcmFmdC4N Cj4gPj4+DQo+ID4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWJlc3MtZXZwbi1vdmVybGF5Lw0KPiA+Pj4NCj4gPj4+IFRoZSBtYWluIGNoYW5nZXMgYXJlOg0K PiA+Pj4NCj4gPj4+ICAgMS4gc2VjdGlvbiAxMC4yIMKtIERDSSB1c2luZyBBU0JSDQo+ID4+PiAg IDIuIFRoZSBzZXR0aW5nIG9mIEV0aGVybmV0IHRhZyBhbmQgVk5JIGZpZWxkcyDCrSB0aGVyZSB3 ZXJlIHNvbWUNCj4gPj4+ICAgICAgaW5jb25zaXN0ZW5jaWVzIGluIGRpZmZlcmVudCBzZWN0aW9u cy4gU2VjdGlvbiA1LjEuMyBjYXB0dXJlcyB0aGUNCj4gPj4+ICAgICAgc2V0dGluZyBvZiB0aGVz ZSBmaWVsZHMgZm9yIGRpZmZlcmVudCB0eXBlIG9mIHNlcnZpY2VzIGluIHByZXR0eQ0KPiA+Pj4g ICAgICBnb29kIGRldGFpbHMuIEFsbCBvdGhlciBzZWN0aW9ucyB3ZXJlIGNsZWFuZWQgdXAgYW5k IG5vdyByZWZlciB0bw0KPiA+Pj4gICAgICBzZWN0aW9uIDUuMS4zLg0KPiA+Pj4NCj4gPj4+IFRo b21hcywNCj4gPj4+DQo+ID4+PiBUaGUgZHJhZnQgaXMgcmVhZHkgZm9yIGl0cyBsb25nLW92ZXJk dWUgV0cgTEMgY29uc2lkZXJpbmcgaG93IGxvbmcNCj4gPj4+IGl0cyBoYXMgYmVlbiBhcm91bmQg YW5kIGl0cyBtdWx0aS12ZW5kb3IgaW1wbGVtZW50YXRpb24gc3RhdHVzLg0KPiA+Pj4NCj4gPj4+ IFJlZ2FyZHMsDQo+ID4+Pg0KPiA+Pj4gQWxpDQo+ID4+Pg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQkVTUyBtYWlsaW5nIGxpc3QNCj4g QkVTU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jl c3MNCg== From nobody Mon Jun 13 14:48:03 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 1223712DA7D; Mon, 13 Jun 2016 14:46:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613214633.6787.26967.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 14:46:33 -0700 Archived-At: Cc: bess@ietf.org, ipr-announce@ietf.org Subject: [bess] IPR Disclosure Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track 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, 13 Jun 2016 21:46:33 -0000 X-List-Received-Date: Mon, 13 Jun 2016 21:46:33 -0000 Dear Andrew Dolganow, Jayant Kotalwar, Eric C. Rosen, Zhaohui (Jeffrey) Zhang: An IPR disclosure that pertains to your Internet-Draft entitled "Explicit Tracking with Wild Card Routes in Multicast VPN" (draft-dolganow-bess-mvpn-expl-track) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2807/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track" Thank you IETF Secretariat From nobody Mon Jun 13 20:00: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 D26E212D11A for ; Mon, 13 Jun 2016 20:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 KBnDZQUHovlb for ; Mon, 13 Jun 2016 20:00:49 -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 180B412B058 for ; Mon, 13 Jun 2016 20:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5403; q=dns/txt; s=iport; t=1465873249; x=1467082849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FkDbyGfAxdRaY/ldS4ti662egAXyBlx3DrEtqlYtFw8=; b=awgsAyUP+Ylp4Q86HhDN2JimllXT6wJw+cF02b6umuD6+rmU8XIdeJpP WHorCBBwPPxzPlbrwy1EWF5N3+HBTDqwkBEldaQDcnE/ir/mgWmi6TotQ d/Ptx/cc9f0pwHxpYRp8oQeXa2PJpuDXwJ6+Gkivp/yZsGjSvylTHRMmQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgCIcl9X/5JdJa1SCoM+Vn0GuyyBe?= =?us-ascii?q?RcLhXUCgTM4FAEBAQEBAQFlJ4RMAQECAgEBAWsLEAIBCEYnCyUCBAENBRsEiBE?= =?us-ascii?q?OumQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0hAkPKIVbBY4nijsBiHuCcII8g?= =?us-ascii?q?WkXhDuIZo9wAR42ggccgUtuAYhFKxh/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,469,1459814400"; d="scan'208";a="118440627" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 03:00:48 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5E30lMS009164 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jun 2016 03:00:48 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 13 Jun 2016 23:00:47 -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.1104.009; Mon, 13 Jun 2016 23:00:47 -0400 From: "Ali Sajassi (sajassi)" To: "Jeffrey (Zhaohui) Zhang" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AQHRxejzmvHRXtSFYE+4iSa44vU+aQ== Date: Tue, 14 Jun 2016 03:00:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17D4EE2F2990AC4BB663396D56BF73FB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ali Sajassi \(sajassi\)" Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B 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, 14 Jun 2016 03:00:51 -0000 Hi Jeffrey, A few points:=20 1) There have been lots of discussions on this topic but you were not in attendance for some of them including the ones held at the last IETF in Bones Aires. So, before jumping into a haste conclusion that there were not consensus on section 10, please check with your own colleagues who participated in those meetings. 2) Regarding the current text in section 10: this text is consistent with the one that was checked for IETF at Yokohama and it is also consistent with RFC 7432 operation. We still require Eth A-D per ES in order to validate Eth A-d per EVI, the only difference is that the mass-withdraw doesn=B9t work (i.e., route validation still works). 3) Your so-called =B3easy solution=B2 doesn=B9t work in all scenarios so th= ere is no point in documenting something that works sometimes :-) If you recall several years ago, we went to great length to accommodate multi-homing across multiple AS=B9s and that=B9s why we added originating router=B9s IP address to the ES route. The 4 byte field in RD type-1, is a router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is unique within an AS only. Thus the suggested solution won=B9t work when a CE is dual-homed to two PEs in two different AS=B9s. We are currently separately documenting a proper solution based on a new sub-TLV added to the attribute in idr-tunnel-encap draft to identify the originating PE. A solution based on this attribute will work for all scenarios. Now the question is what to do in short term. We can either go with the text that it is in section 10.2 of the evpn-overlay draft, plus go with the new draft, or just go with the new draft and remove the suggested solution in section 10.2. I am open to both. Cheers, Ali=20 On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" wrote: >I want to bring up an old discussion about the following: > > In summary, it can be seen that aliasing (and backup path) > functionality should work as is for inter-AS option B without > requiring any addition functionality in ASBRs or PEs. However, the > mass-withdraw functionality falls back from per-ES mode to per-EVI > mode for inter-AS option B - i.e., PEs receiving mass-withdraw route > from the same AS use Ether A-D per ES route; whereas, PEs receiving > mass-withdraw route from different AS use Ether A-D per EVI route. > >There have been lot of discussions on this - offline and in Yokohama >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). The >above text does not reflect the consensus among some of us and in >particular does not reflect what was presented in Yokohama. > >There are two issues with inter-as option B as currently specified in RFC >7432. > >A minor issue is that mass-withdraw degrades from per ES to from per (ES, >EVI) (with the clarification in this overlay draft), which would not >exist if the main issue is resolved as presented in Yokohama. > >The main one is the following requirement in RFC 7432: > > Note that the Ethernet A-D per EVI route may be received by a remote > PE before it receives the set of Ethernet A-D per ES routes. > Therefore, in order to handle corner cases and race conditions, the > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by > a remote PE until it also receives the associated set of Ethernet A-D > per ES routes. > >Basically, the per-EVI A-D routes cannot be used before the corresponding >per-ES A-D routes are received and associated. Either that requirement >must be removed, or there must be a way to associate the per-ES routes >and per-EVI routes from the same PE. > >There is an easy solution to the latter, which was presented in Yokohama >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). That >does require a beefed up requirement: the routes from the same PE MUST >have the same global admin field in the RDs. That should be reasonable, >and RFC already uses RECOMMEND keyword: > >7.9. Route Distinguisher Assignment per MAC-VRF > > The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF > that is advertising the NLRI. An RD MUST be assigned for a given > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on a PE. > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field > comprises an IP address of the PE (typically, the loopback address) > followed by a number unique to the PE. > >Notice the "RECOMMEND" in the above paragraph. > >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > ... > The Route Distinguisher (RD) MUST be set per Section 7.9. > >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > ... > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The > value field comprises an IP address of the PE (typically, the > loopback address) followed by a number unique to the PE. > >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the >problems are solved. While RFC 7432 did not use MUST, I doubt there is >any implementation not using a Type 1 RD for the per-EVI route. > >Jeffrey > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jun 13 22:33:03 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 01E2512D649 for ; Mon, 13 Jun 2016 22:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 nCvKF9CCk-9c for ; Mon, 13 Jun 2016 22:33:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F80512D16C for ; Mon, 13 Jun 2016 22:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5508; q=dns/txt; s=iport; t=1465882380; x=1467091980; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hAYtuX5/+nkb+GTrfW0LV0szCFmncpjikJnBs0dkGlQ=; b=FcsOWbmbWYnMPd5YTrm33Npo+RzRf7IX3oULEmLPIqQ0okRK3AlEU6Ho CAWyvKwzCGTgytVTw5iakDqZjqtGSjb6poYauBV7RmPiRNBOJTNpL2rcK kuZNfou8DHOR2UOvyDYpFmm0RO06bC51IVuNGccOpvP8oyn7yNUOhM1Mf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQC1lV9X/5hdJa1cgz5WfQa7L4F5F?= =?us-ascii?q?wuFdQKBMTgUAQEBAQEBAWUnhEsBAQEEAQEBGlEGFQIBCBEEAQEBJwcnCxQJCAI?= =?us-ascii?q?EARIUiBwOunkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0hECFWwWYYwGGA4gkj?= =?us-ascii?q?yGPcQEeNoNubokJfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,470,1459814400"; d="scan'208";a="114779652" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 05:32:59 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5E5WwV0027641 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jun 2016 05:32:59 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jun 2016 01:32:58 -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.1104.009; Tue, 14 Jun 2016 01:32:58 -0400 From: "Ali Sajassi (sajassi)" To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRpi++kmVRnOfCCEaLlUJwLCbjV5+pXciAgAAV74CAABx8AIAAAd6AgAD40oCAAAcLgIAAlB8AgAAObQCAE5+SgIAAQjEAgAj1lYCAAG49AIAVpCKAgAAP+YCACd7GgIAAcMcA Date: Tue, 14 Jun 2016 05:32:58 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com> In-Reply-To: <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: text/plain; charset="windows-1254" Content-ID: <75AD3797D3FA39468BA737BB304D90C3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 14 Jun 2016 05:33:02 -0000 Hi Thomas, Referencing the section 8 of idr-tunnel-encap draft is too wide a scope IMHO and maybe confusing, thus I'd like to narrow it down. I went over the both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to your comment, I=92d like to narrow it to only section 8.2.2.2. ("When a Valid VNI has not been Signaled=94) with regard to its applicability to evpn-overlay draft - to be more precise is the 2nd bullet of section 8.2.2.2. So, I=92d like to change your suggested text to: "Note that the procedure defined here to use the MPLS Label field to carry the VNI in the presence of a Tunnel Encapsulation Extended Community specifying the use of a VNI, is aligned with the procedures described in section 8.2.2.2 of [tunnel-encap] (=93When a Valid VNI has not been Signaled=94). Cheers, Ali On 6/13/16, 8:49 AM, "BESS on behalf of Thomas Morin" wrote: >Hi Ali, > >The changes in -04 look good. > >I would have one suggestion: say explicitly that the "use the label as >the VNI" behavior is the same as what the tunnel encap says. > >This could be done by adding something like the following to section >5.1.3 : > >Note that the procedure defined here to use the MPLS Label field to >carry the VNI in the presence > of a Tunnel Encapsulation Extended Community specifying the use of a >VNI, is > aligned with the procedures described in [tunnel-encap] (Section >"Use of Virtual Network > Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation >" for "Labeled Address Families"). > >Best, > >-Thomas > > > >Le 07/06/2016 =E0 18:04, Ali Sajassi (sajassi) a =E9crit : >> Hi Martin, >> >> We=B9ll also add idr-tunnel-encaps a Informative reference. With respect >>to >> Tunnel Encap Extended Community (which is the only part of >> idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft >>itself >> references RFC 5512. >> >> During the course of WG LC and RFC editorship of evpn-overlay draft, if >>we >> see that idr-tunnel-encap is progressing fast, then we can drop the >> reference to RFC 5512 and make the reference to idr-tunnel-encap >> Normative. Otherwise, we=B9ll keep both references with RFC 5512 as >> Normative and idr-tunnel-encap as Informative. >> >> Regards, >> Ali >> >> On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" >> wrote: >> >>> Hi, >>> >>> We are fine with keeping 5512 as the Normative reference for now. >>> We would think it wise if the editors can add an Informative reference >>> to draft-ietf-idr-tunnel-encaps (with some text indicating that both >>> specs provide the required support for the procedures). >>> The ideal situation would be that tunnel-encaps progresses fast enough >>> so that in the last stages before publishing evpn-overlay we can be in >>>a >>> situation to make tunnel-encaps the Normative reference. RFC 4897 would >>> facilitate that by the way. >>> >>> If the WG has specific opinions on that matter, they are welcome. >>> >>> We take good note of the shepherd suggestion. We'll confirm who will >>> shepherd the document after WG LC (we'll also call for volunteers >>>during >>> WG Last Call). >>> >>> Reviews are highly welcome anyway, in particular from people >>> close to the topic or implementations, and ideally from more than one >>> person, the best time being now or at least before the WG LC ends. >>> >>> We'll start the WG LC in a couple of days. >>> >>> Martin & Thomas >>> >>> >>> Le 24/05/2016 15:39, John E Drake a =E9crit : >>>> Hi, >>>> >>>> Ali and I decided to keep the normative reference to RFC 5512 rather >>>> than changing it to Eric=B9s tunnel encapsulation draft because the >>>> normative reference pre-dates Eric=B9s draft and because our draft doe= s >>>> not use any of the new capabilities introduced in Eric=B9s draft. >>>> >>>> Ali and I would also like to request that Jorge be the document >>>>shepherd >>>> for this draft. >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>>> *Sent:* Tuesday, May 24, 2016 3:05 AM >>>> *To:* John E Drake; EXT -thomas.morin@orange.com; IDR; BESS; >>>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - >>>> US);draft-ietf-idr-tunnel-encap@tools.ietf.org >>>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. >>>> draft-ietf-idr-tunnel-encaps >>>> >>>> Folks, >>>> >>>> I have updated and published rev03 of even-overlay draft. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ >>>> >>>> The main changes are: >>>> >>>> 1. section 10.2 =AD DCI using ASBR >>>> 2. The setting of Ethernet tag and VNI fields =AD there were some >>>> inconsistencies in different sections. Section 5.1.3 captures the >>>> setting of these fields for different type of services in pretty >>>> good details. All other sections were cleaned up and now refer to >>>> section 5.1.3. >>>> >>>> Thomas, >>>> >>>> The draft is ready for its long-overdue WG LC considering how long its >>>> has been around and its multi-vendor implementation status. >>>> >>>> Regards, >>>> >>>> Ali >>>> > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jun 14 00:24:54 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8412D81B for ; Tue, 14 Jun 2016 00:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 3p37yNbQ0ku1 for ; Tue, 14 Jun 2016 00:24:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E214E128E19 for ; Tue, 14 Jun 2016 00:24:48 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D50E8324950; Tue, 14 Jun 2016 09:24:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AE83235C045; Tue, 14 Jun 2016 09:24:46 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0294.000; Tue, 14 Jun 2016 09:24:46 +0200 From: To: "bess@ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps Thread-Index: AQHRxYsnsR/AkQY4SkqNcNHlof/kz5/oT80AgABAwzg= Date: Tue, 14 Jun 2016 07:24:45 +0000 Message-ID: <17735_1465889086_575FB13E_17735_9038_1_ghf6dvtut5an69jvpg75lee9.1465889056167@email.android.com> References: <5729F1C3.1030605@orange.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <420BA2D8D80A6727.2B2C290F-2299-40BB-B53B-CC36D2B5D826@mail.outlook.com> <1881_1462451514_572B3D3A_1881_7198_1_0vn90oitr7e881gh2sn8qm5f.1462451509961@email.android.com> <17029_1462484835_572BBF63_17029_2323_1_opi9hqsl9b9tani0t0skkcuq.1462484831251@email.android.com> <28175_1463566739_573C4192_28175_2444_1_613f729b-d12e-5c48-29a1-ff000c1184a1@orange.com> <575680F5.2030101@alcatel-lucent.com> <786b038a-bccb-28a7-30b9-73100e8f64f3@orange.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ghf6dvtut5an69jvpg75lee91465889056167emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.14.65417 Archived-At: Subject: Re: [bess] [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps 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, 14 Jun 2016 07:24:52 -0000 --_000_ghf6dvtut5an69jvpg75lee91465889056167emailandroidcom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Sounds perfect. Thanks, -Thomas ---- Ali Sajassi (sajassi) a =E9crit ---- Hi Thomas, Referencing the section 8 of idr-tunnel-encap draft is too wide a scope IMHO and maybe confusing, thus I'd like to narrow it down. I went over the both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to your comment, I=92d like to narrow it to only section 8.2.2.2. ("When a Valid VNI has not been Signaled=94) with regard to its applicability to evpn-overlay draft - to be more precise is the 2nd bullet of section 8.2.2.2. So, I=92d like to change your suggested text to: "Note that the procedure defined here to use the MPLS Label field to carry the VNI in the presence of a Tunnel Encapsulation Extended Community specifying the use of a VNI, is aligned with the procedures described in section 8.2.2.2 of [tunnel-encap] (=93When a Valid VNI has not been Signaled=94). Cheers, Ali On 6/13/16, 8:49 AM, "BESS on behalf of Thomas Morin" wrote: >Hi Ali, > >The changes in -04 look good. > >I would have one suggestion: say explicitly that the "use the label as >the VNI" behavior is the same as what the tunnel encap says. > >This could be done by adding something like the following to section >5.1.3 : > >Note that the procedure defined here to use the MPLS Label field to >carry the VNI in the presence > of a Tunnel Encapsulation Extended Community specifying the use of a >VNI, is > aligned with the procedures described in [tunnel-encap] (Section >"Use of Virtual Network > Identifiers and Embedded Labels when Imposing a Tunnel Encapsulation >" for "Labeled Address Families"). > >Best, > >-Thomas > > > >Le 07/06/2016 =E0 18:04, Ali Sajassi (sajassi) a =E9crit : >> Hi Martin, >> >> We=B9ll also add idr-tunnel-encaps a Informative reference. With respect >>to >> Tunnel Encap Extended Community (which is the only part of >> idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft >>itself >> references RFC 5512. >> >> During the course of WG LC and RFC editorship of evpn-overlay draft, if >>we >> see that idr-tunnel-encap is progressing fast, then we can drop the >> reference to RFC 5512 and make the reference to idr-tunnel-encap >> Normative. Otherwise, we=B9ll keep both references with RFC 5512 as >> Normative and idr-tunnel-encap as Informative. >> >> Regards, >> Ali >> >> On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux" >> wrote: >> >>> Hi, >>> >>> We are fine with keeping 5512 as the Normative reference for now. >>> We would think it wise if the editors can add an Informative reference >>> to draft-ietf-idr-tunnel-encaps (with some text indicating that both >>> specs provide the required support for the procedures). >>> The ideal situation would be that tunnel-encaps progresses fast enough >>> so that in the last stages before publishing evpn-overlay we can be in >>>a >>> situation to make tunnel-encaps the Normative reference. RFC 4897 would >>> facilitate that by the way. >>> >>> If the WG has specific opinions on that matter, they are welcome. >>> >>> We take good note of the shepherd suggestion. We'll confirm who will >>> shepherd the document after WG LC (we'll also call for volunteers >>>during >>> WG Last Call). >>> >>> Reviews are highly welcome anyway, in particular from people >>> close to the topic or implementations, and ideally from more than one >>> person, the best time being now or at least before the WG LC ends. >>> >>> We'll start the WG LC in a couple of days. >>> >>> Martin & Thomas >>> >>> >>> Le 24/05/2016 15:39, John E Drake a =E9crit : >>>> Hi, >>>> >>>> Ali and I decided to keep the normative reference to RFC 5512 rather >>>> than changing it to Eric=B9s tunnel encapsulation draft because the >>>> normative reference pre-dates Eric=B9s draft and because our draft does >>>> not use any of the new capabilities introduced in Eric=B9s draft. >>>> >>>> Ali and I would also like to request that Jorge be the document >>>>shepherd >>>> for this draft. >>>> >>>> Yours Irrespectively, >>>> >>>> John >>>> >>>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] >>>> *Sent:* Tuesday, May 24, 2016 3:05 AM >>>> *To:* John E Drake; EXT -thomas.morin@orange.com; IDR; BESS; >>>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorge (Nokia - >>>> US);draft-ietf-idr-tunnel-encap@tools.ietf.org >>>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs. >>>> draft-ietf-idr-tunnel-encaps >>>> >>>> Folks, >>>> >>>> I have updated and published rev03 of even-overlay draft. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ >>>> >>>> The main changes are: >>>> >>>> 1. section 10.2 =AD DCI using ASBR >>>> 2. The setting of Ethernet tag and VNI fields =AD there were some >>>> inconsistencies in different sections. Section 5.1.3 captures the >>>> setting of these fields for different type of services in pretty >>>> good details. All other sections were cleaned up and now refer to >>>> section 5.1.3. >>>> >>>> Thomas, >>>> >>>> The draft is ready for its long-overdue WG LC considering how long its >>>> has been around and its multi-vendor implementation status. >>>> >>>> Regards, >>>> >>>> Ali >>>> > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_ghf6dvtut5an69jvpg75lee91465889056167emailandroidcom_ Content-Type: text/html; charset="windows-1254" Content-Transfer-Encoding: quoted-printable
Sounds perfect.

Thanks,

-Thomas

---- Ali Sajassi (sajassi) a =E9crit ----


Hi Thomas,

Referencing the section 8 of idr-tunnel-encap draft is too wide a scope
IMHO and maybe confusing, thus I'd like to narrow it down. I went over the<= br> both sections 3.5 and 8 of the idr-tunnel-encap draft and with respect to your comment, I=92d like to narrow it to only section 8.2.2.2. ("When = a
Valid VNI has not been Signaled=94) with regard to its applicability to
evpn-overlay draft - to be more precise is the 2nd bullet of section
8.2.2.2. So, I=92d like to change your suggested text to:

"Note that the procedure defined here to use the MPLS Label field to c= arry
the VNI in the presence of a Tunnel Encapsulation Extended Community
specifying the use of a VNI, is aligned with the procedures described in
section 8.2.2.2 of [tunnel-encap] (=93When a Valid VNI has not been
Signaled=94).

Cheers,
Ali



On 6/13/16, 8:49 AM, "BESS on behalf of Thomas Morin"
<bess-bounces@ietf.org on behalf of thomas.morin@orange.com> wrote:
>Hi Ali,
>
>The changes in -04 look good.
>
>I would have one suggestion: say explicitly that the "use the labe= l as
>the VNI" behavior is  the same as what the tunnel encap says.=
>
>This could be done by adding something like the following to section
>5.1.3 :
>
>Note that the procedure defined here to use the MPLS Label field to
>carry the VNI in the presence
>    of a Tunnel Encapsulation Extended Community specify= ing the use of a
>VNI, is
>    aligned with the procedures described in [tunnel-enc= ap] (Section
>"Use of Virtual Network
>    Identifiers and Embedded Labels when Imposing a Tunn= el Encapsulation
>" for "Labeled Address Families").
>
>Best,
>
>-Thomas
>
>
>
>Le 07/06/2016 =E0 18:04, Ali Sajassi (sajassi) a =E9crit :
>> Hi Martin,
>>
>> We=B9ll also add idr-tunnel-encaps a Informative reference. With r= espect
>>to
>> Tunnel Encap Extended Community (which is the only part of
>> idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draf= t
>>itself
>> references RFC 5512.
>>
>> During the course of WG LC and RFC editorship of evpn-overlay draf= t, if
>>we
>> see that idr-tunnel-encap is progressing fast, then we can drop th= e
>> reference to RFC 5512 and make the reference to idr-tunnel-encap >> Normative. Otherwise, we=B9ll keep both references with RFC 5512 a= s
>> Normative and idr-tunnel-encap as Informative.
>>
>> Regards,
>> Ali
>>
>> On 6/7/16, 1:08 AM, "BESS on behalf of Martin Vigoureux"=
>> <bess-bounces@ietf.org on behalf of martin.vigoureux@nokia.com&= gt;  wrote:
>>
>>> Hi,
>>>
>>> We are fine with keeping 5512 as the Normative reference for n= ow.
>>> We would think it wise if the editors can add an Informative r= eference
>>> to draft-ietf-idr-tunnel-encaps (with some text indicating tha= t both
>>> specs provide the required support for the procedures).
>>> The ideal situation would be that tunnel-encaps progresses fas= t enough
>>> so that in the last stages before publishing evpn-overlay we c= an be in
>>>a
>>> situation to make tunnel-encaps the Normative reference. RFC 4= 897 would
>>> facilitate that by the way.
>>>
>>> If the WG has specific opinions on that matter, they are welco= me.
>>>
>>> We take good note of the shepherd suggestion. We'll confirm wh= o will
>>> shepherd the document after WG LC (we'll also call for volunte= ers
>>>during
>>> WG Last Call).
>>>
>>> Reviews are highly welcome anyway, in particular from people >>> close to the topic or implementations, and ideally from more t= han one
>>> person, the best time being now or at least before the WG LC e= nds.
>>>
>>> We'll start the WG LC in a couple of days.
>>>
>>> Martin & Thomas
>>>
>>>
>>> Le 24/05/2016 15:39, John E Drake a =E9crit :
>>>> Hi,
>>>>
>>>> Ali and I decided to keep the normative reference to RFC 5= 512 rather
>>>> than changing it to Eric=B9s tunnel encapsulation draft be= cause the
>>>> normative reference pre-dates Eric=B9s draft and because o= ur draft does
>>>> not use any of the new capabilities introduced in Eric=B9s= draft.
>>>>
>>>> Ali and I would also like to request that Jorge be the doc= ument
>>>>shepherd
>>>> for this draft.
>>>>
>>>> Yours Irrespectively,
>>>>
>>>> John
>>>>
>>>> *From:*Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
>>>> *Sent:* Tuesday, May 24, 2016 3:05 AM
>>>> *To:* John E Drake; EXT -thomas.morin@orange.com; IDR; BES= S;
>>>> draft-ietf-bess-evpn-overlay@tools.ietf.org; Rabadan, Jorg= e (Nokia -
>>>> US);draft-ietf-idr-tunnel-encap@tools.ietf.org
>>>> *Subject:* Re: [Idr] draft-ietf-bess-evpn-overlay vs.
>>>> draft-ietf-idr-tunnel-encaps
>>>>
>>>> Folks,
>>>>
>>>> I have updated and published rev03 of even-overlay draft.<= br> >>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-over= lay/
>>>>
>>>> The main changes are:
>>>>
>>>>   1. section 10.2 =AD DCI using ASBR
>>>>   2. The setting of Ethernet tag and VNI fields = =AD there were some
>>>>      inconsistencies in different= sections. Section 5.1.3 captures the
>>>>      setting of these fields for = different type of services in pretty
>>>>      good details. All other sect= ions were cleaned up and now refer to
>>>>      section 5.1.3.
>>>>
>>>> Thomas,
>>>>
>>>> The draft is ready for its long-overdue WG LC considering = how long its
>>>> has been around and its multi-vendor implementation status= .
>>>>
>>>> Regards,
>>>>
>>>> Ali
>>>>
>
>_______________________________________________
>BESS mailing list
>BESS@ietf.org
>https://www.ietf= .org/mailman/listinfo/bess

 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_ghf6dvtut5an69jvpg75lee91465889056167emailandroidcom_-- From nobody Tue Jun 14 02:45:06 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 23A4E12D151 for ; Tue, 14 Jun 2016 02:45:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 1JknvMF10kMx for ; Tue, 14 Jun 2016 02:45:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5791D12B064 for ; Tue, 14 Jun 2016 02:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yfcUN2BiA+E0GZCvhR9ZmuHntVXabyh6MQi3o6X64+8=; b=gcUpBB49BbjgBA7SrBZbOYEJVpHqXNpigT18WIBcyV1EbEyGEbEAEqz4Q1soPVfdG4kbP1DdexfsSk6AWR0P1QUMUecPdbpDZNIfePtG0VAaLvFvFff25Tf5Ah8eFqqBEvwBXgHmbQe7jsxbsc7E6xNJC1+e/CDpdeAK3eaTbuo= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) with Microsoft SMTP Server (TLS) id 15.1.517.8; Tue, 14 Jun 2016 09:44:39 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 09:44:39 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Ali Sajassi (sajassi)" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AdHDTr6Q1IW0rlKIThic0r80jZklFgCmjRqAAAzxJGA= Date: Tue, 14 Jun 2016 09:44:39 +0000 Message-ID: References: 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: 16b02efb-5815-44e2-cd63-08d39438814f x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1715; 6:H+JlvtW5VSyKk4OnBbzLwXyNtY7/hUL4eJZVNbKQp9LLHGx4dt+xDDJrKnIV1nfVZy5IPvWQN9AM1HO1E3VY3MZcRzbrUJ1vvw6+DBwHk+odQgSLJDL8SCZTitEzcBJSJXWIDuOla3CmMcky9AoY2zxSO+btfRee/6APXPL4rvPoxjCjK7KHl32SaxQZgH2QKPOMtTFKAbzdI6Ksa8Tgc6MU8/7tHS8T5dS2jMSJu7YTiJnDxCDHmp7gzErkvdiKkHmRtkiDOUdDbK0QF0CrVmsVPGhvjAIbSI5DQiveMbWRUeswz/gwqFzhNwswksxTT2FsJKQyh4J6l78vwDAh4Q==; 5:4vb5zg9RQc/oliEjQoBcdWacEAZCvlXhV52vGz1kcNAf+FP8ITIsveJC3V7G8t2HghepBCYk2fJjemVvR6z5ttKpS3bbIrwX0Voo4TH+u4axSO0/m4PH4OM3Lb4nr88xWcEL7x6lOo7TQmK8cefp3Q==; 24:V6w282SbWS3aZ35AjObQQXYG5uFBIgXDU1hk3tYH5PS5iOcWKHH3TDzty0NwiPkHOzH9TBb9a80tsq6+ftfAMhGeng2c/lRxZhS5JWGKXD4=; 7:UIAxVF0qZRfva1imgGJNwisb2t4zHUTFWaLXCLWSghsnEh6O/XMNox4PV4UvNxOq+ET6GcjEnlFVvXLJ5qzUVYCyIVAFxcdMDXJG0ZSieEDesocBX7lvPDPuQrJuYM7JqnaWH/gkDL2cSFBPUQRp1zoHma1X9TH9fz3cLPuievxiWxQGrnIWyiWNNwcz2zhZCxSfXw+i51CFTZKYwBjTz5bAVbO0NOs9S/YeCDo0jYU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1715; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB1715; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1715; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(13464003)(122556002)(86362001)(66066001)(99286002)(230783001)(2906002)(106356001)(105586002)(586003)(3846002)(11100500001)(102836003)(6116002)(10400500002)(2501003)(8936002)(9686002)(19580405001)(5004730100002)(77096005)(5002640100001)(19580395003)(76176999)(54356999)(74316001)(2950100001)(189998001)(2900100001)(87936001)(76576001)(15975445007)(33656002)(3280700002)(101416001)(5008740100001)(92566002)(81166006)(81156014)(8676002)(50986999)(97736004)(3660700001)(107886002)(5003600100002)(68736007)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1715; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 09:44:39.6535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1715 Archived-At: Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B 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, 14 Jun 2016 09:45:04 -0000 Hi Ali, > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Monday, June 13, 2016 11:01 PM > To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > Cc: Ali Sajassi (sajassi) > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > Inter-AS Option B >=20 >=20 > Hi Jeffrey, >=20 > A few points: >=20 > 1) There have been lots of discussions on this topic but you were not in > attendance for some of them including the ones held at the last IETF in > Bones Aires. So, before jumping into a haste conclusion that there were > not consensus on section 10, please check with your own colleagues who > participated in those meetings. >=20 > 2) Regarding the current text in section 10: this text is consistent with > the one that was checked for IETF at Yokohama and it is also consistent > with RFC 7432 operation. We still require Eth A-D per ES in order to > validate Eth A-d per EVI, the only difference is that the mass-withdraw > doesn=B9t work (i.e., route validation still works). Could the document clarify how the validation is done - how do you conclude= that a per-ES route and a per-EVI route are related? If I understand it co= rrectly, if the correlation can be done, then mass-withdraw works. That is the key of the issue that is missing from the document. >=20 > 3) Your so-called =B3easy solution=B2 doesn=B9t work in all scenarios so = there > is no point in documenting something that works sometimes :-) If you > recall several years ago, we went to great length to accommodate > multi-homing across multiple AS=B9s and that=B9s why we added originating > router=B9s IP address to the ES route. The 4 byte field in RD type-1, is = a > router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is unique > within an AS only. Thus the suggested solution won=B9t work when a CE is > dual-homed to two PEs in two different AS=B9s. If those two PEs happen to have the same router-id, and they happen to choo= se the same local admin field for the RD, e.g. vlan id as section 7.9 of RF= C 7432 says: The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE. This number may be generated by the PE. Or, in the Unique VLAN EVPN case, the low-order 12 bits may be the 12-bit VLAN ID, with the remaining high-order 4 bits set to 0. How do you distinguish the two routes from the PEs? There is no way to guar= antee it "always works" even if you don't use vlan-id. >=20 > We are currently separately documenting a proper solution based on a new > sub-TLV added to the attribute in idr-tunnel-encap draft to identify the > originating PE. A solution based on this attribute will work for all > scenarios. Now the question is what to do in short term. We can either go > with the text that it is in section 10.2 of the evpn-overlay draft, plus > go with the new draft, or just go with the new draft and remove the > suggested solution in section 10.2. I am open to both. Multi-homing across ASes (or any segmentation points) is complicated. I've = spent quite some cycles on it - in particular split horizon becomes more co= mplicated (I documented it in initial unpublished version of draft-zzhang-b= ess-evpn-bum-procedure-updates but then removed it). I would like to be inc= luded in the relevant discussions on the new document. If we can say "multi-homing across ASes" is out of scope for now, then the = overlay draft can certainly clarify inter-as optin B procedure (especially = on how the correlation is done). Otherwise, I'd suggest to remove section 1= 0.2. It is NOT specific to overlay anyway. Jeffrey >=20 > Cheers, > Ali >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > wrote: >=20 > >I want to bring up an old discussion about the following: > > > > In summary, it can be seen that aliasing (and backup path) > > functionality should work as is for inter-AS option B without > > requiring any addition functionality in ASBRs or PEs. However, the > > mass-withdraw functionality falls back from per-ES mode to per-EVI > > mode for inter-AS option B - i.e., PEs receiving mass-withdraw route > > from the same AS use Ether A-D per ES route; whereas, PEs receiving > > mass-withdraw route from different AS use Ether A-D per EVI route. > > > >There have been lot of discussions on this - offline and in Yokohama > >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). The > >above text does not reflect the consensus among some of us and in > >particular does not reflect what was presented in Yokohama. > > > >There are two issues with inter-as option B as currently specified in RF= C > >7432. > > > >A minor issue is that mass-withdraw degrades from per ES to from per (ES= , > >EVI) (with the clarification in this overlay draft), which would not > >exist if the main issue is resolved as presented in Yokohama. > > > >The main one is the following requirement in RFC 7432: > > > > Note that the Ethernet A-D per EVI route may be received by a remote > > PE before it receives the set of Ethernet A-D per ES routes. > > Therefore, in order to handle corner cases and race conditions, the > > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by > > a remote PE until it also receives the associated set of Ethernet A-D > > per ES routes. > > > >Basically, the per-EVI A-D routes cannot be used before the correspondin= g > >per-ES A-D routes are received and associated. Either that requirement > >must be removed, or there must be a way to associate the per-ES routes > >and per-EVI routes from the same PE. > > > >There is an easy solution to the latter, which was presented in Yokohama > >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). That > >does require a beefed up requirement: the routes from the same PE MUST > >have the same global admin field in the RDs. That should be reasonable, > >and RFC already uses RECOMMEND keyword: > > > >7.9. Route Distinguisher Assignment per MAC-VRF > > > > The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF > > that is advertising the NLRI. An RD MUST be assigned for a given > > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on a PE. > > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field > > comprises an IP address of the PE (typically, the loopback address) > > followed by a number unique to the PE. > > > >Notice the "RECOMMEND" in the above paragraph. > > > >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > > ... > > The Route Distinguisher (RD) MUST be set per Section 7.9. > > > >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > > ... > > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The > > value field comprises an IP address of the PE (typically, the > > loopback address) followed by a number unique to the PE. > > > >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the > >problems are solved. While RFC 7432 did not use MUST, I doubt there is > >any implementation not using a Type 1 RD for the per-EVI route. > > > >Jeffrey > > > >_______________________________________________ > >BESS mailing list > >BESS@ietf.org > >https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jun 14 22:59:27 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 0248912B03B for ; Tue, 14 Jun 2016 22:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 8lK6cWsOZ2rV for ; Tue, 14 Jun 2016 22:59:23 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEFA12B038 for ; Tue, 14 Jun 2016 22:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12144; q=dns/txt; s=iport; t=1465970363; x=1467179963; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dbAbc0RGmcqSShIOg3CGhVMPz1aJ+FDZRPlDr523xKY=; b=KVKi2Gz+yIJ8WC0uQ88GiJvRT0BoJzG4P8MY3PExzsLunimyTn21uds7 Bo/q8iEkLrNEbeNeHhTEf6fG+6Zbu4zqR1kmEFkOGyDV1QYIAkpfxgYo/ xQSrXerC5+sv2vsv43rPJLDfZ4KfGEOT4MaGStxFifV9mjREK9StOIs54 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgDo7WBX/5FdJa1SCoM+Vn0GuzSBe?= =?us-ascii?q?RcLhXUCHIEbOBQBAQEBAQEBZSeESwEBAQICAQEBMToXBAIBCBEEAQEBBCMFAgI?= =?us-ascii?q?lCxQJCAIEARIbBIgRDo9HnRUGkQIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBXuJe?= =?us-ascii?q?YQJDygXgmSCYAWYaQGIfIJwgjyBaReEO4hnj3MBHjaCBxyBTG4BiEUrGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,474,1459814400"; d="scan'208";a="118780214" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 05:59:22 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5F5xMXb022073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 05:59:22 GMT Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 01:59:21 -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.1104.009; Wed, 15 Jun 2016 01:59:21 -0400 From: "Ali Sajassi (sajassi)" To: "Jeffrey (Zhaohui) Zhang" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AQHRxejzmvHRXtSFYE+4iSa44vU+aZ/o+fiAgADeB4A= Date: Wed, 15 Jun 2016 05:59:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.76.53] Content-Type: text/plain; charset="euc-kr" Content-ID: <0DD1B228AB860E4C95B66F447320CA1F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 05:59:26 -0000 DQpIaSBKZWZmcmV5LA0KDQpPbiA2LzE0LzE2LCAyOjQ0IEFNLCAiSmVmZnJleSAoWmhhb2h1aSkg WmhhbmciIDx6emhhbmdAanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+SGkgQWxpLA0KPg0KPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEFsaSBTYWphc3NpIChzYWphc3NpKSBb bWFpbHRvOnNhamFzc2lAY2lzY28uY29tXQ0KPj4gU2VudDogTW9uZGF5LCBKdW5lIDEzLCAyMDE2 IDExOjAxIFBNDQo+PiBUbzogSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgPHp6aGFuZ0BqdW5pcGVy Lm5ldD47IGJlc3NAaWV0Zi5vcmcNCj4+IENjOiBBbGkgU2FqYXNzaSAoc2FqYXNzaSkgPHNhamFz c2lAY2lzY28uY29tPg0KPj4gU3ViamVjdDogUmU6IFtiZXNzXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLWJlc3MtZXZwbi1vdmVybGF5LTA0LCB3cnQNCj4+IEludGVyLUFTIE9wdGlvbiBCDQo+PiAN Cj4+IA0KPj4gSGkgSmVmZnJleSwNCj4+IA0KPj4gQSBmZXcgcG9pbnRzOg0KPj4gDQo+PiAxKSBU aGVyZSBoYXZlIGJlZW4gbG90cyBvZiBkaXNjdXNzaW9ucyBvbiB0aGlzIHRvcGljIGJ1dCB5b3Ug d2VyZSBub3QgaW4NCj4+IGF0dGVuZGFuY2UgZm9yIHNvbWUgb2YgdGhlbSBpbmNsdWRpbmcgdGhl IG9uZXMgaGVsZCBhdCB0aGUgbGFzdCBJRVRGIGluDQo+PiBCb25lcyBBaXJlcy4gU28sIGJlZm9y ZSBqdW1waW5nIGludG8gYSBoYXN0ZSBjb25jbHVzaW9uIHRoYXQgdGhlcmUgd2VyZQ0KPj4gbm90 IGNvbnNlbnN1cyBvbiBzZWN0aW9uIDEwLCBwbGVhc2UgY2hlY2sgd2l0aCB5b3VyIG93biBjb2xs ZWFndWVzIHdobw0KPj4gcGFydGljaXBhdGVkIGluIHRob3NlIG1lZXRpbmdzLg0KPj4gDQo+PiAy KSBSZWdhcmRpbmcgdGhlIGN1cnJlbnQgdGV4dCBpbiBzZWN0aW9uIDEwOiB0aGlzIHRleHQgaXMg Y29uc2lzdGVudA0KPj53aXRoDQo+PiB0aGUgb25lIHRoYXQgd2FzIGNoZWNrZWQgZm9yIElFVEYg YXQgWW9rb2hhbWEgYW5kIGl0IGlzIGFsc28gY29uc2lzdGVudA0KPj4gd2l0aCBSRkMgNzQzMiBv cGVyYXRpb24uIFdlIHN0aWxsIHJlcXVpcmUgRXRoIEEtRCBwZXIgRVMgaW4gb3JkZXIgdG8NCj4+ IHZhbGlkYXRlIEV0aCBBLWQgcGVyIEVWSSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHRo ZSBtYXNzLXdpdGhkcmF3DQo+PiBkb2Vzbqn2dCB3b3JrIChpLmUuLCByb3V0ZSB2YWxpZGF0aW9u IHN0aWxsIHdvcmtzKS4NCj4NCj5Db3VsZCB0aGUgZG9jdW1lbnQgY2xhcmlmeSBob3cgdGhlIHZh bGlkYXRpb24gaXMgZG9uZSAtIGhvdyBkbyB5b3UNCj5jb25jbHVkZSB0aGF0IGEgcGVyLUVTIHJv dXRlIGFuZCBhIHBlci1FVkkgcm91dGUgYXJlIHJlbGF0ZWQ/IElmIEkNCj51bmRlcnN0YW5kIGl0 IGNvcnJlY3RseSwgaWYgdGhlIGNvcnJlbGF0aW9uIGNhbiBiZSBkb25lLCB0aGVuDQo+bWFzcy13 aXRoZHJhdyB3b3Jrcy4NCj4NCj5UaGF0IGlzIHRoZSBrZXkgb2YgdGhlIGlzc3VlIHRoYXQgaXMg bWlzc2luZyBmcm9tIHRoZSBkb2N1bWVudC4NCg0KSXQgaGFzIGJlZW4gZGVzY3JpYmVkIGluIDR0 aCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxMC4yLjI6DQoNCiJOb3csIHdoZW4gdGhlIEFDIGJldHdl ZW4gdGhlIFBFMiBhbmQgdGhlIENFIGZhaWxzIGFuZCBQRTIgc2VuZHMgTkxSSQ0KICAgd2l0aGRy YXdhbCBmb3IgRXRoZXIgQS1EIHBlciBFUyByb3V0ZSBhbmQgdGhpcyB3aXRoZHJhd2FsIGdldHMN CiAgIHByb3BhZ2F0ZWQgYW5kIHJlY2VpdmVkIGJ5IHRoZSBQRTMsIHRoZSBCR1AgcHJvY2VzcyBp biBQRTMgcmVtb3Zlcw0KICAgdGhlIGNvcnJlc3BvbmRpbmcgQkdQIHJvdXRlOyBob3dldmVyLCBp dCBkb2Vzbid0IHJlbW92ZSB0aGUNCiAgIGFzc29jaWF0ZWQgaW5mbyAobmFtZWx5IEVTSSBhbmQg QkdQIG5leHQgaG9wKSBmcm9tIHRoZSBMMiByb3V0aW5nDQogICB0YWJsZSAoTDIgUklCKSBiZWNh dXNlIGl0IHN0aWxsIGhhcyB0aGUgb3RoZXIgRXRoZXIgQS1EIHBlciBFUyByb3V0ZQ0KICAgKG9y aWdpbmF0ZWQgZnJvbSBQRTEpIHdpdGggdGhlIHNhbWUgaW5mby4gVGhhdCBpcyB3aHkgdGhlIG1h c3MtDQogICB3aXRoZHJhdyBtZWNoYW5pc20gZG9lcyBub3Qgd29yayB3aGVuIGRvaW5nIERDSSB3 aXRoIGludGVyLUFTIG9wdGlvbg0KICAgQi4gSG93ZXZlciwgYXMgZGVzY3JpYmVkIHByZXZpb3Vs c3ksIHRoZSBhbGlhc2luZyBmdW5jdGlvbiB3b3JrcyBhbmQNCiAgIHNvIGRvZXMgIm1hc3Mtd2l0 aGRyYXcgcGVyIEVWSSIgKHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0aCB3aXRoZHJhd2luZw0KICAg dGhlIEVWUE4gcm91dGUgYXNzb2NpYXRlZCB3aXRoIEFsaWFzaW5nIC0gaS5lLiwgRXRoZXIgQS1E IHBlciBFVkkNCiAgIHJvdXRlKS6hsQ0KDQo+DQo+PiANCj4+IDMpIFlvdXIgc28tY2FsbGVkIKn4 ZWFzeSBzb2x1dGlvbqn3IGRvZXNuqfZ0IHdvcmsgaW4gYWxsIHNjZW5hcmlvcyBzbyB0aGVyZQ0K Pj4gaXMgbm8gcG9pbnQgaW4gZG9jdW1lbnRpbmcgc29tZXRoaW5nIHRoYXQgd29ya3Mgc29tZXRp bWVzIDotKSBJZiB5b3UNCj4+IHJlY2FsbCBzZXZlcmFsIHllYXJzIGFnbywgd2Ugd2VudCB0byBn cmVhdCBsZW5ndGggdG8gYWNjb21tb2RhdGUNCj4+IG11bHRpLWhvbWluZyBhY3Jvc3MgbXVsdGlw bGUgQVOp9nMgYW5kIHRoYXSp9nMgd2h5IHdlIGFkZGVkIG9yaWdpbmF0aW5nDQo+PiByb3V0ZXKp 9nMgSVAgYWRkcmVzcyB0byB0aGUgRVMgcm91dGUuIFRoZSA0IGJ5dGUgZmllbGQgaW4gUkQgdHlw ZS0xLCBpcyBhDQo+PiByb3V0ZXIgSUQgKGZvciBib3RoIElQdjQgYW5kIElQdjYpIGFuZCBwZXIg UkZDIDYyODYsIHJvdXRlci1pZCBpcyB1bmlxdWUNCj4+IHdpdGhpbiBhbiBBUyBvbmx5LiBUaHVz IHRoZSBzdWdnZXN0ZWQgc29sdXRpb24gd29uqfZ0IHdvcmsgd2hlbiBhIENFIGlzDQo+PiBkdWFs LWhvbWVkIHRvIHR3byBQRXMgaW4gdHdvIGRpZmZlcmVudCBBU6n2cy4NCj4NCj5JZiB0aG9zZSB0 d28gUEVzIGhhcHBlbiB0byBoYXZlIHRoZSBzYW1lIHJvdXRlci1pZCwgYW5kIHRoZXkgaGFwcGVu IHRvDQo+Y2hvb3NlIHRoZSBzYW1lIGxvY2FsIGFkbWluIGZpZWxkIGZvciB0aGUgUkQsIGUuZy4g dmxhbiBpZCBhcyBzZWN0aW9uIDcuOQ0KPm9mIFJGQyA3NDMyIHNheXM6DQo+DQo+ICAgVGhlIHZh bHVlIGZpZWxkDQo+ICAgY29tcHJpc2VzIGFuIElQIGFkZHJlc3Mgb2YgdGhlIFBFICh0eXBpY2Fs bHksIHRoZSBsb29wYmFjayBhZGRyZXNzKQ0KPiAgIGZvbGxvd2VkIGJ5IGEgbnVtYmVyIHVuaXF1 ZSB0byB0aGUgUEUuICBUaGlzIG51bWJlciBtYXkgYmUgZ2VuZXJhdGVkDQo+ICAgYnkgdGhlIFBF LiAgT3IsIGluIHRoZSBVbmlxdWUgVkxBTiBFVlBOIGNhc2UsIHRoZSBsb3ctb3JkZXIgMTIgYml0 cw0KPiAgIG1heSBiZSB0aGUgMTItYml0IFZMQU4gSUQsIHdpdGggdGhlIHJlbWFpbmluZyBoaWdo LW9yZGVyIDQgYml0cyBzZXQNCj4gICB0byAwLg0KPg0KPkhvdyBkbyB5b3UgZGlzdGluZ3Vpc2gg dGhlIHR3byByb3V0ZXMgZnJvbSB0aGUgUEVzPyBUaGVyZSBpcyBubyB3YXkgdG8NCj5ndWFyYW50 ZWUgaXQgImFsd2F5cyB3b3JrcyIgZXZlbiBpZiB5b3UgZG9uJ3QgdXNlIHZsYW4taWQuDQoNCklu IHN1Y2ggc2NlbmFyaW9zLCB0aGUgQVNCUnMgcGVyZm9ybSBSRCAoYW5kIFJUKSB0cmFuc2xhdGlv bjsgaG93ZXZlciwgdGhlDQp0cmFuc2xhdGVkIFJEIG5vIGxvbmdlciBuZWVkcyB0byBiZSBvZiB0 eXBlLTEuDQoNCj4NCj4+IA0KPj4gV2UgYXJlIGN1cnJlbnRseSBzZXBhcmF0ZWx5IGRvY3VtZW50 aW5nIGEgcHJvcGVyIHNvbHV0aW9uIGJhc2VkIG9uIGEgbmV3DQo+PiBzdWItVExWIGFkZGVkIHRv IHRoZSBhdHRyaWJ1dGUgaW4gaWRyLXR1bm5lbC1lbmNhcCBkcmFmdCB0byBpZGVudGlmeSB0aGUN Cj4+IG9yaWdpbmF0aW5nIFBFLiBBIHNvbHV0aW9uIGJhc2VkIG9uIHRoaXMgYXR0cmlidXRlIHdp bGwgd29yayBmb3IgYWxsDQo+PiBzY2VuYXJpb3MuIE5vdyB0aGUgcXVlc3Rpb24gaXMgd2hhdCB0 byBkbyBpbiBzaG9ydCB0ZXJtLiBXZSBjYW4gZWl0aGVyDQo+PmdvDQo+PiB3aXRoIHRoZSB0ZXh0 IHRoYXQgaXQgaXMgaW4gc2VjdGlvbiAxMC4yIG9mIHRoZSBldnBuLW92ZXJsYXkgZHJhZnQsIHBs dXMNCj4+IGdvIHdpdGggdGhlIG5ldyBkcmFmdCwgb3IganVzdCBnbyB3aXRoIHRoZSBuZXcgZHJh ZnQgYW5kIHJlbW92ZSB0aGUNCj4+IHN1Z2dlc3RlZCBzb2x1dGlvbiBpbiBzZWN0aW9uIDEwLjIu IEkgYW0gb3BlbiB0byBib3RoLg0KPg0KPk11bHRpLWhvbWluZyBhY3Jvc3MgQVNlcyAob3IgYW55 IHNlZ21lbnRhdGlvbiBwb2ludHMpIGlzIGNvbXBsaWNhdGVkLg0KPkkndmUgc3BlbnQgcXVpdGUg c29tZSBjeWNsZXMgb24gaXQgLSBpbiBwYXJ0aWN1bGFyIHNwbGl0IGhvcml6b24gYmVjb21lcw0K Pm1vcmUgY29tcGxpY2F0ZWQgKEkgZG9jdW1lbnRlZCBpdCBpbiBpbml0aWFsIHVucHVibGlzaGVk IHZlcnNpb24gb2YNCj5kcmFmdC16emhhbmctYmVzcy1ldnBuLWJ1bS1wcm9jZWR1cmUtdXBkYXRl cyBidXQgdGhlbiByZW1vdmVkIGl0KS4gSQ0KPndvdWxkIGxpa2UgdG8gYmUgaW5jbHVkZWQgaW4g dGhlIHJlbGV2YW50IGRpc2N1c3Npb25zIG9uIHRoZSBuZXcgZG9jdW1lbnQuDQoNClN1cmUsIHdl IGNhbiBkZWZpbml0ZWx5IGNvbnNpZGVyIGl0Lg0KDQpDaGVlcnMsDQpBbGkNCg0KPg0KPklmIHdl IGNhbiBzYXkgIm11bHRpLWhvbWluZyBhY3Jvc3MgQVNlcyIgaXMgb3V0IG9mIHNjb3BlIGZvciBu b3csIHRoZW4NCj50aGUgb3ZlcmxheSBkcmFmdCBjYW4gY2VydGFpbmx5IGNsYXJpZnkgaW50ZXIt YXMgb3B0aW4gQiBwcm9jZWR1cmUNCj4oZXNwZWNpYWxseSBvbiBob3cgdGhlIGNvcnJlbGF0aW9u IGlzIGRvbmUpLiBPdGhlcndpc2UsIEknZCBzdWdnZXN0IHRvDQo+cmVtb3ZlIHNlY3Rpb24gMTAu Mi4gSXQgaXMgTk9UIHNwZWNpZmljIHRvIG92ZXJsYXkgYW55d2F5Lg0KPg0KPkplZmZyZXkNCj4N Cj4+IA0KPj4gQ2hlZXJzLA0KPj4gQWxpDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+ PiANCj4+IE9uIDYvMTAvMTYsIDE6MDMgUE0sICJCRVNTIG9uIGJlaGFsZiBvZiBKZWZmcmV5ICha aGFvaHVpKSBaaGFuZyINCj4+IDxiZXNzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHp6 aGFuZ0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiANCj4+ID5JIHdhbnQgdG8gYnJpbmcgdXAgYW4g b2xkIGRpc2N1c3Npb24gYWJvdXQgdGhlIGZvbGxvd2luZzoNCj4+ID4NCj4+ID4gICBJbiBzdW1t YXJ5LCBpdCBjYW4gYmUgc2VlbiB0aGF0IGFsaWFzaW5nIChhbmQgYmFja3VwIHBhdGgpDQo+PiA+ ICAgZnVuY3Rpb25hbGl0eSBzaG91bGQgd29yayBhcyBpcyBmb3IgaW50ZXItQVMgb3B0aW9uIEIg d2l0aG91dA0KPj4gPiAgIHJlcXVpcmluZyBhbnkgYWRkaXRpb24gZnVuY3Rpb25hbGl0eSBpbiBB U0JScyBvciBQRXMuIEhvd2V2ZXIsIHRoZQ0KPj4gPiAgIG1hc3Mtd2l0aGRyYXcgZnVuY3Rpb25h bGl0eSBmYWxscyBiYWNrIGZyb20gcGVyLUVTIG1vZGUgdG8gcGVyLUVWSQ0KPj4gPiAgIG1vZGUg Zm9yIGludGVyLUFTIG9wdGlvbiBCIC0gaS5lLiwgUEVzIHJlY2VpdmluZyBtYXNzLXdpdGhkcmF3 IHJvdXRlDQo+PiA+ICAgZnJvbSB0aGUgc2FtZSBBUyB1c2UgRXRoZXIgQS1EIHBlciBFUyByb3V0 ZTsgd2hlcmVhcywgUEVzIHJlY2VpdmluZw0KPj4gPiAgIG1hc3Mtd2l0aGRyYXcgcm91dGUgZnJv bSBkaWZmZXJlbnQgQVMgdXNlIEV0aGVyIEEtRCBwZXIgRVZJIHJvdXRlLg0KPj4gPg0KPj4gPlRo ZXJlIGhhdmUgYmVlbiBsb3Qgb2YgZGlzY3Vzc2lvbnMgb24gdGhpcyAtIG9mZmxpbmUgYW5kIGlu IFlva29oYW1hDQo+PiA+KGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk0L3NsaWRl cy9zbGlkZXMtOTQtYmVzcy0xLnBkZikuIFRoZQ0KPj4gPmFib3ZlIHRleHQgZG9lcyBub3QgcmVm bGVjdCB0aGUgY29uc2Vuc3VzIGFtb25nIHNvbWUgb2YgdXMgYW5kIGluDQo+PiA+cGFydGljdWxh ciBkb2VzIG5vdCByZWZsZWN0IHdoYXQgd2FzIHByZXNlbnRlZCBpbiBZb2tvaGFtYS4NCj4+ID4N Cj4+ID5UaGVyZSBhcmUgdHdvIGlzc3VlcyB3aXRoIGludGVyLWFzIG9wdGlvbiBCIGFzIGN1cnJl bnRseSBzcGVjaWZpZWQgaW4NCj4+UkZDDQo+PiA+NzQzMi4NCj4+ID4NCj4+ID5BIG1pbm9yIGlz c3VlIGlzIHRoYXQgbWFzcy13aXRoZHJhdyBkZWdyYWRlcyBmcm9tIHBlciBFUyB0byBmcm9tIHBl cg0KPj4oRVMsDQo+PiA+RVZJKSAod2l0aCB0aGUgY2xhcmlmaWNhdGlvbiBpbiB0aGlzIG92ZXJs YXkgZHJhZnQpLCB3aGljaCB3b3VsZCBub3QNCj4+ID5leGlzdCBpZiB0aGUgbWFpbiBpc3N1ZSBp cyByZXNvbHZlZCBhcyBwcmVzZW50ZWQgaW4gWW9rb2hhbWEuDQo+PiA+DQo+PiA+VGhlIG1haW4g b25lIGlzIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnQgaW4gUkZDIDc0MzI6DQo+PiA+DQo+PiA+ ICAgTm90ZSB0aGF0IHRoZSBFdGhlcm5ldCBBLUQgcGVyIEVWSSByb3V0ZSBtYXkgYmUgcmVjZWl2 ZWQgYnkgYSByZW1vdGUNCj4+ID4gICBQRSBiZWZvcmUgaXQgcmVjZWl2ZXMgdGhlIHNldCBvZiBF dGhlcm5ldCBBLUQgcGVyIEVTIHJvdXRlcy4NCj4+ID4gICBUaGVyZWZvcmUsIGluIG9yZGVyIHRv IGhhbmRsZSBjb3JuZXIgY2FzZXMgYW5kIHJhY2UgY29uZGl0aW9ucywgdGhlDQo+PiA+ICAgRXRo ZXJuZXQgQS1EIHBlciBFVkkgcm91dGUgTVVTVCBOT1QgYmUgdXNlZCBmb3IgdHJhZmZpYyBmb3J3 YXJkaW5nDQo+PmJ5DQo+PiA+ICAgYSByZW1vdGUgUEUgdW50aWwgaXQgYWxzbyByZWNlaXZlcyB0 aGUgYXNzb2NpYXRlZCBzZXQgb2YgRXRoZXJuZXQNCj4+QS1EDQo+PiA+ICAgcGVyIEVTIHJvdXRl cy4NCj4+ID4NCj4+ID5CYXNpY2FsbHksIHRoZSBwZXItRVZJIEEtRCByb3V0ZXMgY2Fubm90IGJl IHVzZWQgYmVmb3JlIHRoZQ0KPj5jb3JyZXNwb25kaW5nDQo+PiA+cGVyLUVTIEEtRCByb3V0ZXMg YXJlIHJlY2VpdmVkIGFuZCBhc3NvY2lhdGVkLiBFaXRoZXIgdGhhdCByZXF1aXJlbWVudA0KPj4g Pm11c3QgYmUgcmVtb3ZlZCwgb3IgdGhlcmUgbXVzdCBiZSBhIHdheSB0byBhc3NvY2lhdGUgdGhl IHBlci1FUyByb3V0ZXMNCj4+ID5hbmQgcGVyLUVWSSByb3V0ZXMgZnJvbSB0aGUgc2FtZSBQRS4N Cj4+ID4NCj4+ID5UaGVyZSBpcyBhbiBlYXN5IHNvbHV0aW9uIHRvIHRoZSBsYXR0ZXIsIHdoaWNo IHdhcyBwcmVzZW50ZWQgaW4NCj4+WW9rb2hhbWENCj4+ID4oaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTQvc2xpZGVzL3NsaWRlcy05NC1iZXNzLTEucGRmKS4gVGhhdA0KPj4gPmRv ZXMgcmVxdWlyZSBhIGJlZWZlZCB1cCByZXF1aXJlbWVudDogdGhlIHJvdXRlcyBmcm9tIHRoZSBz YW1lIFBFIE1VU1QNCj4+ID5oYXZlIHRoZSBzYW1lIGdsb2JhbCBhZG1pbiBmaWVsZCBpbiB0aGUg UkRzLiBUaGF0IHNob3VsZCBiZSByZWFzb25hYmxlLA0KPj4gPmFuZCBSRkMgYWxyZWFkeSB1c2Vz IFJFQ09NTUVORCBrZXl3b3JkOg0KPj4gPg0KPj4gPjcuOS4gIFJvdXRlIERpc3Rpbmd1aXNoZXIg QXNzaWdubWVudCBwZXIgTUFDLVZSRg0KPj4gPg0KPj4gPiAgIFRoZSBSb3V0ZSBEaXN0aW5ndWlz aGVyIChSRCkgTVVTVCBiZSBzZXQgdG8gdGhlIFJEIG9mIHRoZSBNQUMtVlJGDQo+PiA+ICAgdGhh dCBpcyBhZHZlcnRpc2luZyB0aGUgTkxSSS4gIEFuIFJEIE1VU1QgYmUgYXNzaWduZWQgZm9yIGEg Z2l2ZW4NCj4+ID4gICBNQUMtVlJGIG9uIGEgUEUuICBUaGlzIFJEIE1VU1QgYmUgdW5pcXVlIGFj cm9zcyBhbGwgTUFDLVZSRnMgb24gYQ0KPj5QRS4NCj4+ID4gICBJdCBpcyBSRUNPTU1FTkRFRCB0 byB1c2UgdGhlIFR5cGUgMSBSRCBbUkZDNDM2NF0uICBUaGUgdmFsdWUgZmllbGQNCj4+ID4gICBj b21wcmlzZXMgYW4gSVAgYWRkcmVzcyBvZiB0aGUgUEUgKHR5cGljYWxseSwgdGhlIGxvb3BiYWNr IGFkZHJlc3MpDQo+PiA+ICAgZm9sbG93ZWQgYnkgYSBudW1iZXIgdW5pcXVlIHRvIHRoZSBQRS4N Cj4+ID4NCj4+ID5Ob3RpY2UgdGhlICJSRUNPTU1FTkQiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGgu DQo+PiA+DQo+PiA+OC40LjEuICBDb25zdHJ1Y3RpbmcgRXRoZXJuZXQgQS1EIHBlciBFVlBOIElu c3RhbmNlIFJvdXRlDQo+PiA+ICAgLi4uDQo+PiA+ICAgVGhlIFJvdXRlIERpc3Rpbmd1aXNoZXIg KFJEKSBNVVNUIGJlIHNldCBwZXIgU2VjdGlvbiA3LjkuDQo+PiA+DQo+PiA+OC4yLjEuICBDb25z dHJ1Y3RpbmcgRXRoZXJuZXQgQS1EIHBlciBFdGhlcm5ldCBTZWdtZW50IFJvdXRlDQo+PiA+ICAg Li4uDQo+PiA+ICAgVGhlIFJvdXRlIERpc3Rpbmd1aXNoZXIgKFJEKSBNVVNUIGJlIGEgVHlwZSAx IFJEIFtSRkM0MzY0XS4gIFRoZQ0KPj4gPiAgIHZhbHVlIGZpZWxkIGNvbXByaXNlcyBhbiBJUCBh ZGRyZXNzIG9mIHRoZSBQRSAodHlwaWNhbGx5LCB0aGUNCj4+ID4gICBsb29wYmFjayBhZGRyZXNz KSBmb2xsb3dlZCBieSBhIG51bWJlciB1bmlxdWUgdG8gdGhlIFBFLg0KPj4gPg0KPj4gPkFzIGxv bmcgYXMgOC40LjEgb3IgNy45IHNheXMgVHlwZSAxIFJEIE1VU1QgYmUgdXNlZCwgdGhlbiBhbGwg dGhlDQo+PiA+cHJvYmxlbXMgYXJlIHNvbHZlZC4gV2hpbGUgUkZDIDc0MzIgZGlkIG5vdCB1c2Ug TVVTVCwgSSBkb3VidCB0aGVyZSBpcw0KPj4gPmFueSBpbXBsZW1lbnRhdGlvbiBub3QgdXNpbmcg YSBUeXBlIDEgUkQgZm9yIHRoZSBwZXItRVZJIHJvdXRlLg0KPj4gPg0KPj4gPkplZmZyZXkNCj4+ ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPkJFU1MgbWFpbGluZyBsaXN0DQo+PiA+QkVTU0BpZXRmLm9yZw0KPj4gPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVzcw0KPg0KDQo= From nobody Wed Jun 15 01:39:06 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 C5E7C12D195 for ; Wed, 15 Jun 2016 01:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EecBUOH6fEGI for ; Wed, 15 Jun 2016 01:39:04 -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 E3CA412D0CB for ; Wed, 15 Jun 2016 01:39:03 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9A830A2DBD7BE for ; Wed, 15 Jun 2016 08:38:59 +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 u5F8d1Uv028681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Jun 2016 08:39:01 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 u5F8ctdC022133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 15 Jun 2016 10:39:00 +0200 Received: from [135.224.207.229] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 15 Jun 2016 10:38:58 +0200 Message-ID: <57611422.7030005@alcatel-lucent.com> Date: Wed, 15 Jun 2016 10:38:58 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <574C626E.2070801@alcatel-lucent.com> In-Reply-To: <574C626E.2070801@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Subject: [bess] Extended poll [Re: Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02] X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 08:39:06 -0000 All, as a heads-up an IPR disclosure has been made recently: https://datatracker.ietf.org/ipr/2807/ I'll give this call one more week. For those who haven't expressed their opinion, please do so. -m Le 30/05/2016 17:55, Martin Vigoureux a écrit : > Hello working group, > > This email starts a two-week poll on adopting > draft-dolganow-bess-mvpn-expl-track-02 [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 13th of June*. > > 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-dolganow-bess-mvpn-expl-track > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Wed Jun 15 02:24:23 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 3C441127078; Wed, 15 Jun 2016 02:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K9YiWmRshxU8; Wed, 15 Jun 2016 02:24:20 -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 6190012D529; Wed, 15 Jun 2016 02:24:18 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 97F74B69944CD; Wed, 15 Jun 2016 09:24:16 +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 u5F9OHgV031373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jun 2016 09:24:17 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 u5F9OGO4005703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jun 2016 09:24:17 GMT Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.234]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Wed, 15 Jun 2016 05:24:16 -0400 From: "Dolganow, Andrew (Nokia - SG)" To: "draft-dolganow-bess-mvpn-expl-track@ietf.org" Thread-Topic: IPR Disclosure Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track Thread-Index: AQHRxb0ODTPTK4nSJ0iez329D14zRp/rDQ0A Date: Wed, 15 Jun 2016 09:24:15 +0000 Message-ID: References: <20160613214633.6787.26967.idtracker@ietfa.amsl.com> In-Reply-To: <20160613214633.6787.26967.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-ID: <87413C5F3A1B67498482DE84EDB1A823@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Vigoureux, Martin \(Nokia - FR\)" , "bess@ietf.org" Subject: Re: [bess] IPR Disclosure Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 09:24:22 -0000 All, Please note that this should cover the IPR disclosures I followed up on as per my earlier email to the list. I am not aware of any other undisclosed IPRs. Andrew On 2016-06-14, 5:46 AM, "IETF Secretariat" wrote: >Dear Andrew Dolganow, Jayant Kotalwar, Eric C. Rosen, Zhaohui (Jeffrey) >Zhang: > > >An IPR disclosure that pertains to your Internet-Draft entitled "Explicit >Tracking with Wild Card Routes in Multicast VPN" >(draft-dolganow-bess-mvpn-expl-track) was submitted to the IETF >Secretariat on=20 >and has been posted on the "IETF Page of Intellectual Property Rights >Disclosures" (https://datatracker.ietf.org/ipr/2807/). The title of the >IPR >disclosure is "Alcatel-Lucent's Statement about IPR related to >draft-dolganow-bess-mvpn-expl-track" > > >Thank you > >IETF Secretariat From nobody Wed Jun 15 03:54: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 D77F012B064 for ; Wed, 15 Jun 2016 03:54:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 goMGDFZATKp7 for ; Wed, 15 Jun 2016 03:54:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D950412D094 for ; Wed, 15 Jun 2016 03:54: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=nKfHRiCWqJ7fFNDNNbnucN9Ol4jSvisTZ3XHUJyuGMk=; b=H6uNGBWAunHROSA7zTERhmccO+j+mycpc3l5PoHe0Q0HsPQUx36Tgcz7dMgcPM7Ee1oWyKx833iYQuR/atDKzxAOPZk5gJBwv4DFSlP+xTnv8gkvMV3JGAQi5fSxeiG79xFf3dmJRzBo/G1j+YYjzEPEsA5zcQD+danmdFcjk88= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 15 Jun 2016 10:54:22 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0517.014; Wed, 15 Jun 2016 10:54:21 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Ali Sajassi (sajassi)" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AdHDTr6Q1IW0rlKIThic0r80jZklFgCmjRqAAAzxJGAAK5X5gAAIt4MA Date: Wed, 15 Jun 2016 10:54:21 +0000 Message-ID: References: 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: 3915fe5a-b02c-4098-1ede-08d3950b686f x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 6:xbB4Gh3SLLhorDTzhtVGL06PeRfzse35fzg48thh8wfB90L+0LhdL2bv3mpt8ipT3azB5ZLWOwm/izfb5lKRWpacg1xMpS6WxUiUBquUFPaAAwiapv34fRMaQihoR3AaJqpamY9OoRuaO4n5JENw+UVUKCjj1Rn3piPMVfDCaxtaM/ZMQZtWjTVBTUVxjmKsZNqeDGHbx39rcdweCtcPFkclHagJMyG3h3e3y14zGP7X2M++oJlcefCPNK8NEGp4RKaDF8xlHkyVe0P/lt9bjQLnkQ0Nj+NLc9ta4QABqlEcVpyHf97llO4fUSTcNbjYhwpbP5mO4NBvIs1ybMTwlg==; 5:WC4avLIbLAncuGh9F4Y2tERwa1WVEAqVkykxyJx4mh1Ta/5vBO5GpZkdChqCfWyG3mB/sXWYyGNOHif+uDgC3I8KgMPYOB16SMqS8Uf9KyO40OK2SFZ2nSx40h7Oz1F/5FKn6SGx9jwGJpSMnqMK0A==; 24:JFPwomslfeg5WKE6WIsAYucfKR6mfInxsx6j/nDFd7TwZjgaMRym55AryOVK+bNiNXXTKyZKOKbaDmZX1j0wQnv/WuRfwFQbTSC4RZw6hCM=; 7:lLd0sZgiFhoZ+KG18PTnWFE/UuZmOakLnsaFXETh+WBfavhevf4ZNHc9kBaAz3KeDUIZYFqEwBP2wWFNhusUZVsMUJJRNEJgOpm4qXiZUeOl2N5Qf8pnO6roUr76mYZoDiU5ppD/P18nyVF0DG1ErMG84KuKEHU/aCfLRWFvy0+yXenfCgNZS215wjH4rXXZIc1XVMceQ1YaFK8bV8e6v4TwQfySIVZyuxFrDAo86Xo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(13464003)(101416001)(2900100001)(2950100001)(99286002)(10400500002)(3280700002)(8936002)(2501003)(81166006)(8676002)(5004730100002)(2906002)(77096005)(81156014)(15975445007)(5008740100001)(33656002)(87936001)(68736007)(3846002)(97736004)(5001770100001)(19580405001)(5003600100002)(230783001)(74316001)(19580395003)(102836003)(6116002)(106356001)(50986999)(54356999)(76176999)(189998001)(122556002)(105586002)(86362001)(3660700001)(586003)(93886004)(9686002)(92566002)(107886002)(76576001)(5002640100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2016 10:54:21.7413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 10:54:44 -0000 Hi Ali, > -----Original Message----- > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > Sent: Wednesday, June 15, 2016 1:59 AM > To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > Inter-AS Option B >=20 >=20 > Hi Jeffrey, >=20 > On 6/14/16, 2:44 AM, "Jeffrey (Zhaohui) Zhang" wrote= : >=20 > >Hi Ali, > > > >> -----Original Message----- > >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > >> Sent: Monday, June 13, 2016 11:01 PM > >> To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > >> Cc: Ali Sajassi (sajassi) > >> Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > >> Inter-AS Option B > >> > >> > >> Hi Jeffrey, > >> > >> A few points: > >> > >> 1) There have been lots of discussions on this topic but you were not > in > >> attendance for some of them including the ones held at the last IETF i= n > >> Bones Aires. So, before jumping into a haste conclusion that there wer= e > >> not consensus on section 10, please check with your own colleagues who > >> participated in those meetings. > >> > >> 2) Regarding the current text in section 10: this text is consistent > >>with > >> the one that was checked for IETF at Yokohama and it is also consisten= t > >> with RFC 7432 operation. We still require Eth A-D per ES in order to > >> validate Eth A-d per EVI, the only difference is that the mass-withdra= w > >> doesn=B9t work (i.e., route validation still works). > > > >Could the document clarify how the validation is done - how do you > >conclude that a per-ES route and a per-EVI route are related? If I > >understand it correctly, if the correlation can be done, then > >mass-withdraw works. > > > >That is the key of the issue that is missing from the document. >=20 > It has been described in 4th paragraph of section 10.2.2: >=20 > "Now, when the AC between the PE2 and the CE fails and PE2 sends NLRI > withdrawal for Ether A-D per ES route and this withdrawal gets > propagated and received by the PE3, the BGP process in PE3 removes > the corresponding BGP route; however, it doesn't remove the > associated info (namely ESI and BGP next hop) from the L2 routing > table (L2 RIB) because it still has the other Ether A-D per ES route > (originated from PE1) with the same info. That is why the mass- > withdraw mechanism does not work when doing DCI with inter-AS option > B. However, as described previoulsy, the aliasing function works and > so does "mass-withdraw per EVI" (which is associated with withdrawing > the EVPN route associated with Aliasing - i.e., Ether A-D per EVI > route)." The above describes why only "mass-withdraw per EVI" works. The main proble= m is NOT with that. It's with the following in RFC 7432 as I mentioned init= ially in this thread: > >> > Note that the Ethernet A-D per EVI route may be received by a remo= te > >> > PE before it receives the set of Ethernet A-D per ES routes. > >> > Therefore, in order to handle corner cases and race conditions, th= e > >> > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding= by > >> > a remote PE until it also receives the associated set of Ethernet = A-D > >> > per ES routes. For the aliasing part, how do you tell if a per-ES route and a per-EVI rout= e are from the same PE? If you cannot tell, then the above validation canno= t be done. If we assume that they always have the same global admin field in the RDs, = then the correlation can be done similar to how you associate the per-EVI r= oute and mac routes as you clarified; but when I first proposed this soluti= on when the option-B issue was brought up, people were saying that RFC 7432= does NOT require the per-ES route and per-EVI route have the same global a= dmin field in the RDs, because: - per-EVI route uses per-mac-vrf RD, which is RECOMMENDED to use type-1 (no= t MUST), with "typically the lookback address". - per-ES route MUST uses a type-1 RD with "typically the loopback address". Note that there is no explicit requirement/guarantee that the two will have= the same global admin field in the RDs. If we put that explicit requiremen= t in, then the problem is solved; and with that, mass-withdraw per ES also = works. Please note that it is not me who is splitting hair here. It is other peopl= e who were saying that RFC does not require they have the same global admin= field. So if we take this opportunity to tighten up the language, then we have an = "easy solution" that always works (more below on that), and it removes hair= splitting arguments from some people. >=20 > > > >> > >> 3) Your so-called =B3easy solution=B2 doesn=B9t work in all scenarios = so > there > >> is no point in documenting something that works sometimes :-) If you > >> recall several years ago, we went to great length to accommodate > >> multi-homing across multiple AS=B9s and that=B9s why we added originat= ing > >> router=B9s IP address to the ES route. The 4 byte field in RD type-1, = is > a > >> router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is > unique > >> within an AS only. Thus the suggested solution won=B9t work when a CE = is > >> dual-homed to two PEs in two different AS=B9s. > > > >If those two PEs happen to have the same router-id, and they happen to > >choose the same local admin field for the RD, e.g. vlan id as section 7.= 9 > >of RFC 7432 says: > > > > The value field > > comprises an IP address of the PE (typically, the loopback address) > > followed by a number unique to the PE. This number may be generated > > by the PE. Or, in the Unique VLAN EVPN case, the low-order 12 bits > > may be the 12-bit VLAN ID, with the remaining high-order 4 bits set > > to 0. > > > >How do you distinguish the two routes from the PEs? There is no way to > >guarantee it "always works" even if you don't use vlan-id. >=20 > In such scenarios, the ASBRs perform RD (and RT) translation; however, th= e > translated RD no longer needs to be of type-1. We discussed this before as well - as long as the RD translation ensures th= at routes with the same global admin field in the RDs continue to have the = same global admin field that is different from those in routes from differe= nt PEs, then the "easy solution" still works. If it is not practical to hav= e different admin field for routes from different PEs after translation, th= en the following requirement cannot be satisfied: Note that the Ethernet A-D per EVI route may be received by a remote PE before it receives the set of Ethernet A-D per ES routes. Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. BTW - now that you say after translation the RD no longer needs to be of ty= pe-1, is there any reason to require type-1 at all, even when there is no i= nter-AS option B? Jeffrey >=20 > > > >> > >> We are currently separately documenting a proper solution based on a > new > >> sub-TLV added to the attribute in idr-tunnel-encap draft to identify > the > >> originating PE. A solution based on this attribute will work for all > >> scenarios. Now the question is what to do in short term. We can either > >>go > >> with the text that it is in section 10.2 of the evpn-overlay draft, > plus > >> go with the new draft, or just go with the new draft and remove the > >> suggested solution in section 10.2. I am open to both. > > > >Multi-homing across ASes (or any segmentation points) is complicated. > >I've spent quite some cycles on it - in particular split horizon becomes > >more complicated (I documented it in initial unpublished version of > >draft-zzhang-bess-evpn-bum-procedure-updates but then removed it). I > >would like to be included in the relevant discussions on the new documen= t. >=20 > Sure, we can definitely consider it. >=20 > Cheers, > Ali >=20 > > > >If we can say "multi-homing across ASes" is out of scope for now, then > >the overlay draft can certainly clarify inter-as optin B procedure > >(especially on how the correlation is done). Otherwise, I'd suggest to > >remove section 10.2. It is NOT specific to overlay anyway. > > > >Jeffrey > > > >> > >> Cheers, > >> Ali > >> > >> > >> > >> > >> > >> > >> > >> On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > >> wrote: > >> > >> >I want to bring up an old discussion about the following: > >> > > >> > In summary, it can be seen that aliasing (and backup path) > >> > functionality should work as is for inter-AS option B without > >> > requiring any addition functionality in ASBRs or PEs. However, the > >> > mass-withdraw functionality falls back from per-ES mode to per-EVI > >> > mode for inter-AS option B - i.e., PEs receiving mass-withdraw > route > >> > from the same AS use Ether A-D per ES route; whereas, PEs receivin= g > >> > mass-withdraw route from different AS use Ether A-D per EVI route. > >> > > >> >There have been lot of discussions on this - offline and in Yokohama > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). Th= e > >> >above text does not reflect the consensus among some of us and in > >> >particular does not reflect what was presented in Yokohama. > >> > > >> >There are two issues with inter-as option B as currently specified in > >>RFC > >> >7432. > >> > > >> >A minor issue is that mass-withdraw degrades from per ES to from per > >>(ES, > >> >EVI) (with the clarification in this overlay draft), which would not > >> >exist if the main issue is resolved as presented in Yokohama. > >> > > >> >The main one is the following requirement in RFC 7432: > >> > > >> > Note that the Ethernet A-D per EVI route may be received by a > remote > >> > PE before it receives the set of Ethernet A-D per ES routes. > >> > Therefore, in order to handle corner cases and race conditions, th= e > >> > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding > >>by > >> > a remote PE until it also receives the associated set of Ethernet > >>A-D > >> > per ES routes. > >> > > >> >Basically, the per-EVI A-D routes cannot be used before the > >>corresponding > >> >per-ES A-D routes are received and associated. Either that requiremen= t > >> >must be removed, or there must be a way to associate the per-ES route= s > >> >and per-EVI routes from the same PE. > >> > > >> >There is an easy solution to the latter, which was presented in > >>Yokohama > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). > That > >> >does require a beefed up requirement: the routes from the same PE MUS= T > >> >have the same global admin field in the RDs. That should be reasonabl= e, > >> >and RFC already uses RECOMMEND keyword: > >> > > >> >7.9. Route Distinguisher Assignment per MAC-VRF > >> > > >> > The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF > >> > that is advertising the NLRI. An RD MUST be assigned for a given > >> > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on a > >>PE. > >> > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field > >> > comprises an IP address of the PE (typically, the loopback address= ) > >> > followed by a number unique to the PE. > >> > > >> >Notice the "RECOMMEND" in the above paragraph. > >> > > >> >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > >> > ... > >> > The Route Distinguisher (RD) MUST be set per Section 7.9. > >> > > >> >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > >> > ... > >> > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The > >> > value field comprises an IP address of the PE (typically, the > >> > loopback address) followed by a number unique to the PE. > >> > > >> >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the > >> >problems are solved. While RFC 7432 did not use MUST, I doubt there i= s > >> >any implementation not using a Type 1 RD for the per-EVI route. > >> > > >> >Jeffrey > >> > > >> >_______________________________________________ > >> >BESS mailing list > >> >BESS@ietf.org > >> >https://www.ietf.org/mailman/listinfo/bess > > From nobody Wed Jun 15 05:47:41 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 5221812D5C9 for ; Wed, 15 Jun 2016 05:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.426, 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 d-KTa-3FK-nQ for ; Wed, 15 Jun 2016 05:47:30 -0700 (PDT) Received: from p-mail2.rd.orange.com (p-mail2.rd.orange.com [161.106.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id 66C8112D533 for ; Wed, 15 Jun 2016 05:47:30 -0700 (PDT) Received: from p-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 95164E300E5; Wed, 15 Jun 2016 14:47:29 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail2.rd.orange.com (Postfix) with ESMTP id 39330E300E4; Wed, 15 Jun 2016 14:47:29 +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.279.2; Wed, 15 Jun 2016 14:47:28 +0200 To: John E Drake , "Rabadan, Jorge (Nokia - US)" , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> From: Thomas Morin Organization: Orange Message-ID: <31d2c99b-de11-9e3c-fae9-2d60017c3090@orange.com> Date: Wed, 15 Jun 2016 14:47:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [bess] draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:47:40 -0000 Hi John, Ali, Through the discussion below it appeared that section 9 and section 5.1.3 needed adjustments to be brought in sync, and indeed there were some changes in last revision. However, I don't think the cleanup/precision is complete yet: - section 5.1.3 says "the MPLS label field in the [...] Inclusive Multicast Ethernet Tag routes is used to carry the VNI" although the "Inclusive Multicast Ethernet Tag Route" has no "MPLS label field" - (directly related to the above) none of these section talks about using the MPLS field of the PMSI Tunnel Attribute as the VNI, although the discussion below concluded that it is what implementations actually do - also, section 9 now says "The Ethernet Tag field of this route is set as described in section 5.1.3.", but I find this sentence useless and redundant (precisely because 5.1.3 already says it and nothing would indicate that section 9 would be exempt of what 5.1.3 says) Additionally, it occurred to me that "the MPLS field" is not, strictly speaking, unambiguous for MAC Advertisement routes, because the route actually has two MPLS fields. The text should just say "MPLS Label1 field" for the MAC/IP advertisement route. Best, -Thomas 2016-05-04, John E Drake: > Jorge, > > We put the VNI value in the MPLS label field of the PMSI attribute for all service types, and we put a value in the Ethernet Tag field following the rules for each service type as described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section-5.1.3). > > You're right that we need to clean up section 9. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] >> Sent: Wednesday, May 04, 2016 3:53 PM >> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; draft-ietf-bess-evpn- >> overlay@tools.ietf.org; Ali Sajassi (sajassi) >> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps >> >> Hi John, >> >> About this: >> >> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we need >> to ask everyone whether they used the Ethernet Tag or the PMSI attribute to carry the VNI >> >> >> In case it helps, I’ve seen a few implementations running and they all encode the VNI in the >> MPLS label field in the PTA. And a couple of them, encode the VNI in the ethernet-tag, in >> addition to the MPLS label in the PTA. In any case, I think section 9 contradicts section 5.1.3 >> and should be clarified. >> >> "5.1.3 Constructing EVPN BGP Routes >> >> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, and **Inclusive >> Multicast Ethernet Tag** routes is used to carry the VNI or VSID." >> >> Thanks. >> Jorge >> >> >> >> >> >> On 5/4/16, 8:34 PM, "EXT John E Drake" wrote: >> >>> Thomas and Jorge, >>> >>> Snipped, comments inline. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>>> >>>>> draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP >>>>> Encapsulation extended to encode the tunnel encap to use for BUM >>>>> traffic, but contrary to other E-VPN routes, relies on the Ethernet >>>>> Tag field of the NLRI to encode the VNI/VSID. >>>> >>>> [JORGE] This is certainly a leftover from an old version where the >>>> VNI/VSID was encoded in the ethernet tag for all the routes. The VNI >>>> should be encoded in the Label field in all the routes. This has to be corrected. >>>> >>>> In fact, section 5.1.3 says: >>>> >>>> 5.1.3 Constructing EVPN BGP Routes >>>> >>>> >>>> >>>> Accordingly, and >>>> specifically to support the option of locally assigned VNIs, the MPLS >>>> label field in the MAC Advertisement, Ethernet AD per EVI, and >>>> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or >>>> VSID. For the balance of this memo, the MPLS label field will be >>>> referred to as the VNI/VSID field. The VNI/VSID field is used for >>>> both local and global VNIs/VSIDs, and for either case the entire 24- >>>> bit field is used to encode the VNI/VSID value. >>>> >>>> >>> >>> >>> [JD] For the IMET route the MPLS label field is carried in the PMSI attribute. I think we >> need to ask everyone whether they >>> used the Ethernet Tag or the PMSI attribute to carry the VNI >>> >>> >>>>>> >>>>>> There are minor things that could be improved in >>>>>> draft-ietf-bess-evpn-overlay wrt. consistency with >>>>>> draft-ietf-idr-tunnel-encaps : >>>>>> >>>>>> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it >>>>>> would be better that draft-ietf-bess-evpn-overlay refers to >>>>>> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. >>>> >>>> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the >>>> encapsulation extended community. There are a few implementations >>>> using this community and it is enough when only the encapsulation type is needed. >>> >>> >>> [JD] I agree and the tunnel encaps draft does keep the EC >>> >>> >>>> >>>>>> >>>>>> * I think it would be better to avoid the explicit list of encap >>>>>> types in section 5.1.3, and rather refer to >>>>>> draft-ietf-idr-tunnel-encaps instead >>>> >>>> [JORGE] I agree. >>> >>> >>> [JD] According to IANA, it allocated the five tunnels types to the >>> overlay draft so I think we need to keep them >>> >>> >>>> >>>>>> * the following minor modification was proposed, but not yet incorporated: >>>>>> >>>>>> John Drake, 2015-11-13 (to BESS ML): >>>>>>> For the overlay draft, replace this text in section 5.1.3: >>>>>>> >>>>>>> "If the BGP Encapsulation extended community is not present, >>>>>>> then the default MPLS encapsulation or a statically configured >>>>>>> encapsulation is assumed." >>>>>>> >>>>>>> With the following: >>>>>>> >>>>>>> "Note that the MPLS encapsulation tunnel type is needed in >>>>>>> order to distinguish between an advertising node that only >>>>>>> supports non-MPLS encapsulations and one that supports MPLS and >>>>>>> non-MPLS encapsulations. An advertising node that only supports >>>>>>> MPLS encapsulation does not need to advertise any encapsulation >>>>>>> tunnel types; i.e., if the BGP Encapsulation extended community >>>>>>> is not present, then either MPLS encapsulation or a statically >>>>>>> configured encapsulation is assumed." >>>>>> >>>>>> I think this change is useful and should be incorporated, although >>>>>> skipping the last sentence would be wise if the full list of >>>>>> tunnel types is removed. >>> >>> >>> [JD] Fine with me either w/ or w/o the last sentence >>> >>> From nobody Wed Jun 15 07:22: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 DF5B012D7BA for ; Wed, 15 Jun 2016 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 2pqu8NVNyk1V for ; Wed, 15 Jun 2016 07:21:52 -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 E96EB12B035 for ; Wed, 15 Jun 2016 07:21:51 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A09205D89AC; Wed, 15 Jun 2016 16:21:50 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 962DC5D8925; Wed, 15 Jun 2016 16:21:50 +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.279.2; Wed, 15 Jun 2016 16:21:50 +0200 To: John E Drake , "Rabadan, Jorge (Nokia - US)" , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <31d2c99b-de11-9e3c-fae9-2d60017c3090@orange.com> From: Thomas Morin Organization: Orange Message-ID: <5980f27a-32f1-25d5-a64c-3786f88d3f69@orange.com> Date: Wed, 15 Jun 2016 16:21:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [bess] draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:21:58 -0000 Sounds good. Thanks, -Thomas 2016-06-15, John E Drake: > Thomas, > > Comments inline. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Thomas Morin [mailto:thomas.morin@orange.com] >> Sent: Wednesday, June 15, 2016 8:47 AM >> To: John E Drake; Rabadan, Jorge (Nokia - US); BESS; draft-ietf-bess-evpn- >> overlay@tools.ietf.org; Ali Sajassi (sajassi) >> Subject: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf- >> bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) >> >> Hi John, Ali, >> >> Through the discussion below it appeared that section 9 and section >> 5.1.3 needed adjustments to be brought in sync, and indeed there were some changes in >> last revision. >> >> However, I don't think the cleanup/precision is complete yet: >> - section 5.1.3 says "the MPLS label field in the [...] Inclusive Multicast Ethernet Tag routes is >> used to carry the VNI" although the "Inclusive Multicast Ethernet Tag Route" has no "MPLS >> label field" >> - (directly related to the above) none of these section talks about using the MPLS field of >> the PMSI Tunnel Attribute as the VNI, although the discussion below concluded that it is >> what implementations actually do > > > [JD] Accordingly, and specifically to support the option of locally assigned VNIs, the MPLS label1 field in the MAC Advertisement route, the MPLS label field in the Ethernet AD per EVI route, and the MPLS label field in the PMSI Tunnel Attribute of the Inclusive Multicast Ethernet Tag route are used to carry the VNI. > > >> - also, section 9 now says "The Ethernet Tag field of this route is set as described in section >> 5.1.3.", but I find this sentence useless and redundant (precisely because 5.1.3 already says >> it and nothing would indicate that section 9 would be exempt of what 5.1.3 says) > > > [JD] We should strike the sentence. > > >> >> Additionally, it occurred to me that "the MPLS field" is not, strictly speaking, unambiguous >> for MAC Advertisement routes, because the route actually has two MPLS fields. The text >> should just say "MPLS Label1 field" for the MAC/IP advertisement route. > > > [JD] See above. > > >> >> Best, >> >> -Thomas >> >> >> 2016-05-04, John E Drake: >>> Jorge, >>> >>> We put the VNI value in the MPLS label field of the PMSI attribute for all service types, >> and we put a value in the Ethernet Tag field following the rules for each service type as >> described in 5.1.3 (https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02#section- >> 5.1.3). >>> >>> You're right that we need to clean up section 9. >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: Rabadan, Jorge (Nokia - US) [mailto:jorge.rabadan@nokia.com] >>>> Sent: Wednesday, May 04, 2016 3:53 PM >>>> To: John E Drake; EXT - thomas.morin@orange.com; BESS; IDR; >>>> draft-ietf-bess-evpn- overlay@tools.ietf.org; Ali Sajassi (sajassi) >>>> Subject: Re: [Idr] draft-ietf-bess-evpn-overlay vs. >>>> draft-ietf-idr-tunnel-encaps >>>> >>>> Hi John, >>>> >>>> About this: >>>> >>>> [JD] For the IMET route the MPLS label field is carried in the PMSI >>>> attribute. I think we need to ask everyone whether they used the >>>> Ethernet Tag or the PMSI attribute to carry the VNI >>>> >>>> >>>> In case it helps, I’ve seen a few implementations running and they >>>> all encode the VNI in the MPLS label field in the PTA. And a couple >>>> of them, encode the VNI in the ethernet-tag, in addition to the MPLS >>>> label in the PTA. In any case, I think section 9 contradicts section 5.1.3 and should be >> clarified. >>>> >>>> "5.1.3 Constructing EVPN BGP Routes >>>> >>>> the MPLS label field in the MAC Advertisement, Ethernet AD per EVI, >>>> and **Inclusive Multicast Ethernet Tag** routes is used to carry the VNI or VSID." >>>> >>>> Thanks. >>>> Jorge >>>> >>>> >>>> >>>> >>>> >>>> On 5/4/16, 8:34 PM, "EXT John E Drake" wrote: >>>> >>>>> Thomas and Jorge, >>>>> >>>>> Snipped, comments inline. >>>>> >>>>> Yours Irrespectively, >>>>> >>>>> John >>>>> >>>>>>> >>>>>>> draft-ietf-bess-evpn-overlay (see section 9) relies on the BGP >>>>>>> Encapsulation extended to encode the tunnel encap to use for BUM >>>>>>> traffic, but contrary to other E-VPN routes, relies on the >>>>>>> Ethernet Tag field of the NLRI to encode the VNI/VSID. >>>>>> >>>>>> [JORGE] This is certainly a leftover from an old version where the >>>>>> VNI/VSID was encoded in the ethernet tag for all the routes. The >>>>>> VNI should be encoded in the Label field in all the routes. This has to be corrected. >>>>>> >>>>>> In fact, section 5.1.3 says: >>>>>> >>>>>> 5.1.3 Constructing EVPN BGP Routes >>>>>> >>>>>> >>>>>> >>>>>> Accordingly, and >>>>>> specifically to support the option of locally assigned VNIs, the MPLS >>>>>> label field in the MAC Advertisement, Ethernet AD per EVI, and >>>>>> Inclusive Multicast Ethernet Tag routes is used to carry the VNI or >>>>>> VSID. For the balance of this memo, the MPLS label field will be >>>>>> referred to as the VNI/VSID field. The VNI/VSID field is used for >>>>>> both local and global VNIs/VSIDs, and for either case the entire 24- >>>>>> bit field is used to encode the VNI/VSID value. >>>>>> >>>>>> >>>>> >>>>> >>>>> [JD] For the IMET route the MPLS label field is carried in the PMSI >>>>> attribute. I think we >>>> need to ask everyone whether they >>>>> used the Ethernet Tag or the PMSI attribute to carry the VNI >>>>> >>>>> >>>>>>>> >>>>>>>> There are minor things that could be improved in >>>>>>>> draft-ietf-bess-evpn-overlay wrt. consistency with >>>>>>>> draft-ietf-idr-tunnel-encaps : >>>>>>>> >>>>>>>> * since draft-ietf-idr-tunnel-encaps will deprecate RFC5512, it >>>>>>>> would be better that draft-ietf-bess-evpn-overlay refers to >>>>>>>> draft-ietf-idr-tunnel-encaps and not anymore to RFC5512. >>>>>> >>>>>> [JORGE] I agree, as long as draft-ietf-idr-tunnel-encaps keeps the >>>>>> encapsulation extended community. There are a few implementations >>>>>> using this community and it is enough when only the encapsulation type is needed. >>>>> >>>>> >>>>> [JD] I agree and the tunnel encaps draft does keep the EC >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>> * I think it would be better to avoid the explicit list of encap >>>>>>>> types in section 5.1.3, and rather refer to >>>>>>>> draft-ietf-idr-tunnel-encaps instead >>>>>> >>>>>> [JORGE] I agree. >>>>> >>>>> >>>>> [JD] According to IANA, it allocated the five tunnels types to the >>>>> overlay draft so I think we need to keep them >>>>> >>>>> >>>>>> >>>>>>>> * the following minor modification was proposed, but not yet incorporated: >>>>>>>> >>>>>>>> John Drake, 2015-11-13 (to BESS ML): >>>>>>>>> For the overlay draft, replace this text in section 5.1.3: >>>>>>>>> >>>>>>>>> "If the BGP Encapsulation extended community is not present, >>>>>>>>> then the default MPLS encapsulation or a statically configured >>>>>>>>> encapsulation is assumed." >>>>>>>>> >>>>>>>>> With the following: >>>>>>>>> >>>>>>>>> "Note that the MPLS encapsulation tunnel type is needed in >>>>>>>>> order to distinguish between an advertising node that only >>>>>>>>> supports non-MPLS encapsulations and one that supports MPLS and >>>>>>>>> non-MPLS encapsulations. An advertising node that only >>>>>>>>> supports MPLS encapsulation does not need to advertise any >>>>>>>>> encapsulation tunnel types; i.e., if the BGP Encapsulation >>>>>>>>> extended community is not present, then either MPLS >>>>>>>>> encapsulation or a statically configured encapsulation is assumed." >>>>>>>> >>>>>>>> I think this change is useful and should be incorporated, >>>>>>>> although skipping the last sentence would be wise if the full >>>>>>>> list of tunnel types is removed. >>>>> >>>>> >>>>> [JD] Fine with me either w/ or w/o the last sentence >>>>> >>>>> > From nobody Wed Jun 15 07:22:27 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 1BB9C12D783 for ; Wed, 15 Jun 2016 07:22:26 -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=unavailable 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 y2aujh5PJf1P for ; Wed, 15 Jun 2016 07:22:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BEB12D621 for ; Wed, 15 Jun 2016 07:13:51 -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=+kiv5+kYxOx5qKdA7rG8xxC1T5YIb4oWtlygf8Kc2mA=; b=Iko35H1MH/OPZwEbNZwpgxJbvCwzSIxqXPT8PVnNrE9zwEWjG2vTIXpkCUq/85yHSUYvT+uWdGjadP6sc1vXobR6JK5x8ff6m4aT430FYykNfh3Swm7RaT19/IuTwGRpXwxh+xML1e6W/zG7NE1lwbIAl0AOUQQU0uN9E7BKLAU= Received: from BY2PR05MB2310.namprd05.prod.outlook.com (10.166.112.148) by BY2PR05MB2309.namprd05.prod.outlook.com (10.166.112.147) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 15 Jun 2016 14:13:49 +0000 Received: from BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) by BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) with mapi id 15.01.0517.014; Wed, 15 Jun 2016 14:13:49 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , "Rabadan, Jorge (Nokia - US)" , BESS , "draft-ietf-bess-evpn-overlay@tools.ietf.org" , "Ali Sajassi (sajassi)" Thread-Topic: draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) Thread-Index: AQHRxwQV9ZoNUfpEM0iF6gUSP1rAXJ/qj2Zg Date: Wed, 15 Jun 2016 14:13:49 +0000 Message-ID: References: <5729F1C3.1030605@orange.com> <5729F7C5.6040604@orange.com> <52D35106-ED5E-4C95-9131-6EA4527370D5@alcatel-lucent.com> <012C176C-A8D6-45AA-BA69-616C0ED7E41E@alcatel-lucent.com> <31d2c99b-de11-9e3c-fae9-2d60017c3090@orange.com> In-Reply-To: <31d2c99b-de11-9e3c-fae9-2d60017c3090@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 15af0077-7732-40c9-f185-08d3952745c4 x-microsoft-exchange-diagnostics: 1; BY2PR05MB2309; 6:YmoXsOXVHpUCJIFYEC3OZUjeLvpgpcDez880Pto9Q7quPeunUHGVUnYhCXkACcHnR4B+8zaEqSPKt5nVmFnkwniqzTwpOtYd37JdvR/xb93o9HL2BMSd7n5Xh+eylQ+E18E240SAJAxrM09tXHkojF4otAkdOFxWxNiIYcyfRizduAgtHxW7xH/oZdtW79MPCXQLxskw2AWNEc8zwfEOl37ApOtQLhlVg86wisUK3/yxvQ0E0cE4eC35Wmux8MEx5MaZC/RHuNcsTtZTKawEeRFj70v7CeS5Q+gLBtP2VeobGJ20H12AW3sdHXTu1MC6KSo/Ljlxzi2f5Bg2MyjFwA==; 5:7+aoy60ztP4fLm3u/tIOM4uNO1V+3NA7l+xjE3FIjrDik/jLa8qEyUb9txZ7lDVOWsbUHPY+iGuAKFSNkiKTVFeq6LaPZBMf3RiPc3NE80ImKwUtaox5xXGBqdIqm4NE5NbDsIp4JxyAMhRDIu03Ag==; 24:Ve1FwA5r+ECCsGNRZQxlSOIze2tcntYI3EvYY8uPtisejPgT9kl6ox+jwgYiYjAyuZZxKSe7p/2h1xjS7dGBHetA+zW++pTqhltMnlOCHEA=; 7:UMDiKIQeoyGJ4ubCzRvM+nhvDC+ZyH5OO0ldVPO1prmrM0zva1+H3E5YIdy3afLN9TyKkkodCDTFpLihZElIFqWRMI77q86UoBdxL9JyAd07MmuKSLexLnEiRMNj6Qnmb5ohfj6UFUczXsiYFNx23OfxONx5zT+/R/YoQp4DNUmDHO+Vrbn03ypVIqS1o8hkWEw46oaBmz4piVhd5aORtUqujpsF+zWERwzKUr/s9JY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2309; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(788757137089)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR05MB2309; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2309; x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(13464003)(377424004)(377454003)(189002)(19580405001)(5003600100002)(74316001)(19580395003)(230783001)(33656002)(87936001)(97736004)(5001770100001)(4001150100001)(68736007)(3846002)(102836003)(6116002)(93886004)(9686002)(92566002)(586003)(5002640100001)(66066001)(107886002)(76576001)(11100500001)(189998001)(106116001)(106356001)(50986999)(54356999)(76176999)(3660700001)(122556002)(105586002)(86362001)(3280700002)(10400500002)(101416001)(2900100001)(2950100001)(99286002)(5008740100001)(15975445007)(81156014)(77096005)(2906002)(8676002)(5004730100002)(8936002)(2501003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2309; H:BY2PR05MB2310.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2016 14:13:49.5469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2309 Archived-At: Subject: Re: [bess] draft-ietf-bess-evpn-overlay / section 5.1.3 vs. section 9 (was Re: [Idr] draft-ietf-bess-evpn-overlay vs. draft-ietf-idr-tunnel-encaps) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:22:26 -0000 VGhvbWFzLA0KDQpDb21tZW50cyBpbmxpbmUuDQoNCllvdXJzIElycmVzcGVjdGl2ZWx5LA0KDQpK b2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGhvbWFzIE1vcmlu IFttYWlsdG86dGhvbWFzLm1vcmluQG9yYW5nZS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVu ZSAxNSwgMjAxNiA4OjQ3IEFNDQo+IFRvOiBKb2huIEUgRHJha2U7IFJhYmFkYW4sIEpvcmdlIChO b2tpYSAtIFVTKTsgQkVTUzsgZHJhZnQtaWV0Zi1iZXNzLWV2cG4tDQo+IG92ZXJsYXlAdG9vbHMu aWV0Zi5vcmc7IEFsaSBTYWphc3NpIChzYWphc3NpKQ0KPiBTdWJqZWN0OiBkcmFmdC1pZXRmLWJl c3MtZXZwbi1vdmVybGF5IC8gc2VjdGlvbiA1LjEuMyB2cy4gc2VjdGlvbiA5ICh3YXMgUmU6IFtJ ZHJdIGRyYWZ0LWlldGYtDQo+IGJlc3MtZXZwbi1vdmVybGF5IHZzLiBkcmFmdC1pZXRmLWlkci10 dW5uZWwtZW5jYXBzKQ0KPiANCj4gSGkgSm9obiwgQWxpLA0KPiANCj4gVGhyb3VnaCB0aGUgZGlz Y3Vzc2lvbiBiZWxvdyBpdCBhcHBlYXJlZCB0aGF0IHNlY3Rpb24gOSBhbmQgc2VjdGlvbg0KPiA1 LjEuMyBuZWVkZWQgYWRqdXN0bWVudHMgdG8gYmUgYnJvdWdodCBpbiBzeW5jLCBhbmQgaW5kZWVk IHRoZXJlIHdlcmUgc29tZSBjaGFuZ2VzIGluDQo+IGxhc3QgcmV2aXNpb24uDQo+IA0KPiBIb3dl dmVyLCBJIGRvbid0IHRoaW5rIHRoZSBjbGVhbnVwL3ByZWNpc2lvbiBpcyBjb21wbGV0ZSB5ZXQ6 DQo+IC0gc2VjdGlvbiA1LjEuMyBzYXlzICJ0aGUgTVBMUyBsYWJlbCBmaWVsZCBpbiB0aGUgWy4u Ll0gSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91dGVzIGlzDQo+IHVzZWQgdG8g Y2FycnkgdGhlIFZOSSIgYWx0aG91Z2ggdGhlICJJbmNsdXNpdmUgTXVsdGljYXN0IEV0aGVybmV0 IFRhZyBSb3V0ZSIgaGFzIG5vICJNUExTDQo+IGxhYmVsIGZpZWxkIg0KPiAtIChkaXJlY3RseSBy ZWxhdGVkIHRvIHRoZSBhYm92ZSkgbm9uZSBvZiB0aGVzZSBzZWN0aW9uIHRhbGtzIGFib3V0IHVz aW5nIHRoZSBNUExTIGZpZWxkIG9mDQo+IHRoZSBQTVNJIFR1bm5lbCBBdHRyaWJ1dGUgYXMgdGhl IFZOSSwgYWx0aG91Z2ggdGhlIGRpc2N1c3Npb24gYmVsb3cgY29uY2x1ZGVkIHRoYXQgaXQgaXMN Cj4gd2hhdCBpbXBsZW1lbnRhdGlvbnMgYWN0dWFsbHkgZG8NCg0KDQpbSkRdIEFjY29yZGluZ2x5 LCBhbmQgc3BlY2lmaWNhbGx5IHRvIHN1cHBvcnQgdGhlIG9wdGlvbiBvZiBsb2NhbGx5IGFzc2ln bmVkIFZOSXMsIHRoZSBNUExTIGxhYmVsMSBmaWVsZCBpbiB0aGUgTUFDIEFkdmVydGlzZW1lbnQg cm91dGUsIHRoZSBNUExTIGxhYmVsIGZpZWxkIGluIHRoZSBFdGhlcm5ldCBBRCBwZXIgRVZJIHJv dXRlLCBhbmQgdGhlIE1QTFMgbGFiZWwgZmllbGQgaW4gdGhlIFBNU0kgVHVubmVsIEF0dHJpYnV0 ZSBvZiB0aGUgSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhlcm5ldCBUYWcgcm91dGUgYXJlIHVzZWQg dG8gY2FycnkgdGhlIFZOSS4NCg0KDQo+IC0gYWxzbywgc2VjdGlvbiA5IG5vdyBzYXlzICJUaGUg RXRoZXJuZXQgVGFnIGZpZWxkIG9mIHRoaXMgcm91dGUgaXMgc2V0IGFzIGRlc2NyaWJlZCBpbiBz ZWN0aW9uDQo+IDUuMS4zLiIsIGJ1dCBJIGZpbmQgdGhpcyBzZW50ZW5jZSB1c2VsZXNzIGFuZCBy ZWR1bmRhbnQgKHByZWNpc2VseSBiZWNhdXNlIDUuMS4zIGFscmVhZHkgc2F5cw0KPiBpdCBhbmQg bm90aGluZyB3b3VsZCBpbmRpY2F0ZSB0aGF0IHNlY3Rpb24gOSB3b3VsZCBiZSBleGVtcHQgb2Yg d2hhdCA1LjEuMyBzYXlzKQ0KDQoNCltKRF0gIFdlIHNob3VsZCBzdHJpa2UgdGhlIHNlbnRlbmNl LiAgDQoNCg0KPiANCj4gQWRkaXRpb25hbGx5LCBpdCBvY2N1cnJlZCB0byBtZSB0aGF0ICJ0aGUg TVBMUyBmaWVsZCIgaXMgbm90LCBzdHJpY3RseSBzcGVha2luZywgdW5hbWJpZ3VvdXMNCj4gZm9y IE1BQyBBZHZlcnRpc2VtZW50IHJvdXRlcywgYmVjYXVzZSB0aGUgcm91dGUgYWN0dWFsbHkgaGFz IHR3byBNUExTIGZpZWxkcy4gIFRoZSB0ZXh0DQo+IHNob3VsZCBqdXN0IHNheSAiTVBMUyBMYWJl bDEgZmllbGQiIGZvciB0aGUgTUFDL0lQIGFkdmVydGlzZW1lbnQgcm91dGUuDQoNCg0KW0pEXSAg U2VlIGFib3ZlLg0KIA0KDQo+IA0KPiBCZXN0LA0KPiANCj4gLVRob21hcw0KPiANCj4gDQo+IDIw MTYtMDUtMDQsIEpvaG4gRSBEcmFrZToNCj4gPiBKb3JnZSwNCj4gPg0KPiA+IFdlIHB1dCB0aGUg Vk5JIHZhbHVlIGluIHRoZSBNUExTIGxhYmVsIGZpZWxkIG9mIHRoZSBQTVNJIGF0dHJpYnV0ZSBm b3IgYWxsIHNlcnZpY2UgdHlwZXMsDQo+IGFuZCB3ZSBwdXQgYSB2YWx1ZSBpbiB0aGUgRXRoZXJu ZXQgVGFnIGZpZWxkIGZvbGxvd2luZyB0aGUgcnVsZXMgZm9yIGVhY2ggc2VydmljZSB0eXBlIGFz DQo+IGRlc2NyaWJlZCBpbiA1LjEuMyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYmVzcy1ldnBuLW92ZXJsYXktMDIjc2VjdGlvbi0NCj4gNS4xLjMpLg0KPiA+DQo+ID4g WW91J3JlIHJpZ2h0IHRoYXQgd2UgbmVlZCB0byBjbGVhbiB1cCBzZWN0aW9uIDkuDQo+ID4NCj4g PiBZb3VycyBJcnJlc3BlY3RpdmVseSwNCj4gPg0KPiA+IEpvaG4NCj4gPg0KPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSYWJhZGFuLCBKb3JnZSAoTm9raWEgLSBV UykgW21haWx0bzpqb3JnZS5yYWJhZGFuQG5va2lhLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5 LCBNYXkgMDQsIDIwMTYgMzo1MyBQTQ0KPiA+PiBUbzogSm9obiBFIERyYWtlOyBFWFQgLSB0aG9t YXMubW9yaW5Ab3JhbmdlLmNvbTsgQkVTUzsgSURSOw0KPiA+PiBkcmFmdC1pZXRmLWJlc3MtZXZw bi0gb3ZlcmxheUB0b29scy5pZXRmLm9yZzsgQWxpIFNhamFzc2kgKHNhamFzc2kpDQo+ID4+IFN1 YmplY3Q6IFJlOiBbSWRyXSBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5IHZzLg0KPiA+PiBk cmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzDQo+ID4+DQo+ID4+IEhpIEpvaG4sDQo+ID4+DQo+ ID4+IEFib3V0IHRoaXM6DQo+ID4+DQo+ID4+IFtKRF0gRm9yIHRoZSBJTUVUIHJvdXRlIHRoZSBN UExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBNU0kNCj4gPj4gYXR0cmlidXRlLiBJ IHRoaW5rIHdlIG5lZWQgdG8gYXNrIGV2ZXJ5b25lIHdoZXRoZXIgdGhleSB1c2VkIHRoZQ0KPiA+ PiBFdGhlcm5ldCBUYWcgb3IgdGhlIFBNU0kgYXR0cmlidXRlIHRvIGNhcnJ5IHRoZSBWTkkNCj4g Pj4NCj4gPj4NCj4gPj4gSW4gY2FzZSBpdCBoZWxwcywgSeKAmXZlIHNlZW4gYSBmZXcgaW1wbGVt ZW50YXRpb25zIHJ1bm5pbmcgYW5kIHRoZXkNCj4gPj4gYWxsIGVuY29kZSB0aGUgVk5JIGluIHRo ZSBNUExTIGxhYmVsIGZpZWxkIGluIHRoZSBQVEEuIEFuZCBhIGNvdXBsZQ0KPiA+PiBvZiB0aGVt LCBlbmNvZGUgdGhlIFZOSSBpbiB0aGUgZXRoZXJuZXQtdGFnLCBpbiBhZGRpdGlvbiB0byB0aGUg TVBMUw0KPiA+PiBsYWJlbCBpbiB0aGUgUFRBLiBJbiBhbnkgY2FzZSwgSSB0aGluayBzZWN0aW9u IDkgY29udHJhZGljdHMgc2VjdGlvbiA1LjEuMyBhbmQgc2hvdWxkIGJlDQo+IGNsYXJpZmllZC4N Cj4gPj4NCj4gPj4gIjUuMS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCj4gPj4gPHNu aXA+DQo+ID4+IHRoZSBNUExTIGxhYmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwg RXRoZXJuZXQgQUQgcGVyIEVWSSwNCj4gPj4gYW5kICoqSW5jbHVzaXZlIE11bHRpY2FzdCBFdGhl cm5ldCBUYWcqKiByb3V0ZXMgaXMgdXNlZCB0byBjYXJyeSB0aGUgVk5JIG9yIFZTSUQuIg0KPiA+ Pg0KPiA+PiBUaGFua3MuDQo+ID4+IEpvcmdlDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+IE9uIDUvNC8xNiwgODozNCBQTSwgIkVYVCBKb2huIEUgRHJha2UiIDxqZHJha2VAanVu aXBlci5uZXQ+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4gVGhvbWFzIGFuZCBKb3JnZSwNCj4gPj4+DQo+ ID4+PiBTbmlwcGVkLCBjb21tZW50cyBpbmxpbmUuDQo+ID4+Pg0KPiA+Pj4gWW91cnMgSXJyZXNw ZWN0aXZlbHksDQo+ID4+Pg0KPiA+Pj4gSm9obg0KPiA+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gZHJh ZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSAoc2VlIHNlY3Rpb24gOSkgcmVsaWVzIG9uIHRoZSBC R1ANCj4gPj4+Pj4gRW5jYXBzdWxhdGlvbiBleHRlbmRlZCB0byBlbmNvZGUgdGhlIHR1bm5lbCBl bmNhcCB0byB1c2UgZm9yIEJVTQ0KPiA+Pj4+PiB0cmFmZmljLCBidXQgY29udHJhcnkgdG8gb3Ro ZXIgRS1WUE4gcm91dGVzLCByZWxpZXMgb24gdGhlDQo+ID4+Pj4+IEV0aGVybmV0IFRhZyBmaWVs ZCBvZiB0aGUgTkxSSSB0byBlbmNvZGUgdGhlIFZOSS9WU0lELg0KPiA+Pj4+DQo+ID4+Pj4gW0pP UkdFXSBUaGlzIGlzIGNlcnRhaW5seSBhIGxlZnRvdmVyIGZyb20gYW4gb2xkIHZlcnNpb24gd2hl cmUgdGhlDQo+ID4+Pj4gVk5JL1ZTSUQgd2FzIGVuY29kZWQgaW4gdGhlIGV0aGVybmV0IHRhZyBm b3IgYWxsIHRoZSByb3V0ZXMuIFRoZQ0KPiA+Pj4+IFZOSSBzaG91bGQgYmUgZW5jb2RlZCBpbiB0 aGUgTGFiZWwgZmllbGQgaW4gYWxsIHRoZSByb3V0ZXMuIFRoaXMgaGFzIHRvIGJlIGNvcnJlY3Rl ZC4NCj4gPj4+Pg0KPiA+Pj4+IEluIGZhY3QsIHNlY3Rpb24gNS4xLjMgc2F5czoNCj4gPj4+Pg0K PiA+Pj4+IDUuMS4zIENvbnN0cnVjdGluZyBFVlBOIEJHUCBSb3V0ZXMNCj4gPj4+Pg0KPiA+Pj4+ IDxzbmlwPg0KPiA+Pj4+DQo+ID4+Pj4gQWNjb3JkaW5nbHksIGFuZA0KPiA+Pj4+ICAgIHNwZWNp ZmljYWxseSB0byBzdXBwb3J0IHRoZSBvcHRpb24gb2YgbG9jYWxseSBhc3NpZ25lZCBWTklzLCB0 aGUgTVBMUw0KPiA+Pj4+ICAgIGxhYmVsIGZpZWxkIGluIHRoZSBNQUMgQWR2ZXJ0aXNlbWVudCwg RXRoZXJuZXQgQUQgcGVyIEVWSSwgYW5kDQo+ID4+Pj4gICAgSW5jbHVzaXZlIE11bHRpY2FzdCBF dGhlcm5ldCBUYWcgcm91dGVzIGlzIHVzZWQgdG8gY2FycnkgdGhlIFZOSSBvcg0KPiA+Pj4+ICAg IFZTSUQuICBGb3IgdGhlIGJhbGFuY2Ugb2YgdGhpcyBtZW1vLCB0aGUgTVBMUyBsYWJlbCBmaWVs ZCB3aWxsIGJlDQo+ID4+Pj4gICAgcmVmZXJyZWQgdG8gYXMgdGhlIFZOSS9WU0lEIGZpZWxkLiBU aGUgVk5JL1ZTSUQgZmllbGQgaXMgdXNlZCBmb3INCj4gPj4+PiAgICBib3RoIGxvY2FsIGFuZCBn bG9iYWwgVk5Jcy9WU0lEcywgYW5kIGZvciBlaXRoZXIgY2FzZSB0aGUgZW50aXJlIDI0LQ0KPiA+ Pj4+ICAgIGJpdCBmaWVsZCBpcyB1c2VkIHRvIGVuY29kZSB0aGUgVk5JL1ZTSUQgdmFsdWUuDQo+ ID4+Pj4NCj4gPj4+PiA8c25pcD4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gW0pEXSAgRm9yIHRoZSBJ TUVUIHJvdXRlIHRoZSBNUExTIGxhYmVsIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIFBNU0kNCj4g Pj4+IGF0dHJpYnV0ZS4gIEkgdGhpbmsgd2UNCj4gPj4gbmVlZCB0byBhc2sgZXZlcnlvbmUgd2hl dGhlciB0aGV5DQo+ID4+PiB1c2VkIHRoZSBFdGhlcm5ldCBUYWcgb3IgdGhlIFBNU0kgYXR0cmli dXRlIHRvIGNhcnJ5IHRoZSBWTkkNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRo ZXJlIGFyZSBtaW5vciB0aGluZ3MgdGhhdCBjb3VsZCBiZSBpbXByb3ZlZCBpbg0KPiA+Pj4+Pj4g ZHJhZnQtaWV0Zi1iZXNzLWV2cG4tb3ZlcmxheSB3cnQuIGNvbnNpc3RlbmN5IHdpdGgNCj4gPj4+ Pj4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMgOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICog c2luY2UgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyB3aWxsIGRlcHJlY2F0ZSBSRkM1NTEy LCBpdA0KPiA+Pj4+Pj4gd291bGQgYmUgYmV0dGVyIHRoYXQgZHJhZnQtaWV0Zi1iZXNzLWV2cG4t b3ZlcmxheSByZWZlcnMgdG8NCj4gPj4+Pj4+IGRyYWZ0LWlldGYtaWRyLXR1bm5lbC1lbmNhcHMg YW5kIG5vdCBhbnltb3JlIHRvIFJGQzU1MTIuDQo+ID4+Pj4NCj4gPj4+PiBbSk9SR0VdIEkgYWdy ZWUsIGFzIGxvbmcgYXMgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2FwcyBrZWVwcyB0aGUNCj4g Pj4+PiBlbmNhcHN1bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eS4gVGhlcmUgYXJlIGEgZmV3IGlt cGxlbWVudGF0aW9ucw0KPiA+Pj4+IHVzaW5nIHRoaXMgY29tbXVuaXR5IGFuZCBpdCBpcyBlbm91 Z2ggd2hlbiBvbmx5IHRoZSBlbmNhcHN1bGF0aW9uIHR5cGUgaXMgbmVlZGVkLg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBbSkRdICAgSSBhZ3JlZSBhbmQgdGhlIHR1bm5lbCBlbmNhcHMgZHJhZnQgZG9l cyBrZWVwIHRoZSBFQw0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAq IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGF2b2lkIHRoZSBleHBsaWNpdCBsaXN0IG9m IGVuY2FwDQo+ID4+Pj4+PiB0eXBlcyBpbiBzZWN0aW9uIDUuMS4zLCBhbmQgcmF0aGVyIHJlZmVy IHRvDQo+ID4+Pj4+PiBkcmFmdC1pZXRmLWlkci10dW5uZWwtZW5jYXBzIGluc3RlYWQNCj4gPj4+ Pg0KPiA+Pj4+IFtKT1JHRV0gSSBhZ3JlZS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gW0pEXSAgQWNj b3JkaW5nIHRvIElBTkEsIGl0IGFsbG9jYXRlZCB0aGUgZml2ZSB0dW5uZWxzIHR5cGVzIHRvIHRo ZQ0KPiA+Pj4gb3ZlcmxheSBkcmFmdCBzbyBJIHRoaW5rIHdlIG5lZWQgdG8ga2VlcCB0aGVtDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+Pj4gKiB0aGUgZm9sbG93aW5nIG1pbm9yIG1vZGlm aWNhdGlvbiB3YXMgcHJvcG9zZWQsIGJ1dCBub3QgeWV0IGluY29ycG9yYXRlZDoNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAgICAgSm9obiBEcmFrZSwgMjAxNS0xMS0xMyAodG8gQkVTUyBNTCk6DQo+ID4+ Pj4+Pj4gICAgIEZvciB0aGUgb3ZlcmxheSBkcmFmdCwgcmVwbGFjZSB0aGlzIHRleHQgaW4gc2Vj dGlvbiA1LjEuMzoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICAiSWYgdGhlIEJHUCBFbmNhcHN1 bGF0aW9uIGV4dGVuZGVkIGNvbW11bml0eSBpcyBub3QgcHJlc2VudCwNCj4gPj4+Pj4+PiB0aGVu IHRoZSBkZWZhdWx0IE1QTFMgZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2FsbHkgY29uZmlndXJl ZA0KPiA+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gaXMgYXNzdW1lZC4iDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiAgICAgV2l0aCB0aGUgZm9sbG93aW5nOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICJO b3RlIHRoYXQgdGhlIE1QTFMgZW5jYXBzdWxhdGlvbiB0dW5uZWwgdHlwZSBpcyBuZWVkZWQgaW4N Cj4gPj4+Pj4+PiBvcmRlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIGFuIGFkdmVydGlzaW5nIG5v ZGUgdGhhdCBvbmx5DQo+ID4+Pj4+Pj4gc3VwcG9ydHMgbm9uLU1QTFMgZW5jYXBzdWxhdGlvbnMg YW5kIG9uZSB0aGF0IHN1cHBvcnRzIE1QTFMgYW5kDQo+ID4+Pj4+Pj4gbm9uLU1QTFMgZW5jYXBz dWxhdGlvbnMuICBBbiAgYWR2ZXJ0aXNpbmcgbm9kZSB0aGF0IG9ubHkNCj4gPj4+Pj4+PiBzdXBw b3J0cyBNUExTIGVuY2Fwc3VsYXRpb24gZG9lcyBub3QgbmVlZCB0byBhZHZlcnRpc2UgYW55DQo+ ID4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiB0dW5uZWwgdHlwZXM7ICBpLmUuLCAgaWYgdGhlIEJHUCBF bmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4gZXh0ZW5kZWQgY29tbXVuaXR5IGlzIG5vdCBwcmVzZW50 LCB0aGVuIGVpdGhlciBNUExTDQo+ID4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBvciBhIHN0YXRpY2Fs bHkgY29uZmlndXJlZCBlbmNhcHN1bGF0aW9uIGlzIGFzc3VtZWQuIg0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgaW5jb3Jwb3Jh dGVkLA0KPiA+Pj4+Pj4gYWx0aG91Z2ggc2tpcHBpbmcgdGhlIGxhc3Qgc2VudGVuY2Ugd291bGQg YmUgd2lzZSBpZiB0aGUgZnVsbA0KPiA+Pj4+Pj4gbGlzdCBvZiB0dW5uZWwgdHlwZXMgaXMgcmVt b3ZlZC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gW0pEXSAgRmluZSB3aXRoIG1lIGVpdGhlciB3LyBv ciB3L28gdGhlIGxhc3Qgc2VudGVuY2UNCj4gPj4+DQo+ID4+Pg0KDQo= From jayant.kotalwar@nokia.com Wed Jun 15 07:33:49 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 4673212D692; Wed, 15 Jun 2016 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewJY40ZpIRyA; Wed, 15 Jun 2016 07:33:47 -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 8080B12D669; Wed, 15 Jun 2016 07:33:47 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 33A393608668C; Wed, 15 Jun 2016 14:33:44 +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 u5FEXk5X030678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jun 2016 14:33:46 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 u5FEXa1O023773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Jun 2016 14:33:46 GMT Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.176]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 15 Jun 2016 10:33:40 -0400 From: "Kotalwar, Jayant (Nokia - US)" To: "Dolganow, Andrew (Nokia - SG)" , "draft-dolganow-bess-mvpn-expl-track@ietf.org" Thread-Topic: IPR Disclosure Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track Thread-Index: AQHRxb0OnIIRssIKo0eiP1gK8w4nw5/qhvKAgAATSnA= Date: Wed, 15 Jun 2016 14:33:40 +0000 Message-ID: References: <20160613214633.6787.26967.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 15 Jun 2016 08:08:27 -0700 Cc: "Vigoureux, Martin \(Nokia - FR\)" , "bess@ietf.org" Subject: Re: [bess] IPR Disclosure Alcatel-Lucent's Statement about IPR related to draft-dolganow-bess-mvpn-expl-track X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 14:34:50 -0000 I am not aware of any other ipr than the one disclosed on the bess mailing = list. --Jayant -----Original Message----- From: Dolganow, Andrew (Nokia - SG) [mailto:andrew.dolganow@nokia.com]=20 Sent: Wednesday, June 15, 2016 2:24 AM To: draft-dolganow-bess-mvpn-expl-track@ietf.org Cc: bess@ietf.org; Vigoureux, Martin (Nokia - FR) Subject: Re: IPR Disclosure Alcatel-Lucent's Statement about IPR related to= draft-dolganow-bess-mvpn-expl-track All, Please note that this should cover the IPR disclosures I followed up on as = per my earlier email to the list. I am not aware of any other undisclosed I= PRs. Andrew On 2016-06-14, 5:46 AM, "IETF Secretariat" wrote: >Dear Andrew Dolganow, Jayant Kotalwar, Eric C. Rosen, Zhaohui (Jeffrey) >Zhang: > > >An IPR disclosure that pertains to your Internet-Draft entitled=20 >"Explicit Tracking with Wild Card Routes in Multicast VPN" >(draft-dolganow-bess-mvpn-expl-track) was submitted to the IETF=20 >Secretariat on and has been posted on the "IETF Page of Intellectual=20 >Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2807/).=20 >The title of the IPR disclosure is "Alcatel-Lucent's Statement about=20 >IPR related to draft-dolganow-bess-mvpn-expl-track" > > >Thank you > >IETF Secretariat From nobody Wed Jun 15 10:26: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 C08FB12DA66 for ; Wed, 15 Jun 2016 10:26:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Wns4NNJFd7Nq for ; Wed, 15 Jun 2016 10:26:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F011E12D83F for ; Wed, 15 Jun 2016 10:26: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=aJOgGCQqFhDKVvgb8Eh6OywwXZRISxvsWK0PKO0uBUk=; b=hyS5SdfDwQr2xp8bBOF+SYEZQIQk3p+EQ/jH/rAs+bYVNHdiTAv1e5uUB0OCGULiG0xCE/tJYRFnaPc6Hc1pIDNJbUknu+8WXHuKRbySiFegpExKylPxMYibJEcfa/agx6S3NnI40MqW/eCYFrhlrO6gDsOTiboWj1q7Xa8NA2Y= Received: from BY2PR05MB2310.namprd05.prod.outlook.com (10.166.112.148) by BY2PR05MB1989.namprd05.prod.outlook.com (10.163.32.155) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 15 Jun 2016 17:26:25 +0000 Received: from BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) by BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) with mapi id 15.01.0517.014; Wed, 15 Jun 2016 17:26:25 +0000 From: John E Drake To: "Jeffrey (Zhaohui) Zhang" , "Ali Sajassi (sajassi)" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AQHRxej3vgRr1akMcUy+MU/s0pIr/p/otuqAgAFTYoCAAFJsgIAAbJRA Date: Wed, 15 Jun 2016 17:26:25 +0000 Message-ID: References: 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=jdrake@juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 4171372e-0ac9-45a1-f85f-08d395422d8e x-microsoft-exchange-diagnostics: 1; BY2PR05MB1989; 6:xo+5+8+oHDqhuueIyB4NGfaO5s90p1afvEg31K6imv7LLs8UwDldn7BvM7CVL9yiqG7/lUv2XM5eY0zvZA+DQxSrhHgev1uZNto5gEayNkgd+cNB1bKRYFHpBF0lf07PZmqbzjcfEuuSJsENETsIGfKJX0iE4xzeuQwR1MyO9djBrArxeLbL/rvQuJKd9+/RKe3oGjE56dZctg3UpASIZBAViSQNg53/0jDxvU5H+X+VZ/HW3Fr+8dq/+NG0M4OTb26zWbQJzWvYAGPu0fuJZicNC/4Wwnsu0pRWImGWE3eqLRsA9q54L6DnuiwQbSUT; 5:qwek8926njg1Hswv5x25YT6c3yQOBdQlOpmc7B1Y+UQcTA/2ASoEBw8losjvJNu0fFLEfF2wVScU8vYDdqciukSvYL8fFtIOZVf4FdPz/6BcFa7NggbBEIBOkeNgKTuTYTipD2C3WBb41bjttorzVw==; 24:HnZmwY8Q1XR9JfF6BE/pk9uwkb/il/5QkRMuV5EEyAuN5+nDVaqrEEN+j4sSiYmQMiEFEwtoyFxOcYJyI/f7SD5SyOSZC3pib38BH1ZALP0=; 7:B0jayyfJW/K5Rnoxd4hUgUDUyoz92Ew9ErDU4gF9F5aAqgPwnWV79NErFY1Q1L8695Ag+zrTmED/+eSOKBENjA6304SVEcOKJDGI0cLTp/mile+D3d9wUzuuN6uofDMd6V67Q5nBCERboEFQaVoncJkFZzEpr01geejbdX3VtAD1xp5/ZOkDfP2zquA987KJlNr5SY5uwkIIk1j/2e73gQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB1989; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB1989; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB1989; x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(13464003)(199003)(55674003)(2501003)(10400500002)(99286002)(2900100001)(5003600100002)(8936002)(2950100001)(68736007)(230783001)(5002640100001)(97736004)(106356001)(122556002)(19580395003)(19580405001)(101416001)(93886004)(4001430100002)(33656002)(106116001)(105586002)(54356999)(81156014)(81166006)(50986999)(586003)(5008740100001)(8676002)(76576001)(4326007)(86362001)(87936001)(2906002)(92566002)(3660700001)(5001770100001)(3846002)(3280700002)(9686002)(5004730100002)(66066001)(11100500001)(74316001)(1941001)(76176999)(107886002)(189998001)(102836003)(6116002)(15975445007)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB1989; H:BY2PR05MB2310.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2016 17:26:25.1824 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB1989 Archived-At: Cc: Ronald Bonica Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:26:46 -0000 Jeffrey, I don't think anyone would argue that the proper solution to per-ES mass wi= thdraw is to include the originating router's address in Ethernet AD and MA= C Advertisement routes and the only discussion is the best way to encode th= is information. Your suggestion of having an ingress PE use the RD field to get the origina= ting router's address has two issues: =20 1) RDs are known to be re-written by inter-provider ASBRs 2) An IPv6 router address will not fit in an RD Furthermore this is a fundamentally new behavior for an ingress PE and an i= mplementation would need to be changed to support it; no implementation of= which I am aware does this today. Given all of the above, the consensus is to include the originating router'= s address in the remote next-hop sub-TLV of the Encapsulation Attribute and= modify egress PEs to include it and ingress PEs to use it. This is a simp= le and incrementally deployable solution and in the meantime per-EVI mass w= ithdraw can be used. Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) = Zhang > Sent: Wednesday, June 15, 2016 6:54 AM > To: Ali Sajassi (sajassi); bess@ietf.org > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inte= r-AS Option B >=20 > Hi Ali, >=20 > > -----Original Message----- > > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > > Sent: Wednesday, June 15, 2016 1:59 AM > > To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > > Inter-AS Option B > > > > > > Hi Jeffrey, > > > > On 6/14/16, 2:44 AM, "Jeffrey (Zhaohui) Zhang" wro= te: > > > > >Hi Ali, > > > > > >> -----Original Message----- > > >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > > >> Sent: Monday, June 13, 2016 11:01 PM > > >> To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > > >> Cc: Ali Sajassi (sajassi) > > >> Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, > > >> wrt Inter-AS Option B > > >> > > >> > > >> Hi Jeffrey, > > >> > > >> A few points: > > >> > > >> 1) There have been lots of discussions on this topic but you were > > >> not > > in > > >> attendance for some of them including the ones held at the last > > >> IETF in Bones Aires. So, before jumping into a haste conclusion > > >> that there were not consensus on section 10, please check with your > > >> own colleagues who participated in those meetings. > > >> > > >> 2) Regarding the current text in section 10: this text is > > >>consistent with the one that was checked for IETF at Yokohama and > > >>it is also consistent with RFC 7432 operation. We still require Eth > > >>A-D per ES in order to validate Eth A-d per EVI, the only > > >>difference is that the mass-withdraw doesn=B9t work (i.e., route > > >>validation still works). > > > > > >Could the document clarify how the validation is done - how do you > > >conclude that a per-ES route and a per-EVI route are related? If I > > >understand it correctly, if the correlation can be done, then > > >mass-withdraw works. > > > > > >That is the key of the issue that is missing from the document. > > > > It has been described in 4th paragraph of section 10.2.2: > > > > "Now, when the AC between the PE2 and the CE fails and PE2 sends NLRI > > withdrawal for Ether A-D per ES route and this withdrawal gets > > propagated and received by the PE3, the BGP process in PE3 removes > > the corresponding BGP route; however, it doesn't remove the > > associated info (namely ESI and BGP next hop) from the L2 routing > > table (L2 RIB) because it still has the other Ether A-D per ES route > > (originated from PE1) with the same info. That is why the mass- > > withdraw mechanism does not work when doing DCI with inter-AS option > > B. However, as described previoulsy, the aliasing function works and > > so does "mass-withdraw per EVI" (which is associated with withdrawin= g > > the EVPN route associated with Aliasing - i.e., Ether A-D per EVI > > route)." >=20 > The above describes why only "mass-withdraw per EVI" works. The main prob= lem is NOT > with that. It's with the following in RFC 7432 as I mentioned initially i= n this thread: >=20 > > >> > Note that the Ethernet A-D per EVI route may be received by a re= mote > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > >> > Therefore, in order to handle corner cases and race conditions, = the > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic forwardi= ng by > > >> > a remote PE until it also receives the associated set of Etherne= t A-D > > >> > per ES routes. >=20 > For the aliasing part, how do you tell if a per-ES route and a per-EVI ro= ute are from the same > PE? If you cannot tell, then the above validation cannot be done. >=20 > If we assume that they always have the same global admin field in the RDs= , then the > correlation can be done similar to how you associate the per-EVI route an= d mac routes as > you clarified; but when I first proposed this solution when the option-B = issue was brought > up, people were saying that RFC 7432 does NOT require the per-ES route an= d per-EVI route > have the same global admin field in the RDs, because: >=20 > - per-EVI route uses per-mac-vrf RD, which is RECOMMENDED to use type-1 (= not MUST), > with "typically the lookback address". > - per-ES route MUST uses a type-1 RD with "typically the loopback address= ". >=20 > Note that there is no explicit requirement/guarantee that the two will ha= ve the same global > admin field in the RDs. If we put that explicit requirement in, then the = problem is solved; > and with that, mass-withdraw per ES also works. >=20 > Please note that it is not me who is splitting hair here. It is other peo= ple who were saying > that RFC does not require they have the same global admin field. >=20 > So if we take this opportunity to tighten up the language, then we have a= n "easy solution" > that always works (more below on that), and it removes hair splitting arg= uments from some > people. >=20 > > > > > > > >> > > >> 3) Your so-called =B3easy solution=B2 doesn=B9t work in all scenario= s so > > there > > >> is no point in documenting something that works sometimes :-) If > > >> you recall several years ago, we went to great length to > > >> accommodate multi-homing across multiple AS=B9s and that=B9s why we > > >> added originating router=B9s IP address to the ES route. The 4 byte > > >> field in RD type-1, is > > a > > >> router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is > > unique > > >> within an AS only. Thus the suggested solution won=B9t work when a C= E > > >> is dual-homed to two PEs in two different AS=B9s. > > > > > >If those two PEs happen to have the same router-id, and they happen > > >to choose the same local admin field for the RD, e.g. vlan id as > > >section 7.9 of RFC 7432 says: > > > > > > The value field > > > comprises an IP address of the PE (typically, the loopback address) > > > followed by a number unique to the PE. This number may be generate= d > > > by the PE. Or, in the Unique VLAN EVPN case, the low-order 12 bits > > > may be the 12-bit VLAN ID, with the remaining high-order 4 bits set > > > to 0. > > > > > >How do you distinguish the two routes from the PEs? There is no way > > >to guarantee it "always works" even if you don't use vlan-id. > > > > In such scenarios, the ASBRs perform RD (and RT) translation; however, > > the translated RD no longer needs to be of type-1. >=20 > We discussed this before as well - as long as the RD translation ensures = that routes with the > same global admin field in the RDs continue to have the same global admin= field that is > different from those in routes from different PEs, then the "easy solutio= n" still works. If it is > not practical to have different admin field for routes from different PEs= after translation, > then the following requirement cannot be satisfied: >=20 > Note that the Ethernet A-D per EVI route may be received by a remote > PE before it receives the set of Ethernet A-D per ES routes. > Therefore, in order to handle corner cases and race conditions, the > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by > a remote PE until it also receives the associated set of Ethernet A-D > per ES routes. >=20 > BTW - now that you say after translation the RD no longer needs to be of = type-1, is there > any reason to require type-1 at all, even when there is no inter-AS optio= n B? >=20 > Jeffrey >=20 > > > > > > > >> > > >> We are currently separately documenting a proper solution based on > > >> a > > new > > >> sub-TLV added to the attribute in idr-tunnel-encap draft to > > >> identify > > the > > >> originating PE. A solution based on this attribute will work for > > >>all scenarios. Now the question is what to do in short term. We can > > >>either go with the text that it is in section 10.2 of the > > >>evpn-overlay draft, > > plus > > >> go with the new draft, or just go with the new draft and remove the > > >> suggested solution in section 10.2. I am open to both. > > > > > >Multi-homing across ASes (or any segmentation points) is complicated. > > >I've spent quite some cycles on it - in particular split horizon > > >becomes more complicated (I documented it in initial unpublished > > >version of draft-zzhang-bess-evpn-bum-procedure-updates but then > > >removed it). I would like to be included in the relevant discussions o= n the new > document. > > > > Sure, we can definitely consider it. > > > > Cheers, > > Ali > > > > > > > >If we can say "multi-homing across ASes" is out of scope for now, > > >then the overlay draft can certainly clarify inter-as optin B > > >procedure (especially on how the correlation is done). Otherwise, I'd > > >suggest to remove section 10.2. It is NOT specific to overlay anyway. > > > > > >Jeffrey > > > > > >> > > >> Cheers, > > >> Ali > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > > >> wrote: > > >> > > >> >I want to bring up an old discussion about the following: > > >> > > > >> > In summary, it can be seen that aliasing (and backup path) > > >> > functionality should work as is for inter-AS option B without > > >> > requiring any addition functionality in ASBRs or PEs. However, t= he > > >> > mass-withdraw functionality falls back from per-ES mode to per-E= VI > > >> > mode for inter-AS option B - i.e., PEs receiving mass-withdraw > > route > > >> > from the same AS use Ether A-D per ES route; whereas, PEs receiv= ing > > >> > mass-withdraw route from different AS use Ether A-D per EVI rout= e. > > >> > > > >> >There have been lot of discussions on this - offline and in > > >> >Yokohama > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). > > >> >The above text does not reflect the consensus among some of us and = in particular > does not reflect what was presented in Yokohama. > > >> > > > >> >There are two issues with inter-as option B as currently specified > > >> >in > > >>RFC > > >> >7432. > > >> > > > >> >A minor issue is that mass-withdraw degrades from per ES to from > > >> >per > > >>(ES, > > >> >EVI) (with the clarification in this overlay draft), which would > > >> >not exist if the main issue is resolved as presented in Yokohama. > > >> > > > >> >The main one is the following requirement in RFC 7432: > > >> > > > >> > Note that the Ethernet A-D per EVI route may be received by a > > remote > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > >> > Therefore, in order to handle corner cases and race conditions, = the > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic > > >> > forwarding > > >>by > > >> > a remote PE until it also receives the associated set of > > >> > Ethernet > > >>A-D > > >> > per ES routes. > > >> > > > >> >Basically, the per-EVI A-D routes cannot be used before the > > >>corresponding > > >> >per-ES A-D routes are received and associated. Either that > > >> >requirement must be removed, or there must be a way to associate > > >> >the per-ES routes and per-EVI routes from the same PE. > > >> > > > >> >There is an easy solution to the latter, which was presented in > > >>Yokohama > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf). > > That > > >> >does require a beefed up requirement: the routes from the same PE > > >> >MUST have the same global admin field in the RDs. That should be > > >> >reasonable, and RFC already uses RECOMMEND keyword: > > >> > > > >> >7.9. Route Distinguisher Assignment per MAC-VRF > > >> > > > >> > The Route Distinguisher (RD) MUST be set to the RD of the MAC-VR= F > > >> > that is advertising the NLRI. An RD MUST be assigned for a give= n > > >> > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on > > >> > a > > >>PE. > > >> > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value fie= ld > > >> > comprises an IP address of the PE (typically, the loopback addre= ss) > > >> > followed by a number unique to the PE. > > >> > > > >> >Notice the "RECOMMEND" in the above paragraph. > > >> > > > >> >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > > >> > ... > > >> > The Route Distinguisher (RD) MUST be set per Section 7.9. > > >> > > > >> >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > > >> > ... > > >> > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The > > >> > value field comprises an IP address of the PE (typically, the > > >> > loopback address) followed by a number unique to the PE. > > >> > > > >> >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the > > >> >problems are solved. While RFC 7432 did not use MUST, I doubt > > >> >there is any implementation not using a Type 1 RD for the per-EVI r= oute. > > >> > > > >> >Jeffrey > > >> > > > >> >_______________________________________________ > > >> >BESS mailing list > > >> >BESS@ietf.org > > >> >https://www.ietf.org/mailman/listinfo/bess > > > >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Wed Jun 15 13:25: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 E904512D61B for ; Wed, 15 Jun 2016 13:24:58 -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 Qop8Xb5JCJbq for ; Wed, 15 Jun 2016 13:24:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8DF12D93C for ; Wed, 15 Jun 2016 13:24:55 -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=gIC/YtYjEOmWVwDNNJ4NVGPGjHlcWiendzPzKo46H8c=; b=Sru97b2PV6Ol8p5xoy9OEGOgv67Z+Yvo5FIVVEm4Y+25EGE/PL+eyk6aLlhwPhik5Pf2EuX86S53bAGYnpdFRWI3U8Us+FjQziqDhGbyZb/nRZEuDZlAp344EEghKRI5+Jtu79kLq7cT6wjDFf7HBhfGJy87B7LIX8N4/gd27xc= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BY2PR05MB2310.namprd05.prod.outlook.com (10.166.112.148) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 15 Jun 2016 20:24:52 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0517.014; Wed, 15 Jun 2016 20:24:51 +0000 From: "Jeffrey (Zhaohui) Zhang" To: John E Drake , "Ali Sajassi (sajassi)" , "bess@ietf.org" Thread-Topic: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B Thread-Index: AdHDTr6Q1IW0rlKIThic0r80jZklFgCmjRqAAAzxJGAAK5X5gAAIt4MAAA9HWIAABU77MA== Date: Wed, 15 Jun 2016 20:24:51 +0000 Message-ID: References: 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: c56373c0-81cd-41a1-5c45-08d3955b1b25 x-microsoft-exchange-diagnostics: 1; BY2PR05MB2310; 6:mnG7EOiXEdJ1IX45uCmawonitRJPvI5rvfT4ABuT0J/S0s45+erjnU2wtzlq9mMeBq5VCLHPcPZKcj7Rym9kPNn8jcW3W9cYsBFTaHDJjervasHKabzPrMrdC25v7L6873vBAdOTYg1//DupPkh8+xbTnz4y2BQGOyK0eoGeS/ENI/vNRs39lxluL4d4WyTmiycCTpncx1BvJxvwJHovF4hPEVDT7qcR/AWU+7lmhUh+Dfg5oRHQR2Km0ArO2sVJD4+Z8ygueQc5QpnCtcNiNEGnngVPNtGdvt7EzRHIQh6y/XzwPCspIeWqbYYM3zY0KHDQQC3r5ZzaVjKNq5AtFA==; 5:Tephlih9Zmfugs7MTJJWMLfVHnrHg08dHBh9FIG5wUmsmO2tOZcYmbwZiNnu0P3a6s8txuNu2QQmJkR5CopI8zxOtdABsueleV6ahFGQFsXmK/hC2qQY5WC2V2ocWH9JHllAvnbTkOoPtHPBHRz0hA==; 24:+WtUqYle+K6SuLBpWpjDqJWxKIl9j+TH7ye6R0tM6CdutFuA7ZPZrsdKX3U2p9UI1uOW1a+OyGSKGRBP/yx8rCBPGqzKdxqsWc7LwvMbnEA=; 7:A9xlSeWczZO8LvQ4qiyc8JummdRM2MpOuNlphULXKfhPtcf8RDwxpSP+qSCPghW/VwC9A8EcyBvH7KP2FDKaKKvOzj9xUe4AxDb+BADJ8mA1KXbqEmv58sCu60gpim7mcgr9KwJm+9EWmY2VSwcblPIh3zEaUmfkIleu4S47FxIruVDR2x9LC5A3PXRfXDLnKqMAFxsw3jBeIOA9PW15ihVpSo5hI7zxE7Wg6QxVFVM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2310; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR05MB2310; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2310; x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377454003)(189002)(24454002)(199003)(55674003)(106356001)(50986999)(81166006)(10400500002)(74316001)(8676002)(2906002)(99286002)(81156014)(4326007)(5003600100002)(8936002)(19580395003)(19580405001)(66066001)(5002640100001)(2501003)(97736004)(5001770100001)(54356999)(230783001)(76176999)(87936001)(189998001)(107886002)(1941001)(101416001)(9686002)(15975445007)(3280700002)(92566002)(5004730100002)(86362001)(76576001)(5008740100001)(3900700001)(68736007)(2900100001)(3660700001)(2950100001)(3846002)(586003)(4001430100002)(105586002)(77096005)(33656002)(6116002)(102836003)(93886004)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2310; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2016 20:24:51.6242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2310 Archived-At: Cc: Ronald Bonica Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt Inter-AS Option B X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:24:59 -0000 Hi John, I think there have been some disconnection that need to be cleared up first= . Section 10.2 of the evpn-overlay has the following two basic points about i= nter-as option B: 1. aliasing works as specified in RFC 7432 (plus clarification in the evpn-= overlay draft) 2. mass-withdraw is only at EVI level not at ES level The problem I have is with #1, not with #2. I have stated that in various d= iscussions long time ago, in the first email of this thread, and repeated i= n my response to Ali in this thread. To repeat, the problem with #1 is the following requirement in RFC 7432: Note that the Ethernet A-D per EVI route may be received by a remote PE before it receives the set of Ethernet A-D per ES routes. Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. You can see that we need to correlate the per-ES route and per-EVI route in= order to do aliasing. How that correlation is done needs to be specified/c= larified. I suggested to use the global admin field of the RD. If the current implementations do not use global admin field to do correlat= ion, then inter-as option B does NOT work as is. More below. > -----Original Message----- > From: John E Drake > Sent: Wednesday, June 15, 2016 1:26 PM > To: Jeffrey (Zhaohui) Zhang ; Ali Sajassi (sajassi) > ; bess@ietf.org > Cc: Ronald Bonica > Subject: RE: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > Inter-AS Option B >=20 > Jeffrey, >=20 > I don't think anyone would argue that the proper solution to per-ES mass > withdraw is to include the originating router's address in Ethernet AD an= d > MAC Advertisement routes and the only discussion is the best way to encod= e > this information. Please note that this is not about mass withdraw. Please see above. >=20 > Your suggestion of having an ingress PE use the RD field to get the > originating router's address has two issues: I am NOT saying to use the RD field to get the originating router's address= . I am saying to use the global admin field of the RD to do the correlation= . If a per-ES route's RD and a per-EVI route's RD has the same global admin= field, then consider that the two routes are from the same PE. That does require strong language to ensure per-ES route and per-EVI route = from the same PE to have the same global admin field that is different from= other PEs' RD's global admin field. That should be specified, and should b= e reasonable. >=20 > 1) RDs are known to be re-written by inter-provider ASBRs That's OK; in my earlier discussions and my reply to Ali I said that as lon= g as the rewriting keep the above requirement "per-ES route and per-EVI rou= te from the same PE to have the same global admin field that is different f= rom other PEs' RD's global admin field" it still works. > 2) An IPv6 router address will not fit in an RD Again, the global admin field of the RD is used as opaque data, not as IP a= ddresses. >=20 > Furthermore this is a fundamentally new behavior for an ingress PE and an > implementation would need to be changed to support it; no implementation > of which I am aware does this today. If an implementation follows the following in RFC 7432: Note that the Ethernet A-D per EVI route may be received by a remote PE before it receives the set of Ethernet A-D per ES routes. Therefore, in order to handle corner cases and race conditions, the Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by a remote PE until it also receives the associated set of Ethernet A-D per ES routes. How will aliasing work "as is" in inter-as option B case? While RFC 7432 does not explicit require "per-ES route and per-EVI route fr= om the same PE to have the same global admin field that is different from o= ther PEs' RD's global admin field" today, I would assert that existing impl= ementations have effectually done that. As long as an ingress PE uses the g= lobal admin field to do the correlation, it should work fine. This does req= uire new code, but I don't see other ways. >=20 > Given all of the above, the consensus is to include the originating > router's address in the remote next-hop sub-TLV of the Encapsulation > Attribute and modify egress PEs to include it and ingress PEs to use it. > This is a simple and incrementally deployable solution and in the meantim= e > per-EVI mass withdraw can be used. This also requires implementation changes, doesn't it? But again, my main p= roblem is NOT with mass withdraw. It's with aliasing. Jeffrey >=20 > Yours Irrespectively, >=20 > John >=20 > > -----Original Message----- > > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui= ) > Zhang > > Sent: Wednesday, June 15, 2016 6:54 AM > > To: Ali Sajassi (sajassi); bess@ietf.org > > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > Inter-AS Option B > > > > Hi Ali, > > > > > -----Original Message----- > > > From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > > > Sent: Wednesday, June 15, 2016 1:59 AM > > > To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > > > Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, wrt > > > Inter-AS Option B > > > > > > > > > Hi Jeffrey, > > > > > > On 6/14/16, 2:44 AM, "Jeffrey (Zhaohui) Zhang" > wrote: > > > > > > >Hi Ali, > > > > > > > >> -----Original Message----- > > > >> From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] > > > >> Sent: Monday, June 13, 2016 11:01 PM > > > >> To: Jeffrey (Zhaohui) Zhang ; bess@ietf.org > > > >> Cc: Ali Sajassi (sajassi) > > > >> Subject: Re: [bess] Comments on draft-ietf-bess-evpn-overlay-04, > > > >> wrt Inter-AS Option B > > > >> > > > >> > > > >> Hi Jeffrey, > > > >> > > > >> A few points: > > > >> > > > >> 1) There have been lots of discussions on this topic but you were > > > >> not > > > in > > > >> attendance for some of them including the ones held at the last > > > >> IETF in Bones Aires. So, before jumping into a haste conclusion > > > >> that there were not consensus on section 10, please check with you= r > > > >> own colleagues who participated in those meetings. > > > >> > > > >> 2) Regarding the current text in section 10: this text is > > > >>consistent with the one that was checked for IETF at Yokohama and > > > >>it is also consistent with RFC 7432 operation. We still require Et= h > > > >>A-D per ES in order to validate Eth A-d per EVI, the only > > > >>difference is that the mass-withdraw doesn=B9t work (i.e., route > > > >>validation still works). > > > > > > > >Could the document clarify how the validation is done - how do you > > > >conclude that a per-ES route and a per-EVI route are related? If I > > > >understand it correctly, if the correlation can be done, then > > > >mass-withdraw works. > > > > > > > >That is the key of the issue that is missing from the document. > > > > > > It has been described in 4th paragraph of section 10.2.2: > > > > > > "Now, when the AC between the PE2 and the CE fails and PE2 sends NLRI > > > withdrawal for Ether A-D per ES route and this withdrawal gets > > > propagated and received by the PE3, the BGP process in PE3 removes > > > the corresponding BGP route; however, it doesn't remove the > > > associated info (namely ESI and BGP next hop) from the L2 routing > > > table (L2 RIB) because it still has the other Ether A-D per ES > route > > > (originated from PE1) with the same info. That is why the mass- > > > withdraw mechanism does not work when doing DCI with inter-AS > option > > > B. However, as described previoulsy, the aliasing function works > and > > > so does "mass-withdraw per EVI" (which is associated with > withdrawing > > > the EVPN route associated with Aliasing - i.e., Ether A-D per EVI > > > route)." > > > > The above describes why only "mass-withdraw per EVI" works. The main > problem is NOT > > with that. It's with the following in RFC 7432 as I mentioned initially > in this thread: > > > > > >> > Note that the Ethernet A-D per EVI route may be received by a > remote > > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > > >> > Therefore, in order to handle corner cases and race conditions= , > the > > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic > forwarding by > > > >> > a remote PE until it also receives the associated set of > Ethernet A-D > > > >> > per ES routes. > > > > For the aliasing part, how do you tell if a per-ES route and a per-EVI > route are from the same > > PE? If you cannot tell, then the above validation cannot be done. > > > > If we assume that they always have the same global admin field in the > RDs, then the > > correlation can be done similar to how you associate the per-EVI route > and mac routes as > > you clarified; but when I first proposed this solution when the option-= B > issue was brought > > up, people were saying that RFC 7432 does NOT require the per-ES route > and per-EVI route > > have the same global admin field in the RDs, because: > > > > - per-EVI route uses per-mac-vrf RD, which is RECOMMENDED to use type-1 > (not MUST), > > with "typically the lookback address". > > - per-ES route MUST uses a type-1 RD with "typically the loopback > address". > > > > Note that there is no explicit requirement/guarantee that the two will > have the same global > > admin field in the RDs. If we put that explicit requirement in, then th= e > problem is solved; > > and with that, mass-withdraw per ES also works. > > > > Please note that it is not me who is splitting hair here. It is other > people who were saying > > that RFC does not require they have the same global admin field. > > > > So if we take this opportunity to tighten up the language, then we have > an "easy solution" > > that always works (more below on that), and it removes hair splitting > arguments from some > > people. > > > > > > > > > > > > >> > > > >> 3) Your so-called =B3easy solution=B2 doesn=B9t work in all scenar= ios so > > > there > > > >> is no point in documenting something that works sometimes :-) If > > > >> you recall several years ago, we went to great length to > > > >> accommodate multi-homing across multiple AS=B9s and that=B9s why w= e > > > >> added originating router=B9s IP address to the ES route. The 4 byt= e > > > >> field in RD type-1, is > > > a > > > >> router ID (for both IPv4 and IPv6) and per RFC 6286, router-id is > > > unique > > > >> within an AS only. Thus the suggested solution won=B9t work when a= CE > > > >> is dual-homed to two PEs in two different AS=B9s. > > > > > > > >If those two PEs happen to have the same router-id, and they happen > > > >to choose the same local admin field for the RD, e.g. vlan id as > > > >section 7.9 of RFC 7432 says: > > > > > > > > The value field > > > > comprises an IP address of the PE (typically, the loopback addres= s) > > > > followed by a number unique to the PE. This number may be > generated > > > > by the PE. Or, in the Unique VLAN EVPN case, the low-order 12 > bits > > > > may be the 12-bit VLAN ID, with the remaining high-order 4 bits > set > > > > to 0. > > > > > > > >How do you distinguish the two routes from the PEs? There is no way > > > >to guarantee it "always works" even if you don't use vlan-id. > > > > > > In such scenarios, the ASBRs perform RD (and RT) translation; however= , > > > the translated RD no longer needs to be of type-1. > > > > We discussed this before as well - as long as the RD translation ensure= s > that routes with the > > same global admin field in the RDs continue to have the same global > admin field that is > > different from those in routes from different PEs, then the "easy > solution" still works. If it is > > not practical to have different admin field for routes from different > PEs after translation, > > then the following requirement cannot be satisfied: > > > > Note that the Ethernet A-D per EVI route may be received by a remote > > PE before it receives the set of Ethernet A-D per ES routes. > > Therefore, in order to handle corner cases and race conditions, the > > Ethernet A-D per EVI route MUST NOT be used for traffic forwarding b= y > > a remote PE until it also receives the associated set of Ethernet A-= D > > per ES routes. > > > > BTW - now that you say after translation the RD no longer needs to be o= f > type-1, is there > > any reason to require type-1 at all, even when there is no inter-AS > option B? > > > > Jeffrey > > > > > > > > > > > > >> > > > >> We are currently separately documenting a proper solution based on > > > >> a > > > new > > > >> sub-TLV added to the attribute in idr-tunnel-encap draft to > > > >> identify > > > the > > > >> originating PE. A solution based on this attribute will work for > > > >>all scenarios. Now the question is what to do in short term. We ca= n > > > >>either go with the text that it is in section 10.2 of the > > > >>evpn-overlay draft, > > > plus > > > >> go with the new draft, or just go with the new draft and remove th= e > > > >> suggested solution in section 10.2. I am open to both. > > > > > > > >Multi-homing across ASes (or any segmentation points) is complicated= . > > > >I've spent quite some cycles on it - in particular split horizon > > > >becomes more complicated (I documented it in initial unpublished > > > >version of draft-zzhang-bess-evpn-bum-procedure-updates but then > > > >removed it). I would like to be included in the relevant discussions > on the new > > document. > > > > > > Sure, we can definitely consider it. > > > > > > Cheers, > > > Ali > > > > > > > > > > >If we can say "multi-homing across ASes" is out of scope for now, > > > >then the overlay draft can certainly clarify inter-as optin B > > > >procedure (especially on how the correlation is done). Otherwise, I'= d > > > >suggest to remove section 10.2. It is NOT specific to overlay anyway= . > > > > > > > >Jeffrey > > > > > > > >> > > > >> Cheers, > > > >> Ali > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> On 6/10/16, 1:03 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > > > >> wrote: > > > >> > > > >> >I want to bring up an old discussion about the following: > > > >> > > > > >> > In summary, it can be seen that aliasing (and backup path) > > > >> > functionality should work as is for inter-AS option B without > > > >> > requiring any addition functionality in ASBRs or PEs. However, > the > > > >> > mass-withdraw functionality falls back from per-ES mode to per= - > EVI > > > >> > mode for inter-AS option B - i.e., PEs receiving mass-withdraw > > > route > > > >> > from the same AS use Ether A-D per ES route; whereas, PEs > receiving > > > >> > mass-withdraw route from different AS use Ether A-D per EVI > route. > > > >> > > > > >> >There have been lot of discussions on this - offline and in > > > >> >Yokohama > > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf)= . > > > >> >The above text does not reflect the consensus among some of us an= d > in particular > > does not reflect what was presented in Yokohama. > > > >> > > > > >> >There are two issues with inter-as option B as currently specifie= d > > > >> >in > > > >>RFC > > > >> >7432. > > > >> > > > > >> >A minor issue is that mass-withdraw degrades from per ES to from > > > >> >per > > > >>(ES, > > > >> >EVI) (with the clarification in this overlay draft), which would > > > >> >not exist if the main issue is resolved as presented in Yokohama. > > > >> > > > > >> >The main one is the following requirement in RFC 7432: > > > >> > > > > >> > Note that the Ethernet A-D per EVI route may be received by a > > > remote > > > >> > PE before it receives the set of Ethernet A-D per ES routes. > > > >> > Therefore, in order to handle corner cases and race conditions= , > the > > > >> > Ethernet A-D per EVI route MUST NOT be used for traffic > > > >> > forwarding > > > >>by > > > >> > a remote PE until it also receives the associated set of > > > >> > Ethernet > > > >>A-D > > > >> > per ES routes. > > > >> > > > > >> >Basically, the per-EVI A-D routes cannot be used before the > > > >>corresponding > > > >> >per-ES A-D routes are received and associated. Either that > > > >> >requirement must be removed, or there must be a way to associate > > > >> >the per-ES routes and per-EVI routes from the same PE. > > > >> > > > > >> >There is an easy solution to the latter, which was presented in > > > >>Yokohama > > > >> >(https://www.ietf.org/proceedings/94/slides/slides-94-bess-1.pdf)= . > > > That > > > >> >does require a beefed up requirement: the routes from the same PE > > > >> >MUST have the same global admin field in the RDs. That should be > > > >> >reasonable, and RFC already uses RECOMMEND keyword: > > > >> > > > > >> >7.9. Route Distinguisher Assignment per MAC-VRF > > > >> > > > > >> > The Route Distinguisher (RD) MUST be set to the RD of the MAC- > VRF > > > >> > that is advertising the NLRI. An RD MUST be assigned for a > given > > > >> > MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs o= n > > > >> > a > > > >>PE. > > > >> > It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value > field > > > >> > comprises an IP address of the PE (typically, the loopback > address) > > > >> > followed by a number unique to the PE. > > > >> > > > > >> >Notice the "RECOMMEND" in the above paragraph. > > > >> > > > > >> >8.4.1. Constructing Ethernet A-D per EVPN Instance Route > > > >> > ... > > > >> > The Route Distinguisher (RD) MUST be set per Section 7.9. > > > >> > > > > >> >8.2.1. Constructing Ethernet A-D per Ethernet Segment Route > > > >> > ... > > > >> > The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. > The > > > >> > value field comprises an IP address of the PE (typically, the > > > >> > loopback address) followed by a number unique to the PE. > > > >> > > > > >> >As long as 8.4.1 or 7.9 says Type 1 RD MUST be used, then all the > > > >> >problems are solved. While RFC 7432 did not use MUST, I doubt > > > >> >there is any implementation not using a Type 1 RD for the per-EVI > route. > > > >> > > > > >> >Jeffrey > > > >> > > > > >> >_______________________________________________ > > > >> >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 Mon Jun 20 00:46:24 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8140F12D804 for ; Mon, 20 Jun 2016 00:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nT4keunnS3DZ for ; Mon, 20 Jun 2016 00:46:20 -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 ACA8412D5D2 for ; Mon, 20 Jun 2016 00:46:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B12DBEDB6FCF4 for ; Mon, 20 Jun 2016 07:46:16 +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 u5K7kIir016503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2016 07:46:18 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u5K7kHJp018560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jun 2016 09:46:18 +0200 Received: from [135.224.223.138] (135.239.27.38) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 09:46:14 +0200 Message-ID: <57679F45.8050400@alcatel-lucent.com> Date: Mon, 20 Jun 2016 09:46:13 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <574C626E.2070801@alcatel-lucent.com> <57611422.7030005@alcatel-lucent.com> In-Reply-To: <57611422.7030005@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [bess] Extended poll [Re: Poll for adoption: draft-dolganow-bess-mvpn-expl-track-02] 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, 20 Jun 2016 07:46:22 -0000 All, we have a new WG Document. Authors, please republish as draft-ietf-bess-mvpn-expl-track-00 Thank you -m Le 15/06/2016 10:38, Martin Vigoureux a écrit : > All, > > as a heads-up an IPR disclosure has been made recently: > https://datatracker.ietf.org/ipr/2807/ > > I'll give this call one more week. > > For those who haven't expressed their opinion, please do so. > > -m > > Le 30/05/2016 17:55, Martin Vigoureux a écrit : >> Hello working group, >> >> This email starts a two-week poll on adopting >> draft-dolganow-bess-mvpn-expl-track-02 [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 13th of June*. >> >> 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-dolganow-bess-mvpn-expl-track >> >> _______________________________________________ >> 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 Mon Jun 20 04:10:37 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 7184412D11E for ; Mon, 20 Jun 2016 04:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x-IDjHVeOVM5 for ; Mon, 20 Jun 2016 04:10:35 -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 1359912B006 for ; Mon, 20 Jun 2016 04:10:35 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7944894EE0921 for ; Mon, 20 Jun 2016 11:10:30 +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 u5KBAWiH020176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2016 11:10:33 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 u5KBAWO0014482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jun 2016 13:10:32 +0200 Received: from [135.224.199.207] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 13:10:32 +0200 Message-ID: <5767CF26.4090906@alcatel-lucent.com> Date: Mon, 20 Jun 2016 13:10:30 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "bess@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: [bess] Slots requests for BESS WG session - IETF 96 - Berlin 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, 20 Jun 2016 11:10:36 -0000 All, it is time we start building the BESS WG agenda for Berlin. The IETF agenda is available at: https://datatracker.ietf.org/meeting/96/agenda.html Please note that it is still a preliminary agenda. The BESS WG session (2h) is currently scheduled on Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) Please send us your request for a presentation slot, indicating draft name, speaker and desired duration (covering presentation + discussion) Please send the requests no later than the 7th of July. Thank you M&T From nobody Mon Jun 20 05:44:11 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 BDAA812B05F for ; Mon, 20 Jun 2016 05:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MNa5OL4J1SRX for ; Mon, 20 Jun 2016 05:44:08 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837C112B05C for ; Mon, 20 Jun 2016 05:44:08 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id A7A92C0254; Mon, 20 Jun 2016 14:44:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 840DD1A0070; Mon, 20 Jun 2016 14:44:06 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.3) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 20 Jun 2016 14:44:06 +0200 From: To: Organization: Orange Message-ID: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> Date: Mon, 20 Jun 2016 14:44:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.3] Archived-At: Cc: draft-boutros-bess-vxlan-evpn@tools.ietf.org Subject: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-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: Mon, 20 Jun 2016 12:44:10 -0000 Hello working group, This email starts a two-week poll on adopting draft-boutros-bess-vxlan-evpn-01 [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 *July 4th*. 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-boutros-bess-vxlan-evpn-01 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Mon Jun 20 06:09:17 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 B8E0A12D0B7 for ; Mon, 20 Jun 2016 06:09:16 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yaYRWOzM-V9W for ; Mon, 20 Jun 2016 06:09:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3F212D0A7 for ; Mon, 20 Jun 2016 06:09:14 -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=H3rvWCx7CEZkTtytDM/b+arcZK/Y+qJRWL+L9L0t+jk=; b=XhHPNdifRxOal1GzCa634TbOeT1WRYfIoIjPt4WCjwRtGXlTRwO81uDWHnNqetrc22Kw1PBiG/8hZHFRXMyuJLnLoe5sLBUpqpe5+vEWhx1S7dKpuEnQVI+7jT1X0mSaW49mW1VlsTQ0u6k/Ir2ZqyThxKM5789eZz17TZZmfXQ= Received: from BY2PR05MB2310.namprd05.prod.outlook.com (10.166.112.148) by BY2PR05MB2311.namprd05.prod.outlook.com (10.166.112.149) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 20 Jun 2016 13:08:52 +0000 Received: from BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) by BY2PR05MB2310.namprd05.prod.outlook.com ([10.166.112.148]) with mapi id 15.01.0523.015; Mon, 20 Jun 2016 13:08:52 +0000 From: John E Drake To: "EXT - thomas.morin@orange.com" , "bess@ietf.org" Thread-Topic: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 Thread-Index: AQHRyvFzo5WYNsfAPkejoGDgJ8XEnp/yU42g Date: Mon, 20 Jun 2016 13:08:52 +0000 Message-ID: References: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> In-Reply-To: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-originating-ip: [66.129.241.13] x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: ddbed128-326d-438c-5e04-08d3990c06cf x-microsoft-exchange-diagnostics: 1; BY2PR05MB2311; 6:8+qH0ZJsZ3PKHtRt/2oyUJ3TVd7lk3ZeycQAS7L5XAXCD38GuKd8rPQFJnkYj6kb7eaN+iEwdSIVkutOCS3ayQvByjTi+6ejdwbIE3nvPmSHmxuQqmh6LDEvTc6gDhE0M8KcwotnzA0Dh1bewnw+dLOZLFhtvt1brSDeMSPW16+ab9JZHVzpn8+D2hz9C9ahR3uRJeBbgJ+lk+/2iJ1KyrAXqj0VOC8IRQWIKsl33UNUcVAn6V/KTQ3IGxEaiE2p1As0zF09M8/5hQJQ7eSkg9COLn8kOQxBKJmU+f4rxW8AjgsVSuNNL0VpbfyiA2EoJQeIHQMIA1SDimzDxZf/DQ==; 5:kvUbnl+NjcJToaSpM0hEmBCL2R4Q6bjGjyRDhNgFzKmWg9OCo4LGR5mqljJrI0yxkIomkc4xRbYD+pj8whMIAAWeONGQh4oOa1cutYpoT1Er0W32pvuv2LjxIROHSH9ACTpbAXrzgqixlBXr5XVWTg==; 24:zEQE/C9aVQgoZWh6vEV4fuRHJbAR2z7ABxxj1AalKfDDeQPyy2SJXUfRySjhi49cnqnExKaPQWvRVnfOvGsCOf4jXwzmXCFfJwI7sMmxzQA=; 7:enhblBA9sPsgZyvunQ+ADeiGMcywrPuRcqsYavna4QgrtY3zYVCGD01E+HR7f/3KI+oIlokqKqp9R9J1sSxnOJyK9UJbopHtvvqlyiRoJhk0pPlvaIhzEWJhGU/EIQ+Tqaw5oLTIO2s1K6OTpu8jKNaOvT7eE0qBzOd7G5WvUq3MhhXdjC+mcg8GJ7FMNS4QuVUyrH2drLMmBPWPZ7O2me9/NLGMOUXhCDghH0IIkaHRw0sLFiZx9R/TXzI4anrT x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB2311; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB2311; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2311; x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(5003600100002)(74316001)(230783001)(92566002)(97736004)(76576001)(5001770100001)(19580395003)(19580405001)(87936001)(5002640100001)(66066001)(189998001)(106356001)(106116001)(105586002)(86362001)(99286002)(586003)(2900100001)(33656002)(11100500001)(2950100001)(2501003)(122556002)(76176999)(7846002)(77096005)(5890100001)(6116002)(3846002)(102836003)(68736007)(4326007)(2906002)(3280700002)(5004730100002)(9686002)(8936002)(3660700001)(81156014)(15975445007)(101416001)(81166006)(50986999)(54356999)(8676002)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB2311; H:BY2PR05MB2310.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: 20 Jun 2016 13:08:52.1061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2311 Archived-At: Cc: "draft-boutros-bess-vxlan-evpn@tools.ietf.org" Subject: Re: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-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: Mon, 20 Jun 2016 13:09:17 -0000 Support. It provides a useful and much needed capability. Not aware of an= y IPR. =20 Yours Irrespectively, John > -----Original Message----- > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of thomas.morin@orang= e.com > Sent: Monday, June 20, 2016 8:44 AM > To: bess@ietf.org > Cc: draft-boutros-bess-vxlan-evpn@tools.ietf.org > Subject: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-boutros-bess-vxlan-evpn-01 [1] as a Working Group Document. >=20 > Please state on the list if you support adoption or not (in both cases, p= lease also state the > reasons). >=20 > This poll runs until *July 4th*. >=20 > 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). >=20 > If you are listed as an Author or Contributor of this Document please res= pond 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. >=20 > No IPR has been disclosed against this Document. >=20 > If you are not listed as an author or contributor, then please explicitly= respond only if you > are aware of any IPR that has not yet been disclosed in conformance with = IETF rules. >=20 > Thank you >=20 > Martin & Thomas > bess chairs >=20 > [1] https://datatracker.ietf.org/doc/draft-boutros-bess-vxlan-evpn-01 >=20 > _____________________________________________________________________ > ____________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou > privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sa= ns autorisation. Si > vous avez recu ce message par erreur, veuillez le signaler a l'expediteur= et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles d'a= lteration, Orange > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that > may be protected by law; they should not be distributed, used or copied w= ithout > authorisation. > If you have received this email in error, please notify the sender and de= lete this message > and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, > changed or falsified. > Thank you. >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jun 20 06:20:20 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 9D97A12D0FF for ; Mon, 20 Jun 2016 06:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 2e9puGZ4Xsli for ; Mon, 20 Jun 2016 06:20:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396C912D0D3 for ; Mon, 20 Jun 2016 06:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1172; q=dns/txt; s=iport; t=1466428812; x=1467638412; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QcZISAELBjG/QsrbkjtfOfTfGHEvW/M9n2EaP5ypEOo=; b=mSeC/IBSg9GLuaWe5S+sVBGU9bUoTmuCmRg0SVqG1OVMWBuS0zDI06GH 1f8CjRBEVLniHKUvtesgue/9DPEQ1n3VD6m5vNqJPOoxgn3jYJcgyulp6 LPAueM1S5oDttqOgNYoEtheEwzKlCdUpzYo8TKTwvFkrQC0WQBsntJZYK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCh7GdX/5FdJa1bA4M+Vn0Gul+Be?= =?us-ascii?q?hcLhXUCgTA4FAEBAQEBAQFlJ4RMAQEEAQEBNywIGQICAQg2EBsMCyUCBAESiDA?= =?us-ascii?q?OwDEBAQEBAQEBAQEBAQEBAQEBAQEBAQEcBYYihE2EYREVhRQFjXWLAQGGBYgkg?= =?us-ascii?q?WlOhASIZ492AR42g3BuAYlIAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,498,1459814400"; d="scan'208";a="114790869" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 13:20:11 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5KDKBCt028220 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 13:20:11 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 09:20:10 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 09:20:10 -0400 From: "Patrice Brissette (pbrisset)" To: Martin Vigoureux , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 96 - Berlin Thread-Index: AQHRyvZ4VTLd2VmQpkOVDZr76B2SMw== Date: Mon, 20 Jun 2016 13:20:10 +0000 Message-ID: References: <5767CF26.4090906@alcatel-lucent.com> In-Reply-To: <5767CF26.4090906@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.192] Content-Type: text/plain; charset="us-ascii" Content-ID: <733BD2D4DC79CB4CA8A5A73665748995@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin 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, 20 Jun 2016 13:20:14 -0000 Martin, Please set me for Yang again. !0 min for L2VPN, EVPN and L3VPN. Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com On 2016-06-20, 4:10 AM, "BESS on behalf of Martin Vigoureux" wrote: >All, > >it is time we start building the BESS WG agenda for Berlin. >The IETF agenda is available at: >https://datatracker.ietf.org/meeting/96/agenda.html >Please note that it is still a preliminary agenda. > >The BESS WG session (2h) is currently scheduled on >Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) > >Please send us your request for a presentation slot, indicating >draft name, speaker and desired duration (covering presentation + >discussion) > >Please send the requests no later than the 7th of July. >Thank you > >M&T > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jun 20 06:29: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 59F5F12B05C for ; Mon, 20 Jun 2016 06:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, 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 VOdFBw4z2_5s for ; Mon, 20 Jun 2016 06:28:57 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2712D0EF for ; Mon, 20 Jun 2016 06:28:57 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9ED4CA440BA; Mon, 20 Jun 2016 15:28:56 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 96C8BA440AD; Mon, 20 Jun 2016 15:28:56 +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.279.2; Mon, 20 Jun 2016 15:28:56 +0200 To: , "pbrisset@cisco.com" References: <5767CF26.4090906@alcatel-lucent.com> From: Thomas Morin Organization: Orange Message-ID: <946b68b9-dc05-86b6-cb32-ba0cdfa8d194@orange.com> Date: Mon, 20 Jun 2016 15:28:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin 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, 20 Jun 2016 13:28:59 -0000 Patrice Brissette (pbrisset) : > Please set me for Yang again. !0 min for L2VPN, EVPN and L3VPN. Well, implicitly we already assume slots requests are about non-zero time duration *. ;-) Typo joke aside, can you tell if you want 10 mins per draft, or if you plan to cover them all in one 10-minute slot ? -Thomas *: and we even accept slot requests for presentations of zero or negative time *after* the meeting is closed and people went back home > > > > > > On 2016-06-20, 4:10 AM, "BESS on behalf of Martin Vigoureux" > wrote: > >> All, >> >> it is time we start building the BESS WG agenda for Berlin. >> The IETF agenda is available at: >> https://datatracker.ietf.org/meeting/96/agenda.html >> Please note that it is still a preliminary agenda. >> >> The BESS WG session (2h) is currently scheduled on >> Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) >> >> Please send us your request for a presentation slot, indicating >> draft name, speaker and desired duration (covering presentation + >> discussion) >> >> Please send the requests no later than the 7th of July. >> Thank you >> >> M&T >> >> _______________________________________________ >> 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 Mon Jun 20 06:43:16 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 79C8912D5C4; Mon, 20 Jun 2016 06:43:14 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620134314.30146.84030.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 06:43:14 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-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: Mon, 20 Jun 2016 13:43:14 -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 : Explicit Tracking with Wild Card Routes in Multicast VPN Authors : Andrew Dolganow Jayant Kotalwar Eric C. Rosen Zhaohui Zhang Filename : draft-ietf-bess-mvpn-expl-track-00.txt Pages : 15 Date : 2016-06-20 Abstract: The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFC6625. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-expl-track-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 Mon Jun 20 06:57:02 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 26F2212D591 for ; Mon, 20 Jun 2016 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c_9lgYQTqfrk for ; Mon, 20 Jun 2016 06:56:58 -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 3031E12D133 for ; Mon, 20 Jun 2016 06:56:57 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 3747E816D33FC for ; Mon, 20 Jun 2016 13:56:52 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KDus4i004070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2016 13:56:55 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KDusrD024364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jun 2016 15:56:54 +0200 Received: from [135.224.204.85] (135.239.27.40) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jun 2016 15:56:54 +0200 Message-ID: <5767F626.2060201@alcatel-lucent.com> Date: Mon, 20 Jun 2016 15:56:54 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: BESS Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: [bess] WG feedback on early allocation request for PMSI Tunnel Attribute Flags 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, 20 Jun 2016 13:57:00 -0000 Dear WG, we have received an early allocation request from the authors of draft-ietf-bess-evpn-optimized-ir (see details below). Please let us know if you are aware of any code-point conflict, or about any question regarding this allocation. We envisage to proceed with the request on the 27th of June. Thank you M&T --- The New Flags are defined in draft-ietf-bess-evpn-optimized-ir-00 in the following way: 0 1 2 3 4 5 6 7 +-+-+-+-+-+--+-+-+ |rsved| T |BM|U|L| +-+-+-+-+-+--+-+-+ Bits 3-4 -->> 'Type' where: + 00 (decimal 0) = RNVE (non-AR support) + 01 (decimal 1) = AR-REPLICATOR + 10 (decimal 2) = AR-LEAF Bit 5 -->> 'BM' + BM= Broadcast and Multicast (BM) flag. BM=1 means "prune-me" from the BM flooding list. BM=0 means regular behavior. Bit 6 -->> 'U' + U= Unknown flag. U=1 means "prune-me" from the Unknown flooding list. U=0 means regular behavior. --- From nobody Mon Jun 20 06:58:54 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8964212B04C; Mon, 20 Jun 2016 06:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160620135852.30239.26477.idtracker@ietfa.amsl.com> Date: Mon, 20 Jun 2016 06:58:52 -0700 Archived-At: Subject: [bess] The BESS WG has placed draft-boutros-bess-vxlan-evpn in state "Call For Adoption By WG Issued" X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:58:52 -0000 The BESS WG has placed draft-boutros-bess-vxlan-evpn in state Call For Adoption By WG Issued (entered by Thomas Morin) The document is available at https://datatracker.ietf.org/doc/draft-boutros-bess-vxlan-evpn/ From nobody Mon Jun 20 08:18:59 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708312D17A for ; Mon, 20 Jun 2016 08:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 PC1TpWG72NeC for ; Mon, 20 Jun 2016 08:18:56 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4D412D129 for ; Mon, 20 Jun 2016 08:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2209; q=dns/txt; s=iport; t=1466435936; x=1467645536; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8QQgAtJKLURqA/KNLbhrWivEOnqAVC/Z2PkHzGg6zdE=; b=G8mGaieHhHoH96I/a068iClSso9CyBPTvodek657NERnWhKWYnLt9Q9t XRT5RxcAHm95IdTFXVmaxCnSdOftv/UxUO03zrVJne10gpIdmlmE9lgnj gS0qeLtbJi2AMqJF2BpbjsuSKENxc51P7EfuyUVO4UqWBBTmE+/I0AZtD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBQCGhX/5NdJa1aA4M+Vn0GumGBe?= =?us-ascii?q?hcLhXUCgTI4FAEBAQEBAQFlJ4RMAQEEAQEBYwgZAgIBCBguGwwLJQIEARKIMA7?= =?us-ascii?q?AXAEBAQEBAQEBAQEBAQEBAQEBAQEBARwFhiKETYRhERWFFAWNdYsBAYYFiCSBa?= =?us-ascii?q?U6EBIhnj3YBHjaDcG4BiUgBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,499,1459814400"; d="scan'208";a="287607339" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2016 15:18:55 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5KFItQr024064 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Jun 2016 15:18:55 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 20 Jun 2016 11:18:54 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1104.009; Mon, 20 Jun 2016 11:18:54 -0400 From: "Patrice Brissette (pbrisset)" To: Thomas Morin , "bess@ietf.org" Thread-Topic: [bess] Slots requests for BESS WG session - IETF 96 - Berlin Thread-Index: AQHRywcOStcG+H4tFU2RC0d+oOftAQ== Date: Mon, 20 Jun 2016 15:18:54 +0000 Message-ID: References: <5767CF26.4090906@alcatel-lucent.com> <946b68b9-dc05-86b6-cb32-ba0cdfa8d194@orange.com> In-Reply-To: <946b68b9-dc05-86b6-cb32-ba0cdfa8d194@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.192] Content-Type: text/plain; charset="Windows-1252" Content-ID: <85F599676CB2E840BAE82B3C38364050@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin 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, 20 Jun 2016 15:18:58 -0000 Thomas, Total: 0+-(-(1<<3))+2 mins overall and I do appreciate your joke=8A first person who make me laugh this morning ;-) Regards, Patrice Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com On 2016-06-20, 9:28 AM, "BESS on behalf of Thomas Morin" wrote: >Patrice Brissette (pbrisset) : >> Please set me for Yang again. !0 min for L2VPN, EVPN and L3VPN. > >Well, implicitly we already assume slots requests are about non-zero >time duration *. ;-) > >Typo joke aside, can you tell if you want 10 mins per draft, or if you >plan to cover them all in one 10-minute slot ? > >-Thomas > >*: and we even accept slot requests for presentations of zero or >negative time *after* the meeting is closed and people went back home > > > >> >> >> >> >> >> On 2016-06-20, 4:10 AM, "BESS on behalf of Martin Vigoureux" >> wrote: >> >>> All, >>> >>> it is time we start building the BESS WG agenda for Berlin. >>> The IETF agenda is available at: >>> https://datatracker.ietf.org/meeting/96/agenda.html >>> Please note that it is still a preliminary agenda. >>> >>> The BESS WG session (2h) is currently scheduled on >>> Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) >>> >>> Please send us your request for a presentation slot, indicating >>> draft name, speaker and desired duration (covering presentation + >>> discussion) >>> >>> Please send the requests no later than the 7th of July. >>> Thank you >>> >>> M&T >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Mon Jun 20 11:40:05 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DAE12D62A for ; Mon, 20 Jun 2016 11:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G2ndwMRknCI9 for ; Mon, 20 Jun 2016 11:40:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B3E12D51A for ; Mon, 20 Jun 2016 11:40:00 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 9B947498A35AF; Mon, 20 Jun 2016 18:39:54 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5KIdw8U007454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2016 18:39:58 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5KIdvLu024766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jun 2016 20:39:58 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.160]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Jun 2016 20:39:57 +0200 From: "Henderickx, Wim (Nokia - BE)" To: John E Drake Thread-Topic: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 Thread-Index: AQHRyvT3HF4UJAv3BUOTQY1Kn18gTp/ysGDO Date: Mon, 20 Jun 2016 18:39:57 +0000 Message-ID: References: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com>, In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-boutros-bess-vxlan-evpn@tools.ietf.org" , "EXT - thomas.morin@orange.com" , "bess@ietf.org" Subject: Re: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-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: Mon, 20 Jun 2016 18:40:03 -0000 Support not aware of IPT deployed widely and we provided IOT as well Sent from my iPhone > On 20 Jun 2016, at 14:09, John E Drake wrote: >=20 > Support. It provides a useful and much needed capability. Not aware of = any IPR. =20 >=20 > Yours Irrespectively, >=20 > John >=20 >> -----Original Message----- >> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of thomas.morin@oran= ge.com >> Sent: Monday, June 20, 2016 8:44 AM >> To: bess@ietf.org >> Cc: draft-boutros-bess-vxlan-evpn@tools.ietf.org >> Subject: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 >>=20 >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >> draft-boutros-bess-vxlan-evpn-01 [1] as a Working Group Document. >>=20 >> Please state on the list if you support adoption or not (in both cases, = please also state the >> reasons). >>=20 >> This poll runs until *July 4th*. >>=20 >> 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 (se= e RFCs 3979, 4879, >> 3669 and 5378 for more details). >>=20 >> If you are listed as an Author or Contributor of this Document please re= spond to this email >> and indicate whether or not you are aware of any relevant undisclosed IP= R. The Document >> won't progress without answers from all the Authors and Contributors. >>=20 >> No IPR has been disclosed against this Document. >>=20 >> If you are not listed as an author or contributor, then please explicitl= y respond only if you >> are aware of any IPR that has not yet been disclosed in conformance with= IETF rules. >>=20 >> Thank you >>=20 >> Martin & Thomas >> bess chairs >>=20 >> [1] https://datatracker.ietf.org/doc/draft-boutros-bess-vxlan-evpn-01 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou >> privilegiees et ne doivent donc pas etre diffuses, exploites ou copies s= ans autorisation. Si >> vous avez recu ce message par erreur, veuillez le signaler a l'expediteu= r et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles d'= alteration, Orange >> decline toute responsabilite si ce message a ete altere, deforme ou fals= ifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that >> may be protected by law; they should not be distributed, used or copied = without >> authorisation. >> If you have received this email in error, please notify the sender and d= elete this message >> and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, >> changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >=20 > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Jun 21 16:58:34 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 D136612DAA7; Tue, 21 Jun 2016 16:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.028 X-Spam-Level: X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4DjQ-V6oEJJ; Tue, 21 Jun 2016 16:58:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF27D12D74F; Tue, 21 Jun 2016 16:57:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CB36FB80D20; Tue, 21 Jun 2016 16:57:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160621235756.CB36FB80D20@rfc-editor.org> Date: Tue, 21 Jun 2016 16:57:56 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7900 on Extranet Multicast in BGP/IP MPLS VPNs 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, 21 Jun 2016 23:58:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7900 Title: Extranet Multicast in BGP/IP MPLS VPNs Author: Y. Rekhter, Ed., E. Rosen, Ed., R. Aggarwal, Y. Cai, T. Morin Status: Standards Track Stream: IETF Date: June 2016 Mailbox: none, erosen@juniper.net, raggarwa_1@yahoo.com, yiqun.cai@alibaba-inc.com, thomas.morin@orange.com Pages: 65 Characters: 155704 Updates: RFC 6513, RFC 6514, RFC 6625 I-D Tag: draft-ietf-bess-mvpn-extranet-07.txt URL: https://www.rfc-editor.org/info/rfc7900 DOI: http://dx.doi.org/10.17487/RFC7900 Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. This document is a product of the BGP Enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Jun 23 06:13:02 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 90DDD12D11B; Thu, 23 Jun 2016 06:13:01 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160623131301.31224.75289.idtracker@ietfa.amsl.com> Date: Thu, 23 Jun 2016 06:13:01 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-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: Thu, 23 Jun 2016 13:13:01 -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 EVPN Authors : Patrice Brissette Himanshu Shah Zhenbin Li Kishore Tiruveedhula Iftekar Hussain Jorge Rabadan Filename : draft-ietf-bess-evpn-yang-00.txt Pages : 12 Date : 2016-06-23 Abstract: This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. Any "add-on" features such as EVPN IRB, EVPN overlay, etc. are for future investigation. This document mainly focuses on EVPN and Ethernet-Segment instance framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-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 Thu Jun 23 07:27:10 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 61C4612D178 for ; Thu, 23 Jun 2016 07:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fox7rhe1rc1y for ; Thu, 23 Jun 2016 07:27:07 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 256C312D177 for ; Thu, 23 Jun 2016 07:27:07 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a66so52698599wme.0 for ; Thu, 23 Jun 2016 07:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=cnHzwEKZ6ES/D3y1MjvxUuwS62COUXy4rb2Xc56tH5Y=; b=o68IWEBEy2/ffqiLn0w5OZTQRLPHGvlNQy0iTkwoZlPafqiURRQ3RnVe9ScU76eAte pO/hL1pfGO4VD7zjeoTPPJSfyXDDK3CgLdGVg7bmAtLd3jYUuIAbfgdYLhd02SbXbD0R WOyr5r+rdC9McbvkDC7RIhP1kP5h9a4f9KZLIw8sDzWxaeL5bGLck7qttZx+L/HJ6Tzn WXjSIEO0wp/p4qP0Yp9Q7N7T8/cqkNhmkVqcStLcJIoRhahI4kdznrpziygrdra88Zpq 9KdtYg4HSKZG7H6nWnIAKFIXqiVHzQ9S65Q1hWfcYzIu0Dtj1R/Eyb68wShgTxLtdDWs eOBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=cnHzwEKZ6ES/D3y1MjvxUuwS62COUXy4rb2Xc56tH5Y=; b=Ijm8dLtKIQMtJJ1el+SgYpc4nNQArWbV9Z4T/RCpeDaMcpgHIAP7FllMYo34sswr18 FAYzLPFTfnyXZp1Ep8Lsp19nzYzKQZgqhuGNHIRudsqfeGHzZldhLjautANzG9mO1JG5 l5vqc79yZXrl+1DZv7U3LIm0LxrvRMv7Ag1SOdY1EjVBBlH3VsdKiOK+MVeyz35Meao/ bYc7GlxZFpL8fZH1EEUJW5/WfPf2f+ajHQ31xEv0jWmvWq5SDvVAS5EyCbfPHSMHMh7D 7LyS6HmCVRerWcJUu2oSk53NpiHYVt/6slwoUZIZo7IFT7P9Z/KZZj0hTKtsDFKALnNX KsJA== X-Gm-Message-State: ALyK8tJgaHT4FCkM7BOxNOTd7JlFbT+33CGS+LqvWZzSI/HZFTYwTCDFdj3m6Atd/ok58Q== X-Received: by 10.194.71.50 with SMTP id r18mr14642981wju.116.1466692025391; Thu, 23 Jun 2016 07:27:05 -0700 (PDT) Received: from [192.168.0.204] (94-43-130-14.dsl.utg.ge. [94.43.130.14]) by smtp.gmail.com with ESMTPSA id f140sm1012960wmf.22.2016.06.23.07.27.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 07:27:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.16.0.160506 Date: Thu, 23 Jun 2016 18:27:02 +0400 From: Jeff Tantsura To: , Message-ID: <78787BA3-0AA5-4031-B91D-D042E7D0848E@gmail.com> Thread-Topic: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 References: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> In-Reply-To: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: draft-boutros-bess-vxlan-evpn@tools.ietf.org Subject: Re: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-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: Thu, 23 Jun 2016 14:27:09 -0000 Hi, Support as co-author Not aware of any relevant undisclosed IPR. Thanks, Jeff >Hello working group, > >This email starts a two-week poll on adopting >draft-boutros-bess-vxlan-evpn-01 [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 *July 4th*. > >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-boutros-bess-vxlan-evpn-01 > >_________________________________________________________________________________________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >Thank you. > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess From nobody Fri Jun 24 09:07:55 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 52D3F12DD32; Fri, 24 Jun 2016 09:00:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160058.10933.99462.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:58 -0700 Archived-At: Cc: aretana@cisco.com, bess@ietf.org Subject: [bess] bess - Requested session has been scheduled for IETF 96 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, 24 Jun 2016 16:01:01 -0000 Dear Thomas Morin, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bess Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: BGP Enabled ServiceS Area Name: Routing Area Session Requester: Thomas Morin Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: rtgwg idr pals sfc sidr l3sm Second Priority: mpls spring pim nvo3 bier Third Priority: i2rs Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 12:54:17 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 AFFB612D1DE for ; Fri, 24 Jun 2016 12:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6a0x71HbMkI0 for ; Fri, 24 Jun 2016 12:54:13 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4660E12D158 for ; Fri, 24 Jun 2016 12:54:13 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 34740C0A64BA1 for ; Fri, 24 Jun 2016 19:54:07 +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 u5OJsASk030648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 24 Jun 2016 19:54:11 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 u5OJsAbP024535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jun 2016 21:54:10 +0200 Received: from [135.224.202.239] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 24 Jun 2016 21:54:09 +0200 Message-ID: <576D8FE1.9020303@alcatel-lucent.com> Date: Fri, 24 Jun 2016 21:54:09 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <5767CF26.4090906@alcatel-lucent.com> In-Reply-To: <5767CF26.4090906@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: Re: [bess] Slots requests for BESS WG session - IETF 96 - Berlin 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, 24 Jun 2016 19:54:15 -0000 All, our slot is confirmed. Please send your slot requests before the deadline indicated below. Thanks martin Le 20/06/2016 13:10, Martin Vigoureux a écrit : > All, > > it is time we start building the BESS WG agenda for Berlin. > The IETF agenda is available at: > https://datatracker.ietf.org/meeting/96/agenda.html > Please note that it is still a preliminary agenda. > > The BESS WG session (2h) is currently scheduled on > Thursday, 21st of July, Afternoon session I 14:00-16:00 (local time) > > Please send us your request for a presentation slot, indicating > draft name, speaker and desired duration (covering presentation + > discussion) > > Please send the requests no later than the 7th of July. > Thank you > > M&T > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Sun Jun 26 08:15:55 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 C8B8F12D0A3; Sun, 26 Jun 2016 08:15:49 -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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160626151549.6070.42464.idtracker@ietfa.amsl.com> Date: Sun, 26 Jun 2016 08:15:49 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2vpn-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: Sun, 26 Jun 2016 15:15:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : YANG Data Model for MPLS-based L2VPN Authors : Himanshu Shah Patrice Brissette Ing-When Chen Iftekar Hussain Bin Wen Filename : draft-ietf-bess-l2vpn-yang-00.txt Pages : 50 Date : 2016-06-26 Abstract: This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2vpn-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-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 Mon Jun 27 06:24:29 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 C5FAC12D0E3; Mon, 27 Jun 2016 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 jpfkusYst7Da; Mon, 27 Jun 2016 06:24:27 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B719612D0B7; Mon, 27 Jun 2016 06:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=544; q=dns/txt; s=iport; t=1467033867; x=1468243467; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=P3nyOj3JtE/K1/sQqxZ7dDFdjFSVBv+a0uWR+9qxjcw=; b=fPlksPHQ34D4J4ee758DdaxShn7GUWJIje+0n83KFwu2w1tsF/IHh6ed riflkxygmuheMNxpu0YAiL+ixUbE7SXZhlTo0CadhYDd1kILwS65p14BV +qGkqn9DxbPyL/X7Z6A/Ndq1d9j1NN349Bkiq59Tsz8hgBi/zSGuH8TSF E=; X-IronPort-AV: E=Sophos;i="5.26,536,1459814400"; d="scan'208";a="635396154" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 13:24:25 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5RDOOrm026588; Mon, 27 Jun 2016 13:24:25 GMT To: bess@ietf.org, draft-ietf-bess-l2vpn-yang@ietf.org From: Benoit Claise Message-ID: <42cf046c-26b9-ced0-c62f-f21b4143bfea@cisco.com> Date: Mon, 27 Jun 2016 15:24:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Benoit Claise Subject: [bess] YANG module in draft-ietf-bess-l2vpn-yang-00 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, 27 Jun 2016 13:24:29 -0000 Dear draft-ietf-bess-l2vpn-yang authors, We can't extract the YANG module in your draft. Therefore, we can't check the compilation. OLD: (CODE BEGINS) file "ietf-l2vpn@2016-05-31.yang" NEW: file "ietf-l2vpn@2016-05-31.yang" OLD: (CODE ENDS) NEW: Can you please let us know if this error was not flagged by idnits? You have the yangvalidator.com web site to help you if you want. Finally, note this was correct in https://tools.ietf.org/html/draft-shah-bess-l2vpn-yang-00 Regards, Benoit From nobody Tue Jun 28 09:23:40 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AE12D54F for ; Tue, 28 Jun 2016 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTgnQ_iBU8YY for ; Tue, 28 Jun 2016 09:23:36 -0700 (PDT) Received: from EX13-EDG-OU-002.vmware.com (ex13-edg-ou-002.vmware.com [208.91.0.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA1E12D54C for ; Tue, 28 Jun 2016 09:23:36 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (10.113.161.72) by EX13-EDG-OU-002.vmware.com (10.113.208.156) with Microsoft SMTP Server id 15.0.1156.6; Tue, 28 Jun 2016 09:23:29 -0700 Received: from EX13-CAS-003.vmware.com (ex13-cas-003.vmware.com [10.113.191.53]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 6783EB073C; Tue, 28 Jun 2016 09:23:35 -0700 (PDT) Received: from EX13-CAS-003.vmware.com (10.113.191.53) by EX13-MBX-027.vmware.com (10.113.191.47) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 28 Jun 2016 09:23:35 -0700 Received: from na01-by2-obe.outbound.protection.outlook.com (10.113.170.11) by EX13-CAS-003.vmware.com (10.113.191.53) with Microsoft SMTP Server (TLS) id 15.0.1156.6 via Frontend Transport; Tue, 28 Jun 2016 09:23:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hRPhByWKAujQGrJLzEXAJtEYHZcfSak/5mOyPNOh3rQ=; b=SaLO9JqdqtYx8y/bdvGspoiqF6VC1p7JpmNE8MGhN5UIzKjwE6kne46FeMu5Jybkf/cwP8OjHXRcVcEi15VR+DccFweKNY3cVaUP9dfCvIEVbnfN0tsxawF8Fwhma/onsaIG1vQZAwM4zRhCrH4FOUDhE6Rp2+04RMsG66m5/tw= Received: from CY1PR05MB2267.namprd05.prod.outlook.com (10.166.192.137) by CY1PR05MB2266.namprd05.prod.outlook.com (10.166.192.136) with Microsoft SMTP Server (TLS) id 15.1.517.8; Tue, 28 Jun 2016 16:23:32 +0000 Received: from CY1PR05MB2267.namprd05.prod.outlook.com ([10.166.192.137]) by CY1PR05MB2267.namprd05.prod.outlook.com ([10.166.192.137]) with mapi id 15.01.0517.016; Tue, 28 Jun 2016 16:23:32 +0000 From: Sami Boutros To: "thomas.morin@orange.com" Thread-Topic: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-01 Thread-Index: AQHRyva6C/QS5o0XbUucB+Q8UFgSWp//HOUw Date: Tue, 28 Jun 2016 16:23:32 +0000 Message-ID: <467E9674-3A24-4020-AC81-221EF4AEA2A8@vmware.com> References: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> In-Reply-To: <13757_1466426646_5767E516_13757_65_3_c07fe734-d3c2-09f5-cdd6-bac2e1117d9a@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sboutros@vmware.com; x-originating-ip: [172.56.38.194] x-ms-office365-filtering-correlation-id: 9c10ea7b-b9f7-4d5f-2a3c-08d39f708c4a x-microsoft-exchange-diagnostics: 1; CY1PR05MB2266; 20:+bjjTzVHPSUyvHeXbuwkiww4YxdiWF0NMIZcBWndDCjBHUA1puHV+Hvor+Amf6kxGlf/uk7dhGnFR4y0hWG+JH56sohogx0xCpuTCByTmJwRGnPIZzISXXvTGKvvtqJPIIB8IMtl3aYsOA4wwyZ++uDULoqXMn3twYnVvFsMp/s= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2266; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR05MB2266; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2266; x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(68736007)(9886003)(110136002)(2906002)(4326007)(97736004)(8936002)(5002640100001)(5890100001)(189998001)(7736002)(7846002)(99286002)(5003630100001)(586003)(11100500001)(2900100001)(77096005)(3660700001)(106356001)(2950100001)(106116001)(105586002)(2351001)(3846002)(102836003)(230783001)(15975445007)(305945005)(3280700002)(6116002)(10400500002)(92566002)(575784001)(86362001)(83716003)(66066001)(122556002)(81166006)(81156014)(8676002)(54356999)(82746002)(50986999)(101416001)(36756003)(76176999)(19580405001)(19580395003)(2501003)(5640700001)(87936001)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR05MB2266; H:CY1PR05MB2267.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (EX13-EDG-OU-002.vmware.com: sboutros@vmware.com does not designate permitted sender hosts) received-spf: None (protection.outlook.com: vmware.com 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-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 16:23:32.2491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2266 Archived-At: Cc: "draft-boutros-bess-vxlan-evpn@tools.ietf.org" , "bess@ietf.org" Subject: Re: [bess] Poll for adoption: draft-boutros-bess-vxlan-evpn-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, 28 Jun 2016 16:23:38 -0000 Support as a co-author and not aware of any ipr Thanks, Sami Sent from my iPhone > On Jun 20, 2016, at 6:22 AM, "thomas.morin@orange.com" wrote: >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting > draft-boutros-bess-vxlan-evpn-01 [1] as a Working Group Document. >=20 > Please state on the list if you support adoption or not (in both cases, p= lease also state the reasons). >=20 > This poll runs until *July 4th*. >=20 > 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). >=20 > 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. >=20 > No IPR has been disclosed against this Document. >=20 > If you are not listed as an author or contributor, then please explicitly= respond only if you are aware of any IPR that has not yet been disclosed i= n conformance with IETF rules. >=20 > Thank you >=20 > Martin & Thomas > bess chairs >=20 > [1] https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf.org_doc_draft-2Dboutros-2Dbess-2Dvxlan-2Devpn-2D01&d=3DCwICaQ&c=3DSqcl0E= z6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=3Dme053Be9qKrCJjUISJBP2sGFEDp-39GNm= gAhZLwv8aY&m=3DK1uFmxlFzD89U7uo4iRU6pSEhwdxCD42QGfWCXlgrvE&s=3D140df9Ysq87q= s5jbDwHs5EQStDRt1MUfX9BDVWX_qh8&e=3D=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Tue Jun 28 13:16:21 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 EF3B612D81F; Tue, 28 Jun 2016 13:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.028 X-Spam-Level: X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1ZyHl2BQsC0; Tue, 28 Jun 2016 13:16:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D3912D881; Tue, 28 Jun 2016 13:13:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2F82EB802ED; Tue, 28 Jun 2016 13:13:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160628201331.2F82EB802ED@rfc-editor.org> Date: Tue, 28 Jun 2016 13:13:31 -0700 (PDT) Archived-At: Cc: bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] RFC 7899 on Multicast VPN State Damping 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, 28 Jun 2016 20:16:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7899 Title: Multicast VPN State Damping Author: T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas Status: Standards Track Stream: IETF Date: June 2016 Mailbox: thomas.morin@orange.com, stephane.litkowski@orange.com, keyupate@cisco.com, zzhang@juniper.net, rkebler@juniper.net, jhaas@juniper.net Pages: 18 Characters: 41294 Updates: RFC 6514 I-D Tag: draft-ietf-bess-multicast-damping-06.txt URL: https://www.rfc-editor.org/info/rfc7899 DOI: http://dx.doi.org/10.17487/RFC7899 This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast. This document is a product of the BGP Enabled Services Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC