From nobody Fri Apr 1 07:04: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 E623912D5FC for ; Fri, 1 Apr 2016 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 G-7LbDJVSdO3 for ; Fri, 1 Apr 2016 07:04:13 -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 83D8212D5F8 for ; Fri, 1 Apr 2016 07:04:10 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id E83C41801CB for ; Fri, 1 Apr 2016 16:04:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id C3F3D1C007B for ; Fri, 1 Apr 2016 16:04:08 +0200 (CEST) Received: from [10.193.71.12] (10.168.234.1) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.279.2; Fri, 1 Apr 2016 16:04:08 +0200 To: References: <56F107CC.4020904@orange.com> <56FCD442.5000602@orange.com> From: Organization: Orange Message-ID: <31113_1459519448_56FE7FD8_31113_2214_1_56FE7FD7.7030509@orange.com> Date: Fri, 1 Apr 2016 16:04:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FCD442.5000602@orange.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.1] Archived-At: Subject: [bess] IETF 95 meeting, final agenda 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, 01 Apr 2016 14:04:20 -0000 Hi everyone, We've just posted an updated agenda (last minute cancellation of draft-hao-bess-evpn-centralized-df-00, replaced by draft-hu-bess-l2vpn-service-yang-00). https://www.ietf.org/proceedings/95/agenda/agenda-95-bess Useful links: - http://tools.ietf.org/wg/bess/agenda?item=agenda-95-bess.html - https://datatracker.ietf.org/meeting/95/materials#bess See you in Buenos Aires, -Thomas Thomas Morin : > The agenda posted below is the final agenda. > > Thank you, > See you the next in Buenos Aires! > > -Thomas > > 2016-03-22, Thomas Morin: >> Hi everyone >> >> We've just posted the **draft** agenda (still subject to changes) for >> our meeting in Buenos Aires: >> >> https://www.ietf.org/proceedings/95/agenda/agenda-95-bess >> >> We were not able to accommodate for all requests for time, thank you for >> your understanding. >> >> Best, >> >> -Thomas/Martin >> >> >> WG Status >> Co-Chairs, 10 min >> >> Yang models >> draft-dhjain-bess-bgp-l3vpn-yang >> draft-shah-bess-l2vpn-yang-01 >> draft-brissette-bess-evpn-yang-01 >> Patrice, 10min >> >> draft-li-bess-4pe-01 >> Zhenqiang, 10 min >> >> draft-zzhang-bess-evpn-bum-procedure-updates-01 >> Jeffrey, 15 min >> >> draft-rabadan-bess-evpn-pref-df-00 >> Jorge, 10 min >> >> draft-rabadan-bess-evpn-ac-df-03 >> Jorge, 5 min >> >> draft-rabadan-bess-vendor-evpn-route-00 >> Jorge, 10 min >> >> draft-boutros-bess-evpn-auto-provisioning-01 >> Rex or Sami, 10 min >> >> draft-boutros-bess-evpn-vpws-service-edge-gateway-02 >> Sami or Patrice, 10 min >> >> draft-lin-bess-evpn-irb-mcast-02 >> Wen, 10 min >> >> draft-sajassi-bess-evpn-l3vpn-multihoming-01 >> Ali, 10 min >> >> draft-hao-bess-evpn-centralized-df-00 >> Weiguo, 10 min >> >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess _________________________________________________________________________________________________________________________ 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 Fri Apr 1 09:44:45 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3110512D5BD; Fri, 1 Apr 2016 09:44:44 -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 q28BkuQ_5F1N; Fri, 1 Apr 2016 09:44:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2C512D0E6; Fri, 1 Apr 2016 09:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Zz/ip4/X2JPCmOI88vNPgXbMaBc3KfdEH73NEDyTAHw=; b=XljZBvb+3+4nQ6pjP1GxyS09vwgkOJPSwzp7MBofrnaRuv5IMHvSiLoNfn6+DR3zEDCcIA61NP8QnzTFHr+CrFTUlfElAeK+2XBC2ckY5xpBNNtkqO4feFQWZNDdhl2A+9tunm+3nEuWOVcEpa3zsIYVikcTXqmgM3ZAdosh/9s= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.79] (66.129.241.12) by BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 1 Apr 2016 16:44:25 +0000 To: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <56FEA566.8070605@juniper.net> Date: Fri, 1 Apr 2016 12:44:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CO2PR05CA016.namprd05.prod.outlook.com (10.141.241.144) To BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) X-MS-Office365-Filtering-Correlation-Id: 8e17178c-0c28-42d3-a7c9-08d35a4ce341 X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 2:aUVinLXzMV79zn8bKLJHSXVcBIJfxnHsP6PAeFj4bpPNqPfgfXcSbnxlaUo+L0iVPuSLRS65mwvJ+kGwRKFuxb3L+/QeGM3aTC4+xGYYwU1Gmn2mELTPaaNPACQp1WBrJP4dyqnYDhvxFjJygJe1tXtyqZGfRrDrgFzIkNNJI87zA1CPNRrfJu+Ag4bdkAFC; 3:FTV4V+Mdd83KHyzz5grGRhwCr0nT7IOzFQkO9uaYyPYY5tg8VeeRoEEgGWX5k6mX9AYQsylBVeRq+G6lZN0qBQdPZrI127/5INlGQKDG76V9sszclAhjNOMDm9YwVPhm; 25:7ry7+PgnVnMgpxej4/6fxYnBsifu2DJlIHO6rA0HxJtbBWNLrGyEH/91cH0A2NLQMMVy90cagy1GFsk2WoKAqeYwzL9oWr3eWwBj6tc4f38seOcpAlkDn0sMv1lc4ABHse4Qk80YxrfS1g/AAPAl0wi0ClOrI0ZvDqNmohM74byEua4Bz0t0bOhZpl21cbmN4KXAlwmo+eqhPanVoZcrRWxUsOZAtUjQjOt7F6IeGbdisqoTdl7i7P5TRovY+46RQEsXpf760yN/YffCI5QnCl60PvRa8kAfLXB/ZBA0JtXZjiVl8MOigaeBYuUzCRx2maU/8QMJ4wiFIpSVnd/koxoDEECHucPL8IefoyBJPAN8fh5WaJvzc1yZCi+dcmgUP2ef7G4L2X4ophGYxl+jbb4Gt7TkiVl/Jy3qD5cySm+/AuAkctfKb+0kGHztTbz04iXTu2mO9CxIFgh9S7DCNiwcIyBsy4uJNPRcJ6vliYSy7hv5O/qGDjSNOa8D3fUHQ8gBSlZVh/S+DnUpGhM8FiqZeVr9M8jqPCBIhTiWTnNMZ6lu6deaLRrnkp8IHAOnDKJ14WRMv2PGDgn7D9nH2NcZD8ab0MLSNY5RUqNiU2c= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB789; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 20:EUDeOr20k3VPNo1HF6RrGQRykRcMkejZvTFLTCQtYqry58DxWHqr7/Bfd+bxNq/JElhESGSK4ozMOdxdEn33994bJeV8c7PSXXZ3f0YP/kUd71RG5p50lSnR08Pfqzk9U2R5EvwXnqgp14/OhwxXYyjwr5rIelL1DkWmbvr6qT9l8YlImhgC4Ea+WvkqCyTBjYk9QYWmjmsQrjQBLZoUJIpdJt4CNSTE5/JSQSwlrKJ8fUh+AiA7YS+3u3NLXQ91AoqIKlRlvhWBDXq/BaDwHBuGJmSfT76AlqAROFx5C13tejTTZY6KW3f5OMm9kVdTj3gMX/wTvrgzxOx01VYuqFquTe7aiPG4xqSRBiBOgC7xl8uYmgD0X3m+V0agFOlVguN7MmYDnAXa8gc0m2T+upZlbheA0kt3kd/ExxYXr3v6wmol8K9MzgFoFO46pKQKzHqinYZQ9qT1trE3+by1M6SN5vsUxM1el0gn5mdyOZEGny2tFqEZiGtscaoyixl7; 4:2/28Rf9has5bTM39r3zbUh3JUHPvfic5rmvM/QuyCfZNU23HmfRazKRJD/sYmUs4g79BlcCK+KJ7gbliD4gffBh29ZWOFKYCiL1ErkAQYDte2KTAl+dlYvwLycUycU5zK4LCJwerRz0MXMRUriNmP2NI0X1FwBQFArn+dS59K5WQPJ3/NcgnDHq34w7l9RRvlLNKYug8Waf/XSSSh+LA9jzmkvTeXbI69Gc0uLVixA/r+4FMa9o4Sa+DCPRFEeO0mIduxoq3TIVx99CCJOFean9f8KHLZbja2+3XjgYsi57efRr3uXDKaJUQ8wqcXwWbERu+0Ahv2o2qZVirTIXPVtfznd1hQong7dM0s2oO4k1RNzz3IbxeutlgIAC66CkB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB789; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB789; X-Forefront-PRVS: 0899B47777 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(1096002)(2906002)(110136002)(19580405001)(19580395003)(586003)(4326007)(81166005)(230700001)(23746002)(6116002)(65816999)(3846002)(83506001)(87266999)(189998001)(33656002)(76176999)(86362001)(54356999)(59896002)(50986999)(230783001)(36756003)(92566002)(42186005)(47776003)(65806001)(77096005)(5008740100001)(64126003)(4001350100001)(5004730100002)(50466002)(2351001)(66066001)(65956001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB789; H:[172.29.37.79]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR05MB789; 23:mG6DXgLMZdxXxbkBuMvht4mv4Qpw9GedWhp2tq?= =?Windows-1252?Q?avOKB8aaYng5q3XQBlNbj+8B+ZRDXPdY58vf9kVR+QohcAha89zki3WG?= =?Windows-1252?Q?iokek0MJD1U04pfcSTq7X253yJt3/DRJ23WaOAvZEQ115U2ugAIPWF65?= =?Windows-1252?Q?kXF083QCH2LH/i+ZbdqhAPEmMsM53qybLz03cGuuSWSungHPSrSHEuUZ?= =?Windows-1252?Q?RUmB5pKEgDp+cr/eb+WB/JFeOowhyAY6oi3UUQTIzq/gm/o/21bbu8jy?= =?Windows-1252?Q?JLi0nTOTuGzzv5yIYH3CBdfdYUDutpN/xNAV29JMOJczkfgkQ45gC315?= =?Windows-1252?Q?m+RszANlpVuW6o1glF1kTmQ0U/JZtrv0bCbNpBEPoU1U6NYxlKa1iSSj?= =?Windows-1252?Q?I5VMBWJHyUK3VoGxUCKWsaoU44feZvj+8Rlyw9WhvsmgD1bWVM5TsET3?= =?Windows-1252?Q?T1XdJ7X87YOLXuEAGVLbQzTkVMNFsyO6L7rUVpsBWC/BoTzct+MSYzKh?= =?Windows-1252?Q?NZ6naudhoIA7HkdDUftwC+Gnzn39OGHkS9nuHjOPKM8QcGTD0XVV7rGT?= =?Windows-1252?Q?QPrmAup1c6vly6FkbKaIwaZH84HZkXMi7YpMnjckckDHugCK/h+SfwkT?= =?Windows-1252?Q?0P0KuFy38R6f8tiYIAdjJERLknYhFpg/0L7JoI67tfXlMMLl0mPApZl+?= =?Windows-1252?Q?wUKs+6wuUIfI/wpioErYvfUVI4Y8JlnJu6E2ZD8LCYUZVwGYzX+AcFnJ?= =?Windows-1252?Q?AM6p85w3o6zLnP/TqFMn888H/kTQOZ3TY89Vj4Km38iHvT3ILlqpY098?= =?Windows-1252?Q?dpJbSuDU12MVNfsQ6xa5dmdlP1+qhL6+viC8E9EWoo1Q9kexBgBJ9vG/?= =?Windows-1252?Q?3Rp65THKwyVpxst5xcBMfnz3pMr5/FEplhYMD0ScP6tmd7nQkNZr9zLC?= =?Windows-1252?Q?iZS4WrM7t5QlPh2iQElgqdUcbZJ75yEyAwR+4EKGlb/S+c9MKt9Vqet0?= =?Windows-1252?Q?RAwsT9kRDSZpTlqnlPog2a+KOfsJVBi7219UUVNOK1X3g9p4qeaZylqt?= =?Windows-1252?Q?z+NCf4zgyxYimSE60U45pkj2hlqMCWS8tYYlv/SR8b7bv65TrYFat9Ra?= =?Windows-1252?Q?2IwplXeGikkrK3YWhxVxfg1sDqBN+XGLZoiUYfXeMB29H7RRX4UaQQ4W?= =?Windows-1252?Q?K661vfxMv2er8QtwEoD8NKCxDsgXY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 5:I883HiG4FtgkIPrdUG++HGAEihD1bRwZa/whEhD4yATimQp341Jt9kaWMVbTjujEO2HMOe1ZKfYxDiYaF5QRt3WJqt/i+wsk25U3MtVEBSku44bNXfRRLTA7v9AfB6F5jCmS7oRtbXkcvLcCKxKJlg==; 24:0r0wNmBQbZSqx6Ke/C92CzD9wfnOZ+EH+JzbKypkcHGBP8mFTd6E2ZnWxd+R99lG7stMOpNS2rZbWA/Y925buU067OhXK6cLHBz1oHek6Lc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2016 16:44:25.6117 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB789 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 16:44:44 -0000 On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote: >> I'm quite sure you have deployed implementations, from several >> prominent vendors, that will not properly handle this case. > I'm waiting for this/these implementation(s) to make a public statement in this thread / IETF WGs. Then we can discuss whether the issue comes from RFCF3107 or from the implementation. > If none make a public statement, we should assume that all implementations are capable of receiving multiple labels, as per RFC 3107. I strongly disagree with this. We should not ignore the facts just because you don't like the way the facts were gathered. A better approach would be to have operators state whether they have any deployments in which the "multiple labels" feature is used in a multi-vendor environment. It is very useful when working on a "bis" draft to determine which features have been proven to work in a multi-vendor environment and which have not. > Any non-compliant implementation may create interoperability issues and unpredictable results. > From an IETF standpoint, the question is whether a RFC 3107 implementation would create interoperability issues, up to shutting down the BGP session. There are deployed 3107 implementations which always assume that the NLRI contains a single label. If you tried to interwork these with 3107 implementations that send multiple labels , you will experience the kind of disruption. 3107bis tries to allow the use of multiple labels while preventing this sort of disruption from occurring. > If you mean that some non-compliant implementation do not work, well let's fix them. The situation is that there is a commonly deployed "bug" in old implementations, but it is not seen because the bug is in a feature that no one has been using. If new implementations use that feature, the bug will be seen, and network disruption will occur. One could say "fix all the old implementations", but it seems wiser to have new implementations avoid tickling the bug. The Capability is not proposed for the purpose of helping the vendors, it's there to help the operators. I'm not sure why you think there would be BGP session drops due to 3107bis; if a 3107 implementation sends multiple labels to a 3107bis implementation, I think the 3107bis implementation would do "treat-as-withdraw" rather than "drop the session". Perhaps a reasonable approach for 3107bis would be the following: - A 3107bis implementation will not send multiple labels to a peer unless the Capability has been received from that peer. (This prevents 3107bis implementations from tickling the 'bug' in 3107 implementations.) - A 3107bis implementation will accept multiple labels from a peer even in the absence of the Capability. Another approach would be to have a knob that determines whether the Capability needs to be used before multiple labels are advertised. From nobody Fri Apr 1 13:23:48 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 EEF4912D156; Fri, 1 Apr 2016 13:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h73Il-Tb0-NS; Fri, 1 Apr 2016 13:23:44 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 E364F12D12D; Fri, 1 Apr 2016 13:23:43 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id c62so89172882lfc.1; Fri, 01 Apr 2016 13:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=uDRJYAXvbRym6A35usQU+r7luvsXrmbHXXD9FzfkpoY=; b=O5a5AF97/e8uZXl6qvMF3v5rfrWetU3+zF/R/X9AzKh3bzlVNDTglBP9vaU65DplqP DQg+hmCwVTW1Rcye8mp15iwcyAJVZHhVZ3uZX+JSsT2GttOYAb2j5dY66A7aZfBCQe6h yCXMVLIfHjzNqt2rS8/4tTfo+VnnunP+2I3UNG+L53AJS+/71d9NOzuMkC//HJf2jVYU 3GX9b6PufluIIuJiUcp7YKUHNo+rtO/tFZ1uAo0Iyqou6GCftlbAILDTeK0/Wh9BBmXk cLBGgztqz7R/YJHcZ5bS9iFIivL55TZCpt+tjHGel2yao3uEshdwAEzrG85IkUVeNPYU F42w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uDRJYAXvbRym6A35usQU+r7luvsXrmbHXXD9FzfkpoY=; b=ksZAsmWm4XWyIMPnSDALT4jweVytUy6fefcImrMMcwTPOW6rbZM8FZNWkx2yX1wIP8 1ij/FUeJZCbxYQJ51KLueodPNzDt4UcoubGtrGWk4yqP3NYy1okqLJBRQHsDbFGkjYmZ 1zXIp3MYAKHehGsTo1jFrGnHHCKzxSCyO8SWD9DQDTg9NOxUj4OVCzkwMYPB2yNCvr21 k7bE+D4Li+TvVSqYKyyl34rtfPn+MawD/7xEAGbYxZwOj/ZCFFb33FOKDQapHS+tTZvk hx4hGCil05bvNqCYClyRFlW6fSxyc3dpZiZOKFkWrLWYE9G0vQfxTgQ5jPYBnxcN+ADu +i9g== X-Gm-Message-State: AD7BkJIlGhP3rbU6J3UH46b8KdCJ/KutbfBRUPN8fvhOk2cPxTqVxfvpsTNj5flpk8C8+KzlFjyIuxxuWVdwTw== MIME-Version: 1.0 X-Received: by 10.25.208.143 with SMTP id h137mr2173652lfg.110.1459542222039; Fri, 01 Apr 2016 13:23:42 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Fri, 1 Apr 2016 13:23:41 -0700 (PDT) In-Reply-To: <56FEA566.8070605@juniper.net> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> Date: Fri, 1 Apr 2016 22:23:41 +0200 X-Google-Sender-Auth: oQF1mYQ0WpUUx18jPcdW5sUC2PM Message-ID: From: Robert Raszuk To: Eric C Rosen Content-Type: multipart/alternative; boundary=001a11411876adf28d052f72274c Archived-At: Cc: Bruno Decraene , "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 20:23:47 -0000 --001a11411876adf28d052f72274c Content-Type: text/plain; charset=UTF-8 Hi Eric, I have read your proposed draft as well as watched this thread with a bit of an interest. To me the best compromise - which is to agree with Bruno's points as well as address your intentions is simply to request new SAFI for 3107bis. >From the draft you are really not updating 3107 base spec but obsoleting it which to me looks like a bad idea. You are even requesting to remove IANA reference to original spec. How would IANA know when is it safe to do that .. meaning when all implementations will not suddenly support and all deployments will enable 3107bis ? New SAFI requires a new capability which you are asking for anyway. As far as implementations please keep in mind very important point that some implementations treat SAFI 1 & 4 in single table and some in separate tables. That when mixed with 3107bis may just explode if not in new set of bugs then with operational nightmare. While we are at this it would be much cleaner to mandate in the new spec to have 3107bis always to use separate tables as compared with from SAFI 1. Thx, Robert. PS. As we all know 3107(bis) tries to add NNI to MPLS. However it must be very well stated that this is only one deployment option for interdomain encapsulation. I would very much like to see a section indicating that IPv6 or/and IPv4 be used as an alternative encap for those applications which require it and when needed provide local bindings between intradomain MPLS and interdomain IP. On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen wrote: > On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote: > >> I'm quite sure you have deployed implementations, from several >>> prominent vendors, that will not properly handle this case. >>> >> I'm waiting for this/these implementation(s) to make a public statement >> in this thread / IETF WGs. Then we can discuss whether the issue comes from >> RFCF3107 or from the implementation. >> If none make a public statement, we should assume that all >> implementations are capable of receiving multiple labels, as per RFC 3107. >> > I strongly disagree with this. We should not ignore the facts just > because you don't like the way the facts were gathered. > > A better approach would be to have operators state whether they have any > deployments in which the "multiple labels" feature is used in a > multi-vendor environment. It is very useful when working on a "bis" draft > to determine which features have been proven to work in a multi-vendor > environment and which have not. > > Any non-compliant implementation may create interoperability issues and >> unpredictable results. >> From an IETF standpoint, the question is whether a RFC 3107 >> implementation would create interoperability issues, up to shutting down >> the BGP session. >> > > There are deployed 3107 implementations which always assume that the NLRI > contains a single label. If you tried to interwork these with 3107 > implementations that send multiple labels , you will experience the kind of > disruption. 3107bis tries to allow the use of multiple labels while > preventing this sort of disruption from occurring. > > If you mean that some non-compliant implementation do not work, well let's >> fix them. >> > > The situation is that there is a commonly deployed "bug" in old > implementations, but it is not seen because the bug is in a feature that no > one has been using. If new implementations use that feature, the bug will > be seen, and network disruption will occur. One could say "fix all the old > implementations", but it seems wiser to have new implementations avoid > tickling the bug. The Capability is not proposed for the purpose of > helping the vendors, it's there to help the operators. > > I'm not sure why you think there would be BGP session drops due to > 3107bis; if a 3107 implementation sends multiple labels to a 3107bis > implementation, I think the 3107bis implementation would do > "treat-as-withdraw" rather than "drop the session". > > Perhaps a reasonable approach for 3107bis would be the following: > > - A 3107bis implementation will not send multiple labels to a peer unless > the Capability has been received from that peer. (This prevents 3107bis > implementations from tickling the 'bug' in 3107 implementations.) > > - A 3107bis implementation will accept multiple labels from a peer even in > the absence of the Capability. > > Another approach would be to have a knob that determines whether the > Capability needs to be used before multiple labels are advertised. > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --001a11411876adf28d052f72274c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

I have read your proposed draft as well as watched t= his thread with a bit of an interest.=C2=A0

To me the best compromise - which is to agree with Br= uno's points as well as address your intentions is simply to request ne= w SAFI for 3107bis.=C2=A0

From the draft you are really not updating 3107 base spec but obsoletin= g it which to me looks like a bad idea.=C2=A0

<= /div>
You are even requesting to remove IANA reference to= original spec. How would IANA know when is it safe to do that .. meaning w= hen all implementations will not suddenly support and all deployments will = enable 3107bis ?=C2=A0

New SAFI requires a new capability which you are asking for anyway.=C2= =A0

As far as implemen= tations please keep in mind very important point that some implementations = treat SAFI 1 & 4 in single table and some in separate tables. That when= mixed with 3107bis may just explode if not in new set of bugs then with op= erational nightmare. While we are at this it would be much cleaner to manda= te in the new spec to have 3107bis always to use separate tables as compare= d with from SAFI 1.

Th= x,
Robert.

PS.=C2=A0

As we all know 3107(bis) tries to add NNI to MPLS. However it must be ver= y well stated that this is only one deployment option for interdomain encap= sulation. I would very much like to see a section indicating that IPv6 or/a= nd IPv4 be used as an alternative encap for those applications which requir= e it and when needed provide local bindings between intradomain MPLS and in= terdomain IP.=C2=A0


On Fri, Apr 1, 2016 at 6:44 PM, = Eric C Rosen <erosen@juniper.net> wrote:
On 3/25/2016 7:25 AM, bruno.decraene@orange.com wr= ote:
I'm quite sure you have deployed=C2=A0 implementations, from several prominent vendors, that will not properly handle this case.
I'm waiting for this/these implementation(s) to make a public statement= in this thread / IETF WGs. Then we can discuss whether the issue comes fro= m RFCF3107 or from the implementation.
If none make a public statement, we should assume that all implementations = are capable of receiving multiple labels, as per RFC 3107.
 I strongly disagree with this.=C2=A0 We should not ignore the facts just be= cause you don't like the way the facts were gathered.

A better approach would be to have operators state whether they have any de= ployments in which the "multiple labels" feature is used in a mul= ti-vendor environment.=C2=A0 It is very useful when working on a "bis&= quot; draft to determine which features have been proven to work in a multi= -vendor environment and which have not.

Any non-compliant implementation may create interoperability issues and unp= redictable results.
=C2=A0From an IETF standpoint, the question is whether a RFC 3107 implement= ation would create interoperability issues, up to shutting down the BGP ses= sion.

 There are deployed 3107 implementations which always assume that the NLRI c= ontains a single label.=C2=A0 If you tried to interwork these with 3107 imp= lementations that send multiple labels , you will experience the kind of di= sruption.=C2=A0 3107bis tries to allow the use of multiple labels while pre= venting this sort of disruption from occurring.

If you mean that some non-compliant implementation do not work, well let= 9;s fix them.

 The situation is that there is a commonly deployed "bug" in old i= mplementations, but it is not seen because the bug is in a feature that no = one has been using.=C2=A0 If new implementations use that feature, the bug = will be seen, and network disruption will occur. One could say "fix al= l the old implementations", but it seems wiser to have new implementat= ions avoid tickling the bug.=C2=A0 =C2=A0The Capability is not proposed=C2= =A0 for the purpose of helping the vendors, it's there to help the oper= ators.

I'm not sure why you think there would be BGP session drops due to 3107= bis; if a 3107 implementation sends multiple labels to a 3107bis implementa= tion, I think the 3107bis implementation would do "treat-as-withdraw&q= uot; rather than "drop the session".

Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer unless t= he Capability has been received from that peer.=C2=A0 (This prevents 3107bi= s implementations from tickling the 'bug' in 3107 implementations.)=

- A 3107bis implementation will accept multiple labels from a peer even in = the absence of the Capability.

Another approach would be to have a knob that determines whether the Capabi= lity needs to be used before multiple labels are advertised.


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

--001a11411876adf28d052f72274c-- From nobody Fri Apr 1 14:29: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 212A412D6F9; Fri, 1 Apr 2016 14:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7gXc8gczci3i; Fri, 1 Apr 2016 14:29:17 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67E212D6F7; Fri, 1 Apr 2016 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21587; q=dns/txt; s=iport; t=1459546155; x=1460755755; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W73FyA6eIwz+tfnYr9jw5O4T+4GSwasDmZLa1mNCgY8=; b=IMzvxgJ2S5NycI/q7aNZnjbw41pc4hw7WlID0pdeQ9nut/qcUtvqvEkV AlNkzBheHZZZFCdHhPp04K42vxnxHlnvtpTeLtfo/9j44pUxSqZP0rtJU iJqengmGHFHLKCpuCCyTZbmeOTyhuWO3sf3hyZLzHQv3cFJaAzyJRKmNA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8BADI5v5W/xbLJq1dgnWBH30GtiCGb?= =?us-ascii?q?xcBCYVsAhyBdwEBAQEBAWYnhEEBAQEEAQEBIEsLEAIBCBEDAQIoAwICAiULFAk?= =?us-ascii?q?IAQEEAQ0FiCcOsyuRFgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEiWV/hFQKDYJTg?= =?us-ascii?q?lYFkxWEZAGOB4FmhE2DKIUyjxcBYoNnbIdofgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,428,1454976000"; d="scan'208,217";a="634937293" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2016 21:29:12 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u31LTBq2018903 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 21:29:12 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 17:29:10 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 1 Apr 2016 17:29:10 -0400 From: "Acee Lindem (acee)" To: Robert Raszuk , Eric C Rosen Thread-Topic: [Idr] [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AdGF3GeY7oYpWXlDQPavaGqQ0wDeuZ9p2nRA4KMbRwCAAD1GgP//zzqA Date: Fri, 1 Apr 2016 21:29:10 +0000 Message-ID: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> In-Reply-To: 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: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D3245FC256368aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: Bruno Decraene , "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] [Idr] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 21:29:25 -0000 --_000_D3245FC256368aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIHRoaW5rIHRoaXMgd291bGQgZGVmZWF0IHRoZSBwdXJwb3NlIG9mIGNs YXJpZnlpbmcgUkZDIDMxMDEgbXVsdGktbGFiZWwgYmVoYXZpb3IgaW4gYSBCSVMgZHJhZnQuIExl dOKAmXMgc2VlIGlmIHdlIGNhbiByZWFjaCBjb25zZW5zdXMgZmlyc3QuDQoNClRoYW5rcywNCkFj ZWUNCg0KRnJvbTogSWRyIDxpZHItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWRyLWJvdW5jZXNA aWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8 bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NCkRhdGU6IEZyaWRheSwgQXByaWwgMSwgMjAxNiBh dCA0OjIzIFBNDQpUbzogRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ8bWFpbHRvOmVy b3NlbkBqdW5pcGVyLm5ldD4+DQpDYzogQnJ1bm8gRGVjcmFlbmUgPGJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiwgIm1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRm Lm9yZz4+LCBCRVNTIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4sIElEUiBM aXN0IDxpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0lk cl0gW2Jlc3NdIGRyYWZ0LXJvc2VuLW1wbHMtcmZjMzEwN2Jpcw0KDQpIaSBFcmljLA0KDQpJIGhh dmUgcmVhZCB5b3VyIHByb3Bvc2VkIGRyYWZ0IGFzIHdlbGwgYXMgd2F0Y2hlZCB0aGlzIHRocmVh ZCB3aXRoIGEgYml0IG9mIGFuIGludGVyZXN0Lg0KDQpUbyBtZSB0aGUgYmVzdCBjb21wcm9taXNl IC0gd2hpY2ggaXMgdG8gYWdyZWUgd2l0aCBCcnVubydzIHBvaW50cyBhcyB3ZWxsIGFzIGFkZHJl c3MgeW91ciBpbnRlbnRpb25zIGlzIHNpbXBseSB0byByZXF1ZXN0IG5ldyBTQUZJIGZvciAzMTA3 YmlzLg0KDQpGcm9tIHRoZSBkcmFmdCB5b3UgYXJlIHJlYWxseSBub3QgdXBkYXRpbmcgMzEwNyBi YXNlIHNwZWMgYnV0IG9ic29sZXRpbmcgaXQgd2hpY2ggdG8gbWUgbG9va3MgbGlrZSBhIGJhZCBp ZGVhLg0KDQpZb3UgYXJlIGV2ZW4gcmVxdWVzdGluZyB0byByZW1vdmUgSUFOQSByZWZlcmVuY2Ug dG8gb3JpZ2luYWwgc3BlYy4gSG93IHdvdWxkIElBTkEga25vdyB3aGVuIGlzIGl0IHNhZmUgdG8g ZG8gdGhhdCAuLiBtZWFuaW5nIHdoZW4gYWxsIGltcGxlbWVudGF0aW9ucyB3aWxsIG5vdCBzdWRk ZW5seSBzdXBwb3J0IGFuZCBhbGwgZGVwbG95bWVudHMgd2lsbCBlbmFibGUgMzEwN2JpcyA/DQoN Ck5ldyBTQUZJIHJlcXVpcmVzIGEgbmV3IGNhcGFiaWxpdHkgd2hpY2ggeW91IGFyZSBhc2tpbmcg Zm9yIGFueXdheS4NCg0KQXMgZmFyIGFzIGltcGxlbWVudGF0aW9ucyBwbGVhc2Uga2VlcCBpbiBt aW5kIHZlcnkgaW1wb3J0YW50IHBvaW50IHRoYXQgc29tZSBpbXBsZW1lbnRhdGlvbnMgdHJlYXQg U0FGSSAxICYgNCBpbiBzaW5nbGUgdGFibGUgYW5kIHNvbWUgaW4gc2VwYXJhdGUgdGFibGVzLiBU aGF0IHdoZW4gbWl4ZWQgd2l0aCAzMTA3YmlzIG1heSBqdXN0IGV4cGxvZGUgaWYgbm90IGluIG5l dyBzZXQgb2YgYnVncyB0aGVuIHdpdGggb3BlcmF0aW9uYWwgbmlnaHRtYXJlLiBXaGlsZSB3ZSBh cmUgYXQgdGhpcyBpdCB3b3VsZCBiZSBtdWNoIGNsZWFuZXIgdG8gbWFuZGF0ZSBpbiB0aGUgbmV3 IHNwZWMgdG8gaGF2ZSAzMTA3YmlzIGFsd2F5cyB0byB1c2Ugc2VwYXJhdGUgdGFibGVzIGFzIGNv bXBhcmVkIHdpdGggZnJvbSBTQUZJIDEuDQoNClRoeCwNClJvYmVydC4NCg0KUFMuDQoNCkFzIHdl IGFsbCBrbm93IDMxMDcoYmlzKSB0cmllcyB0byBhZGQgTk5JIHRvIE1QTFMuIEhvd2V2ZXIgaXQg bXVzdCBiZSB2ZXJ5IHdlbGwgc3RhdGVkIHRoYXQgdGhpcyBpcyBvbmx5IG9uZSBkZXBsb3ltZW50 IG9wdGlvbiBmb3IgaW50ZXJkb21haW4gZW5jYXBzdWxhdGlvbi4gSSB3b3VsZCB2ZXJ5IG11Y2gg bGlrZSB0byBzZWUgYSBzZWN0aW9uIGluZGljYXRpbmcgdGhhdCBJUHY2IG9yL2FuZCBJUHY0IGJl IHVzZWQgYXMgYW4gYWx0ZXJuYXRpdmUgZW5jYXAgZm9yIHRob3NlIGFwcGxpY2F0aW9ucyB3aGlj aCByZXF1aXJlIGl0IGFuZCB3aGVuIG5lZWRlZCBwcm92aWRlIGxvY2FsIGJpbmRpbmdzIGJldHdl ZW4gaW50cmFkb21haW4gTVBMUyBhbmQgaW50ZXJkb21haW4gSVAuDQoNCg0KT24gRnJpLCBBcHIg MSwgMjAxNiBhdCA2OjQ0IFBNLCBFcmljIEMgUm9zZW4gPGVyb3NlbkBqdW5pcGVyLm5ldDxtYWls dG86ZXJvc2VuQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQpPbiAzLzI1LzIwMTYgNzoyNSBBTSwgYnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4g d3JvdGU6DQpJJ20gcXVpdGUgc3VyZSB5b3UgaGF2ZSBkZXBsb3llZCAgaW1wbGVtZW50YXRpb25z LCBmcm9tIHNldmVyYWwNCnByb21pbmVudCB2ZW5kb3JzLCB0aGF0IHdpbGwgbm90IHByb3Blcmx5 IGhhbmRsZSB0aGlzIGNhc2UuDQpJJ20gd2FpdGluZyBmb3IgdGhpcy90aGVzZSBpbXBsZW1lbnRh dGlvbihzKSB0byBtYWtlIGEgcHVibGljIHN0YXRlbWVudCBpbiB0aGlzIHRocmVhZCAvIElFVEYg V0dzLiBUaGVuIHdlIGNhbiBkaXNjdXNzIHdoZXRoZXIgdGhlIGlzc3VlIGNvbWVzIGZyb20gUkZD RjMxMDcgb3IgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24uDQpJZiBub25lIG1ha2UgYSBwdWJsaWMg c3RhdGVtZW50LCB3ZSBzaG91bGQgYXNzdW1lIHRoYXQgYWxsIGltcGxlbWVudGF0aW9ucyBhcmUg Y2FwYWJsZSBvZiByZWNlaXZpbmcgbXVsdGlwbGUgbGFiZWxzLCBhcyBwZXIgUkZDIDMxMDcuDQpJ IHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggdGhpcy4gIFdlIHNob3VsZCBub3QgaWdub3JlIHRoZSBm YWN0cyBqdXN0IGJlY2F1c2UgeW91IGRvbid0IGxpa2UgdGhlIHdheSB0aGUgZmFjdHMgd2VyZSBn YXRoZXJlZC4NCg0KQSBiZXR0ZXIgYXBwcm9hY2ggd291bGQgYmUgdG8gaGF2ZSBvcGVyYXRvcnMg c3RhdGUgd2hldGhlciB0aGV5IGhhdmUgYW55IGRlcGxveW1lbnRzIGluIHdoaWNoIHRoZSAibXVs dGlwbGUgbGFiZWxzIiBmZWF0dXJlIGlzIHVzZWQgaW4gYSBtdWx0aS12ZW5kb3IgZW52aXJvbm1l bnQuICBJdCBpcyB2ZXJ5IHVzZWZ1bCB3aGVuIHdvcmtpbmcgb24gYSAiYmlzIiBkcmFmdCB0byBk ZXRlcm1pbmUgd2hpY2ggZmVhdHVyZXMgaGF2ZSBiZWVuIHByb3ZlbiB0byB3b3JrIGluIGEgbXVs dGktdmVuZG9yIGVudmlyb25tZW50IGFuZCB3aGljaCBoYXZlIG5vdC4NCg0KQW55IG5vbi1jb21w bGlhbnQgaW1wbGVtZW50YXRpb24gbWF5IGNyZWF0ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcyBh bmQgdW5wcmVkaWN0YWJsZSByZXN1bHRzLg0KIEZyb20gYW4gSUVURiBzdGFuZHBvaW50LCB0aGUg cXVlc3Rpb24gaXMgd2hldGhlciBhIFJGQyAzMTA3IGltcGxlbWVudGF0aW9uIHdvdWxkIGNyZWF0 ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcywgdXAgdG8gc2h1dHRpbmcgZG93biB0aGUgQkdQIHNl c3Npb24uDQoNClRoZXJlIGFyZSBkZXBsb3llZCAzMTA3IGltcGxlbWVudGF0aW9ucyB3aGljaCBh bHdheXMgYXNzdW1lIHRoYXQgdGhlIE5MUkkgY29udGFpbnMgYSBzaW5nbGUgbGFiZWwuICBJZiB5 b3UgdHJpZWQgdG8gaW50ZXJ3b3JrIHRoZXNlIHdpdGggMzEwNyBpbXBsZW1lbnRhdGlvbnMgdGhh dCBzZW5kIG11bHRpcGxlIGxhYmVscyAsIHlvdSB3aWxsIGV4cGVyaWVuY2UgdGhlIGtpbmQgb2Yg ZGlzcnVwdGlvbi4gIDMxMDdiaXMgdHJpZXMgdG8gYWxsb3cgdGhlIHVzZSBvZiBtdWx0aXBsZSBs YWJlbHMgd2hpbGUgcHJldmVudGluZyB0aGlzIHNvcnQgb2YgZGlzcnVwdGlvbiBmcm9tIG9jY3Vy cmluZy4NCg0KSWYgeW91IG1lYW4gdGhhdCBzb21lIG5vbi1jb21wbGlhbnQgaW1wbGVtZW50YXRp b24gZG8gbm90IHdvcmssIHdlbGwgbGV0J3MgZml4IHRoZW0uDQoNClRoZSBzaXR1YXRpb24gaXMg dGhhdCB0aGVyZSBpcyBhIGNvbW1vbmx5IGRlcGxveWVkICJidWciIGluIG9sZCBpbXBsZW1lbnRh dGlvbnMsIGJ1dCBpdCBpcyBub3Qgc2VlbiBiZWNhdXNlIHRoZSBidWcgaXMgaW4gYSBmZWF0dXJl IHRoYXQgbm8gb25lIGhhcyBiZWVuIHVzaW5nLiAgSWYgbmV3IGltcGxlbWVudGF0aW9ucyB1c2Ug dGhhdCBmZWF0dXJlLCB0aGUgYnVnIHdpbGwgYmUgc2VlbiwgYW5kIG5ldHdvcmsgZGlzcnVwdGlv biB3aWxsIG9jY3VyLiBPbmUgY291bGQgc2F5ICJmaXggYWxsIHRoZSBvbGQgaW1wbGVtZW50YXRp b25zIiwgYnV0IGl0IHNlZW1zIHdpc2VyIHRvIGhhdmUgbmV3IGltcGxlbWVudGF0aW9ucyBhdm9p ZCB0aWNrbGluZyB0aGUgYnVnLiAgIFRoZSBDYXBhYmlsaXR5IGlzIG5vdCBwcm9wb3NlZCAgZm9y IHRoZSBwdXJwb3NlIG9mIGhlbHBpbmcgdGhlIHZlbmRvcnMsIGl0J3MgdGhlcmUgdG8gaGVscCB0 aGUgb3BlcmF0b3JzLg0KDQpJJ20gbm90IHN1cmUgd2h5IHlvdSB0aGluayB0aGVyZSB3b3VsZCBi ZSBCR1Agc2Vzc2lvbiBkcm9wcyBkdWUgdG8gMzEwN2JpczsgaWYgYSAzMTA3IGltcGxlbWVudGF0 aW9uIHNlbmRzIG11bHRpcGxlIGxhYmVscyB0byBhIDMxMDdiaXMgaW1wbGVtZW50YXRpb24sIEkg dGhpbmsgdGhlIDMxMDdiaXMgaW1wbGVtZW50YXRpb24gd291bGQgZG8gInRyZWF0LWFzLXdpdGhk cmF3IiByYXRoZXIgdGhhbiAiZHJvcCB0aGUgc2Vzc2lvbiIuDQoNClBlcmhhcHMgYSByZWFzb25h YmxlIGFwcHJvYWNoIGZvciAzMTA3YmlzIHdvdWxkIGJlIHRoZSBmb2xsb3dpbmc6DQoNCi0gQSAz MTA3YmlzIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IHNlbmQgbXVsdGlwbGUgbGFiZWxzIHRvIGEg cGVlciB1bmxlc3MgdGhlIENhcGFiaWxpdHkgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSB0aGF0IHBl ZXIuICAoVGhpcyBwcmV2ZW50cyAzMTA3YmlzIGltcGxlbWVudGF0aW9ucyBmcm9tIHRpY2tsaW5n IHRoZSAnYnVnJyBpbiAzMTA3IGltcGxlbWVudGF0aW9ucy4pDQoNCi0gQSAzMTA3YmlzIGltcGxl bWVudGF0aW9uIHdpbGwgYWNjZXB0IG11bHRpcGxlIGxhYmVscyBmcm9tIGEgcGVlciBldmVuIGlu IHRoZSBhYnNlbmNlIG9mIHRoZSBDYXBhYmlsaXR5Lg0KDQpBbm90aGVyIGFwcHJvYWNoIHdvdWxk IGJlIHRvIGhhdmUgYSBrbm9iIHRoYXQgZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBDYXBhYmlsaXR5 IG5lZWRzIHRvIGJlIHVzZWQgYmVmb3JlIG11bHRpcGxlIGxhYmVscyBhcmUgYWR2ZXJ0aXNlZC4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQkVT UyBtYWlsaW5nIGxpc3QNCkJFU1NAaWV0Zi5vcmc8bWFpbHRvOkJFU1NAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg0K --_000_D3245FC256368aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2JlcnQs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoaXMgd291bGQg ZGVmZWF0IHRoZSBwdXJwb3NlIG9mIGNsYXJpZnlpbmcgUkZDIDMxMDEgbXVsdGktbGFiZWwgYmVo YXZpb3IgaW4gYSBCSVMgZHJhZnQuIExldOKAmXMgc2VlIGlmIHdlIGNhbiByZWFjaCBjb25zZW5z dXMgZmlyc3QuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9k aXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0i T0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsg Zm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9N OiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6 ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRP UDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SWRy ICZsdDs8YSBocmVmPSJtYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmciPmlkci1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBBcHJpbCAx LCAyMDE2IGF0IDQ6MjMgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86 IDwvc3Bhbj5FcmljIEMgUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplcm9zZW5AanVuaXBlci5u ZXQiPmVyb3NlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkNjOiA8L3NwYW4+QnJ1bm8gRGVjcmFlbmUgJmx0OzxhIGhyZWY9Im1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8 L2E+Jmd0OywgQkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0 Zi5vcmc8L2E+Jmd0OywNCiBJRFIgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9y ZyI+aWRyQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWRyXSBbYmVzc10gZHJhZnQtcm9zZW4tbXBscy1yZmMz MTA3YmlzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9 ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+ DQpIaSBFcmljLDwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQt ZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KSSBoYXZlIHJlYWQg eW91ciBwcm9wb3NlZCBkcmFmdCBhcyB3ZWxsIGFzIHdhdGNoZWQgdGhpcyB0aHJlYWQgd2l0aCBh IGJpdCBvZiBhbiBpbnRlcmVzdC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNp emU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxs Ij4NClRvIG1lIHRoZSBiZXN0IGNvbXByb21pc2UgLSB3aGljaCBpcyB0byBhZ3JlZSB3aXRoIEJy dW5vJ3MgcG9pbnRzIGFzIHdlbGwgYXMgYWRkcmVzcyB5b3VyIGludGVudGlvbnMgaXMgc2ltcGx5 IHRvIHJlcXVlc3QgbmV3IFNBRkkgZm9yIDMxMDdiaXMuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZTpzbWFsbCI+DQpGcm9tIHRoZSBkcmFmdCB5b3UgYXJlIHJlYWxseSBub3QgdXBkYXRp bmcgMzEwNyBiYXNlIHNwZWMgYnV0IG9ic29sZXRpbmcgaXQgd2hpY2ggdG8gbWUgbG9va3MgbGlr ZSBhIGJhZCBpZGVhLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs bCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250 LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KWW91 IGFyZSBldmVuIHJlcXVlc3RpbmcgdG8gcmVtb3ZlIElBTkEgcmVmZXJlbmNlIHRvIG9yaWdpbmFs IHNwZWMuIEhvdyB3b3VsZCBJQU5BIGtub3cgd2hlbiBpcyBpdCBzYWZlIHRvIGRvIHRoYXQgLi4g bWVhbmluZyB3aGVuIGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3Qgc3VkZGVubHkgc3VwcG9y dCBhbmQgYWxsIGRlcGxveW1lbnRzIHdpbGwgZW5hYmxlIDMxMDdiaXMgPyZuYnNwOzxicj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFs LGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRp Y2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KTmV3IFNBRkkgcmVxdWlyZXMgYSBuZXcg Y2FwYWJpbGl0eSB3aGljaCB5b3UgYXJlIGFza2luZyBmb3IgYW55d2F5LiZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fu cy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQXMgZmFyIGFzIGltcGxlbWVudGF0aW9ucyBwbGVh c2Uga2VlcCBpbiBtaW5kIHZlcnkgaW1wb3J0YW50IHBvaW50IHRoYXQgc29tZSBpbXBsZW1lbnRh dGlvbnMgdHJlYXQgU0FGSSAxICZhbXA7IDQgaW4gc2luZ2xlIHRhYmxlIGFuZCBzb21lIGluIHNl cGFyYXRlIHRhYmxlcy4gVGhhdCB3aGVuIG1peGVkIHdpdGggMzEwN2JpcyBtYXkganVzdCBleHBs b2RlIGlmIG5vdCBpbiBuZXcgc2V0IG9mIGJ1Z3MgdGhlbiB3aXRoIG9wZXJhdGlvbmFsIG5pZ2h0 bWFyZS4NCiBXaGlsZSB3ZSBhcmUgYXQgdGhpcyBpdCB3b3VsZCBiZSBtdWNoIGNsZWFuZXIgdG8g bWFuZGF0ZSBpbiB0aGUgbmV3IHNwZWMgdG8gaGF2ZSAzMTA3YmlzIGFsd2F5cyB0byB1c2Ugc2Vw YXJhdGUgdGFibGVzIGFzIGNvbXBhcmVkIHdpdGggZnJvbSBTQUZJIDEuPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNh bnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQpUaHgsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXpl OnNtYWxsIj4NClJvYmVydC48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NClBTLiZu YnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KQXMgd2UgYWxsIGtub3cgMzEw NyhiaXMpIHRyaWVzIHRvIGFkZCBOTkkgdG8gTVBMUy4gSG93ZXZlciBpdCBtdXN0IGJlIHZlcnkg d2VsbCBzdGF0ZWQgdGhhdCB0aGlzIGlzIG9ubHkgb25lIGRlcGxveW1lbnQgb3B0aW9uIGZvciBp bnRlcmRvbWFpbiBlbmNhcHN1bGF0aW9uLiBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIHNlZSBh IHNlY3Rpb24gaW5kaWNhdGluZyB0aGF0IElQdjYgb3IvYW5kIElQdjQgYmUgdXNlZCBhcyBhbiBh bHRlcm5hdGl2ZQ0KIGVuY2FwIGZvciB0aG9zZSBhcHBsaWNhdGlvbnMgd2hpY2ggcmVxdWlyZSBp dCBhbmQgd2hlbiBuZWVkZWQgcHJvdmlkZSBsb2NhbCBiaW5kaW5ncyBiZXR3ZWVuIGludHJhZG9t YWluIE1QTFMgYW5kIGludGVyZG9tYWluIElQLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm O2ZvbnQtc2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21h aWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEFwciAxLCAy MDE2IGF0IDY6NDQgUE0sIEVyaWMgQyBSb3NlbiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmVyb3NlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmVyb3NlbkBqdW5p cGVyLm5ldDwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIiPk9uIDMvMjUvMjAxNiA3OjI1 IEFNLCA8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPg0KYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PGJyPg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkknbSBxdWl0ZSBzdXJlIHlvdSBoYXZlIGRl cGxveWVkJm5ic3A7IGltcGxlbWVudGF0aW9ucywgZnJvbSBzZXZlcmFsPGJyPg0KcHJvbWluZW50 IHZlbmRvcnMsIHRoYXQgd2lsbCBub3QgcHJvcGVybHkgaGFuZGxlIHRoaXMgY2FzZS48YnI+DQo8 L2Jsb2NrcXVvdGU+DQpJJ20gd2FpdGluZyBmb3IgdGhpcy90aGVzZSBpbXBsZW1lbnRhdGlvbihz KSB0byBtYWtlIGEgcHVibGljIHN0YXRlbWVudCBpbiB0aGlzIHRocmVhZCAvIElFVEYgV0dzLiBU aGVuIHdlIGNhbiBkaXNjdXNzIHdoZXRoZXIgdGhlIGlzc3VlIGNvbWVzIGZyb20gUkZDRjMxMDcg b3IgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24uPGJyPg0KSWYgbm9uZSBtYWtlIGEgcHVibGljIHN0 YXRlbWVudCwgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgYXJlIGNh cGFibGUgb2YgcmVjZWl2aW5nIG11bHRpcGxlIGxhYmVscywgYXMgcGVyIFJGQyAzMTA3Ljxicj4N CjwvYmxvY2txdW90ZT4NCjwvc3Bhbj5JIHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggdGhpcy4mbmJz cDsgV2Ugc2hvdWxkIG5vdCBpZ25vcmUgdGhlIGZhY3RzIGp1c3QgYmVjYXVzZSB5b3UgZG9uJ3Qg bGlrZSB0aGUgd2F5IHRoZSBmYWN0cyB3ZXJlIGdhdGhlcmVkLjxicj4NCjxicj4NCkEgYmV0dGVy IGFwcHJvYWNoIHdvdWxkIGJlIHRvIGhhdmUgb3BlcmF0b3JzIHN0YXRlIHdoZXRoZXIgdGhleSBo YXZlIGFueSBkZXBsb3ltZW50cyBpbiB3aGljaCB0aGUgJnF1b3Q7bXVsdGlwbGUgbGFiZWxzJnF1 b3Q7IGZlYXR1cmUgaXMgdXNlZCBpbiBhIG11bHRpLXZlbmRvciBlbnZpcm9ubWVudC4mbmJzcDsg SXQgaXMgdmVyeSB1c2VmdWwgd2hlbiB3b3JraW5nIG9uIGEgJnF1b3Q7YmlzJnF1b3Q7IGRyYWZ0 IHRvIGRldGVybWluZSB3aGljaCBmZWF0dXJlcyBoYXZlIGJlZW4gcHJvdmVuDQogdG8gd29yayBp biBhIG11bHRpLXZlbmRvciBlbnZpcm9ubWVudCBhbmQgd2hpY2ggaGF2ZSBub3QuPHNwYW4gY2xh c3M9IiI+PGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQpBbnkgbm9uLWNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBtYXkgY3JlYXRlIGludGVy b3BlcmFiaWxpdHkgaXNzdWVzIGFuZCB1bnByZWRpY3RhYmxlIHJlc3VsdHMuPGJyPg0KJm5ic3A7 RnJvbSBhbiBJRVRGIHN0YW5kcG9pbnQsIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIGEgUkZDIDMx MDcgaW1wbGVtZW50YXRpb24gd291bGQgY3JlYXRlIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLCB1 cCB0byBzaHV0dGluZyBkb3duIHRoZSBCR1Agc2Vzc2lvbi48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 YnI+DQo8L3NwYW4+VGhlcmUgYXJlIGRlcGxveWVkIDMxMDcgaW1wbGVtZW50YXRpb25zIHdoaWNo IGFsd2F5cyBhc3N1bWUgdGhhdCB0aGUgTkxSSSBjb250YWlucyBhIHNpbmdsZSBsYWJlbC4mbmJz cDsgSWYgeW91IHRyaWVkIHRvIGludGVyd29yayB0aGVzZSB3aXRoIDMxMDcgaW1wbGVtZW50YXRp b25zIHRoYXQgc2VuZCBtdWx0aXBsZSBsYWJlbHMgLCB5b3Ugd2lsbCBleHBlcmllbmNlIHRoZSBr aW5kIG9mIGRpc3J1cHRpb24uJm5ic3A7IDMxMDdiaXMgdHJpZXMgdG8gYWxsb3cNCiB0aGUgdXNl IG9mIG11bHRpcGxlIGxhYmVscyB3aGlsZSBwcmV2ZW50aW5nIHRoaXMgc29ydCBvZiBkaXNydXB0 aW9uIGZyb20gb2NjdXJyaW5nLjxzcGFuIGNsYXNzPSIiPjxicj4NCjxicj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0 OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSWYgeW91IG1lYW4gdGhhdCBzb21l IG5vbi1jb21wbGlhbnQgaW1wbGVtZW50YXRpb24gZG8gbm90IHdvcmssIHdlbGwgbGV0J3MgZml4 IHRoZW0uPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9zcGFuPlRoZSBzaXR1YXRpb24gaXMg dGhhdCB0aGVyZSBpcyBhIGNvbW1vbmx5IGRlcGxveWVkICZxdW90O2J1ZyZxdW90OyBpbiBvbGQg aW1wbGVtZW50YXRpb25zLCBidXQgaXQgaXMgbm90IHNlZW4gYmVjYXVzZSB0aGUgYnVnIGlzIGlu IGEgZmVhdHVyZSB0aGF0IG5vIG9uZSBoYXMgYmVlbiB1c2luZy4mbmJzcDsgSWYgbmV3IGltcGxl bWVudGF0aW9ucyB1c2UgdGhhdCBmZWF0dXJlLCB0aGUgYnVnIHdpbGwgYmUgc2VlbiwgYW5kIG5l dHdvcmsgZGlzcnVwdGlvbiB3aWxsDQogb2NjdXIuIE9uZSBjb3VsZCBzYXkgJnF1b3Q7Zml4IGFs bCB0aGUgb2xkIGltcGxlbWVudGF0aW9ucyZxdW90OywgYnV0IGl0IHNlZW1zIHdpc2VyIHRvIGhh dmUgbmV3IGltcGxlbWVudGF0aW9ucyBhdm9pZCB0aWNrbGluZyB0aGUgYnVnLiZuYnNwOyAmbmJz cDtUaGUgQ2FwYWJpbGl0eSBpcyBub3QgcHJvcG9zZWQmbmJzcDsgZm9yIHRoZSBwdXJwb3NlIG9m IGhlbHBpbmcgdGhlIHZlbmRvcnMsIGl0J3MgdGhlcmUgdG8gaGVscCB0aGUgb3BlcmF0b3JzLjxi cj4NCjxicj4NCkknbSBub3Qgc3VyZSB3aHkgeW91IHRoaW5rIHRoZXJlIHdvdWxkIGJlIEJHUCBz ZXNzaW9uIGRyb3BzIGR1ZSB0byAzMTA3YmlzOyBpZiBhIDMxMDcgaW1wbGVtZW50YXRpb24gc2Vu ZHMgbXVsdGlwbGUgbGFiZWxzIHRvIGEgMzEwN2JpcyBpbXBsZW1lbnRhdGlvbiwgSSB0aGluayB0 aGUgMzEwN2JpcyBpbXBsZW1lbnRhdGlvbiB3b3VsZCBkbyAmcXVvdDt0cmVhdC1hcy13aXRoZHJh dyZxdW90OyByYXRoZXIgdGhhbiAmcXVvdDtkcm9wIHRoZSBzZXNzaW9uJnF1b3Q7Ljxicj4NCjxi cj4NClBlcmhhcHMgYSByZWFzb25hYmxlIGFwcHJvYWNoIGZvciAzMTA3YmlzIHdvdWxkIGJlIHRo ZSBmb2xsb3dpbmc6PGJyPg0KPGJyPg0KLSBBIDMxMDdiaXMgaW1wbGVtZW50YXRpb24gd2lsbCBu b3Qgc2VuZCBtdWx0aXBsZSBsYWJlbHMgdG8gYSBwZWVyIHVubGVzcyB0aGUgQ2FwYWJpbGl0eSBo YXMgYmVlbiByZWNlaXZlZCBmcm9tIHRoYXQgcGVlci4mbmJzcDsgKFRoaXMgcHJldmVudHMgMzEw N2JpcyBpbXBsZW1lbnRhdGlvbnMgZnJvbSB0aWNrbGluZyB0aGUgJ2J1ZycgaW4gMzEwNyBpbXBs ZW1lbnRhdGlvbnMuKTxicj4NCjxicj4NCi0gQSAzMTA3YmlzIGltcGxlbWVudGF0aW9uIHdpbGwg YWNjZXB0IG11bHRpcGxlIGxhYmVscyBmcm9tIGEgcGVlciBldmVuIGluIHRoZSBhYnNlbmNlIG9m IHRoZSBDYXBhYmlsaXR5Ljxicj4NCjxicj4NCkFub3RoZXIgYXBwcm9hY2ggd291bGQgYmUgdG8g aGF2ZSBhIGtub2IgdGhhdCBkZXRlcm1pbmVzIHdoZXRoZXIgdGhlIENhcGFiaWxpdHkgbmVlZHMg dG8gYmUgdXNlZCBiZWZvcmUgbXVsdGlwbGUgbGFiZWxzIGFyZSBhZHZlcnRpc2VkLg0KPGRpdiBj bGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1Ij48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkJFU1MgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkJFU1NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CRVNT QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmVzcyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3245FC256368aceeciscocom_-- From nobody Fri Apr 1 14:35:39 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3753D12D6F9; Fri, 1 Apr 2016 14:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsBXe0q4fsWO; Fri, 1 Apr 2016 14:35:36 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 AB2F512D6D8; Fri, 1 Apr 2016 14:35:35 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id k79so90163310lfb.2; Fri, 01 Apr 2016 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NraeDOxzHT6xKPnnF27FvW1NPF9PIVLGSABpDsoRqEY=; b=FPDevFBCQLhJ55DSgB6oCpoQudnACdyVCxUeUM1vlw4wbmDyWTKKVreV8hWQ0YcD5B 60bJtN80v6m87DZT6R6QnA12AVr9jF8KztsBIzflEC7K2LzLXunTZkdLcC7fVPoSHv78 sHG7879SMsCDwhR+nApFj5g7cSungM5wpAyOu9/aQPo3B57qqj6Xh5XTf4zQ8ZJj/CSZ S4FfvEXxsXikyETYBr8qhZDplL91L+8p7/0IXzlTFUJk3BbOAswuI570Gwl0vc1/z1kK Xwcaa79XJBgfarMK0JW7MN0nZEK/VDTvAQJv8yliPzukOm3OFP+s1/xzrEAQZtwjUslX Kjqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NraeDOxzHT6xKPnnF27FvW1NPF9PIVLGSABpDsoRqEY=; b=FlylAM69r+fouwGmVopx3sEsseCELXLXdzX9HoKrTj/pifYSWbS4JU3u5Ce7MPvrfr GgX/9vp3+Qbz2WEXzS9rH2Mo6yfo8ClXal8ua/ZQ3JeIbAU1KkeKjJ7p4Kc85y9DDwHg ayDqBku91Kyc+WL3HyNzj6lW8lSE7+VTZ5A+NaAGYhGCWrWJ19ePL5AOxIqm+wi1wiDW 8cjhUgpxU/0IGLaZUsdl8aCbkWoXZu0t3qFJonoTN/4VxN2/kUckSqVkfro9rwaEIpnZ wm5ncZbJkLYDn0ZsZuLhDyYgwtV4Aq4zWumMHh2DK+0uQgihNUJ2rvK9vS4z8OHlkLtf 4QRw== X-Gm-Message-State: AD7BkJJijqtP2nVfRTNpKVe7RppcaXbfqjImKluyBxmvCR1Os1a3S8AnXi1N6yys9wObJWir2lOwg01MzX0nrw== MIME-Version: 1.0 X-Received: by 10.25.87.19 with SMTP id l19mr2834321lfb.27.1459546533835; Fri, 01 Apr 2016 14:35:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Fri, 1 Apr 2016 14:35:33 -0700 (PDT) In-Reply-To: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> Date: Fri, 1 Apr 2016 23:35:33 +0200 X-Google-Sender-Auth: s1x6nZEIaHchybZQ5tBfQkxcp6U Message-ID: From: Robert Raszuk To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a1140ead8aebac2052f7328a4 Archived-At: Cc: Bruno Decraene , "idr@ietf.org" , BESS , Eric C Rosen , "mpls@ietf.org" Subject: Re: [bess] [Idr] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 21:35:39 -0000 --001a1140ead8aebac2052f7328a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi AC, I am much less concern if we must be stuck to 3107 till retirement. I think it would be much smoother on many levels to leave 3107 as is and propose better solution for interdomain label exchange with BGP in new RFC. With time we can obsolete 3107. Such model has been done in the past and worked pretty well AFAIK. Best, r. On Fri, Apr 1, 2016 at 11:29 PM, Acee Lindem (acee) wrote: > Hi Robert, > > I think this would defeat the purpose of clarifying RFC 3101 multi-label > behavior in a BIS draft. Let=E2=80=99s see if we can reach consensus firs= t. > > Thanks, > Acee > > From: Idr on behalf of Robert Raszuk < > robert@raszuk.net> > Date: Friday, April 1, 2016 at 4:23 PM > To: Eric C Rosen > Cc: Bruno Decraene , "mpls@ietf.org" < > mpls@ietf.org>, BESS , IDR List > Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis > > Hi Eric, > > I have read your proposed draft as well as watched this thread with a bit > of an interest. > > To me the best compromise - which is to agree with Bruno's points as well > as address your intentions is simply to request new SAFI for 3107bis. > > From the draft you are really not updating 3107 base spec but obsoleting > it which to me looks like a bad idea. > > You are even requesting to remove IANA reference to original spec. How > would IANA know when is it safe to do that .. meaning when all > implementations will not suddenly support and all deployments will enable > 3107bis ? > > New SAFI requires a new capability which you are asking for anyway. > > As far as implementations please keep in mind very important point that > some implementations treat SAFI 1 & 4 in single table and some in separat= e > tables. That when mixed with 3107bis may just explode if not in new set o= f > bugs then with operational nightmare. While we are at this it would be mu= ch > cleaner to mandate in the new spec to have 3107bis always to use separate > tables as compared with from SAFI 1. > > Thx, > Robert. > > PS. > > As we all know 3107(bis) tries to add NNI to MPLS. However it must be ver= y > well stated that this is only one deployment option for interdomain > encapsulation. I would very much like to see a section indicating that IP= v6 > or/and IPv4 be used as an alternative encap for those applications which > require it and when needed provide local bindings between intradomain MPL= S > and interdomain IP. > > > On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen wrote: > >> On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote: >> >>> I'm quite sure you have deployed implementations, from several >>>> prominent vendors, that will not properly handle this case. >>>> >>> I'm waiting for this/these implementation(s) to make a public statement >>> in this thread / IETF WGs. Then we can discuss whether the issue comes = from >>> RFCF3107 or from the implementation. >>> If none make a public statement, we should assume that all >>> implementations are capable of receiving multiple labels, as per RFC 31= 07. >>> >> I strongly disagree with this. We should not ignore the facts just >> because you don't like the way the facts were gathered. >> >> A better approach would be to have operators state whether they have any >> deployments in which the "multiple labels" feature is used in a >> multi-vendor environment. It is very useful when working on a "bis" dra= ft >> to determine which features have been proven to work in a multi-vendor >> environment and which have not. >> >> Any non-compliant implementation may create interoperability issues and >>> unpredictable results. >>> From an IETF standpoint, the question is whether a RFC 3107 >>> implementation would create interoperability issues, up to shutting dow= n >>> the BGP session. >>> >> >> There are deployed 3107 implementations which always assume that the NLR= I >> contains a single label. If you tried to interwork these with 3107 >> implementations that send multiple labels , you will experience the kind= of >> disruption. 3107bis tries to allow the use of multiple labels while >> preventing this sort of disruption from occurring. >> >> If you mean that some non-compliant implementation do not work, well >>> let's fix them. >>> >> >> The situation is that there is a commonly deployed "bug" in old >> implementations, but it is not seen because the bug is in a feature that= no >> one has been using. If new implementations use that feature, the bug wi= ll >> be seen, and network disruption will occur. One could say "fix all the o= ld >> implementations", but it seems wiser to have new implementations avoid >> tickling the bug. The Capability is not proposed for the purpose of >> helping the vendors, it's there to help the operators. >> >> I'm not sure why you think there would be BGP session drops due to >> 3107bis; if a 3107 implementation sends multiple labels to a 3107bis >> implementation, I think the 3107bis implementation would do >> "treat-as-withdraw" rather than "drop the session". >> >> Perhaps a reasonable approach for 3107bis would be the following: >> >> - A 3107bis implementation will not send multiple labels to a peer unles= s >> the Capability has been received from that peer. (This prevents 3107bis >> implementations from tickling the 'bug' in 3107 implementations.) >> >> - A 3107bis implementation will accept multiple labels from a peer even >> in the absence of the Capability. >> >> Another approach would be to have a knob that determines whether the >> Capability needs to be used before multiple labels are advertised. >> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > --001a1140ead8aebac2052f7328a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi AC,

I am much less concern if we must be stuck to 3107 til= l retirement.=C2=A0

I = think it would be much smoother on many levels to leave 3107 as is and prop= ose better solution for interdomain label exchange with BGP in new RFC.=C2= =A0

With time we can o= bsolete 3107.=C2=A0

Su= ch model has been done in the past and worked pretty well AFAIK.=C2=A0

Best,
r.



On Fri, Apr 1, 2= 016 at 11:29 PM, Acee Lindem (acee) <acee@cisco.com> wrote:
=
Hi Robert,=C2=A0

I think this would defeat the purpose of clarifying RFC 3101 multi-lab= el behavior in a BIS draft. Let=E2=80=99s see if we can reach consensus fir= st.=C2=A0

Thanks,
Acee=C2=A0

From: Idr <idr-bounces@ietf.org> on behalf= of Robert Raszuk <robert@raszuk.net>
Date: Friday, April 1, 2016 at 4:23= PM
To: Eric C Rosen <erosen@juniper.net>
Cc: Bruno Decraene <bruno.decraene@or= ange.com>, "= mpls@ietf.org" <mpls@ietf.org>, BESS <bess@ietf.org>, IDR List <idr@ietf.or= g>
Subject: Re: [Idr] [bess] draft-ros= en-mpls-rfc3107bis

Hi Eric,

I have read your proposed draft as well as watched this thread with a bit o= f an interest.=C2=A0

To me the best compromise - which is to agree with Bruno's points as we= ll as address your intentions is simply to request new SAFI for 3107bis.=C2= =A0

>From the draft you are really not updating 3107 base spec but obsoleting it= which to me looks like a bad idea.=C2=A0

You are even requesting to remove IANA reference to original spec. How woul= d IANA know when is it safe to do that .. meaning when all implementations = will not suddenly support and all deployments will enable 3107bis ?=C2=A0

New SAFI requires a new capability which you are asking for anyway.=C2=A0

As far as implementations please keep in mind very important point that som= e implementations treat SAFI 1 & 4 in single table and some in separate= tables. That when mixed with 3107bis may just explode if not in new set of= bugs then with operational nightmare. While we are at this it would be much cleaner to mandate in the new spec t= o have 3107bis always to use separate tables as compared with from SAFI 1.<= /div>

Thx,
Robert.

PS.=C2=A0

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very = well stated that this is only one deployment option for interdomain encapsu= lation. I would very much like to see a section indicating that IPv6 or/and= IPv4 be used as an alternative encap for those applications which require it and when needed provide loca= l bindings between intradomain MPLS and interdomain IP.=C2=A0


On Fri, Apr 1, 2016 at 6:44 PM, Eric C Rosen <erosen@juniper.= net> wrote:
On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote:
I'm quite sure you have deployed=C2=A0 implementations, from several prominent vendors, that will not properly handle this case.
I'm waiting for this/these implementation(s) to make a public statement= in this thread / IETF WGs. Then we can discuss whether the issue comes fro= m RFCF3107 or from the implementation.
If none make a public statement, we should assume that all implementations = are capable of receiving multiple labels, as per RFC 3107.
I strongly disagree with this.=C2=A0 We should not ignore the facts = just because you don't like the way the facts were gathered.

A better approach would be to have operators state whether they have any de= ployments in which the "multiple labels" feature is used in a mul= ti-vendor environment.=C2=A0 It is very useful when working on a "bis&= quot; draft to determine which features have been proven to work in a multi-vendor environment and which have not.

Any non-compliant implementation may create interoperability issues and unp= redictable results.
=C2=A0From an IETF standpoint, the question is whether a RFC 3107 implement= ation would create interoperability issues, up to shutting down the BGP ses= sion.

There are deployed 3107 implementations which always assume that the= NLRI contains a single label.=C2=A0 If you tried to interwork these with 3= 107 implementations that send multiple labels , you will experience the kin= d of disruption.=C2=A0 3107bis tries to allow the use of multiple labels while preventing this sort of disruption from o= ccurring.

If you mean that some non-compliant implementation do not work, well let= 9;s fix them.

The situation is that there is a commonly deployed "bug" i= n old implementations, but it is not seen because the bug is in a feature t= hat no one has been using.=C2=A0 If new implementations use that feature, t= he bug will be seen, and network disruption will occur. One could say "fix all the old implementations", but it s= eems wiser to have new implementations avoid tickling the bug.=C2=A0 =C2=A0= The Capability is not proposed=C2=A0 for the purpose of helping the vendors= , it's there to help the operators.

I'm not sure why you think there would be BGP session drops due to 3107= bis; if a 3107 implementation sends multiple labels to a 3107bis implementa= tion, I think the 3107bis implementation would do "treat-as-withdraw&q= uot; rather than "drop the session".

Perhaps a reasonable approach for 3107bis would be the following:

- A 3107bis implementation will not send multiple labels to a peer unless t= he Capability has been received from that peer.=C2=A0 (This prevents 3107bi= s implementations from tickling the 'bug' in 3107 implementations.)=

- A 3107bis implementation will accept multiple labels from a peer even in = the absence of the Capability.

Another approach would be to have a knob that determines whether the Capabi= lity needs to be used before multiple labels are advertised.


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

--001a1140ead8aebac2052f7328a4-- From nobody Fri Apr 1 14:45: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 8220C12D6FC; Fri, 1 Apr 2016 14:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TCFZhZvV8ll; Fri, 1 Apr 2016 14:45:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EC212D6F8; Fri, 1 Apr 2016 14:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IScFJinRi5ttutMzW4sGYAkuQXyUgLBmgtyEs6hWjG8=; b=H+uQlIhHTjVKLEPT/OEcLcvighNaNWnD2plcjoYj/GvaYnTt2k8dFylE5R4Uii61cBsYr202L83kFn5MeLQBsPQr0N83Q53ExR6dGGe5Dd5iXcTDIl/b+ojSJHCjo3UcTHvCw6BsmXQJxIvnQdKELabUaTb03pK2UDMa+JSsFwM= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.37.79] (66.129.241.12) by DM2PR05MB798.namprd05.prod.outlook.com (10.141.180.21) with Microsoft SMTP Server (TLS) id 15.1.443.12; Fri, 1 Apr 2016 21:45:18 +0000 To: Robert Raszuk References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> From: Eric C Rosen Message-ID: <56FEEBEC.5060902@juniper.net> Date: Fri, 1 Apr 2016 17:45:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020003050503060808030109" X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR16CA0035.namprd16.prod.outlook.com (25.162.134.173) To DM2PR05MB798.namprd05.prod.outlook.com (10.141.180.21) X-MS-Office365-Filtering-Correlation-Id: 147ec853-f804-48aa-be63-08d35a76eb66 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 2:FJndBnoRzuJf4G1Gw/u1GkWryPzQfjBnfuav3ye0qweXKhC+kIUZNXoWr/OjYGoVwhGmGZG6PK7kBfy4SnpF4aoSui1XAHYD9gK6dRglmLR405x59eOJZKFUEKUZ933OTbqwVSbxT2vGXostYIK37STgYUjpqVDk/Wwq8f4wYiD4IXoSu5tjKMcV9IC2TXdl; 3:5HFlOWp8uMU8RrVlq+7Vi+t2RfwEcI0jBWglpkL/SXCPuGEwtuGlJmpR9xdMfMZI+rAeoxejZHignE6OQLvLNTvC7TFlJJbnLWJip5r6WxpiChWDA0JaSAk/LOgxWF6g; 25:2+DyQ6MngtOGKD5JmllBsmPJYa7XtYXZHaoHsUYwMwXuiDZYywF1hnoe8layxZk+FE8vdrMH9Mwjv7J2arWB/8slCcrV0SK2thcmNrnrfX+Ao9QhwrjgC45OnDZQ7mEQh9NIMOCsoj8tk2OD8vEt0qYFA/Y/X0hdK8gxObKlaDrwSxfKrMYG1uizBaq3HhoMYzPekQzb19uJGmWioLyF4EeXxxSXpRGs+VEcpeYwMXcrG+DBC3awrpMo2XhHd2ya6gDnsMp1CHgdoMCDLb+G2E6KMzqFY1VaB8X3EOzKoqM2fDEHonxchC87YcZyogrsWjpQWiWb5M2rf7oopkfweixjoqyvvLFxJU1fWTCX3Ac= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB798; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 20:V422bNFDCvPfYDbMPMvIfOUnmUD41W/Io5r3w2vks4qOCOjXsEpMLdYhNj3QjIubfrPegdTpfLSHaqjfHORknfhN3zD8diFjI129ZKTgvxBY7qdO/3Xydk7w9tNtymW5gPGI8vmibfRFJ5epJOzxiTCwZ3O5sx1xfJHX/2s+jMMAsFsu4fDIYXLPLeH/5z24gPZJumwefFjd0kWMFht/ZPwOe7vQ4rnjPF3w5cOddqwRdhPaUhV/Fqfb9tFxnGN/rI2UwFO5UI1imcdkt8YUWboe+ROaKrQHHJFxoqwmT9lpWM40v1xgzqa5al5mSliz2d4k8INOOyhZGy+hsc5q7xL5x8/kljeYsiZv7i5B7WZi6MPkxJazuYGByUqM4tIAJEYGFtW0946ii9yydej4DbmXyb1768YseM1nHq3Wz9E3510Pdz2fcGE/o82P6ShzFITu8HnBdainQeUk+mF3RaD02ZhcvAiKH3HYRPg8O5jahLYw1sjq8rUX6TMjXw5t; 4:cShjYY/bPsNUMLMLQQofbu38pBEa5XvWY724Sf/glfRhUs+Hqj1uRVr8TglGJQOdjreuUQaUEdKAF1zPkaR1OrIUlULY443hNUd+Yy3nFLXuk5EjTWUZX/5rfjo4wQU9RjVUFtMIhYmKGr98sxDbDR/XN1L8FT153XQek1fC03j3XeGCUq0mwRoWuUwtDfaM6xLbgryHpINhmG30Bn6CTkX3ZDNC1O41uYHPIO1sMmoy4oVVglSrwDBn3TWbSQSt8VSfkFKolbQ0S89uX/Yc4U5upCfU9kFLVXF57kOBU4+eb6O2XNbneuiK/q+ZSt7LtccntMwfs64/o51igP3m+eJsCA4rSjB4uL60+aSH0H56Du3weEPldA2nlmb46L2u X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DM2PR05MB798; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB798; X-Forefront-PRVS: 0899B47777 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(54014002)(24454002)(377454003)(87266999)(65816999)(230783001)(586003)(54356999)(50986999)(6116002)(76176999)(86362001)(64126003)(3846002)(110136002)(2950100001)(59896002)(84326002)(36756003)(5004730100002)(1096002)(66066001)(65956001)(65806001)(77096005)(42186005)(5008740100001)(4001350100001)(4326007)(19580405001)(92566002)(16236675004)(80316001)(2906002)(270700001)(19580395003)(189998001)(512874002)(81166005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB798; H:[172.29.37.79]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1TUI3OTg7MjM6dDNwajVTbnR0SXY3T3dtQkIycnlqby9wU3dE?= =?utf-8?B?aHpPZ2VCdVR4bm90T3Z4cThVSEdMaERlMm85bGJMdTJCMGUyZXVoTk5iTmQy?= =?utf-8?B?TUcyZFpzcFhGZ0lvOHBERmJlTXlNbFdjSFhNWEtUUmV1d3VMb0s3S3NnbGZq?= =?utf-8?B?R3Q2RUdodGQ1N1pjdHFVVUF2VktEc0FaNThkZE1LbXJ4MVkzZzZFWWgxa0tR?= =?utf-8?B?RWpEWlVVOFVlT2hWQ0Y4dkM2cVdpRDhCdU92dXN3Q0MyenUzRmtwMXlCZUk0?= =?utf-8?B?RTNiNktnb3BtRUxjZzNHcGs3RFBqY2tIcllBTm9oalVOLzZNNTNUb2h1cXMr?= =?utf-8?B?WnFzdDhpemt0cFVwVnpMOU80azZUWi9HQlV5bWE2ZExTR3krRzNDUHR3R0VT?= =?utf-8?B?aTY2dU5mVVFBNGhDQU5wQkI0WFA2MTVuZ2JUVG4xUWc0aWF5VnpUMWIyYlYx?= =?utf-8?B?VFQ1Vks5ZnFmNlFxdzBaUU1hajFDdzRIZ3NhZENJM3Jjc3VGa1pqMkZncG54?= =?utf-8?B?WDNKb0haR1k5K2ZONVI2Z3pQM29mbzk4NmgvRURjUUU4aTZpclZGL1JnUXZh?= =?utf-8?B?YzhLZmZYL0RJUDJhV1VCcit1cFl4WTF6UjZZaFE1VW9aLzVlMmEvZDlQRVQv?= =?utf-8?B?dlJCcVUxT2dVWmhjZFJXSU9mUzRrZGVFVkNWTWQ2ODJ0YS8yV0lyOTU0VTNp?= =?utf-8?B?eS9Zbm1zTGd0bDVUN21nV3ZURmpBVjA4cDRFRmZYWlFkcEtEcSttbUU3WDRD?= =?utf-8?B?eFNvSjRZamViRjJGMGJGQlBnbng5Wk45OC9vNm1aSlZsbmcxZks0NDAxbmpx?= =?utf-8?B?MisxelBXR0hCRVFXdGhNRmFVUFNMWFVjSUthRFl0UlNFZWcxZWYrOXdGVTVa?= =?utf-8?B?YldlTUtKUGNNK1FKNEZyZDVrZS9RWVhESEdsam42S0tJTTk0Tm5DUGsxM2RC?= =?utf-8?B?UTA2cmhOd1lCQVBybWRiSTBRdFB5RG1mVWU2OUFZbWtSR3dFV3RMOVRyRFZq?= =?utf-8?B?am8rV3NuV0k2NFpLVkpDYnNwd0JVZStHdjR6V2lBMEI1T0U1NHhJeWNXUno3?= =?utf-8?B?bGpuMStaT1pXSFJCcXV6QVNWaHpmemUwZFhvMnhrR0xYS3ZLVWpMM2JhaFVX?= =?utf-8?B?Z1RDNGRlUGhKRng0aG9vZG1MbTJYRzNSSzgzQnhEdzRydldiUnhnYnZMZHdl?= =?utf-8?B?Z1RiY21Ua1dmMkwwWm52QW5iZm9OenlOeENJby9TZkJHdDFISnp6Y1pRQlBi?= =?utf-8?B?TkkvT2wyRE1BT2FYRktyU25uSzNkc25tRGl2TExSZkZWeUE2UnowbEdFL2ll?= =?utf-8?B?dFhBNXVKVVgyNXozRkNMQi9YVGh1dU93WGhFQ1BEcGJtV1ZuSngwSkx4ZWZo?= =?utf-8?B?dUhUeFJTQ1BmckRPNTZiZjdHWTZGMGxpNHgwTXFSaHBEdUZtTGZQMlI4NzFy?= =?utf-8?B?bDZuMzAvRG13bkVGQzh4QkUxcmN2blVta0NCdzRGK0xwTXRyY3piOUtuYVJw?= =?utf-8?B?dEFBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB798; 5:3sjFj48Fw2eWDe4CCJuRR8vyl/R5KnfIHHY1HfkKsfmaNuB70Q/nt3PG/SpjpF1K4LY6mMUBbOscgbAftWwhHJEIiqWe7uWI5jVeJSVt7t72doKkTA/BrPziDVmZHe/WDWVvs8kiWtLPDr2GxZ4VnA==; 24:loD4KJeUFTQVCWJt/V90g9rB0tjbr3lnc/9qZX3K2A1P0FOkVfnxSjtz3jDzezJO5t3DoHtitX4xWa+o9fwno5hCgqY1vrw7mx4V7dRXZCs= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2016 21:45:18.1704 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB798 Archived-At: Cc: Bruno Decraene , "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 21:45:23 -0000 --------------020003050503060808030109 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 4/1/2016 4:23 PM, Robert Raszuk wrote: > Hi Eric, > > I have read your proposed draft as well as watched this thread with a > bit of an interest. > > To me the best compromise - which is to agree with Bruno's points as > well as address your intentions is simply to request new SAFI for > 3107bis. I don't think that makes any sense at all. The whole point is to ensure that 3107bis interoperates with 3107 for those features that are already deployed and are already multi-vendor interoperable. > > From the draft you are really not updating 3107 base spec but > obsoleting it which to me looks like a bad idea. That is the nature of a "bis" draft. > > You are even requesting to remove IANA reference to original spec. That is the nature of a "bis" draft. > How would IANA know when is it safe to do that .. meaning when all > implementations will not suddenly support and all deployments will > enable 3107bis ? I don't understand the issue you are raising. I don't see any issue of "safety". > > New SAFI requires a new capability which you are asking for anyway. I don't understand the point you are making here. > > As far as implementations please keep in mind very important point > that some implementations treat SAFI 1 & 4 in single table and some in > separate tables. Yes, and these implementation differences have consequences that are discussed in the draft. > That when mixed with 3107bis may just explode if not in new set of > bugs then with operational nightmare. I don't understand the issue you are raising here. > While we are at this it would be much cleaner to mandate in the new > spec to have 3107bis always to use separate tables as compared with > from SAFI 1. Two goals of this draft are (a) to document the consequences of the implementation differences, and (b) to avoid invalidating any particular implementation. Obviously these goals would not be met if the spec mandated a particular implementation method. > As we all know 3107(bis) tries to add NNI to MPLS. However it must be > very well stated that this is only one deployment option for > interdomain encapsulation. I would very much like to see a section > indicating that IPv6 or/and IPv4 be used as an alternative encap for > those applications which require it and when needed provide local > bindings between intradomain MPLS and interdomain IP. This is entirely out of scope. --------------020003050503060808030109 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/1/2016 4:23 PM, Robert Raszuk wrote:
Hi Eric,

I have read your proposed draft as well as watched this thread with a bit of an interest. 

To me the best compromise - which is to agree with Bruno's points as well as address your intentions is simply to request new SAFI for 3107bis.

I don't think that makes any sense at all.  The whole point is to ensure that 3107bis interoperates with 3107 for those features that are already deployed and are already multi-vendor interoperable. 


From the draft you are really not updating 3107 base spec but obsoleting it which to me looks like a bad idea.

That is the nature of a "bis" draft.


You are even requesting to remove IANA reference to original spec.

That is the nature of a "bis" draft.

How would IANA know when is it safe to do that .. meaning when all implementations will not suddenly support and all deployments will enable 3107bis ?

I don't understand the issue you are raising.  I don't see any issue of "safety".


New SAFI requires a new capability which you are asking for anyway.

I don't understand the point you are making here.
 

As far as implementations please keep in mind very important point that some implementations treat SAFI 1 & 4 in single table and some in separate tables.

Yes, and these implementation differences have consequences that are discussed in the draft.

That when mixed with 3107bis may just explode if not in new set of bugs then with operational nightmare.

I don't understand the issue you are raising here. 

While we are at this it would be much cleaner to mandate in the new spec to have 3107bis always to use separate tables as compared with from SAFI 1.

Two goals of this draft are (a) to document the consequences of the implementation differences, and (b) to avoid invalidating any particular implementation.  Obviously these goals would not be met if the spec mandated a particular implementation method.

As we all know 3107(bis) tries to add NNI to MPLS. However it must be very well stated that this is only one deployment option for interdomain encapsulation. I would very much like to see a section indicating that IPv6 or/and IPv4 be used as an alternative encap for those applications which require it and when needed provide local bindings between intradomain MPLS and interdomain IP.

This is entirely out of scope.








--------------020003050503060808030109-- From nobody Mon Apr 4 06:53:38 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 51C1412D5B6; Mon, 4 Apr 2016 06:53:33 -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.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404135333.15696.25056.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 06:53:33 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-proxy-arp-nd-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, 04 Apr 2016 13:53:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services of the IETF. Title : Operational Aspects of Proxy-ARP/ND in EVPN Networks Authors : Jorge Rabadan Senthil Sathappan Kiran Nagaraj Wim Henderickx Greg Hankins Thomas King Daniel Melzer Erik Nordmark Filename : draft-ietf-bess-evpn-proxy-arp-nd-00.txt Pages : 22 Date : 2016-04-04 Abstract: The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast- forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in [RFC6820]. This document describes how the [RFC7432] EVPN proxy- ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-arp-nd-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 Apr 4 14:28:50 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42F712D8C2; Mon, 4 Apr 2016 14:28:43 -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 MXuTh3CZmFzP; Mon, 4 Apr 2016 14:28:41 -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 0846412D8BB; Mon, 4 Apr 2016 14:28:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5B6EB324545; Mon, 4 Apr 2016 23:28:39 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [10.114.50.55]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3A35F238055; Mon, 4 Apr 2016 23:28:39 +0200 (CEST) Received: from OPEXCNORM2F.corporate.adroot.infra.ftgroup ([fe80::994e:c3e:1d70:d2b4]) by OPEXCNORM63.corporate.adroot.infra.ftgroup ([fe80::950f:e42a:174e:2048%21]) with mapi id 14.03.0279.002; Mon, 4 Apr 2016 23:28:39 +0200 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRjDXCqHf38G7z/0eG06bIad1uvp96Udrw Date: Mon, 4 Apr 2016 21:28:37 +0000 Message-ID: <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> In-Reply-To: <56FEA566.8070605@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.4.203019 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 21:28:43 -0000 > From: Eric C Rosen [mailto:erosen@juniper.net] > Sent: Friday, April 01, 2016 1:44 PM >=20 > On 3/25/2016 7:25 AM, bruno.decraene@orange.com wrote: > >> I'm quite sure you have deployed implementations, from several > >> prominent vendors, that will not properly handle this case. > > I'm waiting for this/these implementation(s) to make a public statement > in this thread / IETF WGs. Then we can discuss whether the issue comes > from RFCF3107 or from the implementation. > > If none make a public statement, we should assume that all > implementations are capable of receiving multiple labels, as per RFC 3107. > I strongly disagree with this. We should not ignore the facts just > because you don't like the way the facts were gathered. >=20 > A better approach would be to have operators state whether they have any > deployments in which the "multiple labels" feature is used in a > multi-vendor environment. It is very useful when working on a "bis" > draft to determine which features have been proven to work in a > multi-vendor environment and which have not. Asking operators or vendors is equally fine for me. My issue is how do we prove that _nobody_ is using it? Proving the negative= is hard, and silence is not part of the proof. To prove the negative, we w= ould need explicit statement from everyone, which looks impossible. =20 > > Any non-compliant implementation may create interoperability issues and > unpredictable results. > > From an IETF standpoint, the question is whether a RFC 3107 > implementation would create interoperability issues, up to shutting down > the BGP session. >=20 > There are deployed 3107 implementations which always assume that the > NLRI contains a single label. If you tried to interwork these with 3107 > implementations that send multiple labels , you will experience the kind > of disruption.=20 Agreed. But between 2 3107 speakers, we can determine which implementation = has a bug. Whereas between a 3107 speaker and 3107bis speaker, both impleme= ntations may be compliant, but still the BGP session would go done. > 3107bis tries to allow the use of multiple labels while > preventing this sort of disruption from occurring. Agreed. I support this. =20 > > If you mean that some non-compliant implementation do not work, well > let's fix them. >=20 > The situation is that there is a commonly deployed "bug" in old > implementations, but it is not seen because the bug is in a feature that > no one has been using. If new implementations use that feature, the bug > will be seen, and network disruption will occur. One could say "fix all > the old implementations", but it seems wiser to have new implementations > avoid tickling the bug. The Capability is not proposed for the > purpose of helping the vendors, it's there to help the operators. I support the capability. =20 > I'm not sure why you think there would be BGP session drops due to > 3107bis; if a 3107 implementation sends multiple labels to a 3107bis > implementation, I think the 3107bis implementation would do > "treat-as-withdraw" rather than "drop the session". "treat-as-withdraw" would be fine for me. But this requires the 3107bis imp= lementation to be able to parse the stack of (multiple) labels, in order to= identify the IP prefix and treat it as withdraw. However, by hypothesis, t= his speaker is not capable of receiving multiple labels (in short skipping = labels until it founds the S bit set) =20 > Perhaps a reasonable approach for 3107bis would be the following: >=20=20 > - A 3107bis implementation will not send multiple labels to a peer > unless the Capability has been received from that peer. (This prevents > 3107bis implementations from tickling the 'bug' in 3107 implementations.) Good for me. > - A 3107bis implementation will accept multiple labels from a peer even > in the absence of the Capability. Good for me. Note that I'm not asking for this route to be installed: I'm fine with trea= t-as-withdraw. But this does imply that the 3107bis speaker be always capab= le of parsing a stack of multiple labels, in order to skip the MPLS stack, = identify the IP prefix, and treat it as withdraw. Your approach seems along the line of my original email where I was proposi= ng the following change: "- Even if the capability is not advertised by both peers, and hence a sing= le label is expected, all implementations MUST check that the "S" bit (in t= his first label) is set to 1. If the bit is cleared, the Prefix MUST be ide= ntified as per RFC 3107/this document and treated as withdraw as defined in= RFC 7606." https://mailarchive.ietf.org/arch/msg/mpls/XNhUSSfwTpnOjNZGlpc7O2j3G1g =20 > Another approach would be to have a knob that determines whether the > Capability needs to be used before multiple labels are advertised. I'm may be missing what you mean, but that alternative approach does not se= em to address my concern. ___________________________________________________________________________= ______________________________________________ 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. From nobody Tue Apr 5 05:05: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 225FA12D759; Tue, 5 Apr 2016 05:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf2Vyrhg3RDf; Tue, 5 Apr 2016 05:05:14 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 9E33612D1E4; Tue, 5 Apr 2016 05:05:06 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id j11so8630921lfb.1; Tue, 05 Apr 2016 05:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=f7e5KaFnjH3OFGPiixQTU3OX1N3TGmojIcOU84gHY4I=; b=0YvDeuKMDO+AZ3DiiPaPCuOaTmz9aZqE7XBj+mIjhC9zFVrqIrLTsx6hc3coavBfol 2tFlw8oZ28oeTP5ThuxG8t7xP6n5L4LQDr4V0RloMXl6c9rKgjre5BJCq3KNfPTBIpWR Add2CpObpqr/hTTKM5nRFiwHEH+BBR47mJLPLse42/juVezxaYNk9rIK5bFqRYrjTtZm +Bi27Di+z2apxCnouj2T6KHFKOpBVTQsJo01KTMoTl6P+4aH2Aytp6fLnOd/LmYM/FLZ L0g3YqTgPwfraKQ5BxVIyJ3o0gRoHkFYEMVIOD+CYb81sno+/Lhn2h+5kcOBY34DHbOn dEBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=f7e5KaFnjH3OFGPiixQTU3OX1N3TGmojIcOU84gHY4I=; b=h0xNVBEzs4iAwLFXVDtD3XsUgiKvwqCL4v4HPQlZlc6gIiZPkW/g2SDnLmAaqqTquP +22838b6xlZBsDtjC29P6I+AuFNcsrq5mWDg/XzUucwspisj3kUINfsBanv1GmGRpQhj TXRYBS6mQKkIX19HMMObS5ZOAjY4kDJbyodQ7lQGuGCwSzvaYnGfRvN5SLEVZPyGtb1F EzGd8zMpgfHJ3Y8ZDIMa0CuYWxvIn9sdzZsbfb9UugH1CW82P00REUYJoLqWIX7SlxIr oK7q52adkNP82WLH+lq6y37z5uAXMVuAcc0mqhhQ5zLJUdq2ELhIqsOUeW27SmWedohv h1wg== X-Gm-Message-State: AD7BkJLkYxdXFtqrgr99NUwgpEykPqZcxO/m7z9uTi6hPE7YXMIB8NVZIwhr1uh29ov4SZJU3lIzbB2TFiL60w== MIME-Version: 1.0 X-Received: by 10.25.207.209 with SMTP id f200mr138035lfg.110.1459857904762; Tue, 05 Apr 2016 05:05:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.136.133 with HTTP; Tue, 5 Apr 2016 05:05:04 -0700 (PDT) In-Reply-To: <56FEEBEC.5060902@juniper.net> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> <56FEEBEC.5060902@juniper.net> Date: Tue, 5 Apr 2016 08:05:04 -0400 X-Google-Sender-Auth: fW9uMCe1LQnt15IJ4U7UDYP9uC0 Message-ID: From: Robert Raszuk To: Eric C Rosen Content-Type: multipart/alternative; boundary=001a114003fed60757052fbba798 Archived-At: Cc: Bruno Decraene , "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 12:05:16 -0000 --001a114003fed60757052fbba798 Content-Type: text/plain; charset=UTF-8 Eric, If as it turns out if the primary motivation for 3107bis is to distribute label stack for segment routing that I do not think per destination prefix is a sufficient granularity. How with 3107(bis) you can match on the src of the packets ? How you can match on the more granular information to steer packets differently depending on the application ? Wouldn't it be more flexible to simply define new attribute to carry the stack within any SAFI as an opaque to BGP data ? That way one can easily use it in unicast SAFI or even in FlowSpec. Thx, R. --001a114003fed60757052fbba798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Eric,

If as it turns out if the primary motivation for 3107bi= s is to distribute label stack for segment routing that I do not think per = destination prefix is a sufficient granularity.=C2=A0

How with 3107(bis) you can match on the src= of the packets ?=C2=A0

How you can match on the more granular information to steer packets diffe= rently depending on the application ?

Wouldn't it be more flexible to simply define new attri= bute to carry the stack within any SAFI as an opaque to BGP data ? That way= one can easily use it in unicast SAFI or even in FlowSpec.=C2=A0

Thx,
R.=

--001a114003fed60757052fbba798-- From nobody Tue Apr 5 06:28:57 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 E1BDA12D169; Tue, 5 Apr 2016 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTJZZSOndQJu; Tue, 5 Apr 2016 06:28:54 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26EF12D921; Tue, 5 Apr 2016 06:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i3CbgejspmXdM4UJH9zrRxu7uDwRSP0wvqt8ikbUdSY=; b=g6TvMylAZfU9uNRKoBgvNHuCBCNhBX0OBdMqXUAXESnKI+kVKCf33PYOBbYwjnTWMw+rAMTqjEL9h7HvxXljcIF5KAQtRdImNv19gcZ69iFKreFHTiayW78+UUOVsuaXYL1hOsykkaG9Mi/3FWDK2kfhs+Y6sZTyCPaH1KBgZJI= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.33] (66.129.241.12) by BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 13:28:47 +0000 To: Robert Raszuk References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> <56FEEBEC.5060902@juniper.net> From: Eric C Rosen Message-ID: <5703BD8A.7090005@juniper.net> Date: Tue, 5 Apr 2016 09:28:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060504090800030109070708" X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR09CA0008.namprd09.prod.outlook.com (10.160.127.18) To BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) X-MS-Office365-Filtering-Correlation-Id: 5345a368-7aca-4cb5-86cc-08d35d563856 X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 2:W/wq34iz7oION6mK/b/S5udWfpF17dzAbN75tbazBjizpBGrEfHax6zJwaVjpy+pjoJ6mHYhe23zhnrkdkOoPc7WZnTC3Bg4q8ZPe3V42JQ7iPt8IPOelvbrZJ75VpZQnUuPUnOHhJUOWWPgZc/BAzwvk0rOLxkKH2DQXzMo1gBT4JQ5jtrg2Iy2y43OR6OP; 3:m3kd2RmXhCTTDvElzrZrtPRSUhu/HsZby0o/alCdjzNa4N7M72XA3p2fvvNoanJSzhFMiMCTt57PJAKL//I4waB2d2yifUy+ELMiOiKdg39feAcxW9sdolAeyN06/lNN X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB789; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 25:nrkxAHNX22thvIvOTQPvfuuSRZZcMXtqc8VthYbNXesiX9VpXBSLV9yiK6YPXPLJXH2fA+hCPtPBNsxgz1m91zAxRJ+MY09wcXdJEEZYe9hi6Kuzf008amUUzHb1zYG+igvls7D4VRoYQ80/TnrBW0xWneOOpdtrryU0ppDDkUXdkDaaNzoevgrHxYSq7STmKltCa+oIZhTUQUQxlgfmgVFiOFQ+fA/NrV5M28XwEjQTNzhODPHTtmvgWe01l6S41dsP2RuwlU50aH4O8MvXx6K3hsbnxv/j730HgKy6+3uaVHIRnDpRBHNQCHIjfa1bTyR5fgYc4De8sB6Tkgp883w3gtHGam9aHyS0JiZEllVcUKQUp9QWCc49GmrDutwPdKS3yIddDFfkqiFEstGAJQmT7r4d/xS4kOjuXKwEeFIJTM72XkEGMELFe9ixtUCEv1/OlFKJOgGE/s5HEj1W/uEU6h9FGeN8Spmw0X58QTng0tWBzGEW76Al8Px/0eZcGTqWl0dG/69PoBqfkK83igi9KC1fZ+Kn3pJXmHI0kcCZ4XEnIWgSENZfEG+xahX0MGD13bHwztRODv9k7SIEJ02MoV0lfxihrkiKR7naD5soNg1jYqihLO8wID6CA2paW1OLhRXwJY+gplMy4olZo6P9gBAlIRqMUYBzdubF5gYxgbUV2fXO1HxS/ZvfRGd79lWT1u2kpNakILKEIap04pvObgWb6BTjCUM+1j+GoDw1IvEdu+gE0DKckJSRjSbMVurXvHNusEFCxGYuTPNcwg== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 20:tcZNjoZ3mDrzwv/EBYSTRvWtYBWYcyNXoIyk3fTlfLfb9OUpV1QPK5o+NWK0nmE51pNcQOS/ts2MavEaW+iLzjvZWXqAXy7i+3P6kQBa3NERDZHKvT2yywFDu8ck8DUO8ZYjR6NyGj6infva4nZXpywXCf42+L623dmXDLbSaH2+ofdiGshNLis0afcSGcwBk70z6i0jH68jWs/a1snNUIsPdd74yBvyFuSb3/97ffOroXxIgSF9AKOgI6+YhiXLPv3cOerLkVXKPnzuOGhbbZuW/NA4AI8GugQeuMGpLpWkjrzLgGNK2IbcpwYEL2XN6jlpO8Ki/DkKMU09QhFEvPzQa7mKehINAigusD46LtYvSpvyKlRj61IEpjxhyU1ebZw3fyuUVjEVG9blB4YPG/Rcrwckvtcg619Rd32WcvSlNX//abJ0ue1cf8n6YTFFQX4OstZXl8dNaWyeB0pPokoE3T6wTCoj2HKkAjaRAkBCN/IkGM19+G5WENYS6Y6Y; 4:poGxuASh04kUXA0wu2rIwl30DWqQz2nUzQkg7eAcwCZlHy/qrue92j2mt5iDVI05a1h9jbdW5rNzEExTlthoerejBcn+78H7bljTkCaIWURGxRcbZyijSISskL2HtZMtY2vV0qO8kYSE0Sl2UGFrEX2HUN+TN+m8j1ayMnY+oycPtv2MN4woRqJK9EkBkNabUZF5MfTNjG8kPfvmsJG5DK3Zx/F2dX4Mo+a69b/7fulVj9+5vxEN6yjcESpDP+vsWqZyWQHyR9YLjrUPfropvuQVFt3dwWph6KquYSmAFkD41xLN89GRQ8cV51I+PfB12f2e4UxS+xUD6E9dULovaQT/WjxM2LtQGp9OM4rcjnNqi0depQcnBZ15ZZZbqCKv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR05MB789; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB789; X-Forefront-PRVS: 0903DD1D85 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(377454003)(24454002)(51444003)(65816999)(86362001)(84326002)(87266999)(270700001)(80316001)(81166005)(76176999)(42186005)(1096002)(189998001)(2906002)(512874002)(110136002)(92566002)(93886004)(586003)(54356999)(36756003)(50986999)(230783001)(64126003)(5008740100001)(2950100001)(33656002)(77096005)(6116002)(4326007)(3846002)(5004730100002)(66066001)(65806001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB789; H:[172.29.33.33]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI3ODk7MjM6TlQ4Ym1IU2NrMEVtNVdlRFY1bkZ6WXc3TGJj?= =?utf-8?B?amZWOEJmYjJJREorcmEwdXM4cVhvbHA2ekppTVg4WnZ6MTF6d0p1N2tLdWlG?= =?utf-8?B?ME5aUU5WNDlscm94T3NmY202OUFzWXZuc0FZQVJoR29vWHk0eDBNM2E5dFI1?= =?utf-8?B?T0Rjdm01Ui9LRjlVaGFsUGdSSzVNRzRDaW9VeHl1anloSVVrT3BsMkRxK1l4?= =?utf-8?B?NHp2Y3BWZnNLTW93NXU3TXgySngyZU1oNWlkSG5CNCtteEFXbVJ4MlFaVjdI?= =?utf-8?B?STAweG1qUnBSZkEva2IzcGhhL2hMV2U2SVIzT3pxZ2tnY1lUc0pvNGwwOGN2?= =?utf-8?B?UGg2RklFOU01UytvOHhaVUFFUHVvdWM5bjR3RkhFNFhEVlhwZ0N2bjVtaVRk?= =?utf-8?B?Z00zLzNQVi9LUDFacTBVdDhFRVNYTGNrVitZajlyTXA0alRCSkJzc1gwTEFP?= =?utf-8?B?cXBZVTNNSTN5U2JSMUhBYjVGckFNRjkrMm54eHdvM1NTbWZxM2lhUjRkVy9l?= =?utf-8?B?cjROY01NS25yM25MWHRBMkI1bXBiUXBTTUF2Z0o1c1dubGdnbHQrZDlhTlNH?= =?utf-8?B?K0psT2VBcmI5VmNSeU1TejczUWdVeUo4RzdMeGsvSUN1VW9CaWI4dCtBb3Rx?= =?utf-8?B?ZUgvdE9KK0JSV2VoVlRMdEluakdGYlFGUDRkaVYrS2ZIaHF6aDJKUTdiby9T?= =?utf-8?B?VTJlNHdkQVNyUE5rblpUUTNoMm0zaEVWUmh0dzMybFh4OGRLRW9nQndWcTFK?= =?utf-8?B?amJrbTBrdnhoK2MyK1lOa093WktVYmE2Nk9Wa1F4aHlHdFYrQU5hanZQYVBz?= =?utf-8?B?OG5MaW1mVWE5M0M2RzJzNktkS2tGcEcvbm5BampxQW5ZVHNlcXVVKzhTNUNk?= =?utf-8?B?N0F6bDdWQVAwNVRsSkQrRzYyOEo1NEVuZXBPd1V0dXpsTjlCWG9zRWdYeTdU?= =?utf-8?B?RHhNNEZ4Sm9hdjMzS1lzc0YzT05OVkc2Y1ZFeXNKc3ltTTZ4OFpqc2c3V0VU?= =?utf-8?B?UmVNV2JkTDF6M0VzNElta2JrZi9WaXdTWjVFVFJtOUZVR3AvQ05iRVBHcG5v?= =?utf-8?B?VWJNa0xyTHp5K0Z1RExWTmdzcGFUeVdkVmVRaTVySnV0M3k2WVRvMTU1eTdi?= =?utf-8?B?QzdGOUJkRURGU1RnYUV5QjhEc2pRS25icXliM3RpRVhjZUU4REc3Y1BCdzFo?= =?utf-8?B?aTk2aXgwRUNseFJkQVltSXdiYnZrWnpQQzlMaWdxVFNlNllnK0FDQUljZGox?= =?utf-8?B?eTlSNHpibUdXUFBXRTlIaWo4Slk0S1ROU1BHb0Z1RkhwZEtCeXRiQzloZ0E5?= =?utf-8?B?ZHdRMkE2NGZqTFVVSGgreTJqanV3NkFBK283aEo4ek1CekYyTlNJVW9FOTlG?= =?utf-8?Q?JDjDfFr?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 5:o15K3RYqayd52H6lFZ9vXr0MqdH+CSRRr7wEyMjoWzxwlJ+bauGGiPKZQNHRajjgTLR5T2F80+SsF0DblbjA2wg/u1C9vP9Fu9vqBfbkQHjDPQhF/vQLW1eK6mDzJ4sm8XvSVcsVa/y2tCS/gcvjCA==; 24:00qc05z5njFWlxioWrxW+FrjscRE2+OGtqrRjV19ukieubuMW9A2orlQ5Q1+/lpLcPa9TouAei72Bd/J7U2uvnw7vG+CcVSEquuFpTarPJo= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2016 13:28:47.3449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB789 Archived-At: Cc: Bruno Decraene , "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:28:56 -0000 --------------060504090800030109070708 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 4/5/2016 8:05 AM, Robert Raszuk wrote: > Wouldn't it be more flexible to simply define new attribute to carry > the stack within any SAFI as an opaque to BGP data ? That way one can > easily use it in unicast SAFI or even in FlowSpec. That can be done with the Tunnel Encapsulation attribute. Look at, for example, at draft-previdi-idr-segment-routing-te-policy (though I think that document still needs quite a bit of work). > If as it turns out if the primary motivation for 3107bis is to > distribute label stack for segment routing 3107bis fixes a number of problems in 3107, and it also specifies how to use the "multiple labels" feature without tickling known bugs in existing deployments. One could argue about whether this is the best tool for various segment routing applications, but that's outside the scope of the draft. And there are use cases that have nothing to do with segment routing; see, e.g., the discussion of context labels in section 4. --------------060504090800030109070708 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/5/2016 8:05 AM, Robert Raszuk wrote:
> Wouldn't it be more flexible to simply define new attribute to carry > the stack within any SAFI as an opaque to BGP data ? That way one can > easily use it in unicast SAFI or even in FlowSpec.

That can be done with the Tunnel Encapsulation attribute.  Look at, for example, at draft-previdi-idr-segment-routing-te-policy (though I think that document still needs quite a bit of work).

> If as it turns out if the primary motivation for 3107bis is to > distribute label stack for segment routing

3107bis fixes a number of problems in 3107, and it also specifies how to use the "multiple labels" feature without tickling known bugs in existing deployments.   One could argue about whether this is the best tool for various segment routing applications, but that's outside the scope of the draft.  And there are use cases that have nothing to do with segment routing; see, e.g., the discussion of context labels in section 4.







 
--------------060504090800030109070708-- From nobody Tue Apr 5 06:49:50 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD612D5E9; Tue, 5 Apr 2016 06:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhFdRV0Fpmx1; Tue, 5 Apr 2016 06:49:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FA412D16D; Tue, 5 Apr 2016 06:49:46 -0700 (PDT) Received: from [31.133.177.67] (dhcp-b143.meeting.ietf.org [31.133.177.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9F7D91802ABC; Tue, 5 Apr 2016 15:49:44 +0200 (CEST) From: Loa Andersson To: "idr@ietf. org" , "bess@ietf.org" Message-ID: <5703C26F.4000807@pi.nu> Date: Tue, 5 Apr 2016 21:49:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls-chairs@ietf.org" Subject: [bess] HEADS UP - discussion on draf-rosen-mpls-rfc3107bis in the mpls wg meeting in BA 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, 05 Apr 2016 13:49:49 -0000 Working Groups, Please note that there will be a discussion on draf-rosen-mpls-rfc3107bis in the MPLS wg meeting, Wednesday morning. Currently the discussion is planned to start at 11.25am, though the time may be subject to change. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 5 07:26: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 1D96712D17D; Tue, 5 Apr 2016 07:26:14 -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 sQrn2R-9eXmM; Tue, 5 Apr 2016 07:26:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E1412D11B; Tue, 5 Apr 2016 07:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZyB2y8DIjjN5bD/EVTIwcP6LAyUnLEVzNo3nFdymrM=; b=IFbjN2kO8B4EtKVt/+i4Cm9K+BP6cLMlrjbYTS3EBC8UPbC6HJgQbpo0dqLZP8EGFWzpSZkKeu546cHckHvtkZKLUCzHw0bC00k/TcSvxl+WnRhXY5Uc611a8yyT98pWPz5akLFWwO7r9OX8+Jz6Dn6jzZJNbkKFj8g1PxEuuoM= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.33] (66.129.241.12) by BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 14:25:54 +0000 To: References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <5703CAEC.9040407@juniper.net> Date: Tue, 5 Apr 2016 10:25:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR0601CA0032.namprd06.prod.outlook.com (10.160.162.42) To BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) X-MS-Office365-Filtering-Correlation-Id: 5ffe3a67-7b3d-447b-7a3d-08d35d5e331b X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 2:ufDLkJSurOq5cZeNZiRJ1SdC83hMZbjfeBxqF+UY6HLIvLElVNqRM9aD5tYamlQwNJ76wraLJCLSOhamKtJM3XDR1+r+yWMtQpssYf6cFhihrMrSwaIuRNNcThi+EHa7+JxAuIUwjAX1syet1kn2hF9/CrbK/rdUPynZxH+8MhmseDAac2qpc+upka1usVMp; 3:QlHZ9Qw5EeB9IORFMpKVKuywYhFUrQwlKWpmPCqLzdrvsdqp5lP87AWJCW4QmRUHQxFeLxF82wlWhkF5+gOtSgROv2bKtBJLV89lw0GRAvn4ffF8jD/wynW6HqcmEV+D; 25:lwtEYf67Kq1vRlTyrQaRRAFifuLfeKGRhn83fLkkstIJLX+bcNQuFL0CFfqo5+r50qf1NrASMtYX6dvgSag3L2lfJfXguW1iPBguobMRuJc83tM4aLrqb6Puupf6e8QohRGknmslqhA+WnCm6gUoeDr7Lt+y97+Tk8GV4nAZE53LhZDxRJQCcn9d2B7ACFbKhEtsBoFAq0iltS/uaGixLOL8hqeaFzCviq+zFjgBsDOmnMIgbBmAb5OCYCyrBLOubSpMUkc2fhbdR1gcHY95BDZm/2bvKGayK0p6kXueiZ/OOCISR1yhteiB59gQjHncVZmUDxwc/+GmRhDY1c8tCW0zNnOYpCzOYf9NCLWjhXM= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB788; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 20:p9UcKtIzB+VC4jMVkaycdirTwx/gQvtlZ8zbZHioIjxpKLqg5zbT48jGPb651LOsIQ9MbVGcDhgr33IAotLsPKaCZFUQ4QQruqdwFDFJ4Zp+i0l5qbNx4pvEwX1x6C6Jv6ylAF3Jhmko96v/AsBV3jMBv0sU1dQ1cy4jWpNZF1Y/fuD7b69veIT2XecWX0s/eDVaFzcH5iJqqSu981n8UlVsfCkr57+mt4FoE9kS1ysDf42NA32rNaQ0ipBXhJ/ITHK123c4cgQlAFEkmtP4rnqD+6zou5WnEuTSZjB17bDa6iU0pYAatdsGVVpefMlKJBqUv2l4zhQvkk2AV1EWNFJ/0Kzmwl/k1pcHfdRL8d2YO1sLctOVpnVqpcS+0YWanE7rzOr0Twle7y7FjFst11ofIt8M+PmZHzN7hB0M7Sevmtmapcnysw+nRXuz9x0j1zzuO3Y3iAoNM2vEZpoOKWTOEVYLlIps+jNfxZXglUlrbYBMSEI9G2yZlOzJAwou; 4:/nRROFlKGXFH7j6CqUE1YqTwigdc0cSQEwttl7t8/j8L/eQghoPAAkatrTxTHDihATmX6VicdS+J+3RW7TpUpIkAbixS3bmuU+aLkodpSJu2NaBj6nzlSU9P2HZ4sZJ4JIWohD/Kk4wWb+jqXERAG3guikYYVEOIrtbow/aWKqwFbpflYW4wRzB649bO4Wzpy5Cgh7IfQMLU68pEEWK9CDIbkDLxm51KKNr/GLC9aXJYa+P/IvW/3sXbS6RiO4nJao78W5U8sIyR7ZgyDPNJMdVvTM8oc5OUP8qj7xpelrYmI4Ddjtq4B+SZudlHmFVfGkWm34383ZCp+VJvHCZjbu6oBZCCDiWnj/MYFHKo1VmQPFanrb1nB6/70K/s2mQl X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR05MB788; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB788; X-Forefront-PRVS: 0903DD1D85 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(5008740100001)(4326007)(19580405001)(80316001)(19580395003)(1096002)(2906002)(3846002)(93886004)(6116002)(50466002)(586003)(81166005)(77096005)(230783001)(189998001)(2351001)(42186005)(2950100001)(110136002)(5004730100002)(33656002)(230700001)(66066001)(92566002)(50986999)(65806001)(36756003)(65816999)(64126003)(87266999)(54356999)(47776003)(76176999)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB788; H:[172.29.33.33]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB788; 23:sQ8sgoiUucJYi89EKfAxzK6rAVmDv/EQIy65Vi?= =?Windows-1252?Q?DDMghdqxs/Qfyc8XDM5mKVMjL4u/O/keYG2amtVsrCt0hMFy9nzfr7nW?= =?Windows-1252?Q?L0VI39ppdL2yfQyGU55gg7ew1zV7aNuiSF0Flg/sqWQbf73Zt0j7oaqm?= =?Windows-1252?Q?YR2ChaC6H5SyI7Qz9/Lnx4dtdzUSuejXZ51rM0pUMSbgX3zmf5ZbJiAb?= =?Windows-1252?Q?hxu4mjR9oY7b9BUbogL1qVKccvSCtGXWR3jKRLwb7sWhbhI3EDJhd1M6?= =?Windows-1252?Q?ZKxS20Em7/dDpV8HSBwcKjzbcZnfnBtSSzB09sbGYMaLfZToAu0RtGw8?= =?Windows-1252?Q?Ucvg+X+gcaZUGtdSsXJVXSd+xnDp2Vm4O6yj0GhEzz49qBkVUc2hwgEm?= =?Windows-1252?Q?1itR1zOqutMQ8Q4zksqadJ5EN8Y1NPRVgTphbiLV8VjQ4nEFZTcOIHbY?= =?Windows-1252?Q?nZKEcpLKjaEQjCJ4BAcOjiwYZTqZYyosKiAy7P2I6z0ze/WoEGA6q94N?= =?Windows-1252?Q?R4qYEZ2TJRO+ujlypoyR319aoXN7dqEtjXawDd9xX8jjq9bTNaktV9Oe?= =?Windows-1252?Q?nTH0CMnPhWfQPJ5Qemosfow+VBF+RPEz2MpkCU4w2/o21wxI3+6VqVUv?= =?Windows-1252?Q?Wo4mmgRauYC7SE5KvHh0XPGgM0NXJCSClSvgSDBpfe2swJcJogQsv8/T?= =?Windows-1252?Q?n0gCESRcE573O3KwmDb1+dGiUzNaH+YyA/i5SaA41jfmRPEx53B6HnQN?= =?Windows-1252?Q?DLPBr5WE5V/2lhUWCDiMajwZfTDTbzib+579BJXQcRD3H2MMkxCezK/3?= =?Windows-1252?Q?4Ff7wF0jGYxbzkfb6tJ0chUg5dOc9sKF3relp1Q6ztvrWRRplHRV17d6?= =?Windows-1252?Q?12/fIJpCqFc4IobcmeB/U+FCDQ0AAfxfHfGuYXG5VRxs5+Amsh52Zr2j?= =?Windows-1252?Q?Ti1HqlWr+I0H9KO8PKJcfFS3BXC7v/DECxxJmWpiJUUmiTxzpssdNXld?= =?Windows-1252?Q?AVYJVtwsXULFwnCzT20ZWKZMPBmGhWXU8UQBc6V4tRAV8V3gN0WJSXTD?= =?Windows-1252?Q?3XRGI2MNGY/thK2PzQf+/zTPKoMMRB1qxdeJBGU9t41elbvxOib128dC?= =?Windows-1252?Q?XvymHL93V+ZxbtfHWeAFY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 5:UPNxHGlwgQsn23R+CzMtFwdxE77PVOJ8ZShx10vTjc0geNT7TtJWM/45O2rfwIm48j2gEaOqXxwfC3PJGI2lWDlANTujScJWrW1oLcZO6WmRxofjmxNfV6zz4qmYYcX5KzSJhD6ZxGcMf3l9NxvCaA==; 24:lw0pQPv3P7ZVGUL41gQtLCOE27qsKWQ5o7U1tDlTYadQROdjw6GypzXepeT6cEADhdzeBWFZRP5jdlB3Z+Qu6m2q2/f4XMDJfsSgPv3s0K8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2016 14:25:54.5119 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB788 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:26:14 -0000 On 4/4/2016 5:28 PM, bruno.decraene@orange.com wrote: > My issue is how do we prove that_nobody_ is using it? Proving the negative is hard, and silence is not part of the proof. To prove the negative, we would need explicit statement from everyone, which looks impossible. I think you're exaggerating a little ;-) I'm having trouble believing that you are unable to determine whether the 3107 "multiple labels" feature is in use in any of your company's deployments. I think a more serious concern is how to avoid tickling the "day 1" bugs that may exist. There may be implementations, supporting only a single label, that fail to set the S bit. There may be implementations, supporting only a single label, that fail to check the S bit. These "day 1" bugs will never have caused a problem, because the multiple labels feature has not been used. We should endeavor to ensure that these"day 1" bugs do not cause a problem in the future if newer implementations begin to use the multiple labels feature. Right now, we're arguing about which of the following two strategies is more likely to cause a problem: 1. In the first strategy, 3107bis requires the S bit to be set when there is a single label. This will allow 3107bis to interoperate with 3107 implementations of "multiple labels", but it will not allow 3107bis to interoperate with (buggy) 3107 implementations that send a single label, but don't set the S bit. 2. In the second strategy, 3107bis assumes, in the absence of the Capability, that there is only a single label, and doesn't bother to check the S bit. This will allow 3107bis to interoperate with (buggy) implementations that send a single label but fail to set the S bit; it will not allow 3107bis to interoperate with (non-buggy) 3107 implementations of multiple labels. My argument is that the second strategy is better because it will be less disruptive. This is based on my belief that the "day 1" bugs do exist, and that the "multiple labels" feature has yet to be deployed. Your argument seems to be that the first strategy is better because (a) it only causes disruption if the 3107 implementation has a bug, in which case the bug can be fixed, and (b) if the second strategy is used, a 3107-compliant implementation of multiple labels will fail to interoperate with a 3107bis-compliant implementation of multiple labels, and both implementors will claim compliance. I think your argument is reasonable, the question is really just which strategy will cause less disruption. Do other members of the WGs have opinions about this? From nobody Wed Apr 6 05:09: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 4385812D981 for ; Wed, 6 Apr 2016 05:09:22 -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 AocXfbRFAkHF for ; Wed, 6 Apr 2016 05:09:19 -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 0CC0212D9B5 for ; Wed, 6 Apr 2016 05:09:18 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 23D91DD764EB5 for ; Wed, 6 Apr 2016 12:09:13 +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 u36C9ECL027941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Apr 2016 12:09:15 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 u36C9D8b020284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Apr 2016 14:09:14 +0200 Received: from [135.224.206.114] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 6 Apr 2016 14:09:01 +0200 Message-ID: <5704FC58.7000604@alcatel-lucent.com> Date: Wed, 6 Apr 2016 14:08:56 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <56CB3E3E.6080602@alcatel-lucent.com> In-Reply-To: <56CB3E3E.6080602@alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [bess] Poll for adoption: draft-fm-bess-service-chaining-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, 06 Apr 2016 12:09:22 -0000 All, this poll has ended. Although an IPR disclosure came during the poll I did not see any change wrt to the support of this document. We thus have a new WG document. Authors, please republish as draft-ietf-bess-service-chaining-00 Thank you Le 22/02/2016 17:58, EXT Martin Vigoureux a crit : > Hello working group, > > This email starts a two-week poll on adopting > draft-fm-bess-service-chaining-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 7th of March*. > > Note that IPR has been disclosed against an earlier version of this > document: > https://datatracker.ietf.org/ipr/2284/ > > Yet, 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-fm-bess-service-chaining/ > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > From nobody Wed Apr 6 05:09:44 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 4041212D97E; Wed, 6 Apr 2016 05:09:43 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406120943.24997.416.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 05:09:43 -0700 Archived-At: Subject: [bess] The BESS WG has placed draft-fm-bess-service-chaining 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: Wed, 06 Apr 2016 12:09:43 -0000 The BESS WG has placed draft-fm-bess-service-chaining in state Call For Adoption By WG Issued (entered by Martin Vigoureux) The document is available at https://datatracker.ietf.org/doc/draft-fm-bess-service-chaining/ From nobody Wed Apr 6 12:34:53 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 BE60512D559; Wed, 6 Apr 2016 12:34:48 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406193448.24912.51916.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 12:34:48 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-evpn-df-election-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: Wed, 06 Apr 2016 19:34:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : A new Designated Forwarder Election for the EVPN Authors : Satya Ranjan Mohanty Keyur Patel Ali Sajassi John Drake Antoni Przygienda Filename : draft-ietf-bess-evpn-df-election-00.txt Pages : 15 Date : 2016-04-06 Abstract: This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-df-election-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 Apr 7 11:51:19 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454A12D576 for ; Thu, 7 Apr 2016 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLEfz2QaFoRM for ; Thu, 7 Apr 2016 11:51:16 -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 5276812D533 for ; Thu, 7 Apr 2016 11:51:16 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E138C21C303D4; Thu, 7 Apr 2016 18:51:10 +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 u37IpDhp008807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 18:51:14 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 u37IpDt7010645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 20:51:13 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 20:51:13 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "sboutros@cisco.com" Thread-Topic: draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AQHRkP518O/6Q+6y30Kf5VbbrPl3Rw== Date: Thu, 7 Apr 2016 18:51:13 +0000 Message-ID: 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.39] Content-Type: multipart/alternative; boundary="_000_C56EF1050FBB46E3A05BBC6D44816DBDalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-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, 07 Apr 2016 18:51:18 -0000 --_000_C56EF1050FBB46E3A05BBC6D44816DBDalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGRyYWZ0IHRyaWVzIHRvIGFkZHJlc3MgYSAxOjEgYXV0by1wcm92aXNpb25pbmcgYmV0d2Vl biB0aGUgVlBXUyBhbmQgU2VydmljZSBvbiB0aGUgc2VydmljZSBQRS4NCldvdWxkIHRoZSBkcmFm dCBhbHNvIGFkZHJlc3MgYSAxOk4gcHJvdmlzaW9uaW5nIG1vZGVsLCBtZWFuaW5nIDEgVlBXUyB0 byBtdWx0aXBsZSBzZXJ2aWNlcyB1c2luZyBWTEFOIG11bHRpcGxleGluZyBvbiB0aGUgc2Vydmlj ZSBQRT8NCg== --_000_C56EF1050FBB46E3A05BBC6D44816DBDalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F63923CBB837541B70A2147A3944AD3@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoZSBkcmFmdCB0cmllcyB0byBhZGRyZXNzIGEgMToxIGF1dG8tcHJvdmlzaW9uaW5nIGJl dHdlZW4gdGhlIFZQV1MgYW5kIFNlcnZpY2Ugb24gdGhlIHNlcnZpY2UgUEUuPC9kaXY+DQo8ZGl2 PldvdWxkIHRoZSBkcmFmdCBhbHNvIGFkZHJlc3MgYSAxOk4gcHJvdmlzaW9uaW5nIG1vZGVsLCBt ZWFuaW5nIDEgVlBXUyB0byBtdWx0aXBsZSBzZXJ2aWNlcyB1c2luZyBWTEFOIG11bHRpcGxleGlu ZyBvbiB0aGUgc2VydmljZSBQRT88L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19T SUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_C56EF1050FBB46E3A05BBC6D44816DBDalcatellucentcom_-- From nobody Thu Apr 7 11:54: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 D4F1412D5C2; Thu, 7 Apr 2016 11:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5V7_DJfHR6Bu; Thu, 7 Apr 2016 11:54:20 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D581E12D56E; Thu, 7 Apr 2016 11:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1741; q=dns/txt; s=iport; t=1460055259; x=1461264859; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xcO4hDTPk81g+qXPcvPErz5LjqHSGmlnLLPLLrBDEdI=; b=ZghWaoTYG3yxs87mSChdR4U1yt8Mat1+FEXSLipiidl1Nt0vCcgt0Rw/ RH4Tpp8rfE/PVVOePXrkVn3XRLetiWqWqfC4dZNb9+mI40HMku3fq5GPA NeFKXF2YdN6MhBpO+jn7dqL/NVOH8lttD6nbbyHiL/HUViiimWSYduAJ6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBgrAZX/5tdJa1dgzdTfQa6PQENg?= =?us-ascii?q?XMjhWoCgUU4FAEBAQEBAQFlJ4RCAQEEOjQLEAIBCDYFCzIUBwEGAwIEAQ0FiCc?= =?us-ascii?q?OwXgBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuKFQWTGYRrAYV2iBWBZ4RNi?= =?us-ascii?q?FqPIwEeAQFCggkUFYE1bId1fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="256909470" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 18:54:18 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u37IsIN5011338 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 18:54:18 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 13:54:17 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 13:54:18 -0500 From: "Alvaro Retana (aretana)" To: "idr@ietf.org" , "pim@ietf.org" Thread-Topic: Last Call: (Multicast VPN state damping) to Proposed Standard Thread-Index: AQHRkP7jaJ+aOgEU8EmJjlM4C33WVw== Date: Thu, 7 Apr 2016 18:54:17 +0000 Message-ID: References: <20160323191825.2494.1251.idtracker@ietfa.amsl.com> In-Reply-To: <20160323191825.2494.1251.idtracker@ietfa.amsl.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: [10.82.234.83] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DC3A42AAA3AC34AA791DE0DE9671674@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: [bess] FW: Last Call: (Multicast VPN state damping) to Proposed Standard 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, 07 Apr 2016 18:54:22 -0000 idr and pim WGs: Hi! Please take a look at this document and send comments to the bess WG. The IETF Last Call expires on Apr/13, but the document is scheduled to be reviewed by the IESG on May/5, so there's enough time to address comments. Thanks! Alvaro. On 3/23/16, 3:18 PM, "iesg-secretary@ietf.org" wrote: > >The IESG has received a request from the BGP Enabled Services WG (bess) >to consider the following document: >- 'Multicast VPN state damping' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2016-04-13. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > This document describes procedures to damp multicast VPN 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. New procedures are proposed inspired from BGP > unicast route damping principles, but adapted to multicast. > > > > > >The file can be obtained via >https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ > >IESG discussion can be tracked via >https://datatracker.ietf.org/doc/draft-ietf-bess-multicast-damping/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Apr 7 11:58:15 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 8EA1512D6D8 for ; Thu, 7 Apr 2016 11:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 G3t6DWVb47lO for ; Thu, 7 Apr 2016 11:58:12 -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 1DD8212D6D6 for ; Thu, 7 Apr 2016 11:58:12 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EB590DEB8285F; Thu, 7 Apr 2016 18:58:06 +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 u37IwAa6017643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Apr 2016 18:58:10 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 u37Iw5Nj021509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Apr 2016 20:58:09 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 7 Apr 2016 20:58:07 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "sami_boutros@yahoo.com" Thread-Topic: draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AQHRkP518O/6Q+6y30Kf5VbbrPl3R59+iQcA Date: Thu, 7 Apr 2016 18:58:06 +0000 Message-ID: References: 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.39] Content-Type: multipart/alternative; boundary="_000_CB49F903256E4AC787976F224F366AD6alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-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, 07 Apr 2016 18:58:13 -0000 --_000_CB49F903256E4AC787976F224F366AD6alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzZW5kaW5nIHdpdGggcHJvcGVyIGVtYWlsIGFkZHJlc3Mgb2YgU2FtaQ0KDQpGcm9tOiBXaW0g SGVuZGVyaWNreCA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzp3aW0u aGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgNyBBcHJpbCAy MDE2IGF0IDE1OjUxDQpUbzogInNib3V0cm9zQGNpc2NvLmNvbTxtYWlsdG86c2JvdXRyb3NAY2lz Y28uY29tPiIgPHNib3V0cm9zQGNpc2NvLmNvbTxtYWlsdG86c2JvdXRyb3NAY2lzY28uY29tPj4N CkNjOiAiYmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4iIDxiZXNzQGlldGYub3Jn PG1haWx0bzpiZXNzQGlldGYub3JnPj4NClN1YmplY3Q6IGRyYWZ0LWJvdXRyb3MtYmVzcy1ldnBu LXZwd3Mtc2VydmljZS1lZGdlLWdhdGV3YXktMDINCg0KVGhlIGRyYWZ0IHRyaWVzIHRvIGFkZHJl c3MgYSAxOjEgYXV0by1wcm92aXNpb25pbmcgYmV0d2VlbiB0aGUgVlBXUyBhbmQgU2VydmljZSBv biB0aGUgc2VydmljZSBQRS4NCldvdWxkIHRoZSBkcmFmdCBhbHNvIGFkZHJlc3MgYSAxOk4gcHJv dmlzaW9uaW5nIG1vZGVsLCBtZWFuaW5nIDEgVlBXUyB0byBtdWx0aXBsZSBzZXJ2aWNlcyB1c2lu ZyBWTEFOIG11bHRpcGxleGluZyBvbiB0aGUgc2VydmljZSBQRT8NCg== --_000_CB49F903256E4AC787976F224F366AD6alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <63E2E0E43E82C946A049AD9C6E51EF36@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlJlc2VuZGluZyB3aXRoIHByb3BlciBlbWFpbCBhZGRyZXNzIG9mIFNhbWk8L2Rpdj4NCjxk aXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5XaW0gSGVuZGVyaWNreCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+d2ltLmhl bmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDcgQXByaWwgMjAxNiBhdCAxNTo1 MTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90Ozxh IGhyZWY9Im1haWx0bzpzYm91dHJvc0BjaXNjby5jb20iPnNib3V0cm9zQGNpc2NvLmNvbTwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYm91dHJvc0BjaXNjby5jb20iPnNib3V0cm9zQGNp c2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8 L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwv c3Bhbj5kcmFmdC1ib3V0cm9zLWJlc3MtZXZwbi12cHdzLXNlcnZpY2UtZWRnZS1nYXRld2F5LTAy PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+VGhlIGRyYWZ0IHRyaWVzIHRvIGFkZHJlc3MgYSAxOjEgYXV0by1wcm92aXNpb25pbmcg YmV0d2VlbiB0aGUgVlBXUyBhbmQgU2VydmljZSBvbiB0aGUgc2VydmljZSBQRS48L2Rpdj4NCjxk aXY+V291bGQgdGhlIGRyYWZ0IGFsc28gYWRkcmVzcyBhIDE6TiBwcm92aXNpb25pbmcgbW9kZWws IG1lYW5pbmcgMSBWUFdTIHRvIG11bHRpcGxlIHNlcnZpY2VzIHVzaW5nIFZMQU4gbXVsdGlwbGV4 aW5nIG9uIHRoZSBzZXJ2aWNlIFBFPzwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CB49F903256E4AC787976F224F366AD6alcatellucentcom_-- From nobody Thu Apr 7 14:44:38 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 23CCF12D634 for ; Thu, 7 Apr 2016 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWRc5x5FzCPc for ; Thu, 7 Apr 2016 14:44:34 -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 C45D212D640 for ; Thu, 7 Apr 2016 14:44:33 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4030AA442CE for ; Thu, 7 Apr 2016 23:44:32 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 3906CA442CD for ; Thu, 7 Apr 2016 23:44:32 +0200 (CEST) Received: from [172.31.0.202] (10.193.116.12) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.266.1; Thu, 7 Apr 2016 23:44:31 +0200 To: BESS From: Thomas Morin Organization: Orange Message-ID: <5706D4BA.9060908@orange.com> Date: Thu, 7 Apr 2016 18:44:26 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [bess] minutes of our IETF 95 meeting 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, 07 Apr 2016 21:44:37 -0000 Hi everyone, We have just posted draft minutes for today's meeting. You can read them at https://www.ietf.org/proceedings/95/minutes/minutes-95-bess Please send any comments you may have on these minutes. Many many thanks to Gunter for his minute taking! -Thomas/Martin From nobody Fri Apr 8 05:21:57 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 0BF5112D790 for ; Fri, 8 Apr 2016 05:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gVbPVP9whSfg for ; Fri, 8 Apr 2016 05:21:54 -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 4E7C712D6F2 for ; Fri, 8 Apr 2016 05:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5649; q=dns/txt; s=iport; t=1460118114; x=1461327714; h=from:to:cc:subject:date:message-id:mime-version; bh=JyDqvs6uCiP4PRpfKahFMOEYPLkJDlf+BT+ATQlcZ4E=; b=PRMOuy6/WPd5dWVtOeBPviKkNdv9+B8ezSte+tyInjn+78c1BdQIXlOy Qy8JTuL81qTkSbNlwOItvpUtD9+8Khl0nogTCyvGjeTNYO4Qb8vSyphIm 7sEshAnf4d2kkQ7djoKF+hEI9jOE7fLXdOfJQPNUeE8jiVgLQbvYEXIiF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAgCFoQdX/4oNJK1cgmtMgVAGqWSFA?= =?us-ascii?q?4ZlhHMBDYFzhg2BNjgUAQEBAQEBAWUnhEEBAgR5EgEIEQMBAig5EwEJCgQBDQW?= =?us-ascii?q?IEgMSwDwBAQEBAQEBAwEBAQEBAQEBGIpsgkGBThEBPoU2BYYvDJEYMQGMHIFvj?= =?us-ascii?q?w2HSodaAR4BAUKDZ2yIBTZ+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,449,1454976000"; d="scan'208,217"; a="91425706" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 12:21:53 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u38CLref016166 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 12:21:53 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; Fri, 8 Apr 2016 08:21:52 -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; Fri, 8 Apr 2016 08:21:52 -0400 From: "Ali Sajassi (sajassi)" To: "Henderickx, Wim (Nokia - BE)" , "sami_boutros@yahoo.com" Thread-Topic: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AQHRkZE7rkus9b9NJ0iaXL27tPuoig== Date: Fri, 8 Apr 2016 12:21:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.9.49] Content-Type: multipart/alternative; boundary="_000_D32D27EC192614sajassiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-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: Fri, 08 Apr 2016 12:21:56 -0000 --_000_D32D27EC192614sajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wim, The current draft is for vlan-based mode of EVPN-VPWS; where each EVPN P2P = LSP tunnel is mapped to a single service. If needed, it can be expanded to = vlan-bundle EVPN-VPWS mode as well. Cheers, Ali From: BESS > on behalf = of "Henderickx, Wim (Nokia - BE)" > Date: Thursday, April 7, 2016 at 3:58 PM To: "sami_boutros@yahoo.com" > Cc: "bess@ietf.org" > Subject: Re: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Resending with proper email address of Sami From: Wim Henderickx > Date: Thursday 7 April 2016 at 15:51 To: "sboutros@cisco.com" > Cc: "bess@ietf.org" > Subject: draft-boutros-bess-evpn-vpws-service-edge-gateway-02 The draft tries to address a 1:1 auto-provisioning between the VPWS and Ser= vice on the service PE. Would the draft also address a 1:N provisioning model, meaning 1 VPWS to mu= ltiple services using VLAN multiplexing on the service PE? --_000_D32D27EC192614sajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7DAA925B92A17C4B85462C53231F131F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Wim,

The current draft is for vlan-based mode of EVPN-VPWS; where each EVPN= P2P LSP tunnel is mapped to a single service. If needed, it can be expande= d to vlan-bundle EVPN-VPWS mode as well.

Cheers,
Ali

From: BESS <bess-bounces@ietf.org> on behalf of "Hende= rickx, Wim (Nokia - BE)" <wim.henderickx@nokia.com>
Date: Thursday, April 7, 2016 at 3:= 58 PM
To: "sami_boutros@yahoo.com" <sami_boutros@yahoo.com>
Cc: "bess@ietf.org" <bess@i= etf.org>
Subject: Re: [bess] draft-boutros-b= ess-evpn-vpws-service-edge-gateway-02

Resending with proper email address of Sami

From: Wim Henderickx <wim.henderickx@alcatel-lucent.co= m>
Date: Thursday 7 April 2016 at 15:5= 1
To: "sboutros@cisco.com" <sboutros@cisco.com>
Cc: "bess@ietf.org" <bess@i= etf.org>
Subject: draft-boutros-bess-evpn-vp= ws-service-edge-gateway-02

The draft tries to address a 1:1 auto-provisioning between the VPWS an= d Service on the service PE.
Would the draft also address a 1:N provisioning model, meaning 1 VPWS = to multiple services using VLAN multiplexing on the service PE?
 --_000_D32D27EC192614sajassiciscocom_-- From nobody Fri Apr 8 05:49: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 AE11812D836 for ; Fri, 8 Apr 2016 05:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGKFTht87Gqh for ; Fri, 8 Apr 2016 05:49:02 -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 55F1E12D822 for ; Fri, 8 Apr 2016 05:49:02 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B13D6C58A5817; Fri, 8 Apr 2016 12:48:57 +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 u38CmxP6009274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 12:49:00 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 u38CmvQv030865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 14:48:59 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 14:48:59 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "EXT Ali Sajassi (sajassi)" , "sami_boutros@yahoo.com" Thread-Topic: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AQHRkZE7rkus9b9NJ0iaXL27tPuoip9/sxQA Date: Fri, 8 Apr 2016 12:48:59 +0000 Message-ID: <12A9FF6C-1151-4777-8F5A-B62B2B140191@alcatel-lucent.com> References: 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: multipart/alternative; boundary="_000_12A9FF6C115147778F5AB62B2B140191alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" Subject: Re: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-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: Fri, 08 Apr 2016 12:49:05 -0000 --_000_12A9FF6C115147778F5AB62B2B140191alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIGlmIHdlIGdvIGZvciB0aGUgc29sdXRpb25zIHdlIHNob3VsZCBpbmNsdWRlIHRo aXMgc2NlbmFyaW8uDQoNCg0KRnJvbTogQWxpIFNhamFzc2kgPHNhamFzc2lAY2lzY28uY29tPG1h aWx0bzpzYWphc3NpQGNpc2NvLmNvbT4+DQpEYXRlOiBGcmlkYXkgOCBBcHJpbCAyMDE2IGF0IDA5 OjIxDQpUbzogV2ltIEhlbmRlcmlja3ggPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNv bTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPj4sICJzYW1pX2JvdXRy b3NAeWFob28uY29tPG1haWx0bzpzYW1pX2JvdXRyb3NAeWFob28uY29tPiIgPHNhbWlfYm91dHJv c0B5YWhvby5jb208bWFpbHRvOnNhbWlfYm91dHJvc0B5YWhvby5jb20+Pg0KQ2M6ICJiZXNzQGll dGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPiIgPGJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtiZXNzXSBkcmFmdC1ib3V0cm9zLWJlc3MtZXZwbi12 cHdzLXNlcnZpY2UtZWRnZS1nYXRld2F5LTAyDQoNCg0KSGkgV2ltLA0KDQpUaGUgY3VycmVudCBk cmFmdCBpcyBmb3Igdmxhbi1iYXNlZCBtb2RlIG9mIEVWUE4tVlBXUzsgd2hlcmUgZWFjaCBFVlBO IFAyUCBMU1AgdHVubmVsIGlzIG1hcHBlZCB0byBhIHNpbmdsZSBzZXJ2aWNlLiBJZiBuZWVkZWQs IGl0IGNhbiBiZSBleHBhbmRlZCB0byB2bGFuLWJ1bmRsZSBFVlBOLVZQV1MgbW9kZSBhcyB3ZWxs Lg0KDQpDaGVlcnMsDQpBbGkNCg0KRnJvbTogQkVTUyA8YmVzcy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkhlbmRlcmlja3gsIFdp bSAoTm9raWEgLSBCRSkiIDx3aW0uaGVuZGVyaWNreEBub2tpYS5jb208bWFpbHRvOndpbS5oZW5k ZXJpY2t4QG5va2lhLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiBhdCAzOjU4 IFBNDQpUbzogInNhbWlfYm91dHJvc0B5YWhvby5jb208bWFpbHRvOnNhbWlfYm91dHJvc0B5YWhv by5jb20+IiA8c2FtaV9ib3V0cm9zQHlhaG9vLmNvbTxtYWlsdG86c2FtaV9ib3V0cm9zQHlhaG9v LmNvbT4+DQpDYzogImJlc3NAaWV0Zi5vcmc8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+IiA8YmVzc0Bp ZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2Jlc3NdIGRyYWZ0 LWJvdXRyb3MtYmVzcy1ldnBuLXZwd3Mtc2VydmljZS1lZGdlLWdhdGV3YXktMDINCg0KUmVzZW5k aW5nIHdpdGggcHJvcGVyIGVtYWlsIGFkZHJlc3Mgb2YgU2FtaQ0KDQpGcm9tOiBXaW0gSGVuZGVy aWNreCA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzp3aW0uaGVuZGVy aWNreEBhbGNhdGVsLWx1Y2VudC5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgNyBBcHJpbCAyMDE2IGF0 IDE1OjUxDQpUbzogInNib3V0cm9zQGNpc2NvLmNvbTxtYWlsdG86c2JvdXRyb3NAY2lzY28uY29t PiIgPHNib3V0cm9zQGNpc2NvLmNvbTxtYWlsdG86c2JvdXRyb3NAY2lzY28uY29tPj4NCkNjOiAi YmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4iIDxiZXNzQGlldGYub3JnPG1haWx0 bzpiZXNzQGlldGYub3JnPj4NClN1YmplY3Q6IGRyYWZ0LWJvdXRyb3MtYmVzcy1ldnBuLXZwd3Mt c2VydmljZS1lZGdlLWdhdGV3YXktMDINCg0KVGhlIGRyYWZ0IHRyaWVzIHRvIGFkZHJlc3MgYSAx OjEgYXV0by1wcm92aXNpb25pbmcgYmV0d2VlbiB0aGUgVlBXUyBhbmQgU2VydmljZSBvbiB0aGUg c2VydmljZSBQRS4NCldvdWxkIHRoZSBkcmFmdCBhbHNvIGFkZHJlc3MgYSAxOk4gcHJvdmlzaW9u aW5nIG1vZGVsLCBtZWFuaW5nIDEgVlBXUyB0byBtdWx0aXBsZSBzZXJ2aWNlcyB1c2luZyBWTEFO IG11bHRpcGxleGluZyBvbiB0aGUgc2VydmljZSBQRT8NCg== --_000_12A9FF6C115147778F5AB62B2B140191alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgYmVsaWV2ZSBpZiB3ZSBnbyBmb3IgdGhlIHNvbHV0aW9ucyB3ZSBzaG91bGQgaW5jbHVk ZSB0aGlzIHNjZW5hcmlvLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlk PSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbGkgU2FqYXNzaSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnNhamFzc2lAY2lzY28uY29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXkgOCBBcHJpbCAyMDE2 IGF0IDA5OjIxPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ V2ltIEhlbmRlcmlja3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVs LWx1Y2VudC5jb20iPndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86c2FtaV9ib3V0cm9zQHlhaG9vLmNvbSI+c2FtaV9ib3V0cm9z QHlhaG9vLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW1pX2JvdXRyb3NAeWFo b28uY29tIj5zYW1pX2JvdXRyb3NAeWFob28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YmVzc0Bp ZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNz QGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbYmVzc10gZHJhZnQtYm91dHJvcy1iZXNz LWV2cG4tdnB3cy1zZXJ2aWNlLWVkZ2UtZ2F0ZXdheS0wMjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGkgV2ltLDwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGN1cnJlbnQgZHJhZnQgaXMgZm9yIHZsYW4t YmFzZWQgbW9kZSBvZiBFVlBOLVZQV1M7IHdoZXJlIGVhY2ggRVZQTiBQMlAgTFNQIHR1bm5lbCBp cyBtYXBwZWQgdG8gYSBzaW5nbGUgc2VydmljZS4gSWYgbmVlZGVkLCBpdCBjYW4gYmUgZXhwYW5k ZWQgdG8gdmxhbi1idW5kbGUgRVZQTi1WUFdTIG1vZGUgYXMgd2VsbC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+QWxpPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5Okx1Y2lkYSBHcmFuZGU7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkJFU1MgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzLWJvdW5j ZXNAaWV0Zi5vcmciPmJlc3MtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAm cXVvdDtIZW5kZXJpY2t4LCBXaW0gKE5va2lhIC0gQkUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86d2ltLmhlbmRlcmlja3hAbm9raWEuY29tIj53aW0uaGVuZGVyaWNreEBub2tpYS5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1 cnNkYXksIEFwcmlsIDcsIDIwMTYgYXQgMzo1OCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzYW1pX2JvdXRyb3NA eWFob28uY29tIj5zYW1pX2JvdXRyb3NAeWFob28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNhbWlfYm91dHJvc0B5YWhvby5jb20iPnNhbWlfYm91dHJvc0B5YWhvby5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFti ZXNzXSBkcmFmdC1ib3V0cm9zLWJlc3MtZXZwbi12cHdzLXNlcnZpY2UtZWRnZS1nYXRld2F5LTAy PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+UmVzZW5kaW5nIHdpdGggcHJvcGVyIGVtYWlsIGFkZHJlc3Mgb2YgU2FtaTwvZGl2Pg0K PGRpdj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNv bG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1 bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1S SUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbTogPC9zcGFuPldpbSBIZW5kZXJpY2t4ICZsdDs8YSBocmVmPSJtYWlsdG86d2lt LmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tIj53aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1 Y2VudC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+VGh1cnNkYXkgNyBBcHJpbCAyMDE2IGF0IDE1OjUxPGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNib3V0 cm9zQGNpc2NvLmNvbSI+c2JvdXRyb3NAY2lzY28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNib3V0cm9zQGNpc2NvLmNvbSI+c2JvdXRyb3NAY2lzY28uY29tPC9hPiZndDs8YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVm PSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPmRyYWZ0LWJvdXRyb3Mt YmVzcy1ldnBuLXZwd3Mtc2VydmljZS1lZGdlLWdhdGV3YXktMDI8YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5UaGUgZHJhZnQgdHJp ZXMgdG8gYWRkcmVzcyBhIDE6MSBhdXRvLXByb3Zpc2lvbmluZyBiZXR3ZWVuIHRoZSBWUFdTIGFu ZCBTZXJ2aWNlIG9uIHRoZSBzZXJ2aWNlIFBFLjwvZGl2Pg0KPGRpdj5Xb3VsZCB0aGUgZHJhZnQg YWxzbyBhZGRyZXNzIGEgMTpOIHByb3Zpc2lvbmluZyBtb2RlbCwgbWVhbmluZyAxIFZQV1MgdG8g bXVsdGlwbGUgc2VydmljZXMgdXNpbmcgVkxBTiBtdWx0aXBsZXhpbmcgb24gdGhlIHNlcnZpY2Ug UEU/PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_12A9FF6C115147778F5AB62B2B140191alcatellucentcom_-- From nobody Fri Apr 8 05:58: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 0E13012D822 for ; Fri, 8 Apr 2016 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HnZj62oX_Lv for ; Fri, 8 Apr 2016 05:58:11 -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 15ED912D6DA for ; Fri, 8 Apr 2016 05:58:11 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id B4CFEDB1FBABE; Fri, 8 Apr 2016 12:58:06 +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 u38Cw9iA022763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Apr 2016 12:58:09 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 u38Cvvrc017563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 14:58:08 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 8 Apr 2016 14:58:00 +0200 From: "Henderickx, Wim (Nokia - BE)" To: Sami Boutros Thread-Topic: draft-boutros-bess-evpn-vpws-service-edge-gateway-02 Thread-Index: AQHRkP518O/6Q+6y30Kf5VbbrPl3R59+iQcAgAFbOYD//9J/gA== Date: Fri, 8 Apr 2016 12:58:00 +0000 Message-ID: <2632004E-40F0-430B-B685-36E47E46D45A@alcatel-lucent.com> References: <326691902.1639813.1460119251696.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <326691902.1639813.1460119251696.JavaMail.yahoo@mail.yahoo.com> 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.38] Content-Type: multipart/alternative; boundary="_000_2632004E40F0430BB68536E47E46D45Aalcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "bess@ietf.org" , Sami Boutros Subject: Re: [bess] draft-boutros-bess-evpn-vpws-service-edge-gateway-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: Fri, 08 Apr 2016 12:58:14 -0000 --_000_2632004E40F0430BB68536E47E46D45Aalcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2sgdGh4DQoNCkZyb206IEVYVCBTYW1pIEJvdXRyb3MgPHNhbWlfYm91dHJvc0B5YWhvby5jb208 bWFpbHRvOnNhbWlfYm91dHJvc0B5YWhvby5jb20+Pg0KUmVwbHktVG86IFNhbWkgQm91dHJvcyA8 c2FtaV9ib3V0cm9zQHlhaG9vLmNvbTxtYWlsdG86c2FtaV9ib3V0cm9zQHlhaG9vLmNvbT4+DQpE YXRlOiBGcmlkYXkgOCBBcHJpbCAyMDE2IGF0IDA5OjQwDQpUbzogV2ltIEhlbmRlcmlja3ggPHdp bS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxj YXRlbC1sdWNlbnQuY29tPj4NCkNjOiAiYmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9y Zz4iIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4sIFNhbWkgQm91dHJvcyA8 Ym91dHJvcy5zYW1pQGdtYWlsLmNvbTxtYWlsdG86Ym91dHJvcy5zYW1pQGdtYWlsLmNvbT4+DQpT dWJqZWN0OiBSZTogZHJhZnQtYm91dHJvcy1iZXNzLWV2cG4tdnB3cy1zZXJ2aWNlLWVkZ2UtZ2F0 ZXdheS0wMg0KDQpIaSBXaW0sDQoNCkFzIEFsaSBtZW50aW9uZWQsIHRoZSBkaWZmZXJlbnQgc2Vy dmljZSBpbnRlcmZhY2VzIHN1cHBvcnRlZCB1bmRlciBldnBuLXZwd3MgY2FuIGJlIHN1cHBvcnRl ZCwgZm9yIHRoZSB2bGFuLWF3YXJlIHNlcnZpY2VzIHVuZGVyIHRoZSBzYW1lIGV2cG4tdnB3cyBM U1AsIGlkZWFzIGFzIHRoZSBvbmUgZGVzY3JpYmVkIGJ5IHRoZSBuZXcgZHJhZnQgdGhhdCBBbGkg d2lsbCBwdWJsaXNoIGNhbiBiZSB1c2VkLg0KDQpXaWxsIGFkZCBhIHNlY3Rpb24gb24gdGhpcyB0 b28sIGluIHRoYXQgY2FzZSBhIHNlcGFyYXRlIGV2cG4gQUQgcm91dGUgcGVyIHZsYW4gc2Vydmlj ZSB3aWxsIGJlIGFkdmVydGlzZWQsIGFuZCBtdWx0aXBsZSBldnBuLWFkIHJvdXRlcyB3aWxsIHNo YXJlIHRoZSBzYW1lIGV2cG4tdnB3cyBMU1AgbGFiZWwuDQoNClRoYW5rcywNCg0KU2FtaQ0KDQoN Ck9uIFRodXJzZGF5LCBBcHJpbCA3LCAyMDE2IDExOjU4IEFNLCAiSGVuZGVyaWNreCwgV2ltIChO b2tpYSAtIEJFKSIgPHdpbS5oZW5kZXJpY2t4QG5va2lhLmNvbTxtYWlsdG86d2ltLmhlbmRlcmlj a3hAbm9raWEuY29tPj4gd3JvdGU6DQoNCg0KUmVzZW5kaW5nIHdpdGggcHJvcGVyIGVtYWlsIGFk ZHJlc3Mgb2YgU2FtaQ0KDQpGcm9tOiBXaW0gSGVuZGVyaWNreCA8d2ltLmhlbmRlcmlja3hAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20+ Pg0KRGF0ZTogVGh1cnNkYXkgNyBBcHJpbCAyMDE2IGF0IDE1OjUxDQpUbzogInNib3V0cm9zQGNp c2NvLmNvbTxtYWlsdG86c2JvdXRyb3NAY2lzY28uY29tPiIgPHNib3V0cm9zQGNpc2NvLmNvbTxt YWlsdG86c2JvdXRyb3NAY2lzY28uY29tPj4NCkNjOiAiYmVzc0BpZXRmLm9yZzxtYWlsdG86YmVz c0BpZXRmLm9yZz4iIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4NClN1Ympl Y3Q6IGRyYWZ0LWJvdXRyb3MtYmVzcy1ldnBuLXZwd3Mtc2VydmljZS1lZGdlLWdhdGV3YXktMDIN Cg0KVGhlIGRyYWZ0IHRyaWVzIHRvIGFkZHJlc3MgYSAxOjEgYXV0by1wcm92aXNpb25pbmcgYmV0 d2VlbiB0aGUgVlBXUyBhbmQgU2VydmljZSBvbiB0aGUgc2VydmljZSBQRS4NCldvdWxkIHRoZSBk cmFmdCBhbHNvIGFkZHJlc3MgYSAxOk4gcHJvdmlzaW9uaW5nIG1vZGVsLCBtZWFuaW5nIDEgVlBX UyB0byBtdWx0aXBsZSBzZXJ2aWNlcyB1c2luZyBWTEFOIG11bHRpcGxleGluZyBvbiB0aGUgc2Vy dmljZSBQRT8NCg0KDQo= --_000_2632004E40F0430BB68536E47E46D45Aalcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pk9rIHRoeDwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVIt Qk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJP VFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVIt VE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu PkVYVCBTYW1pIEJvdXRyb3MgJmx0OzxhIGhyZWY9Im1haWx0bzpzYW1pX2JvdXRyb3NAeWFob28u Y29tIj5zYW1pX2JvdXRyb3NAeWFob28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+UmVwbHktVG86IDwvc3Bhbj5TYW1pIEJvdXRyb3MgJmx0OzxhIGhyZWY9 Im1haWx0bzpzYW1pX2JvdXRyb3NAeWFob28uY29tIj5zYW1pX2JvdXRyb3NAeWFob28uY29tPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZy aWRheSA4IEFwcmlsIDIwMTYgYXQgMDk6NDA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+VG86IDwvc3Bhbj5XaW0gSGVuZGVyaWNreCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpbS5o ZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNl bnQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYub3Jn PC9hPiZndDssIFNhbWkgQm91dHJvcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvdXRyb3Muc2FtaUBn bWFpbC5jb20iPmJvdXRyb3Muc2FtaUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IGRyYWZ0LWJvdXRyb3MtYmVz cy1ldnBuLXZwd3Mtc2VydmljZS1lZGdlLWdhdGV3YXktMDI8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiMwMDA7IGJhY2tncm91 bmQtY29sb3I6I2ZmZjsgZm9udC1mYW1pbHk6SGVsdmV0aWNhTmV1ZSwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgQXJpYWwsIEx1Y2lkYSBHcmFuZGUsIHNhbnMtc2VyaWY7Zm9udC1zaXplOjE2 cHgiPg0KPGRpdiBkaXI9Imx0ciIgaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBf NDEyMCI+PHNwYW4gaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDMwOSI+SGkg V2ltLDwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5 NzBfNDM1OSIgZGlyPSJsdHIiPjxzcGFuIGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQz OTcwXzQzMDkiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfeW0xOV8x XzE0NjAxMTg0NDM5NzBfNDUwNyIgZGlyPSJsdHIiPjxzcGFuIGlkPSJ5dWlfM18xNl8wX3ltMTlf MV8xNDYwMTE4NDQzOTcwXzQzMDkiPkFzIEFsaSBtZW50aW9uZWQsIHRoZSBkaWZmZXJlbnQgc2Vy dmljZSBpbnRlcmZhY2VzIHN1cHBvcnRlZCB1bmRlciBldnBuLXZwd3MgY2FuIGJlIHN1cHBvcnRl ZCwgZm9yIHRoZSB2bGFuLWF3YXJlIHNlcnZpY2VzIHVuZGVyIHRoZSBzYW1lIGV2cG4tdnB3cyBM U1AsDQogaWRlYXMgYXMgdGhlIG9uZSBkZXNjcmliZWQgYnkgdGhlIG5ldyBkcmFmdCB0aGF0IEFs aSB3aWxsIHB1Ymxpc2ggY2FuIGJlIHVzZWQuPC9zcGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ PGJyPg0KPHNwYW4gaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDMwOSI+PC9z cGFuPjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4gaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0 NjAxMTg0NDM5NzBfNDMwOSI+V2lsbCBhZGQgYSBzZWN0aW9uIG9uIHRoaXMgdG9vLCBpbiB0aGF0 IGNhc2UgYSBzZXBhcmF0ZSBldnBuIEFEIHJvdXRlIHBlciB2bGFuIHNlcnZpY2Ugd2lsbCBiZSBh ZHZlcnRpc2VkLCBhbmQgbXVsdGlwbGUgZXZwbi1hZCByb3V0ZXMgd2lsbCBzaGFyZSB0aGUgc2Ft ZSBldnBuLXZwd3MgTFNQIGxhYmVsLjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9Inl1aV8z XzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDMxMCIgZGlyPSJsdHIiPjxicj4NCjxzcGFuIGlk PSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQzMDkiPjwvc3Bhbj48L2Rpdj4NCjxk aXYgaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDMxMSIgZGlyPSJsdHIiPjxz cGFuIGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQzMDkiPlRoYW5rcyw8L3Nw YW4+PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQ2Njci IGRpcj0ibHRyIj48YnI+DQo8c3BhbiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3 MF80MzA5Ij48L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4 NDQzOTcwXzQ2NjYiIGRpcj0ibHRyIj48c3BhbiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDEx ODQ0Mzk3MF80MzA5Ij5TYW1pPC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0icXRkU2VwYXJhdGVC UiI+PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJkaXNwbGF5OiBibG9jazsiIGlkPSJ5 dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQyNzkiIGNsYXNzPSJ5YWhvb19xdW90ZWQi Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80Mjc4IiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYU5ldWUsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIEFy aWFsLCBMdWNpZGEgR3JhbmRlLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7Ij4NCjxkaXYg aWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDI3NyIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2FOZXVlLCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBBcmlhbCwgTHVj aWRhIEdyYW5kZSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyI+DQo8ZGl2IGlkPSJ5dWlf M18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQyODEiIGRpcj0ibHRyIj48Zm9udCBpZD0ieXVp XzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80MjgwIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+ T24gVGh1cnNkYXksIEFwcmlsIDcsIDIwMTYgMTE6NTggQU0sICZxdW90O0hlbmRlcmlja3gsIFdp bSAoTm9raWEgLSBCRSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3aW0uaGVuZGVyaWNreEBu b2tpYS5jb20iPndpbS5oZW5kZXJpY2t4QG5va2lhLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PGJyPg0K PC9mb250PjwvZGl2Pg0KPGJyPg0KPGJyPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2 MDExODQ0Mzk3MF80Mjc2IiBjbGFzcz0ieV9tc2dfY29udGFpbmVyIj4NCjxkaXYgaWQ9InlpdjA0 NjU0NjQxNjQiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80Mjc1 Ij4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDI3NCI+DQo8ZGl2 IGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQyNzMiPg0KPGRpdiBpZD0ieXVp XzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80MjcyIj5SZXNlbmRpbmcgd2l0aCBwcm9wZXIg ZW1haWwgYWRkcmVzcyBvZiBTYW1pPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0ieWl2MDQ2NTQ2NDE2 NE1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQyODMiPjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9InlpdjA0NjU0NjQxNjRPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IGlk PSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQ1MDgiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2ZvbnQtc2l6ZToxMnB0O3RleHQtYWxpZ246bGVmdDtjb2xvcjpibGFjaztCT1JE RVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1bSBub25lO1BBRERJTkctQk9U VE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6MGluO0JPUkRFUi1UT1A6I2I1 YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25lO1BBRERJTkctVE9QOjNwdDsi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5Gcm9tOiA8L3NwYW4+V2ltIEhlbmRl cmlja3ggJmx0OzxhIGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQ1NjgiIHJl bD0ibm9mb2xsb3ciIHltYWlsdG89Im1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2Vu dC5jb20iIHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRl bC1sdWNlbnQuY29tIj53aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkOyI+RGF0ZTogPC9zcGFuPlRodXJzZGF5 IDcgQXByaWwgMjAxNiBhdCAxNTo1MTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk OyI+VG86IDwvc3Bhbj4mcXVvdDs8YSBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3 MF80NjY1IiByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86c2JvdXRyb3NAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOnNib3V0cm9zQGNpc2NvLmNvbSI+c2JvdXRy b3NAY2lzY28uY29tPC9hPiZxdW90OyAmbHQ7PGEgaWQ9Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAx MTg0NDM5NzBfNDU0NCIgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOnNib3V0cm9zQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpzYm91dHJvc0BjaXNjby5jb20i PnNib3V0cm9zQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQ7Ij5DYzogPC9zcGFuPiZxdW90OzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1haWx0 bzpiZXNzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5v cmciPmJlc3NAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRv PSJtYWlsdG86YmVzc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpiZXNz QGlldGYub3JnIj5iZXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZDsiPlN1YmplY3Q6IDwvc3Bhbj5kcmFmdC1ib3V0cm9zLWJlc3MtZXZwbi12cHdz LXNlcnZpY2UtZWRnZS1nYXRld2F5LTAyPGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8w X3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQ1MDkiPjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNf MTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80NjYzIj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfeW0x OV8xXzE0NjAxMTg0NDM5NzBfNDY2MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9y OnJnYigwLCAwLCAwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLCBzYW5zLXNl cmlmOyI+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wX3ltMTlfMV8xNDYwMTE4NDQzOTcwXzQ2NjEiPg0K PGRpdiBpZD0ieXVpXzNfMTZfMF95bTE5XzFfMTQ2MDExODQ0Mzk3MF80NjYwIj4NCjxkaXYgaWQ9 Inl1aV8zXzE2XzBfeW0xOV8xXzE0NjAxMTg0NDM5NzBfNDY2NCI+VGhlIGRyYWZ0IHRyaWVzIHRv IGFkZHJlc3MgYSAxOjEgYXV0by1wcm92aXNpb25pbmcgYmV0d2VlbiB0aGUgVlBXUyBhbmQgU2Vy dmljZSBvbiB0aGUgc2VydmljZSBQRS48L2Rpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfeW0xOV8x XzE0NjAxMTg0NDM5NzBfNDY1OSI+V291bGQgdGhlIGRyYWZ0IGFsc28gYWRkcmVzcyBhIDE6TiBw cm92aXNpb25pbmcgbW9kZWwsIG1lYW5pbmcgMSBWUFdTIHRvIG11bHRpcGxlIHNlcnZpY2VzIHVz aW5nIFZMQU4gbXVsdGlwbGV4aW5nIG9uIHRoZSBzZXJ2aWNlIFBFPzwvZGl2Pg0KPGRpdj4NCjxk aXYgaWQ9InlpdjA0NjU0NjQxNjQiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_2632004E40F0430BB68536E47E46D45Aalcatellucentcom_-- From nobody Mon Apr 11 07:22: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 6519412EF51; Mon, 11 Apr 2016 07:22:50 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160411142250.13041.58773.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 07:22:50 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-ir-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 14:22: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 : Ingress Replication Tunnels in Multicast VPN Authors : Eric C. Rosen Karthik Subramanian Zhaohui Zhang Filename : draft-ietf-bess-ir-03.txt Pages : 22 Date : 2016-04-11 Abstract: RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to- multipoint trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be "directly connected" to its child nodes. When a parent node has to send a multicast data packet to its child nodes, it does not use layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-ir/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-ir-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-ir-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 11 23:28:38 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 413B112E4E2 for ; Mon, 11 Apr 2016 23:28:37 -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=unavailable 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 5ygMx3lx0vx8 for ; Mon, 11 Apr 2016 23:28:35 -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 07F9812E4E1 for ; Mon, 11 Apr 2016 23:28:34 -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 u3C6SQ9t046178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Apr 2016 15:28:27 +0900 (JST) (envelope-from glenn@cysols.com) To: Benoit Claise , 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> From: Glenn Mansfield Keeni Message-ID: <570C9586.7030905@cysols.com> Date: Tue, 12 Apr 2016 15:28:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56FBE17E.5090609@cisco.com> Content-Type: multipart/mixed; boundary="------------050504020600070007030301" Archived-At: 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 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, 12 Apr 2016 06:28:37 -0000 This is a multi-part message in MIME format. --------------050504020600070007030301 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 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 --------------050504020600070007030301 Content-Type: text/plain; charset=UTF-8; name="L2L3-VPN-Comments-20160411" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="L2L3-VPN-Comments-20160411" Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1iZXNzLWwybDMtdnBuLW1jYXN0LW1pYi0wMi50eHQu Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgpUaGlzIGlzIGEgcHJlbGltaW5hcnkgcmV2aWV3LiBPbmNlIHRoZSBmb2xsb3dpbmcgcG9p bnRzIGFyZSAKdGFrZW4gY2FyZSBvZiwgd2UgY2FuIGdldCBkb3duIHRvIGEgZGV0YWlsZWQg aW4tZGVwdGggcmV2aWV3LiAKCjEuICBBYnN0cmFjdDoKMS4xIEEgc2VudGVuY2Ugb24gaG93 IHRoZSBtYW5hZ2VkIG9iamVjdHMgd2lsbCBiZSB1c2VkIGJ5IAogICAgYXBwbGljYXRpb25z IGZvciBvcGVyYXRpb25zLCBtb25pdG9yaW5nIGFuZCBtYW5hZ2VtZW50IAogICAgd291bGQg YmUgZ29vZC4gICAKCjIuICBJbnRyb2R1Y3Rpb24KMi4xIFBsZWFzZSBnaXZlIHRoZSBmdWxs IGV4cGFuc2lvbiBvZiB0aGUgYWJicmV2aWF0aW9ucyAKICAgIGFwcGVhcmluZyBmb3IgdGhl IGZpcnN0IHRpbWUuICAoUEUsIFZQTFMsLi4pIAoKMi4yIFRoZSB0ZXJtaW5vbG9neSBzZWN0 aW9uIGlzIGEgYml0IHRlcnNlLiBFeHBsYWluaW5nIHRoZSAKICAgIHRlcm1zIHRoYXQgYXJl IHVzZWQsIG5pY2VseSB3aXRoIHJlZmVyZW5jZSB0byB0aGUgcHJvdG9jb2wgCiAgICBkb2N1 bWVudHMgd2lsbCBpbXByb3ZlIHJlYWRhYmlsaXR5LgogICAgZS5nLgogICAgIC0gUE1TSSwg SS1QTVNJLCBTLVBNU0ksIHByb3ZpZGVyIHR1bm5lbHMKMi4zIElzIHRoZXJlIGEgZGlmZmVy ZW5jZSBiZXR3ZWVuIAogICAgICAgIm11bHRpY2FzdCBpbiBMYXllciAyIGFuZCBMYXllciAz IFZQTnMgLCBkZWZpbmVkIGJ5CiAgICAgICAgUkZDIDcxMTcgYW5kIFJGQyA2NTEzLzY1MTQi IAogICAgdXNlZCBpbiB0aGUgREVTQ1JJUFRJT04gaW4gdGhlIE1PRFVMRS1JREVOVElUWQog ICAgYW5kIAogICAgICAgIm11bHRpY2FzdCBpbiBCR1AvTVBMUyBMMiBvciBJUCBWUE4iCiAg ICB1c2VkIGluIHRoZSBERVNDUklQVElPTiBvZiBMMkwzVnBuTWNhc3RQcm92aWRlclR1bm5l bFR5cGUgPwogICAgSWYgdGhlc2UgYXJlIHRoZSBzYW1lLCBpdCB3aWxsIGJlIGhlbHBmdWwg dG8gc3RpY2sgdG8gdGhlIAogICAgc2FtZSBleHByZXNzaW9uLiBJZiB0aGVzZSBhcmUgbm90 IHRoZSBzYW1lLCB0aGUgZGljdGluY3Rpb24gCiAgICBzaG91bGQgYmUgY2xhcmlmaWVkLgog CgozLiAgU3VtbWFyeSBvZiBNSUIgTW9kdWxlLgogICAgQW4gb3ZlcnZpZXcgb2YgdGhlIEwy TDMtVlBOLU1DQVNULU1JQiB3aWxsIGJlIGdvb2QtIHRoZSAKICAgIHN0cnVjdHVyZSBvZiB0 aGUgTUlCLCBzaG9ydCBkZXNjcmlwdGlvbnMgb2YgdGhlIHRhYmxlKHMpIAogICAgaW5jbHVk aW5nIHVzYWdlIG9mIHRoZSB0YWJsZShzKSBmb3IgbWFuYWdlbWVudCBhbmQvb3IgYnkgCiAg ICBvdGhlciBNSUIocykuCgpNSUIgZGVmaW5pdGlvbnM6CjQuIE1JQiBzeW50YXggY2hlY2tp bmc6CiAgIHNtaWxpbnQgLXMgLWUgLWwgNSBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQiAyPkwy TDMtVlBOLU1DQVNULU1JQi50eHQKCiAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjYzOiBb NF0ge2h5cGhlbi1pbi1sYWJlbH0gd2FybmluZzogbmFtZWQgbnVtYmVyIGByc3ZwLXAybXAn IG11c3Qgbm90IGluY2x1ZGUgYSBoeXBoZW4gaW4gU01JdjIKICAgbWlicy9MMkwzLVZQTi1N Q0FTVC1NSUI6NjQ6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJuaW5nOiBuYW1lZCBudW1i ZXIgYGxkcC1wMm1wJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGluIFNNSXYyCiAgIG1p YnMvTDJMMy1WUE4tTUNBU1QtTUlCOjY1OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0gd2Fybmlu ZzogbmFtZWQgbnVtYmVyIGBwaW0tYXNtJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGlu IFNNSXYyCiAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjY2OiBbNF0ge2h5cGhlbi1pbi1s YWJlbH0gd2FybmluZzogbmFtZWQgbnVtYmVyIGBwaW0tc3NtJyBtdXN0IG5vdCBpbmNsdWRl IGEgaHlwaGVuIGluIFNNSXYyCiAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjY3OiBbNF0g e2h5cGhlbi1pbi1sYWJlbH0gd2FybmluZzogbmFtZWQgbnVtYmVyIGBwaW0tYmlkaXInIG11 c3Qgbm90IGluY2x1ZGUgYSBoeXBoZW4gaW4gU01JdjIKICAgbWlicy9MMkwzLVZQTi1NQ0FT VC1NSUI6Njg6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJuaW5nOiBuYW1lZCBudW1iZXIg YGluZ3Jlc3MtcmVwbGljYXRpb24nIG11c3Qgbm90IGluY2x1ZGUgYSBoeXBoZW4gaW4gU01J djIKICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6Njk6IFs0XSB7aHlwaGVuLWluLWxhYmVs fSB3YXJuaW5nOiBuYW1lZCBudW1iZXIgYGxkcC1tcDJtcCcgbXVzdCBub3QgaW5jbHVkZSBh IGh5cGhlbiBpbiBTTUl2MgogICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjoyMTU6IFs1XSB7 Z3JvdXAtdW5yZWZ9IHdhcm5pbmc6IGN1cnJlbnQgZ3JvdXAgYGwyTDNWcG5NY2FzdE9wdGlv bmFsR3JvdXAnIGlzIG5vdCByZWZlcmVuY2VkIGluIHRoaXMgbW9kdWxlCiAgIG1pYnMvTDJM My1WUE4tTUNBU1QtTUlCOjQ6IFs1XSB7aW1wb3J0LXVudXNlZH0gd2FybmluZzogaWRlbnRp ZmllciBgTk9USUZJQ0FUSU9OLVRZUEUnIGltcG9ydGVkIGZyb20gbW9kdWxlIGBTTk1QdjIt U01JJyBpcyBuZXZlciB1c2VkCiAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjU6IFs1XSB7 aW1wb3J0LXVudXNlZH0gd2FybmluZzogaWRlbnRpZmllciBgVW5zaWduZWQzMicgaW1wb3J0 ZWQgZnJvbSBtb2R1bGUgYFNOTVB2Mi1TTUknIGlzIG5ldmVyIHVzZWQKICAgbWlicy9MMkwz LVZQTi1NQ0FTVC1NSUI6ODogWzVdIHtpbXBvcnQtdW51c2VkfSB3YXJuaW5nOiBpZGVudGlm aWVyIGBOT1RJRklDQVRJT04tR1JPVVAnIGltcG9ydGVkIGZyb20gbW9kdWxlIGBTTk1QdjIt Q09ORicgaXMgbmV2ZXIgdXNlZAogICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjoxMTogWzVd IHtpbXBvcnQtdW51c2VkfSB3YXJuaW5nOiBpZGVudGlmaWVyIGBUcnV0aFZhbHVlJyBpbXBv cnRlZCBmcm9tIG1vZHVsZSBgU05NUHYyLVRDJyBpcyBuZXZlciB1c2VkCiAgIG1pYnMvTDJM My1WUE4tTUNBU1QtTUlCOjExOiBbNV0ge2ltcG9ydC11bnVzZWR9IHdhcm5pbmc6IGlkZW50 aWZpZXIgYFJvd1N0YXR1cycgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYFNOTVB2Mi1UQycgaXMg bmV2ZXIgdXNlZAogICBtaWJzL0wyTDMtVlBOLU1DQVNULU1JQjoxMjogWzVdIHtpbXBvcnQt dW51c2VkfSB3YXJuaW5nOiBpZGVudGlmaWVyIGBUaW1lU3RhbXAnIGltcG9ydGVkIGZyb20g bW9kdWxlIGBTTk1QdjItVEMnIGlzIG5ldmVyIHVzZWQKICAgbWlicy9MMkwzLVZQTi1NQ0FT VC1NSUI6MTI6IFs1XSB7aW1wb3J0LXVudXNlZH0gd2FybmluZzogaWRlbnRpZmllciBgVGlt ZUludGVydmFsJyBpbXBvcnRlZCBmcm9tIG1vZHVsZSBgU05NUHYyLVRDJyBpcyBuZXZlciB1 c2VkCiAgIG1pYnMvTDJMMy1WUE4tTUNBU1QtTUlCOjE1OiBbNV0ge2ltcG9ydC11bnVzZWR9 IHdhcm5pbmc6IGlkZW50aWZpZXIgYFNubXBBZG1pblN0cmluZycgaW1wb3J0ZWQgZnJvbSBt b2R1bGUgYFNOTVAtRlJBTUVXT1JLLU1JQicgaXMgbmV2ZXIgdXNlZAogICBtaWJzL0wyTDMt VlBOLU1DQVNULU1JQjoxODogWzVdIHtpbXBvcnQtdW51c2VkfSB3YXJuaW5nOiBpZGVudGlm aWVyIGBJbmV0QWRkcmVzcycgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYElORVQtQUREUkVTUy1N SUInIGlzIG5ldmVyIHVzZWQKICAgbWlicy9MMkwzLVZQTi1NQ0FTVC1NSUI6MTg6IFs1XSB7 aW1wb3J0LXVudXNlZH0gd2FybmluZzogaWRlbnRpZmllciBgSW5ldEFkZHJlc3NUeXBlJyBp bXBvcnRlZCBmcm9tIG1vZHVsZSBgSU5FVC1BRERSRVNTLU1JQicgaXMgbmV2ZXIgdXNlZAoK NS4gUkVGRVJFTkNFIGNsYXVzZXM6IFBsZWFzZSB1c2UgUkVGRVJFTkNFIGNsYXVzZXMgbGli ZXJhbGx5LgogICBXaGVyZXZlciBwb3NzaWJsZSwgcHJvdmlkZSByZWZlcmVuY2VzIGZvciBv YmplY3RzIHVzZWQgaW4gCiAgIHRoZSBNSUIuIFRoZSByZWZlcmVuY2VzIHdpbGwgcG9pbnQg dG8gc3BlY2lmaWMgc2VjdGlvbnMvCiAgIHN1Yi1zZWN0aW9ucyBvZiB0aGUgUkZDcyBkZWZp bmluZyB0aGUgcHJvdG9jb2wgZm9yIHdoaWNoIHRoZSAKICAgTUlCIGlzIGJlaW5nIGRlc2ln bmVkLiBJdCB3aWxsIGdyZWF0bHkgaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkgCiAgIG9mIHRo ZSBkb2N1bWVudC4gCgo2LiBJTVBPUlRTIGNsYXVzZQogICBNSUIgbW9kdWxlcyBmcm9tIHdo aWNoIGl0ZW1zIGFyZSBpbXBvcnRlZCBtdXN0IGJlIGNpdGVkIGFuZCAKICAgaW5jbHVkZWQg aW4gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLgogICBUaGUgY29udmVudGlvbmFsIHN0eWxl IGlzIAogICAgIG1wbHNTdGRNSUIKICAgICAgICBGUk9NIE1QTFMtVEMtU1RELU1JQiAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIFtSRkMzODExXQoKNy4gUGxlYXNlIHVwZGF0ZSB0 aGUgTU9EVUxFLUlERU5USVRZLiAoVGhlcmUgYXJlIG5vIHN5bnRhbnRpYyBlcnJvcnMuKQo3 LjEgQ09OVEFDVC1JTkZPCiAgICBGb2xsb3dpbmcgdGhlIGNvbnZlbnRpb25zIChpbmNsdWRp bmcgaW5kZW50YXRpb24gc3R5bGUpIHdpbGwgCiAgICBpbXByb3ZlIHRoZSByZWFkYWJpbGl0 eS4gKGUuZy4gUkZDNDM4MiwgUkZDNTEzMikuCiAgICBXaWxsIGJlIGdvb2QgaWYgaXQgZG9l cyBub3Qgb3ZlcmZsb3cgaW50byB0aGUgbmV4dCBwYWdlLgogICAgCjcuMiBSRVZJU0lPTiBj bGF1c2U6IGZvbGxvdyB0aGUgY29udmVudGlvbiByZWNvbW1lbmRlZCBpbiBSRkM0MTgxIAog ICAgc2VjIDQuNQogICAgICAgICAgUkVWSVNJT04gICAgIjIwMDIxMjEzMjM1OFoiICAtLSBE ZWNlbWJlciAxMywgMjAwMgogICAgICAgICAgREVTQ1JJUFRJT04gIkluaXRpYWwgdmVyc2lv biwgcHVibGlzaGVkIGFzIFJGQyB5eXl5LiIKICAgLS0gUkZDIEVkLjogcmVwbGFjZSB5eXl5 IHdpdGggYWN0dWFsIFJGQyBudW1iZXIgJiByZW1vdmUgdGhpcyBub3RlOgo3LjMgT0lEIGFz c2lnbm1lbnQ6IGZvbGxvdyB0aGUgY29udmVudGlvbiByZWNvbW1lbmRlZCBpbiBSRkM0MTgx IAogICAgc2VjIDQuNSBpCiAgICByZXBsYWNlIAogICAgICAgICAgOjo9IHsgZXhwZXJpbWVu dGFsIDk5IH0gLS0gbnVtYmVyIHRvIGJlIGFzc2lnbmVkCiAgICBieQogICAgICAgICAgOjo9 IHsgPHN1YnRyZWU+IFhYWCB9CiAgIC0tIFJGQyBFZC46IHJlcGxhY2UgWFhYIHdpdGggSUFO QS1hc3NpZ25lZCBudW1iZXIgJiByZW1vdmUgdGhpcyBub3RlIAogICA8c3VidHJlZT4gd2ls bCBiZSB0aGUgc3VidHJlZSB1bmRlciB3aGljaCB0aGUgbW9kdWxlIHdpbGwgYmUgCiAgIHJl Z2lzdGVyZWQuCgoKOC4gU3BlY2lmaWMgTU8gYW5kIFRDIHJlbGF0ZWQgY29tbWVudHMuCiAg ICAgIEwyTDNWcG5NY2FzdFByb3ZpZGVyVHVubmVsVHlwZSA6Oj0gVEVYVFVBTC1DT05WRU5U SU9OCiAgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQKICAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICAiVHlwZXMgb2YgcHJvdmlkZXIgdHVubmVscyB1c2VkIGZvciBtdWx0aWNh c3QgaW4KICAgICAgICAgICAgIEJHUC9NUExTIEwyIG9yIElQIFZQTi4iCiAgICAgICAgU1lO VEFYICAgICAgIElOVEVHRVIgeyB1bmNvbmZpZ3VyZWQgKDApLAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcnN2cC1wMm1wICgxKSwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGxkcC1wMm1wICgyKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBp bS1hc20gKDMpLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGltLXNzbSAoNCks CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwaW0tYmlkaXIgKDUpLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaW5ncmVzcy1yZXBsaWNhdGlvbiAoNiksCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBsZHAtbXAybXAgKDcpCgogICAgbyBXb3VsZCBi ZSBuaWNlIHRvIGFsaWduIHRoZSBlbnVtZXJhdGlvbiBsYWJlbHMgd2l0aCB0aGUgCiAgICAg IGxhYmVscyBpbiB0aGUgcHJvdG9jb2wgZG9jdW1lbnQgUkZDIDY1MTQgdW5sZXNzIHRoZXJl IGlzIAogICAgICBhIGdvb2QgcmVhc29uIGZvciBub3QgZG9pbmcgc28uIChZb3Ugd2lsbCBo YXZlIHRvIHRha2UgCiAgICAgIGNhcmUgb2YgdGhlIHNtaSBjb21waWxhdGlvbiBlcnJvcnMg dG9vOyAnLScgaXMgbm90IGFsbG93ZWQgKS4gCiAgICAgICAgICAgIAo4LjEgIGwyTDNWcG5N Y2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVFbnRyeSBPQkpFQ1QtVFlQRQogICAgICAgICBTWU5U QVggICAgICAgIEwyTDNWcG5NY2FzdFBtc2lUdW5uZWxBdHRyaWJ1dGVFbnRyeQogICAgICAg ICBNQVgtQUNDRVNTICAgIG5vdC1hY2Nlc3NpYmxlCiAgICAgICAgIFNUQVRVUyAgICAgICAg Y3VycmVudAogICAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICAgIkFuIGVudHJ5IGlu IHRoaXMgdGFibGUgY29ycmVzcG9uZHMgdG8gYW4gUE1TSSBhdHRyaWJ1dGUKICAgICAgICAg ICAgICB0aGF0IGlzIGFkdmVydGlzZWQvcmVjZWl2ZWQgb24gdGhpcyByb3V0ZXIuCiAgICAg ICAgICAgICAgRm9yIEJHUC1iYXNlZCBzaWduYWxpbmcgKGZvciBJLVBNU0kgdmlhIGF1dG8t ZGlzY292ZXJ5CiAgICAgICAgICAgICAgcHJvY2VkdXJlLCBvciBmb3IgUy1QTVNJIHZpYSBT LVBNU0kgQS1EIHJvdXRlcyksCiAgICAgICAgICAgICAgdGhleSBhcmUganVzdCBhcyBzaWdu YWxlZCBieSBCR1AgKFJGQyA2NTE0IHNlY3Rpb24gNSwKICAgICAgICAgICAgICAnUE1TSSBU dW5uZWwgYXR0cmlidXRlJykuCiAgICAgICAgICAgICAgRm9yIFVEUC1iYXNlZCBTLVBNU0kg c2lnbmFsaW5nIGZvciBQSU0tTVZQTiwKICAgICAgICAgICAgICB0aGV5J3JlIGRlcml2ZWQg ZnJvbSBTLVBNU0kgSm9pbiBNZXNzYWdlCiAgICAgICAgICAgICAgKFJGQyA2NTEzIHNlY3Rp b24gNy40LjIsICdVRFAtYmFzZWQgUHJvdG9jb2wnKS4uCiAgICAKICAgICAgICAgICAgICBO b3RlIHRoYXQgQkdQLWJhc2VkIHNpZ25hbGluZyBtYXkgYmUgdXNlZCBmb3IKICAgICAgICAg ICAgICBQSU0tTVZQTiBhcyB3ZWxsLiIKICAgIG8gRml4IHRoZSAiLi4iIGluICInVURQLWJh c2VkIFByb3RvY29sJykuLiIgYWJvdmUuIAogICAgbyBQbGVhc2UgZ2l2ZSB0aGUgcmVmZXJl bmNlIGZvciB0aGlzIFRhYmxlLiAKICAgICAgSXMgaXQtICAiUE1TSSBUdW5uZWwgYXR0cmli dXRlIiBpbiBSRkMgNjUxMyBTZWMuNCAgPyAgIAogICAgICAgICAgICAgICJQTVNJIFR1bm5l bCBhdHRyaWJ1dGUiIGluIFJGQyA2NTE0IFNlYy41ICA/ICAgCiAgICAgICAgICAgICAgIGJv dGg/CiAgICAgIEFueSBvdGhlciBwb2ludGVycz8KCjguMiAgIGwyTDNWcG5NY2FzdFBtc2lU dW5uZWxBdHRyaWJ1dGVGbGFncyBPQkpFQ1QtVFlQRQogICAgICAgICBTWU5UQVggICAgICAg IE9DVEVUIFNUUklORyAoU0laRSAoMSkpCiAgICAgICAgIE1BWC1BQ0NFU1MgICAgbm90LWFj Y2Vzc2libGUKICAgICAgICAgU1RBVFVTICAgICAgICBjdXJyZW50CiAgICAgICAgIERFU0NS SVBUSU9OCiAgICAgICAgICAgICAiRm9yIFVEUC1iYXNlZCBTLVBNU0kgc2lnbmFsaW5nIGZv ciBQSU0tTVZQTiwgdGhpcyBpcyAwLgogICAgICAgICAgICAgIEZvciBCR1AtYmFzZWQgSS9T LVBNU0kgc2lnbmFsaW5nLCB0aGlzIGlzIHRoZSBGbGFncwogICAgICAgICAgICAgIGZpZWxk IGluIFBNU0kgVHVubmVsIEF0dHJpYnV0ZSBvZiB0aGUgY29ycmVzcG9uZGluZwogICAgICAg ICAgICAgIEkvUy1QTVNJIEEtRCByb3V0ZS4iCiAgICAgICAgIDo6PSB7IGwyTDNWcG5NY2Fz dFBtc2lUdW5uZWxBdHRyaWJ1dGVFbnRyeSAxIH0KICAgIG8gIFBsZWFzZSBjb25maXJtIHRo YXQgdGhlIGFib3ZlIGlzIGEgY29tcGxldGUgZW51bWVyYXRpb24gb2YgdGhlIAogICAgICAg dHlwZXMgb2Ygc2lnbmFsbGluZy4gIAogICAgbyAgUkZDIDY1MTQgU2VjLjUgc2F5cyB0aGF0 IHRoZSBGbGFncyBmaWVsZCBpbmRpY2F0ZXMKICAgICAgICJMZWFmIEluZm9ybWF0aW9uIFJl cXVpcmVkIi4gVGhhdCBpcyB1c2VmdWwgaW5mb3JtYXRpb24uIAogICAgICAgUGxlYXNlIGlu Y2x1ZGUgaW4gdGhlIGRlc2NyaXB0aW9uLiAgCgo4LjMgICBsMkwzVnBuTWNhc3RQbXNpVHVu bmVsQXR0cmlidXRlSWQgT0JKRUNULVRZUEUKICAgICAgICAgU1lOVEFYICAgICAgICBPQ1RF VCBTVFJJTkcgKCBTSVpFICgwLi4zNykgKQogICAgICAgICBNQVgtQUNDRVNTICAgIG5vdC1h Y2Nlc3NpYmxlCiAgICAgICAgIFNUQVRVUyAgICAgICAgY3VycmVudAogICAgICAgICBERVND UklQVElPTgogICAgICAgICAgICAgIkZvciBVRFAtYmFzZWQgUy1QTVNJIHNpZ25hbGluZyBm b3IgUElNLU1WUE4sIHRoZSBmaXJzdAogICAgICAgICAgICAgIGZvdXIgb3Igc2l4dGVlbiBv Y3RldHMgb2YgdGhpcyBhdHRyaWJ1dGUgYXJlIGZpbGxlZCB3aXRoCiAgICAgICAgICAgICAg dGhlIHByb3ZpZGVyIHR1bm5lbCBncm91cCBhZGRyZXNzIChJUHY0IG9yIElQdjYpLi4KICAg ICAgICAgICAgICBGb3IgQkdQLWJhc2VkIEkvUy1QTVNJIHNpZ25hbGluZywgdGhpcyBpcyB0 aGUgVHVubmVsIElkZW50aWZpZXIKICAgICAgICAgICAgICBGaWVsZCBpbiBQTVNJIFR1bm5l bCBBdHRyaWJ1dGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgSS9TLVBNU0kKICAgICAgICAgICAg ICBBLUQgcm91dGUuIgogICAgbyBDaGVjayB0aGUgc2l6ZSBzcGVjaWZpY2F0aW9ucy4gVGhl IHNwZWNzIGFib3ZlIHNheSBpdCBjYW4gYmUgCiAgICAgIGFsbCBzaXplcyAwLi4zNy4gVGhh dCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgREVTQ1JJUFRJT04gY2xhdXNlLiAKICAgIG8gRml4 IHRoZSAiLi4iIGluICIoSVB2NCBvciBJUHY2KS4uIiBhYm92ZS4gCiAgICBvIFJGQyA2NTE0 IFNlYyA1LiAgUE1TSSBUdW5uZWwgQXR0cmlidXRlIGdpdmVzIHRoZSBUdW5uZWwgSWRlbnRp ZmllcnMKICAgICAgZm9yIG1MRFAsIFBJTS1TTSwgUElNLVNTTSwgQklESVItUElNLEluZ3Jl c3MgUmVwbGljYXRpb24sTVAyTVAuIAogICAgICBJdCBhcHBlYXJzIHRoYXQgdGhlIHNpemVz IChyYW5nZSkgZm9yIGVhY2ggY2FzZSB3aWxsIGJlIGRpZmZlcmVudC4gCiAgICAgIFBsZWFz ZSBjbGFyaWZ5IHRoYXQsIGFuZCBpZiB0aGVyZSBhcmUgZGlzY3JldGUgc2l6ZXMsIHNwZWNp ZnkgCiAgICAgIGFjY29yZGluZ2x5LiAKICAgICAgCgo4LjMgIGwyTDNWcG5NY2FzdFBtc2lU dW5uZWxQb2ludGVyIE9CSkVDVC1UWVBFCiAgICAgICAgU1lOVEFYICAgICAgICBSb3dQb2lu dGVyCiAgICAgICAgTUFYLUFDQ0VTUyAgICByZWFkLW9ubHkKICAgICAgICBTVEFUVVMgICAg ICAgIGN1cnJlbnQKICAgICAgICBERVNDUklQVElPTgogICAgICAgICAgICAiSWYgdGhlIHR1 bm5lbCBleGlzdHMgaW4gc29tZSBNSUIgdGFibGUsIHRoaXMgaXMgdGhlCiAgICAgICAgICAg ICByb3cgcG9pbnRlciB0byBpdC4iCiAgICBvICJzb21lIE1JQiB0YWJsZSIgOiBzcGVjaWZ5 IHdoaWNoIE1JQiB0YWJsZS4gCiAgICBvIEluIHdoYXQgY2FzZSB3aWxsIHRoZSB0dW5uZWwg ZXhpc3QgYW5kIGluIHdoYXQgY2FzZSB3aWxsIGl0IG5vdD8KICAgIG8gV2hhdCB3aWxsIGJl IHRoZSBiZWhhdmlvdXIgaWYgdGhlIGFib3ZlIGNvbmRpdGlvbiBpcyBub3Qgc2F0aXNmaWVk PwoKOC40ICBsMkwzVnBuTWNhc3RQbXNpVHVubmVsSWYgT0JKRUNULVRZUEUKICAgICAgICBT WU5UQVggICAgICAgIFJvd1BvaW50ZXIKICAgICAgICBNQVgtQUNDRVNTICAgIHJlYWQtb25s eQogICAgICAgIFNUQVRVUyAgICAgICAgY3VycmVudAogICAgICAgIERFU0NSSVBUSU9OCiAg ICAgICAgICAgICJJZiB0aGUgdHVubmVsIGhhcyBhIGNvcnJlc3BvbmRpbmcgaW50ZXJmYWNl LCB0aGlzIGlzIHRoZQogICAgICAgICAgICAgcm93IHBvaW50ZXIgdG8gdGhlIGlmTmFtZSB0 YWJsZS4iCiAgICAgbyBERVNDUklQVElPTiBsb29rcyBpbmNvcnJlY3QuIFBsZWFzZSBmaXgg aXQuIERvIHlvdSB3YW50IHRvIHNheSAKICAgICAgIHRoaXMgb2JqZWN0IHBvaW50cyB0byB0 aGUgY29ycmVzcG9uZGluZyByb3cgaW4gdGhlIGlmVGFibGU/IAogICAgIG8gSW4gd2hhdCBj YXNlIGRvZXMgdGhlIFR1bm5lbElmIGV4aXN0IGFuZCBpbiB3aGF0IGNhc2Ugd2lsbCBpdCBu b3Q/CiAgICAgbyBXaGF0IHdpbGwgYmUgZXhwZWN0ZWQgaWYgdGhlIHR1bm5lbCBkb2VzIG5v dCBoYXZlIGEgY29ycmVzcG9uZGluZyAKICAgICAgIGludGVyZmFjZT8KCjkuIFRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMgbm90IGZvbGxvdyB0aGUgU2VjdXJp dHkgCiAgIEd1aWRlbGluZXMgZm9yIElFVEYgTUlCIE1vZHVsZXMgCiAgIGh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL2FyZWEvb3BzL3RyYWMvd2lraS9taWItc2VjdXJpdHkuCiAgIFBs ZWFzZSBmaXguIAogICAKCjEwLklELW5pdHMKMTAuMSBDaGVja2luZyBuaXRzIGFjY29yZGlu ZyB0byBodHRwOi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0IDoKICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KICAgCiAgICAgKiogVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9m IHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qgb25lCiAgICAg ICAgYmVpbmcgMyBjaGFyYWN0ZXJzIGluIGV4Y2VzcyBvZiA3Mi4KICAgCjEwLjIgQ2hlY2tp bmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZAog ICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAKICAgICA9PSBNaXNzaW5nIFJlZmVyZW5j ZTogJ1JGQyA3MTE3JyBpcyBtZW50aW9uZWQgb24gbGluZSA3NiwgYnV0IG5vdAogICAgICAg IGRlZmluZWQKICAgICAgICAnZGVzY3JpYmVkIGluIFtSRkM2NTEzLCBSRkM2NTE0LCBSRkMg NzExN10gYW5kIG90aGVyIGRvY3VtZW50cyB0aGEuLi4nCgoxMS4gIFRoZXJlIGlzIGFub3Ro ZXIgV0lQIE1WUE4tTUlCIGluIGRyYWZ0LWlldGYtYmVzcy1tdnBuLW1pYi0wMi50eHQKICAg ICBNVlBOLU1JQiBoYXMgb2JqZWN0cyB0aGF0IHJlZmVyIHRvIEwyTDMtVlBOLU1DQVNULU1J Qi4gICAKICAgICBJcyB0aGVyZSBhIGdvb2QgcmVhc29uIGZvciBub3QgbWVyZ2luZyB0aGUg MiBkb2N1bWVudHM/IEkgaGF2ZSBub3Qgc2VlbiAKICAgICBhbnkgZGlzY3Vzc2lvbiBvciBl eHBsYW5hdGlvbiBvbiB0aGlzLiBJIG1heSBoYXZlIG1pc3NlZCBpdC4gUGxlYXNlCiAgICAg Y2xhcmlmeSBvciwgZ2l2ZSBzb21lIHBvaW50ZXJzLiAKCg== --------------050504020600070007030301-- From nobody Tue Apr 12 10:07:19 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3808E12DA0C; Tue, 12 Apr 2016 10:07:15 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412170715.32214.31099.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 10:07:15 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-mvpn-extranet-07.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:07:15 -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 : Extranet Multicast in BGP/IP MPLS VPNs Authors : Yakov Rekhter Eric C. Rosen Rahul Aggarwal Yiqun Cai Thomas Morin Filename : draft-ietf-bess-mvpn-extranet-07.txt Pages : 62 Date : 2016-04-12 Abstract: 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 MVPN extranet service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-mvpn-extranet-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-extranet-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 12 20:03: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 0806812DFFB for ; Tue, 12 Apr 2016 20:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUMufwmDXFmb for ; Tue, 12 Apr 2016 20:03:18 -0700 (PDT) Received: from BLU004-OMC1S14.hotmail.com (blu004-omc1s14.hotmail.com [65.55.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3705A12DFD3 for ; Tue, 12 Apr 2016 20:03:18 -0700 (PDT) Received: from BLU436-SMTP164 ([65.55.116.7]) by BLU004-OMC1S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 12 Apr 2016 20:03:17 -0700 X-TMN: [/IOE/6eCsfaDkZIfTuqPEf2MTCdsrWWzY9Ztvo3+mUU=] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Wed, 13 Apr 2016 11:03:24 +0800 From: "li_zhenqiang@hotmail.com" To: thomas.morin , bess References: <5706D4BA.9060908@orange.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart006047015165_=----" X-OriginalArrivalTime: 13 Apr 2016 03:03:16.0683 (UTC) FILETIME=[069529B0:01D19531] Archived-At: Subject: Re: [bess] minutes of our IETF 95 meeting 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, 13 Apr 2016 03:03:20 -0000 ------=_001_NextPart006047015165_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Zm9yIGRyYWZ0LWxpLWJlc3MtNHBlLTAxOg0KUGxlYXNlIGFkZCBteSByZXNwb25zZSB0byBjb21t ZW50cyBmcm9tIEtleXVyIGFuZCBXaW06IDRQRSByb3V0ZXJzIG5lZWQgSVB2NCBuZXh0IGhvcCBp bmZvcm1hdGlvbiB0byBpbnN0YWxsIHRoZWlyIElQdjQgcm91dGluZyB0YWJsZS4NCg0KVGhhbmtz IGFuZCBCZXN0IFJlZ2FyZHMsDQoNCg0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tDQogDQpGcm9t OiBUaG9tYXMgTW9yaW4NCkRhdGU6IDIwMTYtMDQtMDggMDU6NDQNClRvOiBCRVNTDQpTdWJqZWN0 OiBbYmVzc10gbWludXRlcyBvZiBvdXIgSUVURiA5NSBtZWV0aW5nDQpIaSBldmVyeW9uZSwNCiAN CldlIGhhdmUganVzdCBwb3N0ZWQgZHJhZnQgbWludXRlcyBmb3IgdG9kYXkncyBtZWV0aW5nLg0K IA0KWW91IGNhbiByZWFkIHRoZW0gYXQgDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy85NS9taW51dGVzL21pbnV0ZXMtOTUtYmVzcw0KIA0KUGxlYXNlIHNlbmQgYW55IGNvbW1lbnRz IHlvdSBtYXkgaGF2ZSBvbiB0aGVzZSBtaW51dGVzLg0KIA0KTWFueSBtYW55IHRoYW5rcyB0byBH dW50ZXIgZm9yIGhpcyBtaW51dGUgdGFraW5nIQ0KIA0KLVRob21hcy9NYXJ0aW4NCiANCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCRVNTIG1haWxpbmcg bGlzdA0KQkVTU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iZXNzDQogDQo= ------=_001_NextPart006047015165_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A<= div>for draft-li-bess-4pe-0= 1:
Please add my response to comments from&n= bsp;Keyur and Wim: 4PE routers need IPv4 next hop inform= ation to install their IPv4 routing table.
=0A

<= div>Thanks and Best Regards,
=0A
li_zhenqiang@hotm= ail.com
=0A
 
Date: 2016-04-08 05:44
To: BESS
= Subject: [bess] minutes of our IETF 95 meeting
<= div>
Hi everyone,
=0A
 
=0A
We have just posted= draft minutes for today's meeting.
=0A
 
=0A
You c= an read them at
=0A
https://www.ietf.org/proceedings/95/minutes/= minutes-95-bess
=0A
 
=0A
Please send any comments = you may have on these minutes.
=0A
 
=0A
Many many = thanks to Gunter for his minute taking!
=0A
 
=0A
-= Thomas/Martin
=0A
 
=0A
___________________________= ____________________
=0A
BESS mailing list
=0A
BESS@ietf= .org
=0A
https://www.ietf.org/mailman/listinfo/bess
=0A
=  
=0A
=0A ------=_001_NextPart006047015165_=------ From nobody Tue Apr 12 21:04: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 9836E12DB5B for ; Tue, 12 Apr 2016 21:04:03 -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=unavailable 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 aonV7fSt1Hex for ; Tue, 12 Apr 2016 21:04:02 -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 E63A612D9E8 for ; Tue, 12 Apr 2016 21:04:01 -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 u3D43qnY053340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2016 13:03:52 +0900 (JST) (envelope-from glenn@cysols.com) To: Benoit Claise , 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: <570DC523.3040907@cysols.com> Date: Wed, 13 Apr 2016 13:03:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570C9586.7030905@cysols.com> Content-Type: multipart/mixed; boundary="------------060001030700080202080101" Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , ops-ads@ietf.org, Martin Vigoureux , bess@ietf.org, Mach Chen Subject: [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, 13 Apr 2016 04:04:03 -0000 This is a multi-part message in MIME format. --------------060001030700080202080101 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 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 and then we will get onto the next phase. Hope this helps. Glenn --------------060001030700080202080101 Content-Type: text/plain; charset=UTF-8; name="MCAST-VPN-MIB-Comments-20160411" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MCAST-VPN-MIB-Comments-20160411" Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1iZXNzLW12cG4tbWliLTAyLnR4dAotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhpcyBpcyBh IHByZWxpbWluYXJ5IHJldmlldy4gT25jZSB0aGUgZm9sbG93aW5nIHBvaW50cyBhcmUgCnRh a2VuIGNhcmUgb2YsIHdlIGNhbiBnZXQgZG93biB0byBhIGRldGFpbGVkIGluLWRlcHRoIHJl dmlldy4gCgoxLiAgQWJzdHJhY3Q6CjEuMSBQbGVhc2UgZ2l2ZSB0aGUgZnVsbCBleHBhbnNp b24gb2YgTVBMUy9CR1AKMS4yICJJbiBwYXJ0aWN1bGFyLCBpdCBkZXNjcmliZXMgbWFuYWdl ZCBvYmplY3RzIHRvIGNvbmZpZ3VyZSBhbmQvb3IKICAgICBtb25pdG9yIE11bHRpY2FzdCBp biBNUExTL0JHUCBJUCBWUE5zIChNVlBOKSBvbiBhIHJvdXRlci4iCiAgICBJcyB0aGlzIGZv ciBhbnkgcm91dGVyIG9yLCBhICJQcm92aWRlciBFZGdlIiByb3V0ZXIgPyAKICAgIFBsZWFz ZSBmaXggYWNjb3JkaW5nbHkuCgoyLiAgSW50cm9kdWN0aW9uCjIuMSBQRSAtIGFwcGVhcnMg Zmlyc3QgdGltZS4gUGxlYXNlIGdpdmUgdGhlIGZ1bGwgZXhwYW5zaW9uLgoyLjIgSXMgdGhl IHByb3RvY29sIGZvciAiZXhjaGFuZ2luZyBWUE4gbXVsdGljYXN0IiBvciAKICAgICJleGNo YW5naW5nIFZQTiBtdWx0aWNhc3Qgc3RhdGVzIj8gUGxlYXNlIGZpeCBhcHByb3ByaWF0ZWx5 LgoyLjMgVGhlIGV4cHJlc3Npb24gInN0YW5kYXJkIE1JQiIgaW4gdGhlIGZvbGxvd2luZyBp cyBjb25mdXNpbmc6IAogICAgIlRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHN0YW5kYXJkIE1J QiBmb3IgTVZQTi1zcGVjaWZpYyAKICAgIG9iamVjdHMgdGhhdCBhcmUgZ2VuZXJpYyB0byBi b3RoIFBJTS1NVlBOIGFuZCBCR1AtTVZQTi4iCiAgICBJcyB0aGVyZSBhbnkgc3BlY2lhbCBz aWduaWZpY2FuY2UgaW4gdGhlICJzdGFuZGFyZCIgYWJvdmU/IAogICAgSWYgbm8sIHRoZW4g cGxlYXNlIGRyb3AgdGhlIHdvcmQuIAogICAgQXJlIHRoZSBvYmplY3RzICJnZW5lcmljIiB0 byBQSU0tTVZQTiBhbmQgQkdQLU1WUE4gb3IgImNvbW1vbiIgCiAgICB0byAgUElNLU1WUE4g YW5kIEJHUC1NVlBOID8gUGxlYXNlIGNoYW5nZSBhY2NvcmRpbmdseS4KMi40IFBsZWFzZSBn aXZlIHRoZSBmdWxsIGV4cGFuc2lvbiBvZiB0aGUgYWJicmV2aWF0aW9ucyBvY2N1cmluZyAK ICAgIGZvciB0aGUgZmlyc3QgdGltZSBpbiB0aGUgZG9jdW1lbnQuIChNUExTLCBMM1ZQTiku IAoyLjUgVGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gaXMgYSBiaXQgdGVyc2UuIEV4cGxhaW5p bmcgdGhlIHRlcm1zIAogICAgdGhhdCBhcmUgdXNlZCwgd2l0aCByZWZlcmVuY2UgdG8gdGhl IHByb3RvY29sIGRvY3VtZW50cyB3aWxsIAogICAgaW1wcm92ZSByZWFkYWJpbGl0eS4KICAg IGUuZy4gCiAgICAgLSBNVlBOLCBQRSwgUE1TSS90dW5uZWxzLCAKICAgICAtIEMtbXVsdGlj YXN0IHJvdXRpbmcgZXhjaGFuZ2UgcHJvdG9jb2wgKFBJTSBvciBCR1ApLCAKICAgICAgIEMt bXVsdGljYXN0IHN0YXRlcwogICAgIC0gSS1QTVNJLCBTLVBNU0ksIHByb3ZpZGVyIHR1bm5l bHMKICAgICAgCjMuICBNVlBOIE1JQi4KICAgIFRoaXMgZ2l2ZXMgdGhlIG92ZXJ2aWV3IG9m IHRoZSBNVlBOIE1JQi4KICAgIFRoZSBNSUIgbW9kdWxlIGFpbXMgdG8gcHJvdmlkZSAiY29u ZmlndXJpbmcgYW5kL29yIG1vbml0b3JpbmciICAKICAgICAKMy4xIEluCiAgICAiVGhpcyBN SUIgZW5hYmxlcyBjb25maWd1cmluZyBhbmQvb3IgbW9uaXRvcmluZyBvZiBNVlBOcyBvbiBQ RQogICAgZGV2aWNlczogdGhlIHdob2xlIG11bHRpY2FzdCBWUE4gbWFjaGluZXJ5Li4uLi4i CiAgICAidGhlIHdob2xlIG11bHRpY2FzdCBWUE4gbWFjaGluZXJ5IiBpcyB2ZXJ5IGRpZmZp Y3VsdCB0byBkZWZpbmUuIAogICAgUGxlYXNlIHVzZSBwcmVjaXNlbHkgZGVmaW5lZCB0ZXJt cy4gCgozLjIgSW4gIlRvIHJlcHJlc2VudCB0aGVtLC4uLi4iCiAgICAidGhlbSIgc2VlbXMg YW1iaWd1b3VzLCBwbGVhc2UgY2xhcmlmeS4gCgoKMy4zIFRoZSBkaWFncmFtIG5lZWRzIHNv bWUgZXhwbGFuYXRpb24uCiAgICBXaGF0IGRvIHRoZSBib3hlcyByZXByZXNlbnQ/IFRhYmxl cyA/IFRoZSBsYWJlbHMgYXJlIG1lYW50IHRvIGJlCiAgICB0YWJsZSBuYW1lcyA/IFRoZSB0 YWJsZSBuYW1lcyBkbyBub3QgbWF0Y2ggdGhlIGxhYmVscy4KICAgIFdoYXQgZG8gdGhlIGFy cm93cyBzaWduaWZ5PyBQbGVhc2UgZXhwbGFpbi4gCgozLjQgVGhlIHNob3J0IGV4cGxhbmF0 aW9uIG9mIHRoZSB0YWJsZXMgY291bGQgYmUgYXVnbWVudGVkIHdpdGggc29tZQogICAgaW5m b3JtYXRpb24gb24gd2hhdCB0aGV5IHJlcHJlc2VudCBhbmQgYW4gaWRlYSBvZiBob3cgdGhl eSB3aWxsICAKICAgIGJlIHVzZWQuICggUkZDIDQzODIgcHJvdmlkZXMgYSBnb29kIGV4YW1w bGUpLgogCgpNSUIgZGVmaW5pdGlvbnM6CjQuIE1JQiBzeW50YXggY2hlY2tpbmc6CiAgIHNt aWxpbnQgLXMgLWUgLWwgNSBtaWJzL01DQVNULVZQTi1NSUIgMj5NQ0FTVC1WUE4tTUlCLnR4 dAoKICAgbWlicy9NQ0FTVC1WUE4tTUlCOjI4OTogWzRdIHtoeXBoZW4taW4tbGFiZWx9IHdh cm5pbmc6IG5hbWVkIG51bWJlciBgaGlnaGVzdC1wZS1hZGRyZXNzJyBtdXN0IG5vdCBpbmNs dWRlIGEgaHlwaGVuIGluIFNNSXYyCiAgIG1pYnMvTUNBU1QtVlBOLU1JQjoyOTA6IFs0XSB7 aHlwaGVuLWluLWxhYmVsfSB3YXJuaW5nOiBuYW1lZCBudW1iZXIgYGMtcm9vdC1ncm91cC1o YXNoaW5nJyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGluIFNNSXYyCiAgIG1pYnMvTUNB U1QtVlBOLU1JQjoyOTE6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJuaW5nOiBuYW1lZCBu dW1iZXIgYHVjYXN0LXVtaC1yb3V0ZScgbXVzdCBub3QgaW5jbHVkZSBhIGh5cGhlbiBpbiBT TUl2MgogICBtaWJzL01DQVNULVZQTi1NSUI6MzA2OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0g d2FybmluZzogbmFtZWQgbnVtYmVyIGBzZW5kZXItcmVjZWl2ZXInIG11c3Qgbm90IGluY2x1 ZGUgYSBoeXBoZW4gaW4gU01JdjIKICAgbWlicy9NQ0FTVC1WUE4tTUlCOjMwNzogWzRdIHto eXBoZW4taW4tbGFiZWx9IHdhcm5pbmc6IG5hbWVkIG51bWJlciBgcmVjZWl2ZXItb25seScg bXVzdCBub3QgaW5jbHVkZSBhIGh5cGhlbiBpbiBTTUl2MgogICBtaWJzL01DQVNULVZQTi1N SUI6MzA4OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0gd2FybmluZzogbmFtZWQgbnVtYmVyIGBz ZW5kZXItb25seScgbXVzdCBub3QgaW5jbHVkZSBhIGh5cGhlbiBpbiBTTUl2MgogICBtaWJz L01DQVNULVZQTi1NSUI6MzY5OiBbNF0ge2h5cGhlbi1pbi1sYWJlbH0gd2FybmluZzogbmFt ZWQgbnVtYmVyIGBycHQtc3B0JyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVuIGluIFNNSXYy CiAgIG1pYnMvTUNBU1QtVlBOLU1JQjozNzA6IFs0XSB7aHlwaGVuLWluLWxhYmVsfSB3YXJu aW5nOiBuYW1lZCBudW1iZXIgYHNwdC1vbmx5JyBtdXN0IG5vdCBpbmNsdWRlIGEgaHlwaGVu IGluIFNNSXYyCiAgIG1pYnMvTUNBU1QtVlBOLU1JQjo0MTI6IFs1XSB7aW5kZXgtZXhjZWVk cy10b28tbGFyZ2V9IHdhcm5pbmc6IGluZGV4IG9mIHJvdyBgbXZwblBtc2lDb25maWdFbnRy eScgY2FuIGV4Y2VlZCBPSUQgc2l6ZSBsaW1pdCBieSAzOTggc3ViaWRlbnRpZmllcihzKQog ICBtaWJzL01DQVNULVZQTi1NSUI6NTM0OiBbNV0ge2luZGV4LWV4Y2VlZHMtdG9vLWxhcmdl fSB3YXJuaW5nOiBpbmRleCBvZiByb3cgYG12cG5TcG1zaUNvbmZpZ0VudHJ5JyBjYW4gZXhj ZWVkIE9JRCBzaXplIGxpbWl0IGJ5IDQzMCBzdWJpZGVudGlmaWVyKHMpCiAgIG1pYnMvTUNB U1QtVlBOLU1JQjo2NDk6IFs1XSB7aW5kZXgtZXhjZWVkcy10b28tbGFyZ2V9IHdhcm5pbmc6 IGluZGV4IG9mIHJvdyBgbXZwbklwbXNpRW50cnknIGNhbiBleGNlZWQgT0lEIHNpemUgbGlt aXQgYnkgNDMwIHN1YmlkZW50aWZpZXIocykKICAgbWlicy9NQ0FTVC1WUE4tTUlCOjc0MTog WzVdIHtpbmRleC1leGNlZWRzLXRvby1sYXJnZX0gd2FybmluZzogaW5kZXggb2Ygcm93IGBt dnBuSW50ZXJBc0lwbXNpRW50cnknIGNhbiBleGNlZWQgT0lEIHNpemUgbGltaXQgYnkgMTc0 IHN1YmlkZW50aWZpZXIocykKICAgbWlicy9NQ0FTVC1WUE4tTUlCOjgxMDogWzVdIHtpbmRl eC1leGNlZWRzLXRvby1sYXJnZX0gd2FybmluZzogaW5kZXggb2Ygcm93IGBtdnBuU3Btc2lF bnRyeScgY2FuIGV4Y2VlZCBPSUQgc2l6ZSBsaW1pdCBieSA2ODcgc3ViaWRlbnRpZmllcihz KQogICBtaWJzL01DQVNULVZQTi1NSUI6MTAxNjogWzRdIHtncm91cC1tZW1iZXJzaGlwfSB3 YXJuaW5nOiBub3RpZmljYXRpb24gYG12cG5NdnJmQ2hhbmdlJyBtdXN0IGJlIGNvbnRhaW5l ZCBpbiBhdCBsZWFzdCBvbmUgY29uZm9ybWFuY2UgZ3JvdXAKICAgbWlicy9NQ0FTVC1WUE4t TUlCOjExMjc6IFs1XSB7Z3JvdXAtdW5yZWZ9IHdhcm5pbmc6IGN1cnJlbnQgZ3JvdXAgYG12 cG5QbXNpQ29uZmlnR3JvdXAnIGlzIG5vdCByZWZlcmVuY2VkIGluIHRoaXMgbW9kdWxlCiAg IG1pYnMvTUNBU1QtVlBOLU1JQjoxMjExOiBbNV0ge2dyb3VwLXVucmVmfSB3YXJuaW5nOiBj dXJyZW50IGdyb3VwIGBtdnBuT3B0aW9uYWxHcm91cCcgaXMgbm90IHJlZmVyZW5jZWQgaW4g dGhpcyBtb2R1bGUKICAgbWlicy9NQ0FTVC1WUE4tTUlCOjg6IFs1XSB7aW1wb3J0LXVudXNl ZH0gd2FybmluZzogaWRlbnRpZmllciBgTk9USUZJQ0FUSU9OLUdST1VQJyBpbXBvcnRlZCBm cm9tIG1vZHVsZSBgU05NUHYyLUNPTkYnIGlzIG5ldmVyIHVzZWQKICAgbWlicy9NQ0FTVC1W UE4tTUlCOjIzOiBbNV0ge2ltcG9ydC11bnVzZWR9IHdhcm5pbmc6IGlkZW50aWZpZXIgYE1w bHNMYWJlbCcgaW1wb3J0ZWQgZnJvbSBtb2R1bGUgYE1QTFMtVEMtU1RELU1JQicgaXMgbmV2 ZXIgdXNlZAoKNS4gSU1QT1JUUyBjbGF1c2UKICAgTUlCIG1vZHVsZXMgZnJvbSB3aGljaCBp dGVtcyBhcmUgaW1wb3J0ZWQgbXVzdCBiZSBjaXRlZCBhbmQgaW5jbHVkZWQKICAgaW4gdGhl IG5vcm1hdGl2ZSByZWZlcmVuY2VzLgogICBUaGUgY29udmVudGlvbmFsIHN0eWxlIGlzIAog ICAgIG1wbHNTdGRNSUIKICAgICAgICBGUk9NIE1QTFMtVEMtU1RELU1JQiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBbUkZDMzgxMV0KCjYuIFBsZWFzZSB1cGRhdGUgdGhlIE1P RFVMRS1JREVOVElUWS4gKFRoZXJlIGFyZSBubyBzeW50YW50aWMgZXJyb3JzLikKNi4xICdP UkdBTklaQVRJT04gIklFVEYgTGF5ZXItMyBWaXJ0dWFsIFByaXZhdGUKICAgICAgICAgICAg ICAgICAgTmV0d29ya3MgV29ya2luZyBHcm91cC4iJwogICAgbmVlZHMgdG8gYmUgZml4ZWQg dG8gCiAgICAnT1JHQU5JWkFUSU9OICJJRVRGIEJFU1MgV29ya2luZyBHcm91cC4iJwogICAg b3Igc29tZXRoaW5nIG1vcmUgYXBwcm9wcmlhdGUuCgo2LjIgQ09OVEFDVC1JTkZPCiAgICBG b2xsb3dpbmcgdGhlIGNvbnZlbnRpb25zIChpbmNsdWRpbmcgaW5kZW50YXRpb24gc3R5bGUp IHdpbGwKICAgIGltcHJvdmUgdGhlIHJlYWRhYmlsaXR5LiAoZS5nLiBSRkM0MzgyLCBSRkM1 MTMyKS4KCjYuMiBSRVZJU0lPTiBjbGF1c2U6IGZvbGxvdyB0aGUgY29udmVudGlvbiBvZiBS RkM0MTMxIHNlYyA0LjUKICAgICAgICAgIFJFVklTSU9OICAgICIyMDAyMTIxMzIzNThaIiAg LS0gRGVjZW1iZXIgMTMsIDIwMDIKICAgICAgICAgIERFU0NSSVBUSU9OICJJbml0aWFsIHZl cnNpb24sIHB1Ymxpc2hlZCBhcyBSRkMgeXl5eS4iCiAgIC0tIFJGQyBFZC46IHJlcGxhY2Ug eXl5eSB3aXRoIGFjdHVhbCBSRkMgbnVtYmVyICYgcmVtb3ZlIHRoaXMgbm90ZToKNi4zIE9J RCBhc3NpZ25tZW50OiBmb2xsb3cgdGhlIGNvbnZlbnRpb24gb2YgUkZDNDEzMSBzZWMgNC41 CiAgICByZXBsYWNlIAogICAgICAgICAgOjo9IHsgZXhwZXJpbWVudGFsIDk5IH0gLS0gbnVt YmVyIHRvIGJlIGFzc2lnbmVkCiAgICBieQogICAgICAgICAgOjo9IHsgPHN1YnRyZWU+IFhY WCB9CiAgIC0tIFJGQyBFZC46IHJlcGxhY2UgWFhYIHdpdGggSUFOQS1hc3NpZ25lZCBudW1i ZXIgJiByZW1vdmUgdGhpcyBub3RlIAogICA8c3VidHJlZT4gd2lsbCBiZSB0aGUgc3VidHJl ZSB1bmRlciB3aGljaCB0aGUgbW9kdWxlIHdpbGwgYmUgCiAgIHJlZ2lzdGVyZWQuCgoKNy4g V2hlcmV2ZXIgcG9zc2libGUsIHBsZWFzZSBwcm92aWRlIHJlZmVyZW5jZXMgZm9yIG9iamVj dHMgdXNlZCBpbiB0aGUgCiAgIE1JQi4gVGhlIHJlZmVyZW5jZXMgd2lsbCBwb2ludCB0byBz cGVjaWZpYyBzZWN0aW9ucy9zdWItc2VjdGlvbnMgb2YgCiAgIFJGQ3MgZGVmaW5pbmcgdGhl IHByb3RvY29sIGZvciB3aGljaCB0aGUgTUlCIGlzIGJlaW5nIGRlc2lnbmVkLiAgCgo4LiBN T3MuCjguMSBTY2FsYXIgT2JqZWN0czogVGhlIG5hbWUgbXZwbk12cmZOdW1iZXIgbWF5IGJl IG1pc2xlYWRpbmcuIAogICAgSSB3b3VsZCByZWNvbW1lbmQgdGhlIHVzYWdlIG9mIHRoZSBz YW1lIG5hbWluZyBzdHlsZSAKICAgIGFzIFJGQyA0MzgyIGUuZy4gbXZwbk12cmZzLCBtdnBu VjRNdnJmcywgbXZwblY2TXZyZnMgKGluc3RlYWQgb2YgCiAgICBtdnBuTXZyZk51bWJlciwg bXZwbk12cmZOdW1iZXJWNCwgbXZwbk12cmZOdW1iZXJWNiwgLi4uKSB1bmxlc3MgCiAgICB0 aGVyZSBpcyBzb21lIGdvb2QgcmVhc29uIHRvIG5vdCBkbyBpdC4gCgo4LjIgbXZwbk12cmZO dW1iZXIgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgICAgIFVuc2lnbmVkMzIKICAg ICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoZSB0b3RhbCBudW1iZXIgb2YgTVZSRnMg dGhhdCBhcmUgcHJlc2VudCBvbiB0aGlzIGRldmljZSwKICAgICAgICAgICAgd2hldGhlciBm b3IgSVB2NCwgSVB2Niwgb3IgbUxEUCBDLU11bHRpY2FzdC4iCiAgICBvIFBsZWFzZSBtYWtl IHRoZSBkZXNjcmlwdGlvbiBwcmVjaXNlLiBFLmcuIGlmIGl0IGlzIHRoZSBzdW0gb2YgCiAg ICAgIElQdjQgTVZSRnMsIElQdjYgTVZSRnMgYW5kIG1MRFAgQy1NdWx0aWNhc3QgTVZSRnMg c3RhdGUgaXQgCiAgICAgIGV4cGxpY2l0bHkuICAgCiAgICBvIFRoZSBleHByZXNzaW9uICJw cmVzZW50IG9uIHRoaXMgZGV2aWNlIiBpcyB1c2VkLiAKICAgICAgRG9lcyAicHJlc2VudCIg aW1wbHkgImNvbmZpZ3VyZWQiIE1WUkZzIG9yICJhY3RpdmUiIE1WUkZzLiAgCiAgICAgIElm IGl0IGlzIG51bWJlciBvZiBhY3RpdmUgTVZSRnMgdGhlbiBvbmUgd291bGQgZXhwZWN0IHRo YXQgCiAgICAgIHRoZSBudW1iZXIgd2lsbCB2YXJ5IChpbmNyZWFzZSBvciBkZWNyZWFzZSku IElmIHRoYXQgaXMgdGhlCiAgICAgIGNhc2U6IAogICAgICByZXBsYWNlCiAgICAgICBTWU5U QVggICAgICAgIFVuc2lnbmVkMzIgCiAgICAgIGJ5CiAgICAgICBTWU5UQVggICAgICAgIEdh dWdlMzIKCjguMyBGb3IgYWxsIHRoZSBmb2xsb3dpbmcgc2NhbGFyczogCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBtdnBuTXZyZk51bWJlcgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgbXZwbk12cmZOdW1iZXJWNAogICAgICAgICAgICAgICAgICAgICAgICAgICAgbXZw bk12cmZOdW1iZXJWNgogICAgICAgICAgICAgICAgICAgICAgICAgICAgbXZwbk12cmZOdW1i ZXJQaW1WNAogICAgICAgICAgICAgICAgICAgICAgICAgICAgbXZwbk12cmZOdW1iZXJQaW1W NgogICAgICAgICAgICAgICAgICAgICAgICAgICAgbXZwbk12cmZOdW1iZXJCZ3BWNAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgbXZwbk12cmZOdW1iZXJCZ3BWNgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgbXZwbk12cmZOdW1iZXJNbGRwCiAgICBzYW1lIGNvbW1lbnRz IGFzIDguMi4gCgoKOC40IG12cG5HZW5BZGRyZXNzRmFtaWx5IE9CSkVDVC1UWVBFCiAgICAg ICBERVNDUklQVElPTgogICAgICAgICAgICJUaGUgQWRkcmVzcyBGYW1taWx5IHRoYXQgdGhp cyBlbnRyeSBpcyBmb3IiCiAgICAgcy9GYW1taWx5L0ZhbWlseS8gCgo4LjUgbXZwbkdlbk9w ZXJTdGF0dXNDaGFuZ2UgT0JKRUNULVRZUEUKICAgICAgIFNZTlRBWCAgICAgIElOVEVHRVIg eyBjcmVhdGVkTXZyZigxKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWxldGVk TXZyZigyKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RpZmllZE12cmZJcG1z aUNvbmZpZygzKSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RpZmllZE12cmZT cG1zaUNvbmZpZyg0KQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQogICAgICAgREVT Q1JJUFRJT04KICAgICAgICAgICAiVGhpcyBvYmplY3QgZGVzY3JpYmVzIHRoZSBsYXN0IG9w ZXJhdGlvbmFsIGNoYW5nZSB0aGF0CiAgICBvIFRoZSBuYW1lIGRvZXMgbm90IGxvb2sgcmln aHQuIEZyb20gdGhlIFNZTlRBWCBhbmQgdGhlIERFU0NSSVBUSU9OCiAgICAgIGl0IGFwcGVh cnMgdGhhdCB0aGlzIGlzIGFib3V0IGNvbmZpZyBvciBNVlJGIGNoYW5nZSByYXRoZXIgdGhh biAKICAgICAgIk9wZXJTdGF0dXMiIGNoYW5nZS4gUGxlYXNlIGNoZWNrIGFuZCBmaXguICAK ICAgIG8gUGxlYXNlIGNvbmZpcm0gdGhhdCB0aGUgdmFsdWVzIGluIHRoZSByb3cgaXRzZWxm IHdpbGwgbm90IGJlIGNoYW5nZWQKICAgICAgYWZ0ZXIgY3JlYXRpb24uICggeW91IGRvIG5v dCBoYXZlIGEgJ21vZGlmaWVkTXZyZkNvbmZpZycpCgo4LjYgbXZwbkdlbkNtY2FzdFJvdXRl UHJvdG9jb2wgT0JKRUNULVRZUEUKICAgICAgIE1BWC1BQ0NFU1MgICAgcmVhZC13cml0ZQog ICAgICAgOjo9IHsgbXZwbkdlbmVyYWxFbnRyeSA0IH0KICAgIG8gWW91IGNhbm5vdCBoYXZl IE1BWC1BQ0NFU1MgICAgcmVhZC13cml0ZSBmb3IgYSByb3cgdGhhdCBtYXkgYmUgCiAgICAg IGR5bmFtaWNhbGx5IGNyZWF0ZWQuIAogICAgICBSZXBsYWNlIAogICAgICAgTUFYLUFDQ0VT UyAgICByZWFkLXdyaXRlCiAgICAgIGJ5IAogICAgICAgTUFYLUFDQ0VTUyAgICByZWFkLWNy ZWF0ZSAKICAgICAgaWYgeW91IHdhbnQgdG8gZHluYW1pY2FsbHkgY2hhbmdlIHRoYXQgdmFs dWUsIG90aGVyd2lzZSwgCiAgICAgICBNQVgtQUNDRVNTICAgIHJlYWQtb25seSAKICAgICAg d2lsbCBzdWZmaWNlLiAKCjguOCBtdnBuR2VuSXBtc2lDb25maWcgT0JKRUNULVRZUEUKICAg ICAgIERFU0NSSVBUSU9OCiAgICAgICAgICAgIlRoaXMgcG9pbnRzIHRvIGEgcm93IGluIG12 cG5QbXNpQ29uZmlnVGFibGUsCiAgICAgICAgICAgIGZvciBJLVBNU0kgY29uZmlndXJhdGlv bi4iCiAgICBvIFBsZWFzZSBzcGVjaWZ5IHRoZSBleHBlY3RlZCBiZWhhdmlvdXIgd2hlbiBp dCBpcyBub3QgYW4gSS1QTVNJCgo4LjkgbXZwbkdlbkludGVyQXNQbXNpQ29uZmlnCiAgICBv IHNhbWUgY29tbWVudCBhcyBhYm92ZQoKOC4xMCBtdnBuR2VuUm93U3RhdHVzCiAgICBtdnBu R2VuUm93U3RhdHVzIE9CSkVDVC1UWVBFCiAgICAgICBTWU5UQVggICAgICAgIFJvd1N0YXR1 cwogICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAiVGhpcyBpcyB1c2VkIHRvIGNyZWF0 ZSBvciBkZWxldGUgYSByb3cgaW4gdGhpcyB0YWJsZS4iCiAgICBvIFRoZSBkZXNjcmlwdGlv biBpcyBpbmFkZXF1YXRlIGZvciBhbiBpbXBsZW1lbnRvciAoYW5kIAogICAgICBvdGhlcnMg dG9vKS4gCiAgICAgIERldGFpbGVkIHNwZWNpZmljYXRpb24vaW5zdHJ1Y3Rpb24gbXVzdCBi ZSBnaXZlbiBpbmRpY2F0aW5nCiAgICAgIHdoaWNoIGNvbHVtbmFyIG9iamVjdHMgIGhhdmUg dG8gYmUgc2V0IHRvIHZhbGlkIHZhbHVlcyBiZWZvcmUKICAgICAgdGhlIHJvdyBjYW4gYmUg YWN0aXZhdGVkOyBhbmQgd2hldGhlciBjb2x1bW5zIGluIHRoZSByb3cgbWF5IAogICAgICBi ZSBtb2RpZmllZCB3aGVuIHRoZSBzdGF0dXMgdmFsdWUgaXMgYWN0aXZlLiAKICAgICAgUGxl YXNlIGRvIHRoZSBuZWVkZnVsLiAKICAgICAgKFJlZiBSRkMgNDE4MSBTZWMgNC42LjQuICBD b25jZXB0dWFsIFRhYmxlIERlZmluaXRpb25zCiAgICAgICAgICAgUkZDIDQzODIgTU8gbXBs c0wzVnBuSWZDb25mUm93U3RhdHVzIGZvciBvbmUgZXhhbXBsZS4KICAgIG8gWW91IG11c3Qg aGF2ZSBhIG12cG5HZW5Sb3dTdG9yYWdlVHlwZSBvciB0aGUgREVTQ1JJUFRJT04gb2YKICAg ICAgbXZwbkdlblJvd1N0YXR1cyBtdXN0IGluZGljYXRlIHdoYXQgd2lsbCBoYXBwZW4gdG8g dGhlIHJvdyAKICAgICAgYWZ0ZXIgYW4gYWdlbnQgcmVzdGFydAoKOS4gU2ltaWxhciBjb21t ZW50cyAoOC4xIH4gOC4xMCkgZm9yIHRoZSByZW1haW5pbmcgdGFibGVzIGluIHRoZSBNSUIK ICAgUGFydGljdWxhcmx5IDguMTAgZm9yIHRoZSBSb3dTdGF0dXMgdHlwZSBvYmplY3RzIAog ICAgICAgICAgICAgICAgICAgICAgICBtdnBuR2VuUm93U3RhdHVzCiAgICAgICAgICAgICAg ICAgICAgICAgIG12cG5QbXNpQ29uZmlnUm93U3RhdHVzCiAgICAgICAgICAgICAgICAgICAg ICAgIG12cG5TcG1zaUNvbmZpZ1Jvd1N0YXR1cy4KICAgUGxlYXNlIGNoZWNrIGFuZCBmaXgu CiAgIAoxMC4gbXZwbk12cmZDaGFuZ2UgTk9USUZJQ0FUSU9OLVRZUEUKICAgICAgIE9CSkVD VFMgICAgIHsKICAgICAgICAgICAgICAgICAgICAgbXZwbkdlbk9wZXJTdGF0dXNDaGFuZ2UK ICAgICAgICAgICAgICAgICAgIH0KICAgICAgIDo6PSB7IG12cG5Ob3RpZmljYXRpb25zIDIg fQogICAgCiAgICBvIHNob3VsZCBiZSAgeyBtdnBuTm90aWZpY2F0aW9ucyAxIH0KICAgIG8g SW5jbHVkZSB0aGUgTU9zIHRoYXQgdGhlIGFkbWluaXN0cmF0b3IvbWFuYWdlciBtYXkgd2Fu dCB0byAKICAgICAgc2VlIGluIE9CSkVDVFMuIAogICAgICAKICAgICAgCjExLiBUaGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIG5vdCBmb2xsb3cgdGhlIFNlY3Vy aXR5IAogICAgR3VpZGVsaW5lcyBmb3IgSUVURiBNSUIgTW9kdWxlcyAKICAgIGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvb3BzL3RyYWMvd2lraS9taWItc2VjdXJpdHkuIAoK MTIuICBDT01QTElBTkNFLgoxMi4xIFlvdSBzZWVtIHRvIG1hbmRhdGUgTUFYLUFDQ0VTUyBy ZWFkLXdyaXRlL3JlYWQtY3JlYXRlIGZvciAKICAgICBjb21wbGlhbmNlLiBJcyB0aGlzIGlu dGVuZGVkPyBDb25maWd1cmF0aW9uIGNhcGFiaWxpdHkgTVVTVCBiZSAKICAgICBzdXBwb3J0 ZWQ/ICBQbGVhc2Ugbm90ZSB0aGF0IHNlYyAyLiAgTVZQTiBNSUIgc2F5cyAKICAgICAiVGhp cyBNSUIgZW5hYmxlcyBjb25maWd1cmluZyBhbmQvb3IgbW9uaXRvcmluZyBvZiBNVlBOcyAu Li4iCiAgICAgVGhlIGN1cnJlbnQgY29tcGxpYW5jZSByZXF1aXJlbWVudCBjb250cmFkaWN0 cyB0aGUgYWJvdmUgY2xhaW0uIAogICAgIFBsZWFzZSBjaGVjayBhbmQgZml4LgoKICAgICBJ dCBpcyBnZW5lcmFsIGFuZCBzb3VuZCBwcmFjdGljZSB0byBhbGxvdyBmb3IgTUFYLUFDQ0VT UyAKICAgICByZWFkLW9ubHkgY29tcGxpYW5jZS4gU29tZSBpbXBsZW1lbnRhdGlvbnMgbWF5 IHN1cHBvcnQgCiAgICAgbW9uaXRvcmluZyBidXQgbm90IGNvbmZpZ3VyYXRpb24uICAKICAg ICBQbGVhc2UgY2hlY2sgYW5kIGZpeC4KCkdlbmVyYWwgbml0czoKMTMuMSAgUGFnZS0xICBz L2FuIHBvcnRpb24vYSBwb3J0aW9uLwoxMy4yICBQYWdlLTEgIHMvd2UnbGwvd2Ugd2lsbC8g CjEzLjMgIFBhZ2UtNSAgcy8gbXZwblNwbXNpVGFibGVcL0V0bnJ5L212cG5TcG1zaVRhYmxl LwogICAgICAgIEkgdGhpbmsgdGhhdCB0aGUgIi9FbnRyeSIgd2FzIHJlbW92ZWQgZnJvbSBz aW1pbGFyIHRpdGxlcwogICAgICAgIGluIHRoZSBlYXJsaWVyIGRyYWZ0IGFzIGFkaXZpc2Vk IGJ5IHRoZSBkb2N1bWVudCBzaGVwaGVyZC4gCiAgICAgICAgVGhpcyBvbmUgc2hvdWxkIGJl IHJlbW92ZWQgdG9vLiAKMTMuNCBJRC1uaXRzOgogICAgIENoZWNraW5nIG5pdHMgYWNjb3Jk aW5nIHRvIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQtaW5mby9jaGVja2xpc3QgOgogICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCiAgICAKICAgICAgKiogVGhlcmUgaXMgMSBpbnN0YW5jZSBv ZiB0b28gbG9uZyBsaW5lcyBpbiB0aGUgZG9jdW1lbnQsIHRoZSBsb25nZXN0IG9uZQogICAg ICAgICBiZWluZyA0IGNoYXJhY3RlcnMgaW4gZXhjZXNzIG9mIDcyLgogICAgCiAgICAgIENo ZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogUHJvcG9zZWQgU3RhbmRh cmQKICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgICAgPT0gVW51c2VkIFJlZmVyZW5j ZTogJ0tFWVdPUkRTJyBpcyBkZWZpbmVkIG9uIGxpbmUgMTM4MSwgYnV0IG5vIGV4cGxpY2l0 CiAgICAgICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQKICAgICAgICAgJ1tL RVlXT1JEU10gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIFJlcXVpLi4uJwoKMTQuIFRoZXJlIGlzIGFub3RoZXIgV0lQIEwyTDMtVlBOLU1D QVNULU1JQiBpbiB0aGUgV0cuCiAgICBJcyB0aGVyZSBhIGdvb2QgcmVhc29uIGZvciBub3Qg bWVyZ2luZyB0aGUgMiBkb2N1bWVudHM/CiAgICBTb21lIGNsYXJpZmljYXRpb24gb3IgcG9p bnRlcnMgd2lsbCBiZSBoZWxwZnVsLgo= --------------060001030700080202080101-- From nobody Wed Apr 13 03:11:25 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 E1E6812D9BE; Tue, 12 Apr 2016 12:29:26 -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 AylP0kRTGcpr; Tue, 12 Apr 2016 12:29:23 -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 7C4EA12D1BE; Tue, 12 Apr 2016 12:29:23 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5B39A5EFF16B3; Tue, 12 Apr 2016 19:29:17 +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 u3CJTKPY023711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 19:29:20 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 u3CJTJRP012131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2016 21:29:20 +0200 Received: from [135.224.194.255] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 12 Apr 2016 21:29:19 +0200 Message-ID: <570D4C8E.6040800@alcatel-lucent.com> Date: Tue, 12 Apr 2016 21:29: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: Susan Hares , "'Benoit Claise'" , "'The IESG'" , "joelja@bogus.com" References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> In-Reply-To: <000d01d13d94$80868a10$81939e30$@ndzh.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: X-Mailman-Approved-At: Wed, 13 Apr 2016 03:11:22 -0700 Cc: draft-ietf-bess-mvpn-extranet@ietf.org, 'Eric C Rosen' , aretana@cisco.com, "'John G. Scudder'" , bess-chairs@ietf.org, bess@ietf.org Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) 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, 12 Apr 2016 19:29:27 -0000 Dear all, we took the opportunity of this IETF meeting to discuss with Sue, Joel and Benoit, and with Eric. Sue has had two requests: 1/ to add some text clarifying the encoding and processing of the Extended Communities this document is defining. Eric had already integrated this text in the document (v06) and more specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended Community) and 4.5 (for the Extranet Separation Extended Community). The text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the split. We have reviewed that with Sue and my understanding of our discussion is that this is acceptable. 2/ to add some text covering risks of mis-configurations Eric has added the paragraph quite soon in the document (the Overview section), such that the reader is aware. Following Thomas' suggestion to enhance that text with other cases of incorrect configurations, Eric has also added some text to the Security Considerations section. Since the document describes a tool-set, rather than trying to describe all the possible usages of these tools, the preferred approach was to give a form of warning on risks of misconf. Our understanding is that the addition of this paragraph would meet Sue's expectations. Version 07, which incorporates the above, is available. Sue, please review the changes and let us know if our understanding is correct or not, and thus if you consider your points addressed. Thank you all Best regards, Martin & Thomas Le 23/12/2015 16:13, Susan Hares a écrit : > Eric: > > *To clear my objection to this draft*, please add these sections to make > it clear what the content of the BGP values and their handling. We > disagree on what the BGP registry document states, but that point is not > worth holding up this document. People can find the type and sub-type > fields in the registry. What is not in the registry is a clear > description of the restrictions of the value field and handling. > > Placing the BGP Extended communities within the rest of the rules is > just unclear. Please put these two sections in and give the details in > this sections. > > As to the deployment section, you did not consider the text I offer > below and the suggested insertion in the security section. Perhaps you > can consider that text in your next email. On whether this deployment > section is “DISCUSS” worthy, I am still communicating with Benoit and Joel. > > I wish you the peace and joy of the Christmas season, > > Sue Hares > > ============= > > Sections which must be added to clear my concerns > > ---------------------------------------------------------------- > > *4.4.1 Extranet Source Extended Community * > > To facilitate this, we define a new Transitive Opaque Extended > Community, the "Extranet Source" Extended Community. > > The value field of this extended community is all zeros. > > *Restrictions: *This value field MUST be set to zero upon origination, > MUST be ignored upon reception and MUST be passed unchanged by > intermediate routers. > > *Additional Restrictions: *A Route Reflector MUST NOT add/remove the > Extranet Source Extended Community from the VPN-IP routes reflected by > the Route Reflector, including the case where VPN-IP routes received > via IBGP are reflected to EBGP peers (inter-AS option (c), see > [RFC6513] Section 10). > > *4.4.2 Extranet Separation Extended community * > > ** > > We define a new Transitive Opaque Extended Community, the "Extranet > Separation" Extended Community. This Extended Community is used only > when extranet separation is being used. > > *Restrictions:* Its value field MUST be set to zero upon origination, > MUST be ignored upon reception, and MUST be > > passed unchanged by intermediate routers. > > * Restrictions on Adding/deleting this community:* ?? (Eric – please > add something here). > > *Comments that could be put in a Security section: * > > ** > > Whenever a VPN is provisioned, there is a risk that provisioning errors > will result in an unintended cross-connection of VPNs, which would > create a security problem for the customers. Extranet can be > particularly tricky, as it intentionally cross-connects VPNs, but in a > manner that is intended to be strictly limited by policy. If one is > connecting two VPNs that have overlapping address spaces, one has to be > sure that the inter-VPN traffic isn't to/from the part of the address > space that is in the overlap. The draft discusses a lot of the corner > cases, and a lot of the scenarios in which things can go wrong. > > *From:*BESS [mailto:bess-bounces@ietf.org] *On Behalf Of *Eric C Rosen > *Sent:* Tuesday, December 22, 2015 2:08 PM > *To:* Susan Hares; 'Benoit Claise'; 'The IESG' > *Cc:* draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; > aretana@cisco.com; bess-chairs@ietf.org; > martin.vigoureux@alcatel-lucent.com; bess@ietf.org > *Subject:* Re: [bess] Benoit Claise's Discuss on > draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) > > On 12/22/2015 12:51 PM, Susan Hares wrote: > > Eric: > > Thank you for revisions in version -05 of your document. Unfortunately > it does not resolve either of the two points I raised. > > 1)*On the BGP Extended Communities*, I feel your specification is > *unclear and warrants change on the DISCUSS* Criteria due to > interoperability issues. > > > I've explained why I don't think this is correct. In particular, I > don't think it is wise to mention the value of the "Transitive Opaque > Extended Community Type" codepoint, as this can be found in the IANA > registry for Transitive Extended Community types, and implementers > should really be encouraged to consult the registries for the codepoints. > > > 2)I’ve given you 2 small sections to add to your document at the > beginning of section 4.4. to resolve this DISCUSS point. > > > Note that the codepoint you mention for Transitive Opaque Extended > Community Type is not correct. Unnecessary last minute changes do tend > to introduce errors. > > > 3)You need to just fill in one part below on RR restrictions for > *Extranet Separation Extended community*. > > > I will add some text saying that RRs must not add or remove this EC. > > > 2) *On the deployment section:* I given text and examples – but I think > you still misunderstand what I am looking for. > > > Perhaps. > > > Since you are an author of academic papers, > > > I am not. > > > consider I am looking for an operator-based “abstract” that focuses the > reader on the key points.I am sure you can create one for this document, > but I not clear why you object to it the concept. > > > It seems to me that you are asking for something that could be titled > "An Operator's Guide to Provisioning Extranet MVPN". While that might > be useful, it is not within the scope of the current document. As I've > said, I am not aware of any IETF requirement that requires such a thing > to be included. > > > will you please let me know that you have read my suggested text > insertions on both these topics. > > > I have. > > > > > > > From nobody Wed Apr 13 04:32:39 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E66212DD17; Wed, 13 Apr 2016 04:32:37 -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 S3TtBNp5e2yU; Wed, 13 Apr 2016 04:32:35 -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 4970012DC58; Wed, 13 Apr 2016 04:32:35 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A63752640C2; Wed, 13 Apr 2016 13:32:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7FD6935C04E; Wed, 13 Apr 2016 13:32:33 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:33 +0200 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRhfj1qHf38G7z/0eG06bIad1uvp9p2nRAgBygCdA= Date: Wed, 13 Apr 2016 11:32:32 +0000 Message-ID: <7059_1460547153_570E2E51_7059_19177_1_53C29892C857584299CBF5D05346208A0F86D0FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F86D0FFOPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.13.110317 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:32:37 -0000 --_000_53C29892C857584299CBF5D05346208A0F86D0FFOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see 1 comment inline [Bruno] From: Eric C Rosen [mailto:erosen@juniper.net] On 4/4/2016 5:28 PM, bruno.decraene@orange.com wrote: > My issue is how do we prove that_nobody_ is using it? Proving the negati= ve is hard, and silence is not part of the proof. To prove the negative, we= would need explicit statement from everyone, which looks impossible. I think you're exaggerating a little ;-) I'm having trouble believing that you are unable to determine whether the 3107 "multiple labels" feature is in use in any of your company's deployments. [Bruno] Indeed, we had a different perspective. On my side, I was assuming that the IETF would not introduce a non-backward= compatible specification change, without first checking that none of the d= eployment would be affected. My point was that this is hard to prove. On your side, you were assuming that the responsibility would be on each ne= twork operator to check whether they would have an issue. This is breaking = the big problem into N smaller ones. --Bruno ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F86D0FFOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Plea= se see 1 comment inline [Bruno]

 

From: Eric C Rosen [mailto:erosen@juniper.net]

On 4/4/2016 5:28 PM, bruno.decraene@orange.com wrote:

> My issue is how do we p= rove that_nobody_  is using it? Proving the negative is hard, and sile= nce is not part of the proof. To prove the negative, we would need explicit= statement from everyone, which looks impossible.

 

I think you're exaggerating = a little ;-)  I'm having trouble believing

that you are unable to deter= mine whether the 3107 "multiple labels"

feature is in use in any of = your company's deployments.

 

[Bru= no] Indeed, we had a different perspective.

On m= y side, I was assuming that the IETF would not introduce a non-backward com= patible specification change, without first checking that none of the deplo= yment would be affected. My point was that this is hard to prove.

On y= our side, you were assuming that the responsibility would be on each networ= k operator to check whether they would have an issue. This is breaking the = big problem into N smaller ones.

 

 

--Br= uno

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F86D0FFOPEXCLILM21corp_-- From nobody Wed Apr 13 04:33: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 BAAFC12DC58; Wed, 13 Apr 2016 04:32:49 -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 551FrufEoGmS; Wed, 13 Apr 2016 04:32:42 -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 E763812DE39; Wed, 13 Apr 2016 04:32:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B9D0822C2CC; Wed, 13 Apr 2016 13:32:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 97AB6238062; Wed, 13 Apr 2016 13:32:40 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:40 +0200 From: To: Eric C Rosen Thread-Topic: draft-rosen-mpls-rfc3107bis Thread-Index: AdGVaEaLL3G3O9S6RJ2NuhcTrvYwZA== Date: Wed, 13 Apr 2016 11:32:40 +0000 Message-ID: <22090_1460547160_570E2E58_22090_19743_1_53C29892C857584299CBF5D05346208A0F86D10D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.13.110317 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:32:50 -0000 Eric, Could the draft clarifies the BGP Route Reflector behavior when reflecting = a route received from a buggy 3107 implementation with S=3D0? a) One may argue that the RR should not modify the NLRI and hence reflect t= he route with S=3D0 b) One may argue that the RR should reflect the route after setting S=3D1 i= n order to be a speaker compliant with 3107bis & 3107. c) One may argue that this is an error and treat the IP Prefix as withdraw IMO I think I would prefer b) in order to not propagate the bug. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Apr 13 04:33: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 5457412DF51; Wed, 13 Apr 2016 04:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 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=-0.996, 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 3r0uo0qeZSud; Wed, 13 Apr 2016 04:32:59 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E30E12DEDB; Wed, 13 Apr 2016 04:32:48 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id E4FE22033B; Wed, 13 Apr 2016 13:32:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id ADE37120055; Wed, 13 Apr 2016 13:32:46 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:46 +0200 From: To: "Eric C Rosen (erosen@juniper.net)" Thread-Topic: draft-rosen-mpls-rfc3107bis-00 Thread-Index: AdGVaWAVw1/+shVVQDGYCBeSt0ROWg== Date: Wed, 13 Apr 2016 11:32:45 +0000 Message-ID: <12391_1460547166_570E2E5E_12391_13123_1_53C29892C857584299CBF5D05346208A0F86D11B@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: [bess] draft-rosen-mpls-rfc3107bis-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: Wed, 13 Apr 2016 11:33:09 -0000 Hi Eric, - Do you think that it may be useful to have a sentence about Carrier's Car= rier IP VPN? I fear that some implementation may allow multiple labels for = SAFI 4 (labelled IP) but not for SAFI 128 (VPN) and would not be capable of= translating/swapping from N labels on the PE-CE (SAFI 4) side, toward 1 la= bel to the PE-PE (SAFI 128) side. In such case, it may be preferable to adv= ertise this non-capability on the PE-CE side (e.g. by sending the multiple = label capability with a max label of 1) - The current BGP capability encoding does not allow for the sending a diff= erent number of accepted labels on a per SAFI basis. I don't know whether t= his could be useful (in the future) but I do note that, as indicated in the= draft, it's already useful to be able to advertise N>1 for some SAFI and N= =3D1 for some others. So may be the flexibility could be useful. I'll leave= the cost/benefit choice up to you. Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Apr 13 04:38:36 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 B9EEC12D581; Wed, 13 Apr 2016 04:38:30 -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=unavailable 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 WbEGc7Wcn4yP; Wed, 13 Apr 2016 04:38:30 -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 3836512DC5A; Wed, 13 Apr 2016 04:32:39 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AEAA818C579; Wed, 13 Apr 2016 13:32:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 89D6927C073; Wed, 13 Apr 2016 13:32:37 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:37 +0200 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRhfj1qHf38G7z/0eG06bIad1uvp9p2nRAgBylsnA= Date: Wed, 13 Apr 2016 11:32:36 +0000 Message-ID: <20147_1460547157_570E2E55_20147_8686_2_53C29892C857584299CBF5D05346208A0F86D106@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.13.105417 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:38:31 -0000 From: Eric C Rosen [mailto:erosen@juniper.net] > the "day 1" bugs do exist Do we really have implementation not setting the S bit on the sending side?? I don't see how this could be per design, as I fail to see a reason: - sending with S=3D1 or S=3D0 has the same cost from an implementation pers= pective, so this is not a "simplification" issue - sending with S=3D0 is a clear violation of RFC 3107 and will trigger a BG= P session shutdown from a peer compliant with 3107, so this does not seem l= ike a desirable goal from an implementation standpoint. Now, that could be a bug, but that bug would be detected with the first int= eroperability test with a compliant RFC 3107 implementation... So, how have we got into this situation? How can we be there 15 years after= the publication of RFC 3107? Thanks -- Bruno ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Apr 13 04:41:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1C612DA0E; Wed, 13 Apr 2016 04:41:32 -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 6yJQe2pxUMXY; Wed, 13 Apr 2016 04:41:30 -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 1FAD912D9AE; Wed, 13 Apr 2016 04:41:30 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A98B218C548; Wed, 13 Apr 2016 13:32:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 735FF27C067; Wed, 13 Apr 2016 13:32:24 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:24 +0200 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRjDXCqHf38G7z/0eG06bIad1uvp+Gad4g Date: Wed, 13 Apr 2016 11:32:24 +0000 Message-ID: <20149_1460547161_570E2E48_20149_19157_1_53C29892C857584299CBF5D05346208A0F86D0F8@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> In-Reply-To: <56FEA566.8070605@juniper.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F86D0F8OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.13.110317 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:41:32 -0000 --_000_53C29892C857584299CBF5D05346208A0F86D0F8OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the late answer and for breaking the email thread. (my laptop har= d drive failed during the IETF week). Please see 2 comments inline [Bruno] And as already expressed, I support the adoption of this document. From: Eric C Rosen [mailto:erosen@juniper.net] Right now, we're arguing about which of the following two strategies is more likely to cause a problem: 1. In the first strategy, 3107bis requires the S bit to be set when there is a single label. This will allow 3107bis to interoperate with 3107 implementations of "multiple labels", but it will not allow 3107bis to interoperate with (buggy) 3107 implementations that send a single label, but don't set the S bit. 2. In the second strategy, 3107bis assumes, in the absence of the Capability, that there is only a single label, and doesn't bother to check the S bit. This will allow 3107bis to interoperate with (buggy) implementations that send a single label but fail to set the S bit; it will not allow 3107bis to interoperate with (non-buggy) 3107 implementations of multiple labels. My argument is that the second strategy is better because it will be less disruptive. This is based on my belief that the "day 1" bugs do exist, and that the "multiple labels" feature has yet to be deployed. Your argument seems to be that the first strategy is better because (a) it only causes disruption if the 3107 implementation has a bug, in which case the bug can be fixed, and (b) if the second strategy is used, a 3107-compliant implementation of multiple labels will fail to interoperate with a 3107bis-compliant implementation of multiple labels, and both implementors will claim compliance. [Bruno] Thank you for this good and fair summary. I would add: (c) a 3107-compliant implementation of multiple labels sending= one route with multiple labels to a 3107bis-compliant implementation of a = single label, will trigger the shutdown of the BGP sessions and hence the r= emoval of all labelled routes and most likely all routes from all AFI/SAFI = sharing this BGP session. This is very disruptive. And both implementors wi= ll claim compliance. There may be a third strategy: second strategy, plus when a BGP error is fo= und when parsing the NLRI, search for the S bit in order to identify the IP= prefix and treat it as withdraw. (rather than kill the BGP session) To be on the extra safe side, I'd prefer the third strategy, on the basis t= hat you never know what you can receive (cf the BGP attribute 99 incident, = which nobody asked for/expected), plus the 3107 speaker sending multiple la= bels IS compliant. If you don't think that this is feasible/reasonable, I'm fine with the seco= nd strategy. I think your argument is reasonable, the question is really just which strategy will cause less disruption. [Bruno] In either case, it seems like the draft will need to document the i= ssue and warn the network operator about it. Do other members of the WGs have opinions about this? ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F86D0F8OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorr= y for the late answer and for breaking the email thread. (my laptop hard dr= ive failed during the IETF week).

Plea= se see 2 comments inline [Bruno]

And = as already expressed, I support the adoption of this document.

 

From: Eric C Rosen [mailto:erosen@juniper.net]

Right now, we're arguing abo= ut which of the following two strategies is

more likely to cause a probl= em:

 

1. In the first strategy, 31= 07bis requires the S bit to be set when

there is a single label.&nbs= p; This will allow 3107bis to interoperate with

3107 implementations of &quo= t;multiple labels", but it will not allow 3107bis

to interoperate with (buggy)= 3107 implementations that send a single

label, but don't set the S b= it.

 

2. In the second strategy, 3= 107bis assumes, in the absence of the

Capability, that there is on= ly a single label, and doesn't bother to

check the S bit.  This = will allow 3107bis to interoperate with (buggy)

implementations that send a = single label but fail to set the S bit; it

will not allow 3107bis to in= teroperate with (non-buggy) 3107

implementations of multiple = labels.

 

My argument is that the seco= nd strategy is better because it will be

less disruptive.  This = is based on my belief that the "day 1" bugs do

exist, and that the "mu= ltiple labels" feature has yet to be deployed.

 

Your argument seems to be th= at the first strategy is better because (a) 

it only causes disruption if= the 3107 implementation has a bug, in which

case the bug can be fixed, a= nd (b) if the second strategy is used, a

3107-compliant implementatio= n of multiple labels will fail to

interoperate with a 3107bis-= compliant implementation of multiple labels,

and both implementors will c= laim compliance.

 

[Bru= no] Thank you for this good and fair summary.

I wo= uld add: (c) a 3107-compliant implementation of multiple labels sending one= route with multiple labels to a 3107bis-compliant implementation of a sing= le label, will trigger the shutdown of the BGP sessions and hence the removal of all labelled routes and most lik= ely all routes from all AFI/SAFI sharing this BGP session. This is very dis= ruptive. And both implementors will claim compliance.

 

 

Ther= e may be a third strategy: second strategy, plus when a BGP error is found = when parsing the NLRI, search for the S bit in order to identify the IP pre= fix and treat it as withdraw. (rather than kill the BGP session)

 

To b= e on the extra safe side, I’d prefer the third strategy, on the basis= that you never know what you can receive (cf the BGP attribute 99 incident= , which nobody asked for/expected), plus the 3107 speaker sending multiple labels IS compliant.

If y= ou don’t think that this is feasible/reasonable, I’m fine with = the second strategy.

 

 

I think your argument is rea= sonable, the question is really just which

strategy will cause less dis= ruption.

 

[Bru= no] In either case, it seems like the draft will need to document the issue= and warn the network operator about it.

 

Do other members of the WGs = have opinions about this?

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F86D0F8OPEXCLILM21corp_-- From nobody Wed Apr 13 05:36:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A8312DFF7 for ; Wed, 13 Apr 2016 05:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB899igqODGs for ; Wed, 13 Apr 2016 05:36:30 -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 5AEB912DBBF for ; Wed, 13 Apr 2016 05:36:30 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 391F5905A7AD0; Wed, 13 Apr 2016 12:36:26 +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 u3DCaRXC020487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2016 12:36:28 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 u3DCaOTw018833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Apr 2016 14:36:26 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 13 Apr 2016 14:36:26 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "li_zhenqiang@hotmail.com" , "thomas.morin" , bess Thread-Topic: [bess] minutes of our IETF 95 meeting Thread-Index: AQHRlTENo3Q27kNTQk+3J1FsLbie55+H6I8A Date: Wed, 13 Apr 2016 12:36:25 +0000 Message-ID: <50162F37-4383-4A23-86D1-F4D54D04D0D4@alcatel-lucent.com> References: <5706D4BA.9060908@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.38] Content-Type: multipart/alternative; boundary="_000_50162F3743834A2386D1F4D54D04D0D4alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] minutes of our IETF 95 meeting 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, 13 Apr 2016 12:36:32 -0000 --_000_50162F3743834A2386D1F4D54D04D0D4alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgYW5zd2VyIGhhcyBiZWVuIHlvdSBjYW4gdXNlIGVpdGhlciB2NCBvciB2NiBOSCBhcyBwZXIg UkZDNTU0OSBzZWN0aW9uIDYuMS82LjINCg0KRnJvbTogQkVTUyA8YmVzcy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgImxpX3poZW5x aWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPiIgPGxpX3po ZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPj4NCkRh dGU6IFdlZG5lc2RheSAxMyBBcHJpbCAyMDE2IGF0IDA2OjAzDQpUbzogInRob21hcy5tb3JpbiIg PHRob21hcy5tb3JpbkBvcmFuZ2UuY29tPG1haWx0bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbT4+ LCBiZXNzIDxiZXNzQGlldGYub3JnPG1haWx0bzpiZXNzQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbYmVzc10gbWludXRlcyBvZiBvdXIgSUVURiA5NSBtZWV0aW5nDQoNCmZvciBkcmFmdC1saS1i ZXNzLTRwZS0wMToNClBsZWFzZSBhZGQgbXkgcmVzcG9uc2UgdG8gY29tbWVudHMgZnJvbSBLZXl1 ciBhbmQgV2ltOiA0UEUgcm91dGVycyBuZWVkIElQdjQgbmV4dCBob3AgaW5mb3JtYXRpb24gdG8g aW5zdGFsbCB0aGVpciBJUHY0IHJvdXRpbmcgdGFibGUuDQoNClRoYW5rcyBhbmQgQmVzdCBSZWdh cmRzLA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpX3poZW5xaWFuZ0Bob3Rt YWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPg0KDQpGcm9tOiBUaG9tYXMg TW9yaW48bWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tPg0KRGF0ZTogMjAxNi0wNC0wOCAw NTo0NA0KVG86IEJFU1M8bWFpbHRvOmJlc3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbYmVzc10gbWlu dXRlcyBvZiBvdXIgSUVURiA5NSBtZWV0aW5nDQpIaSBldmVyeW9uZSwNCg0KV2UgaGF2ZSBqdXN0 IHBvc3RlZCBkcmFmdCBtaW51dGVzIGZvciB0b2RheSdzIG1lZXRpbmcuDQoNCllvdSBjYW4gcmVh ZCB0aGVtIGF0DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21p bnV0ZXMtOTUtYmVzcw0KDQpQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMgeW91IG1heSBoYXZlIG9u IHRoZXNlIG1pbnV0ZXMuDQoNCk1hbnkgbWFueSB0aGFua3MgdG8gR3VudGVyIGZvciBoaXMgbWlu dXRlIHRha2luZyENCg0KLVRob21hcy9NYXJ0aW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkJFU1MgbWFpbGluZyBsaXN0DQpCRVNTQGlldGYub3Jn PG1haWx0bzpCRVNTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9iZXNzDQoNCg== --_000_50162F3743834A2386D1F4D54D04D0D4alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pk15IGFuc3dlciBoYXMgYmVlbiB5b3UgY2FuIHVzZSBlaXRoZXIgdjQgb3IgdjYgTkggYXMg cGVyIFJGQzU1NDkgc2VjdGlvbiA2LjEvNi4yPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09V VExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29s b3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVt IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJ R0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5Gcm9tOiA8L3NwYW4+QkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3MtYm91bmNlc0Bp ZXRmLm9yZyI+YmVzcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90 OzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90 bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXkgMTMgQXByaWwgMjAx NiBhdCAwNjowMzxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFu PiZxdW90O3Rob21hcy5tb3JpbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3Jp bkBvcmFuZ2UuY29tIj50aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7LCBiZXNzICZsdDs8 YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW2Jlc3Nd IG1pbnV0ZXMgb2Ygb3VyIElFVEYgOTUgbWVldGluZzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PHN0eWxlPmJvZHkgeyBsaW5lLWhlaWdodDogMS41OyB9YmxvY2txdW90ZSB7 IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMC41ZW07 IH1ib2R5IHsgZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiA/Pz8/OyBjb2xvcjogcmdi KDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9Ym9keSB7IGZvbnQtc2l6ZTogMTAuNXB0OyBj b2xvcjogcmdiKDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9PC9zdHlsZT4NCjxkaXY+DQo8 ZGl2PmZvciZuYnNwOzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1zcGFj ZTogcHJlLXdyYXA7IHdpZG93czogMTsgZm9udC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQtY29s b3I6IHdpbmRvdzsiPmRyYWZ0LWxpLWJlc3MtNHBlLTAxOjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNw YW4+PC9zcGFuPlBsZWFzZSBhZGQgbXkgcmVzcG9uc2UgdG8gY29tbWVudHMgZnJvbSZuYnNwOzxz cGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdp ZG93czogMTsgZm9udC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPktl eXVyIGFuZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1z cGFjZTogcHJlLXdyYXA7IHdpZG93czogMTsgZm9udC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQt Y29sb3I6IHdpbmRvdzsiPldpbTogNFBFIHJvdXRlcnMgbmVlZCBJUHY0IG5leHQgaG9wIGluZm9y bWF0aW9uIHRvIGluc3RhbGwgdGhlaXIgSVB2NCByb3V0aW5nIHRhYmxlLjwvc3Bhbj48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLDwvZGl2Pg0K PGhyIHN0eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIgY29sb3I9IiNiNWM0ZGYiIHNp emU9IjEiIGFsaWduPSJsZWZ0Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0eWxlPSJNQVJHSU46IDEw cHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPGRpdj48YSBocmVm PSJtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tIj5saV96aGVucWlhbmdAaG90bWFpbC5j b208L2E+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDAuNWVtOyI+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdiBzdHls ZT0iUEFERElORy1SSUdIVDogOHB4OyBQQURESU5HLUxFRlQ6IDhweDsgRk9OVC1TSVpFOiAxMnB4 O0ZPTlQtRkFNSUxZOnRhaG9tYTtDT0xPUjojMDAwMDAwOyBCQUNLR1JPVU5EOiAjZWZlZmVmOyBQ QURESU5HLUJPVFRPTTogOHB4OyBQQURESU5HLVRPUDogOHB4Ij4NCjxkaXY+PGI+RnJvbTo8L2I+ Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5tb3JpbkBvcmFuZ2UuY29tIj5UaG9tYXMgTW9y aW48L2E+PC9kaXY+DQo8ZGl2PjxiPkRhdGU6PC9iPiZuYnNwOzIwMTYtMDQtMDgmbmJzcDswNTo0 NDwvZGl2Pg0KPGRpdj48Yj5Ubzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5v cmciPkJFU1M8L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1tiZXNzXSBtaW51 dGVzIG9mIG91ciBJRVRGIDk1IG1lZXRpbmc8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj5IaSBldmVyeW9uZSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldlIGhhdmUg anVzdCBwb3N0ZWQgZHJhZnQgbWludXRlcyBmb3IgdG9kYXkncyBtZWV0aW5nLjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+WW91IGNhbiByZWFkIHRoZW0gYXQgPC9kaXY+DQo8ZGl2Pjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L21pbnV0ZXMvbWludXRl cy05NS1iZXNzIj5odHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21p bnV0ZXMtOTUtYmVzczwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlBsZWFzZSBz ZW5kIGFueSBjb21tZW50cyB5b3UgbWF5IGhhdmUgb24gdGhlc2UgbWludXRlcy48L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hbnkgbWFueSB0aGFua3MgdG8gR3VudGVyIGZvciBoaXMg bWludXRlIHRha2luZyE8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi1UaG9tYXMvTWFy dGluPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj5CRVNTIG1haWxpbmcgbGlzdDwv ZGl2Pg0KPGRpdj48YSBocmVmPSJtYWlsdG86QkVTU0BpZXRmLm9yZyI+QkVTU0BpZXRmLm9yZzwv YT48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9iZXNzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3M8L2E+ PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_50162F3743834A2386D1F4D54D04D0D4alcatellucentcom_-- From nobody Wed Apr 13 05:47:33 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E854912E19B for ; Wed, 13 Apr 2016 05:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zT84zosCSfW for ; Wed, 13 Apr 2016 05:47:31 -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 92EFA12E197 for ; Wed, 13 Apr 2016 05:47:31 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6B9155D8AD2; Wed, 13 Apr 2016 14:47:30 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 619DA5D8857; Wed, 13 Apr 2016 14:47:30 +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, 13 Apr 2016 14:47:30 +0200 To: "li_zhenqiang@hotmail.com" , bess References: <5706D4BA.9060908@orange.com> From: Thomas Morin Organization: Orange Message-ID: <570E3FCF.4000408@orange.com> Date: Wed, 13 Apr 2016 14:47:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080305080407040502040603" Archived-At: Subject: Re: [bess] minutes of our IETF 95 meeting 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, 13 Apr 2016 12:47:33 -0000 --------------080305080407040502040603 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi, I've updated the minutes. Thanks for the precision. Beyond this minute adjustment, I understand that the key thing you need to clarify is what is missing or problematic in RFC5549. Thank you, -Thomas 2016-04-13, li_zhenqiang@hotmail.com: > for draft-li-bess-4pe-01: > Please add my response to comments from Keyur and Wim: 4PE routers > need IPv4 next hop information to install their IPv4 routing table. > > Thanks and Best Regards, > ------------------------------------------------------------------------ > li_zhenqiang@hotmail.com > > *From:* Thomas Morin > *Date:* 2016-04-08 05:44 > *To:* BESS > *Subject:* [bess] minutes of our IETF 95 meeting > Hi everyone, > We have just posted draft minutes for today's meeting. > You can read them at > https://www.ietf.org/proceedings/95/minutes/minutes-95-bess > Please send any comments you may have on these minutes. > Many many thanks to Gunter for his minute taking! > -Thomas/Martin > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --------------080305080407040502040603 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Hi,

I've updated the minutes.
Thanks for the precision.

Beyond this minute adjustment, I understand that the key thing you need to clarify is what is missing or problematic in RFC5549.

Thank you,

-Thomas


2016-04-13, li_zhenqiang@hotmail.com:
for draft-li-bess-4pe-01:
Please add my response to comments from Keyur and Wim: 4PE routers need IPv4 next hop information to install their IPv4 routing table.

Thanks and Best Regards,
 
Date: 2016-04-08 05:44
To: BESS
Subject: [bess] minutes of our IETF 95 meeting
Hi everyone,
 
We have just posted draft minutes for today's meeting.
 
You can read them at
 
Please send any comments you may have on these minutes.
 
Many many thanks to Gunter for his minute taking!
 
-Thomas/Martin
 
_______________________________________________
BESS mailing list
 

--------------080305080407040502040603-- From nobody Wed Apr 13 05:57: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 8D31212E237; Wed, 13 Apr 2016 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-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 c5vej7fumv-c; Wed, 13 Apr 2016 05:57:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A77ED12E233; Wed, 13 Apr 2016 05:57:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79A0E1E478; Wed, 13 Apr 2016 09:01:28 -0400 (EDT) Date: Wed, 13 Apr 2016 09:01:28 -0400 From: Jeffrey Haas To: bruno.decraene@orange.com Message-ID: <20160413130128.GB9940@pfrc.org> References: <22090_1460547160_570E2E58_22090_19743_1_53C29892C857584299CBF5D05346208A0F86D10D@OPEXCLILM21.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22090_1460547160_570E2E58_22090_19743_1_53C29892C857584299CBF5D05346208A0F86D10D@OPEXCLILM21.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" , BESS , Eric C Rosen , "mpls@ietf.org" Subject: Re: [bess] [Idr] draft-rosen-mpls-rfc3107bis X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 12:57:09 -0000 On Wed, Apr 13, 2016 at 11:32:40AM +0000, bruno.decraene@orange.com wrote: > Could the draft clarifies the BGP Route Reflector behavior when reflecting a route received from a buggy 3107 implementation with S=0? > a) One may argue that the RR should not modify the NLRI and hence reflect the route with S=0 > b) One may argue that the RR should reflect the route after setting S=1 in order to be a speaker compliant with 3107bis & 3107. > c) One may argue that this is an error and treat the IP Prefix as withdraw > > IMO I think I would prefer b) in order to not propagate the bug. Normally I would argue for c. What I'm really curious about is implementations that may not be setting end-of-stack currently for their 3107. Time to read what our code does upon receipt. -- Jeff From nobody Wed Apr 13 12:32:56 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064EB12E47B for ; Wed, 13 Apr 2016 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 hs3aDJYzToNy for ; Wed, 13 Apr 2016 12:32:52 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3187112E47A for ; Wed, 13 Apr 2016 12:32:52 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id C4E0B2033D; Wed, 13 Apr 2016 21:32:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 9AF111A0066; Wed, 13 Apr 2016 21:32:50 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 21:32:50 +0200 From: To: "bess@ietf.org" , Eric C Rosen Thread-Topic: [Technical Errata Reported] RFC4577 (4659) Thread-Index: AQHRkWXeVyBEqJQPakq2SxP8hzLIg5+IU7sH Date: Wed, 13 Apr 2016 19:32:50 +0000 Message-ID: <8999_1460575970_570E9EE2_8999_16499_1_tkacok4dcs1l9p853epsaq10.1460575967638@email.android.com> References: <20160408071024.CC4FC180205@rfc-editor.org> In-Reply-To: <20160408071024.CC4FC180205@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_tkacok4dcs1l9p853epsaq101460575967638emailandroidcom_" MIME-Version: 1.0 Archived-At: Subject: [bess] TR: [Technical Errata Reported] RFC4577 (4659) 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, 13 Apr 2016 19:32:55 -0000 --_000_tkacok4dcs1l9p853epsaq101460575967638emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This errata on RFC4577, "OSPF as the PE/CE Protocol for BGP/MPLS IP VPNs" was reported to l3vpn, n= ow closed, and to original authors for some of whom with obsolete addresses. -Thomas ---- Message original ---- Objet : [Technical Errata Reported] RFC4577 (4659) Envoy=E9 : 8 avr. 2016 9:11 AM De : RFC Errata System =C0 : erosen@cisco.com,ppsenak@cisco.com,ppe@cisco.com,brian@innovationslab= .net,terry.manderson@icann.org,martin.vigoureux@alcatel-lucent.com,MORIN Th= omas IMT/OLN Cc : chao.fu@ericsson.com,l3vpn@ietf.org,rfc-editor@rfc-editor.org The following errata report has been submitted for RFC4577, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Privat= e Networks (VPNs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4577&eid=3D4659 -------------------------------------- Type: Technical Reported by: Chao Fu Section: 4.1.4 Original Text ------------- If a PE attaches to a CE via a link that is in a non-zero area, then the PE serves as an ABR for that area. Corrected Text -------------- PE always serves as an ABR if it attaches to a CE. Notes ----- Even the PE attaches to a CE via a link that is in backbone area, it should= also be thought as an ABR. Otherwise the CE cannot calculate the type 3 LS= As from PE because there is no ABR. Section 4.2.3 has the similar description and should also be updated: "If a PE has a link that belongs to a non-zero area, the PE functions as an Area Border Router (ABR) for that area." Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4577 (draft-ietf-l3vpn-ospf-2547-06) -------------------------------------- Title : OSPF as the Provider/Customer Edge Protocol for BGP/M= PLS IP Virtual Private Networks (VPNs) Publication Date : June 2006 Author(s) : E. Rosen, P. Psenak, P. Pillay-Esnault Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG ___________________________________________________________________________= ______________________________________________ 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_tkacok4dcs1l9p853epsaq101460575967638emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This errata on  RFC4577,
"OSPF as the PE/CE Protocol for BGP/MPLS IP VPNs" was reported to= l3vpn,  now closed, and to original authors for some of whom with obs= olete addresses.

-Thomas



---- Message original ----
Objet : [Technical Errata Reported] RFC4577 (4659)
Envoy=E9 : 8 avr. 2016 9:11 AM
De : RFC Errata System <rfc-editor@rfc-editor.org>
=C0 : erosen@cisco.com,ppsenak@cisco.com,ppe@cisco.com,brian@innovatio= nslab.net,terry.manderson@icann.org,martin.vigoureux@alcatel-lucent.com,MOR= IN Thomas IMT/OLN <thomas.morin@orange.com>
Cc : chao.fu@ericsson.com,l3vpn@ietf.org,rfc-editor@rfc-editor.org

The following errata report has been submitted for= RFC4577,
"OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual P= rivate Networks (VPNs)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4577&eid=3D4= 659

--------------------------------------
Type: Technical
Reported by: Chao Fu <chao.fu@ericsson.com>

Section: 4.1.4

Original Text
-------------
   If a PE attaches to a CE via a link that is in a non-zero area= , then
   the PE serves as an ABR for that area.

Corrected Text
--------------
   PE always serves as an ABR if it attaches to a CE.

Notes
-----
Even the PE attaches to a CE via a link that is in backbone area, it should= also be thought as an ABR. Otherwise the CE cannot calculate the type 3 LS= As from PE because there is no ABR.

Section 4.2.3 has the similar description and should also be updated:
   "If a PE has a link that belongs to a non-zero area, the = PE functions
   as an Area Border Router (ABR) for that area."

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC4577 (draft-ietf-l3vpn-ospf-2547-06)
--------------------------------------
Title           &nbs= p;   : OSPF as the Provider/Customer Edge Protocol for BGP/MPLS I= P Virtual Private Networks (VPNs)
Publication Date    : June 2006
Author(s)           : E. = Rosen, P. Psenak, P. Pillay-Esnault
Category            = : PROPOSED STANDARD
Source           &nb= sp;  : Layer 3 Virtual Private Networks INT
Area            = ;    : Internet
Stream           &nb= sp;  : IETF
Verifying Party     : IESG

 
______________________________________________________________________=
___________________________________________________

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_tkacok4dcs1l9p853epsaq101460575967638emailandroidcom_-- From nobody Thu Apr 14 01:42: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 D2A0B12E3B2; Thu, 14 Apr 2016 01:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd8hY1xBTeYN; Thu, 14 Apr 2016 01:42:17 -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 DFE0212E3A5; Thu, 14 Apr 2016 01:42:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMD46058; Thu, 14 Apr 2016 08:42:13 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 09:42:11 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 16:42:04 +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+JJ4yg Date: Thu, 14 Apr 2016 08:42:04 +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.0A020204.570F57E5.0096, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.171, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 309fbe081d9549f40ad1ea13049f8431 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: Thu, 14 Apr 2016 08:42:19 -0000 Hi Glenn, Thanks for your review and the comments! To the authors: Please address the comments asap, once the comments addressed, we could sen= d the draft to IESG for publication. Thanks, 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 Thu Apr 14 01:43:48 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 CC2C212DD21; Thu, 14 Apr 2016 01:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUQ6HwnixwlM; Thu, 14 Apr 2016 01:43:45 -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 9075112E3B3; Thu, 14 Apr 2016 01:43:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHK44392; Thu, 14 Apr 2016 08:43:42 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 09:43:42 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 16:43:35 +0800 From: Mach Chen To: Glenn Mansfield Keeni , Benoit Claise , "thomas.morin@orange.com" Thread-Topic: MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt Thread-Index: AQHRlISMh8u6luSAOkaDg/z0ac1/rZ+JKmJA Date: Thu, 14 Apr 2016 08:43:35 +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> In-Reply-To: <570C9586.7030905@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.0A010203.570F583F.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.171, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1bc96d5ad6851814b2af2e0442bbdf57 Archived-At: Cc: "Jeffrey \(Zhaohui\) Zhang" , "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-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: Thu, 14 Apr 2016 08:43:47 -0000 Hi Glenn, Thanks for your review and the comments! To the authors: Please address the comments asap, once the comments addressed, we could sen= d the draft to IESG for publication. Thanks, Mach > -----Original Message----- > From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] > Sent: Tuesday, April 12, 2016 2:28 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-l2l3-vpn-mcast-mib-02.txt >=20 > 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 docum= ent > 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 :-) >=20 > The comments are attached. >=20 > Glenn >=20 From nobody Thu Apr 14 14:45:35 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 3B89912E3FA; Thu, 14 Apr 2016 14:45:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160414214531.6913.58491.idtracker@ietfa.amsl.com> Date: Thu, 14 Apr 2016 14:45:31 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-service-chaining-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, 14 Apr 2016 21:45:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS of the IETF. Title : Service Chaining using Virtual Networks with BGP VPNs Authors : Rex Fernando Stuart Mackie Dhananjaya Rao Bruno Rijsman Maria Napierala Thomas Morin Filename : draft-ietf-bess-service-chaining-00.txt Pages : 41 Date : 2016-04-14 Abstract: This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-service-chaining/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-service-chaining-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 Fri Apr 15 11:44:38 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 2F19812E03C; Fri, 15 Apr 2016 11:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.898 X-Spam-Level: X-Spam-Status: No, score=-107.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWktK1XTItW8; Fri, 15 Apr 2016 11:43:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467EA12DEDA; Fri, 15 Apr 2016 11:43:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 369F118000B; Fri, 15 Apr 2016 11:42:50 -0700 (PDT) To: rbonica@juniper.net, hj2387@att.com, luay.jalil@verizon.com, rbonica@juniper.net, keyupate@cisco.com, lucy.yong@huawei.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160415184250.369F118000B@rfc-editor.org> Date: Fri, 15 Apr 2016 11:42:50 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 15 Apr 2016 11:44:37 -0700 Cc: aretana@cisco.com, iesg@ietf.org, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] [Errata Rejected] RFC7543 (4402) 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, 15 Apr 2016 18:43:11 -0000 The following errata report has been rejected for RFC7543, "Covering Prefixes Outbound Route Filter for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7543&eid=4402 -------------------------------------- Status: Rejected Type: Technical Reported by: Ron Bonica Date Reported: 2015-06-26 Rejected by: Alvaro Retana (IESG) Section: 7 Original Text ------------- +------------------------------------------------+---------------+ | Registry | Code Point | +------------------------------------------------+---------------+ | BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) | | Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) | +------------------------------------------------+---------------+ Corrected Text -------------- +------------------------------------------------+---------------+ | Registry | Code Point | +------------------------------------------------+---------------+ | BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) | | Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) | | Capability Codes | CP-ORF (72) | +------------------------------------------------+---------------+ Notes ----- In the original text, we forgot to mention the value of the BGP capability code. --VERIFIER NOTES-- RFC 5291 describes The Outbound Route Filter (ORF) Capability for BGP. According to RFC 5291, when two BGP speakers initiate a session between one another and they intend to exchange ORFs of any type, they must advertise the ORF capability. The ORF capability is registered with a value of 3 in the IANA BGP Capability Code Registry. The ORF capability also includes a list of ORF types that the BGP speaker can send and/or receive. IANA also maintains a BGP Outbound Route Filtering (ORF) Types registry. RFC 7543 describes a new ORF type, called the Covering Prefix ORF (CP-ORF). RFC 7543 should conform to generic ORF procedures defined in RFC 5291. Specifically, when two BGP speakers initiate a session between one another and they intend to exchange CP-ORFs, they must advertise the ORF capability (value 3). The ORF capability must include CP-ORF (value 65) in the ORF type list. -------------------------------------- RFC7543 (draft-ietf-bess-orf-covering-prefixes-06) -------------------------------------- Title : Covering Prefixes Outbound Route Filter for BGP-4 Publication Date : May 2015 Author(s) : H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong Category : PROPOSED STANDARD Source : BGP Enabled Services Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 15 11:57: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 0C21F12D7EE for ; Fri, 15 Apr 2016 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.918 X-Spam-Level: X-Spam-Status: No, score=-107.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFK-kvfYxsbL for ; Fri, 15 Apr 2016 11:56:01 -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 B105912D7E1 for ; Fri, 15 Apr 2016 11:56:01 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9A330180206; Fri, 15 Apr 2016 11:55:42 -0700 (PDT) To: hj2387@att.com, luay.jalil@verizon.com, rbonica@juniper.net, keyupate@cisco.com, lucy.yong@huawei.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, martin.vigoureux@nokia.com, thomas.morin@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160415185542.9A330180206@rfc-editor.org> Date: Fri, 15 Apr 2016 11:55:42 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 15 Apr 2016 11:57:19 -0700 Cc: rbonica@juniper.net, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] [Editorial Errata Reported] RFC7543 (4669) 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, 15 Apr 2016 18:56:03 -0000 The following errata report has been submitted for RFC7543, "Covering Prefixes Outbound Route Filter for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7543&eid=4669 -------------------------------------- Type: Editorial Reported by: Ron Bonica Section: 4 and 5 Original Text ------------- V-spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability Corrected Text -------------- V-spoke1 establishes a BGP session with the RR, advertising the ORF capability (including the CP ORF Type in its ORF Type list) as well as the Multiprotocol Extensions capability Notes ----- This text occurs twice, once in Section 4 and again in Section 5 Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7543 (draft-ietf-bess-orf-covering-prefixes-06) -------------------------------------- Title : Covering Prefixes Outbound Route Filter for BGP-4 Publication Date : May 2015 Author(s) : H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong Category : PROPOSED STANDARD Source : BGP Enabled Services Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 15 15:22: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 5EA9612DB9B; Fri, 15 Apr 2016 15:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.918 X-Spam-Level: X-Spam-Status: No, score=-107.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_FuxWL7N35c; Fri, 15 Apr 2016 15:19:36 -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 27C5812DA05; Fri, 15 Apr 2016 15:19:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8B73D18019D; Fri, 15 Apr 2016 15:19:16 -0700 (PDT) To: rbonica@juniper.net, hj2387@att.com, luay.jalil@verizon.com, rbonica@juniper.net, keyupate@cisco.com, lucy.yong@huawei.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160415221916.8B73D18019D@rfc-editor.org> Date: Fri, 15 Apr 2016 15:19:16 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 15 Apr 2016 15:22:48 -0700 Cc: aretana@cisco.com, iesg@ietf.org, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] [Errata Held for Document Update] RFC7543 (4669) 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, 15 Apr 2016 22:19:37 -0000 The following errata report has been held for document update for RFC7543, "Covering Prefixes Outbound Route Filter for BGP-4". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7543&eid=4669 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ron Bonica Date Reported: 2016-04-15 Held by: Alvaro Retana (IESG) Section: 4 and 5 Original Text ------------- V-spoke1 establishes a BGP session with the RR, negotiating the CP-ORF capability as well as the Multiprotocol Extensions capability Corrected Text -------------- V-spoke1 establishes a BGP session with the RR, advertising the ORF capability (including the CP ORF Type in its ORF Type list) as well as the Multiprotocol Extensions capability Notes ----- This text occurs twice, once in Section 4 and again in Section 5 -------------------------------------- RFC7543 (draft-ietf-bess-orf-covering-prefixes-06) -------------------------------------- Title : Covering Prefixes Outbound Route Filter for BGP-4 Publication Date : May 2015 Author(s) : H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong Category : PROPOSED STANDARD Source : BGP Enabled Services Area : Routing Stream : IETF Verifying Party : IESG From nobody Sat Apr 16 05:40:42 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 16A0212D59D; Sat, 16 Apr 2016 05:40:39 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160416124039.24063.97385.idtracker@ietfa.amsl.com> Date: Sat, 16 Apr 2016 05:40:39 -0700 Archived-At: Cc: bess@ietf.org Subject: [bess] I-D Action: draft-ietf-bess-l2l3-vpn-mcast-mib-03.txt X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 12:40:39 -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 : L2L3 VPN Multicast MIB Author : Zhaohui Zhang Filename : draft-ietf-bess-l2l3-vpn-mcast-mib-03.txt Pages : 9 Date : 2016-04-16 Abstract: This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes common managed objects used to configure and/or monitor both L2 and L3 VPN Multicast. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 16 05:47:39 2016 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7B12E11F; Sat, 16 Apr 2016 05:47:39 -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 OiJRkVm794zo; Sat, 16 Apr 2016 05:47:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A301712E10F; Sat, 16 Apr 2016 05:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lOBDpMPEViFIhSbsqPZ9neLlgkPJJidOGK5eBaqO5U0=; b=NwmSYO9MwY1GeG1wrVs/g1OLf8Mx+WDRKMPxGWBB1S3WAeD/w4L/l3ingUqP6HNgFuFCyJ35isLWs5WfoCtplb0XxOfXTj2fLLSuQkpiG9vQTYhrqZ7vhw+UxICIZ5kYXw4DTO5YASstvZx+0U5CvuIPl+009fuCERktlUBHmi0= 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.466.19; Sat, 16 Apr 2016 12:47:16 +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.0453.030; Sat, 16 Apr 2016 12:47:16 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Glenn Mansfield Keeni , Benoit Claise , "EXT - thomas.morin@orange.com" Thread-Topic: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt Thread-Index: AQHRlISOhJkL7usALUq641jolYM5pJ+H1dUQ Date: Sat, 16 Apr 2016 12:47:16 +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> In-Reply-To: <570C9586.7030905@cysols.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cysols.com; dkim=none (message not signed) header.d=none;cysols.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: d1e04414-4d25-49d1-54e8-08d365f53dc4 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:SG3bvaxa/XdgDIKY1v2MsH1Q+ru5TetkmpPXOsu0BBneSATwdKhhY5zdMbm2a3heiThzdWqFYr5f42Bxt61W/qKIzwHPft3gjdGmnKpQxYHE6l0YVINt/wot/F8wZYRCLlpE1RQFp4NZwk39Sm5f5pvX2V1rLZgw6wH+XOTj4HDel8jgiHrMGp3uCM3aMD45; 24:8nEmmJB/za33xtze56HZlHwBF18O+gUSiR30Jpw4qfpA81VLbME6R6JlUC8zvP2t4gTN8Tdj+gEDgFBXVFIKsNBSIMs+G0aKTRyHc0g2zfs=; 7:VkgAQHUSDZ3oJ+JUopqODPkM1o5TnHzIc6WcWF8Rw0uIdj/rJqvwR4OkMKA1KQkn4JDN/EPbz8RcmYFE9ia9rc0vQJgvsYAXis9E4aGWL4Cr0o9FgVYYuvx6MmgmbBiHA9Efh0wiOKd0y3BzRTCNFh75n2dyx5nOLaLEHBpkhEVH0qlBMQGighX/bIefxWipEjK2sShZfgIgreuzw8UyMauUF9gjIs5sdKGnBwX4fZs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 09144DB0F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(86362001)(87936001)(33656002)(93886004)(66066001)(1096002)(5001770100001)(10400500002)(2950100001)(19580405001)(5002640100001)(15975445007)(2900100001)(5003600100002)(50986999)(54356999)(230783001)(77096005)(76176999)(1720100001)(99286002)(106116001)(586003)(76576001)(4326007)(3280700002)(3660700001)(81166005)(5890100001)(1220700001)(74316001)(5008740100001)(19580395003)(102836003)(2906002)(189998001)(5004730100002)(92566002)(6116002)(9686002)(3846002)(11100500001)(122556002)(21314002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 16 Apr 2016 12:47:16.5322 (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: Cc: Mach Chen , "ops-ads@ietf.org" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-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: Sat, 16 Apr 2016 12:47:39 -0000 Glenn, Thanks for your comments. I've addressed most of your comments in the new r= evision: URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-v= pn-mcast-mib-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-m= cast-mib/ Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-= mib-03 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bess-l2l3-vp= n-mcast-mib-03 Please see below. > 1. Abstract: > 1.1 A sentence on how the managed objects will be used by=20 > applications for operations, monitoring and management=20 > would be good. =20 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 configur= e and/or monitor both L2 and L3 VPN Multicast. >=20 > 2. Introduction > 2.1 Please give the full expansion of the abbreviations=20 > appearing for the first time. (PE, VPLS,..)=20 Fixed. >=20 > 2.2 The terminology section is a bit terse. Explaining the=20 > terms that are used, nicely with reference to the protocol=20 > 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 re= levant technologies. Having said that, I'll explain PMSI a bit further. > 2.3 Is there a difference between=20 > "multicast in Layer 2 and Layer 3 VPNs , defined by > RFC 7117 and RFC 6513/6514"=20 > used in the DESCRIPTION in the MODULE-IDENTITY > and=20 > "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=20 > same expression. If these are not the same, the dictinction=20 > should be clarified. No difference. I was using "Layer 3" or "L3" but it was pointed out that th= e layer 3 VPN is often referred to IP VPN in other RFCs and I was advised t= o 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 c= hange it back. > =20 >=20 > 3. Summary of MIB Module. > An overview of the L2L3-VPN-MCAST-MIB will be good- the=20 > structure of the MIB, short descriptions of the table(s)=20 > including usage of the table(s) for management and/or by=20 > other MIB(s). I had that, but have added one sentence about the only table. >=20 > 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 stricte= st level of validation. I've now fixed the following issues and verified. >=20 > mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named numbe= r `rsvp-p2mp' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: named numbe= r `ldp-p2mp' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: named numbe= r `pim-asm' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: named numbe= r `pim-ssm' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: named numbe= r `pim-bidir' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: named numbe= r `ingress-replication' must not include a hyphen in SMIv2 > mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: named numbe= r `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 `NO= TIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used > mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: identifier `Un= signed32' imported from module `SNMPv2-SMI' is never used > mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: identifier `NO= TIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used > mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier `T= ruthValue' imported from module `SNMPv2-TC' is never used > mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: identifier `R= owStatus' imported from module `SNMPv2-TC' is never used > mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier `T= imeStamp' imported from module `SNMPv2-TC' is never used > mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: identifier `T= imeInterval' imported from module `SNMPv2-TC' is never used > mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: identifier `S= nmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never used > mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier `I= netAddress' imported from module `INET-ADDRESS-MIB' is never used > mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: identifier `I= netAddressType' imported from module `INET-ADDRESS-MIB' is never used Removed the above unused imports. >=20 > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. > Wherever possible, provide references for objects used in=20 > the MIB. The references will point to specific sections/ > sub-sections of the RFCs defining the protocol for which the=20 > MIB is being designed. It will greatly improve the readability=20 > of the document.=20 Added. >=20 > 6. IMPORTS clause > MIB modules from which items are imported must be cited and=20 > included in the normative references. > The conventional style is=20 > mplsStdMIB > FROM MPLS-TC-STD-MIB -- [RFC3811] Added. >=20 > 7. Please update the MODULE-IDENTITY. (There are no syntantic errors.) > 7.1 CONTACT-INFO > Following the conventions (including indentation style) will=20 > improve the readability. (e.g. RFC4382, RFC5132). > Will be good if it does not overflow into the next page. Fixed. > =20 > 7.2 REVISION clause: follow the convention recommended in RFC4181=20 > 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=20 > sec 4.5 i > replace=20 > ::=3D { experimental 99 } -- number to be assigned > by > ::=3D { XXX } > -- RFC Ed.: replace XXX with IANA-assigned number & remove this note=20 > will be the subtree under which the module will be=20 > registered. >=20 I kept "experimental 99" so that I could continue to use mib tools to valid= ate; but I added notes for the editor to replace them as you indicated. >=20 > 8. Specific MO and TC related comments. > L2L3VpnMcastProviderTunnelType ::=3D 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) >=20 > o Would be nice to align the enumeration labels with the=20 > labels in the protocol document RFC 6514 unless there is=20 > a good reason for not doing so. (You will have to take=20 > care of the smi compilation errors too; '-' is not allowed ).=20 Are spaces allowed? I don't know so I used hyphen. For now I replace with t= hings like rsvpP2mp. Or could/should I just remove the definitions, so that if a new type is def= ined in the future there is no need to update the MIB? > =20 > 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').. > =20 > Note that BGP-based signaling may be used for > PIM-MVPN as well." > o Fix the ".." in "'UDP-based Protocol').." above.=20 > o Please give the reference for this Table.=20 > Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? =20 > "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? =20 > both? > Any other pointers? Fixed. >=20 > 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." > ::=3D { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } > o Please confirm that the above is a complete enumeration of the=20 > types of signalling. =20 > o RFC 6514 Sec.5 says that the Flags field indicates > "Leaf Information Required". That is useful information.=20 > Please include in the description. =20 The intent is to simply return the octet value of the flags field, w/o list= ing individual bits like "Leaf Information Required". More bits could be de= fined in the future but the MIB would not change. Is that OK? >=20 > 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 Identi= fier > Field in PMSI Tunnel Attribute of the corresponding I/S-PMS= I > A-D route." > o Check the size specifications. The specs above say it can be=20 > all sizes 0..37. That is not clear from the DESCRIPTION clause.=20 > o Fix the ".." in "(IPv4 or IPv6).." above.=20 > o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel Identifiers > for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress Replication,MP2MP.=20 > It appears that the sizes (range) for each case will be different.= =20 > Please clarify that, and if there are discrete sizes, specify=20 > accordingly.=20 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 j= ust give a size range so that it is flexible. Is that ok? > =20 >=20 > 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.=20 I can give an example, like mplsTunnelTable [RFC 3812]. It could be whateve= r 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, t= hen it exists. > o What will be the behaviour if the above condition is not satisfied? A null pointer should be given. >=20 > 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=20 > this object points to the corresponding row in the ifTable?=20 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= =20 > interface? Null row pointer. >=20 > 9. The Security Considerations section does not follow the Security=20 > Guidelines for IETF MIB Modules=20 > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. > Please fix.=20 I was really hoping that it would not have to be that tedious. SNMP/MIB sec= urity should be no different from the CLI security - once you secure the in= frastructure then what's more to do? I'll need more time to work on this. Let me try to address the issues in th= e other mib first and come back to this. > =20 >=20 > 10.ID-nits > 10.1 Checking nits according to http://www.ietf.org/id-info/checklist : > --------------------------------------------------------------------= ------- > =20 > ** There are 4 instances of too long lines in the document, the long= est one > being 3 characters in excess of 72. I fixed some but there still three too long lines: l2L3VpnMcastPmsiTunnelAttributeType L2L3VpnMcastProviderTunnelType, l2L3VpnMcastGroups OBJECT IDENTIFIER ::=3D {l2L3VpnMcastConformance = 1} l2L3VpnMcastCompliances OBJECT IDENTIFIER ::=3D {l2L3VpnMcastConformance = 2} Should I break them into different lines or just keep them as is? Any examp= le of expected indentation if I break the lines? > =20 > 10.2 Checking references for intended status: Proposed Standard > --------------------------------------------------------------------= ------- > =20 > =3D=3D Missing Reference: 'RFC 7117' is mentioned on line 76, but no= t > defined > 'described in [RFC6513, RFC6514, RFC 7117] and other documents th= a...' I hope I understood and fixed it (removing the space in "RFC 7117"). >=20 > 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. =20 > Is there a good reason for not merging the 2 documents? I have not s= een=20 > 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; Marti= n > Vigoureux ; bess@ietf.org; Mach Chen > > Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.tx= t >=20 > 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 :-) >=20 > The comments are attached. >=20 > Glenn >=20 From nobody Sat Apr 16 06:15: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 4D5D212DFD2; Sat, 16 Apr 2016 06:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 JBYeyiS6JQ9r; Sat, 16 Apr 2016 06:15:23 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7088512DF90; Sat, 16 Apr 2016 06:15:20 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3GDFFnF030326; Sat, 16 Apr 2016 14:15:15 +0100 Received: from 950129200 (79.135.99.37.dsl.gradwelldsl.co.uk [79.135.99.37] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3GDFDls030317 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 16 Apr 2016 14:15:14 +0100 From: "Adrian Farrel" To: Date: Sat, 16 Apr 2016 14:15:09 +0100 Message-ID: <025201d197e2$036356a0$0a2a03e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGX4fhGnlzr1h/0RzGa0v7pyr329A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22264.006 X-TM-AS-Result: No--13.238-10.0-31-10 X-imss-scan-details: No--13.238-10.0-31-10 X-TMASE-MatchedRID: lmH6rhp2L6YR9y8WJPyXEOG5dRZCgxC3QRPZCRdX9cLSYAzZ6KmqWnC9 AyVdCQIhtuNkyoIlwhIRCKHXY1XXLAcSBA/LYDihiUPZPmKZOQmjiNbvNIOD2SNGK7UC7ElMd91 HBZ7FfSun3CoLR87HhZAT+CtY2Up9FaWlXDtMVAO4jAucHcCqnYLsLasl5ROhmr+3kFS/aEMlZN CxOodpvI5QJnWdA+oBNWPYAkCKHy7ANTc0UpB7DoQ6iEG+7EHnvrwC6hEjckW/xUIBoV49Vm8DD 2DFdcraxbxTVHzsS2JGxzgXmrQoiFuaKtrRcKHlAjTI/+6gf4OSXgxCkmWQJzGJJjSDu/oWFrcE JbktXOujHGv1pGJl9SY+GceJKnHQtPyViaiKKqap4G6k2AuBh0MuCEbD2XRNu3gEBpQvABWXqrF 0nhL4j6McWD+ItIvS1hxOHx7BSHvlRxm3A2wKujl/1fD/Gopd2K+lN2ZUJHbEQdG7H66TyH4gKq 42LRYkl4oq0ZN8abhsvW3caqo2/kUcHPk7rqCD6NRqzJbncfp+3BndfXUhXQ== Archived-At: Cc: draft-ietf-bess-service-chaining@ietf.org Subject: [bess] Security considerations for draft-ietf-bess-service-chaining X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 13:15:26 -0000 Thanks to the authors for posting the update to this document. Casting an eye over the text, I would like to make some suggestions for making the document more ready for progression to publication. FWIW, I think the technical content is good and stable, but there is some editorial work needed. Minor edits I'll just send direct to the authors. Things of more substance I'll send to the list. The first (this) is some more substance for the Security Considerations section which I don't think will pass through the IESG in its current state. Cheers, Adrian === OLD 11 Security Considerations The security considerations for SFCs are broadly similar to those concerning the data, control and management planes of any device placed in a network. Details are out of scope for this document. NEW NEW 11 Security Considerations The security of an SFC system as described in this document depend heavily on the security of BGP since attacks on the information distributed by the protocol could result in disruption to or subversion of the service function chain. For example, a chain of security functions could be made to deliver the packets in the flow, but circumnavigate the security functions that were supposed to be applied to the packets. Therefore, the use of the security mechanisms defined for BGP is necessary. BGP runs over TCP and so protection of the TCP messages can provide a high level of protection for the SFC control plane. Security for BGP is discussed in [RFC4271] and [RFC6952]. Traffic flows in an SFC might be considered to be somewhat more vulnerable that in a normal routing system where the service functions are executed in dedicated hardware as "bumps in the wire". In particular, when service functions are provided as generic software for example in a data center, the traffic flows are only as secure as the data center infrastructure and software installations. One might imagine "data replication as a service" being installed without the permission of the network operator or traffic source. However, this class of problem is generic to all SFC systems and not specific to the solution described in this document. It needs to be addressed as part of the SFC infrastructure and does not depend on the security of the protocols used to establish and manage the service function chains themselves. For more details see [sfc-arch]. END ADD Informational Reference [RFC6952] Jethanandani, M., Patel, K., and Zheng, L., "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013. END From nobody Mon Apr 18 15:24:38 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 F002512DFD2 for ; Mon, 18 Apr 2016 15:24:36 -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=unavailable 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 rJAZL_108J_a for ; Mon, 18 Apr 2016 15:24:34 -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 74A9012E572 for ; Mon, 18 Apr 2016 15:24:34 -0700 (PDT) Received: from [192.168.0.93] (cysvpn06.priv.cysol.co.jp [192.168.0.93]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id u3IMOQNq086946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Apr 2016 07:24:27 +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: <57155E95.8010305@cysols.com> Date: Tue, 19 Apr 2016 07:24:21 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Archived-At: Cc: Mach Chen , Martin Vigoureux , "bess@ietf.org" , "ops-ads@ietf.org" Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-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, 18 Apr 2016 22:24:37 -0000 Jeffrey, $B!!!!(BThanks for the update. Will get back to you after a detailed review is done. Glenn 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 > From nobody Thu Apr 21 22:24:26 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 CF80312E027; Thu, 21 Apr 2016 14:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 NqBnonEfTajA; Thu, 21 Apr 2016 14:27:37 -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 BC27F12DC46; Thu, 21 Apr 2016 14:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7689; q=dns/txt; s=iport; t=1461274055; x=1462483655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1TEzp/n/yI1lUGBli7x76rQVKqku8v8PwYibmLFrdMM=; b=H0hkCH3R4i/HrmJIfoNLEooFkqWPNc7PeP7awqjeKjHTAuRQe1tK8jwE BIuNJOTQ1SenCeDrQMaw8U1DwsTzdUmv0x2qI0TLv3FIPnmygXvO85DAi 1g2uHIdbWnCVA6IgmXXPAUVU5tZQWYi1SznbYPvn9zUd6VGJksBk7MnK1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCJRBlX/5BdJa1egziBUAa3aoIPA?= =?us-ascii?q?Q2BdIYOAoEtOBQBAQEBAQEBZSeEQQEBAQMBeRACAQgOAwQBAQEnBzIUCQgCBAE?= =?us-ascii?q?NBRSIDgjAKAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLhA8KBwEchVgBBId0h?= =?us-ascii?q?heFE4RxAY4TgWaETYMphTSPLQEeAQFCggQFFhWBNWyHOQkXH34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,514,1454976000"; d="scan'208";a="96278682" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 21:27:34 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3LLRY4i028976 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Apr 2016 21:27:34 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Apr 2016 16:27:33 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Thu, 21 Apr 2016 16:27:34 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "Benoit Claise (bclaise)" , "joelja@bogus.com" Thread-Topic: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) Thread-Index: AQHRnBSe1N/fnQv93UyfZpEd+XJ70g== Date: Thu, 21 Apr 2016 21:27:34 +0000 Message-ID: References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <570D4C8E.6040800@alcatel-lucent.com> In-Reply-To: <570D4C8E.6040800@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.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 21 Apr 2016 22:24:25 -0700 Cc: "bess-chairs@ietf.org" , "draft-ietf-bess-mvpn-extranet@ietf.org" , 'Eric C Rosen' , "'John G. Scudder'" , Martin Vigoureux , "bess@ietf.org" , 'The IESG' Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) 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, 21 Apr 2016 21:27:39 -0000 Sue: Hi! Can you please take a look at this? Thanks! Alvaro. On 4/12/16, 3:29 PM, "Martin Vigoureux" wrote: >Dear all, > >we took the opportunity of this IETF meeting to discuss with Sue, Joel >and Benoit, and with Eric. > >Sue has had two requests: >1/ to add some text clarifying the encoding and processing of the >Extended Communities this document is defining. >Eric had already integrated this text in the document (v06) and more >specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended >Community) and 4.5 (for the Extranet Separation Extended Community). The >text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the split. > >We have reviewed that with Sue and my understanding of our discussion is >that this is acceptable. > >2/ to add some text covering risks of mis-configurations >Eric has added the paragraph quite soon in the document (the Overview >section), such that the reader is aware. Following Thomas' suggestion to >enhance that text with other cases of incorrect configurations, Eric has >also added some text to the Security Considerations section. >Since the document describes a tool-set, rather than trying to describe >all the possible usages of these tools, the preferred approach was to >give a form of warning on risks of misconf. > >Our understanding is that the addition of this paragraph would meet >Sue's expectations. > >Version 07, which incorporates the above, is available. > >Sue, please review the changes and let us know if our understanding is >correct or not, and thus if you consider your points addressed. > >Thank you all > >Best regards, >Martin & Thomas > >Le 23/12/2015 16:13, Susan Hares a =E9crit : >> Eric: >> >> *To clear my objection to this draft*, please add these sections to make >> it clear what the content of the BGP values and their handling. We >> disagree on what the BGP registry document states, but that point is not >> worth holding up this document. People can find the type and sub-type >> fields in the registry. What is not in the registry is a clear >> description of the restrictions of the value field and handling. >> >> Placing the BGP Extended communities within the rest of the rules is >> just unclear. Please put these two sections in and give the details in >> this sections. >> >> As to the deployment section, you did not consider the text I offer >> below and the suggested insertion in the security section. Perhaps you >> can consider that text in your next email. On whether this deployment >> section is =B3DISCUSS=B2 worthy, I am still communicating with Benoit an= d >>Joel. >> >> I wish you the peace and joy of the Christmas season, >> >> Sue Hares >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Sections which must be added to clear my concerns >> >> ---------------------------------------------------------------- >> >> *4.4.1 Extranet Source Extended Community * >> >> To facilitate this, we define a new Transitive Opaque Extended >> Community, the "Extranet Source" Extended Community. >> >> The value field of this extended community is all zeros. >> >> *Restrictions: *This value field MUST be set to zero upon origination, >> MUST be ignored upon reception and MUST be passed unchanged by >> intermediate routers. >> >> *Additional Restrictions: *A Route Reflector MUST NOT add/remove the >> Extranet Source Extended Community from the VPN-IP routes reflected by >> the Route Reflector, including the case where VPN-IP routes received >> via IBGP are reflected to EBGP peers (inter-AS option (c), see >> [RFC6513] Section 10). >> >> *4.4.2 Extranet Separation Extended community * >> >> ** >> >> We define a new Transitive Opaque Extended Community, the "Extranet >> Separation" Extended Community. This Extended Community is used only >> when extranet separation is being used. >> >> *Restrictions:* Its value field MUST be set to zero upon origination, >> MUST be ignored upon reception, and MUST be >> >> passed unchanged by intermediate routers. >> >> * Restrictions on Adding/deleting this community:* ?? (Eric =AD pleas= e >> add something here). >> >> *Comments that could be put in a Security section: * >> >> ** >> >> Whenever a VPN is provisioned, there is a risk that provisioning errors >> will result in an unintended cross-connection of VPNs, which would >> create a security problem for the customers. Extranet can be >> particularly tricky, as it intentionally cross-connects VPNs, but in a >> manner that is intended to be strictly limited by policy. If one is >> connecting two VPNs that have overlapping address spaces, one has to be >> sure that the inter-VPN traffic isn't to/from the part of the address >> space that is in the overlap. The draft discusses a lot of the corner >> cases, and a lot of the scenarios in which things can go wrong. >> >> *From:*BESS [mailto:bess-bounces@ietf.org] *On Behalf Of *Eric C Rosen >> *Sent:* Tuesday, December 22, 2015 2:08 PM >> *To:* Susan Hares; 'Benoit Claise'; 'The IESG' >> *Cc:* draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; >> aretana@cisco.com; bess-chairs@ietf.org; >> martin.vigoureux@alcatel-lucent.com; bess@ietf.org >> *Subject:* Re: [bess] Benoit Claise's Discuss on >> draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) >> >> On 12/22/2015 12:51 PM, Susan Hares wrote: >> >> Eric: >> >> Thank you for revisions in version -05 of your document. Unfortunately >> it does not resolve either of the two points I raised. >> >> 1)*On the BGP Extended Communities*, I feel your specification is >> *unclear and warrants change on the DISCUSS* Criteria due to >> interoperability issues. >> >> >> I've explained why I don't think this is correct. In particular, I >> don't think it is wise to mention the value of the "Transitive Opaque >> Extended Community Type" codepoint, as this can be found in the IANA >> registry for Transitive Extended Community types, and implementers >> should really be encouraged to consult the registries for the >>codepoints. >> >> >> 2)I=B9ve given you 2 small sections to add to your document at the >> beginning of section 4.4. to resolve this DISCUSS point. >> >> >> Note that the codepoint you mention for Transitive Opaque Extended >> Community Type is not correct. Unnecessary last minute changes do tend >> to introduce errors. >> >> >> 3)You need to just fill in one part below on RR restrictions for >> *Extranet Separation Extended community*. >> >> >> I will add some text saying that RRs must not add or remove this EC. >> >> >> 2) *On the deployment section:* I given text and examples =AD but I thi= nk >> you still misunderstand what I am looking for. >> >> >> Perhaps. >> >> >> Since you are an author of academic papers, >> >> >> I am not. >> >> >> consider I am looking for an operator-based =B3abstract=B2 that focuses = the >> reader on the key points.I am sure you can create one for this document, >> but I not clear why you object to it the concept. >> >> >> It seems to me that you are asking for something that could be titled >> "An Operator's Guide to Provisioning Extranet MVPN". While that might >> be useful, it is not within the scope of the current document. As I've >> said, I am not aware of any IETF requirement that requires such a thing >> to be included. >> >> >> will you please let me know that you have read my suggested text >> insertions on both these topics. >> >> >> I have. >> >> >> >> >> >> >> From nobody Fri Apr 22 00:31:36 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2F612DEC5; Fri, 22 Apr 2016 00:31:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422073135.7658.28317.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 00:31:35 -0700 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Benoit Claise's No Objection on draft-ietf-bess-mvpn-extranet-07: (with COMMENT) 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, 22 Apr 2016 07:31:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-bess-mvpn-extranet-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial suggestions: Summary: In general the authors provide dense English text to describe this rules. In general the English text contains valid complex sentences. However, a few things should be suggested: 1) PTA – define it in a definition section or spell out the abbreviation 2) Phrases like “the RT RT-R” become overly dense. Use “Route Target RT-R”. 3) Breaking up section 6.2.1 – with subjection and subtitles would make it more readable, 4) P. 36 second paragraph. The reason for the “MUST” in 1st full paragraph is a bit vague. It seems logical, but the reasoning is just vague in the text. 5) paragraph 2 in page 47 (section 7.3.1) is awkward, please reword. 6) Paragraph 5 in page 47 (section 7.3.1) – does not explain why the condition should hold. The authors have done this in eac other case, so it seems inconsistent. 7) Page 53 – section 7.4.5 paragraph 3 “VRF route Import EC” – please spell out first usage and give abbreviation (VRF Route Import Extended Community (EC). From nobody Fri Apr 22 13:23:47 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 35D7612E25B; Fri, 22 Apr 2016 12:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 sRXWdHTY4bn4; Fri, 22 Apr 2016 12:57:27 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0BA6D12E392; Fri, 22 Apr 2016 12:57:26 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.77; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'Benoit Claise \(bclaise\)'" , References: <20151217133049.1038.44405.idtracker@ietfa.amsl.com> <56741869.5020505@juniper.net> <00af01d139c6$898fb720$9caf2560$@ndzh.com> <567859EC.6030103@juniper.net> <006101d13ce1$725cd650$571682f0$@ndzh.com> <56799F9F.4010907@juniper.net> <000d01d13d94$80868a10$81939e30$@ndzh.com> <570D4C8E.6040800@alcatel-lucent.com> In-Reply-To: Date: Fri, 22 Apr 2016 15:57:02 -0400 Message-ID: <00e001d19cd1$242b2400$6c816c00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01D19CAF.9D1E17E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLS05QNmCOjnF9/ygy/QKz2M1D3eQInyoXdAa7znfEBVAvt0wHDkPeBAtg1BY8CZOkRNAHQgax6AoCZZi6dEAqIMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 22 Apr 2016 13:23:43 -0700 Cc: bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, 'Eric C Rosen' , "'John G. Scudder'" , 'Martin Vigoureux' , bess@ietf.org, 'The IESG' Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) 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, 22 Apr 2016 19:57:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E1_01D19CAF.9D1E17E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alvaro:=20 =20 There were two portions to my comment: Deployment considerations and easily found BGP-Community definitions. The text fits 95% of my desired work. I have two small suggested changes in each category. I have included these below. I can live with either of these suggested changes being rejected.=20 =20 I asked John Scudder (my IDR Co-chair) regarding the textural flow in = this document. John seems to follow Eric=92s writing style with ease. You = might want to pass the textual change for deployments I suggested below by = John as well as Thomas and Martin. It may also be useful for to have John = Scudder read through the text to make sure we have not damaged Eric=92s flow and style. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Deployment considerations:=20 =20 The text reads a bit harsh now in the "VPN security violations", and may = I suggest the following addition in=20 Paragraph 12. =20 =20 /Old We use the term "VPN security violation" to refer to any situation = in which a packet is delivered to a particular VPN, even though, by policy, it should not be delivered to that VPN. / =20 New=20 /We use the term "VPN security violation" to refer to any situation in which a packet is delivered to a particular VPN, even though, by policy, it should not be delivered to that VPN. =20 A bit of context on VPN technology may put the=20 "VPN security violation" in context. Any application=20 of the technology based on [RFC4364] requires=20 that an operator pay special=20 attention to configurations of RTs, any manual configuration of VRFs, and the=20 intended data paths.=20 Please see the section 9 on security=20 considerations for additional details. =20 / =20 Clearly Distinguishable BGP Communities:=20 =20 Could I suggest just one white space changes to version 7 for the BGP Aspect? =20 =20 Section 4.4.1=20 =20 Old/ To facilitate this, we define a new Transitive Opaque Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document) the "Extranet Source" Extended Community. When a CE router advertises (via BGP) a route to a PE router, and the AFI/SAFI of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source Extended Community MAY be attached to the route. The value field of the Extended Community MUST be set to zero. By placing this Extended Community on a particular route, a CE router indicates to a PE router that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied to that route. That is, the CE router may use this Extended Community to indicate to the PE router that a particular route is to be treated as a route that matches the address of an extranet source, and exported accordingly to other VPNs. A PE router that interprets this Extended Community MUST ignore the contents of the value field. / New/=20 To facilitate this, we define a new Transitive Opaque Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document) the "Extranet Source" Extended Community. When a CE router advertises (via BGP) a route to a PE router, and the AFI/SAFI of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source Extended Community MAY be attached to the route. The value field of the Extended Community MUST be set to zero.=20 =20 By placing this Extended Community on a particular route, a CE router indicates to a PE router that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied to that route. That is, the CE router may use this Extended Community to indicate to the PE router that a particular route is to be treated as a route that matches the address of an extranet source, and exported accordingly to other VPNs. A PE router that interprets this Extended Community MUST ignore the contents of the value field. / =20 This add white-space with textual change, but a spacing helps the person easily see the definition of the extended community.=20 =20 Sue=20 =20 -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Thursday, April 21, 2016 5:28 PM To: Susan Hares; Benoit Claise (bclaise); joelja@bogus.com Cc: 'Eric C Rosen'; draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; bess-chairs@ietf.org; bess@ietf.org; Martin Vigoureux; 'The = IESG' Subject: Re: [bess] Benoit Claise's Discuss on draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) =20 Sue: =20 Hi! Can you please take a look at this? =20 Thanks! =20 Alvaro. =20 On 4/12/16, 3:29 PM, "Martin Vigoureux" < martin.vigoureux@nokia.com> wrote: =20 >Dear all, >=20 >we took the opportunity of this IETF meeting to discuss with Sue, Joel=20 >and Benoit, and with Eric. >=20 >Sue has had two requests: >1/ to add some text clarifying the encoding and processing of the=20 >Extended Communities this document is defining. >Eric had already integrated this text in the document (v06) and more=20 >specifically in Sections 4.4.1, 4.4.2 (for the Extranet Source Extended >Community) and 4.5 (for the Extranet Separation Extended Community).=20 >The text on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the split. >=20 >We have reviewed that with Sue and my understanding of our discussion=20 >is that this is acceptable. >=20 >2/ to add some text covering risks of mis-configurations Eric has added = >the paragraph quite soon in the document (the Overview section), such=20 >that the reader is aware. Following Thomas' suggestion to enhance that=20 >text with other cases of incorrect configurations, Eric has also added=20 >some text to the Security Considerations section. >Since the document describes a tool-set, rather than trying to describe = >all the possible usages of these tools, the preferred approach was to=20 >give a form of warning on risks of misconf. >=20 >Our understanding is that the addition of this paragraph would meet=20 >Sue's expectations. >=20 >Version 07, which incorporates the above, is available. >=20 >Sue, please review the changes and let us know if our understanding is=20 >correct or not, and thus if you consider your points addressed. >=20 >Thank you all >=20 >Best regards, >Martin & Thomas >=20 >Le 23/12/2015 16:13, Susan Hares a =E9crit : >> Eric: >>=20 >> *To clear my objection to this draft*, please add these sections to = make >> it clear what the content of the BGP values and their handling. We >> disagree on what the BGP registry document states, but that point is=20 >> not worth holding up this document. People can find the type and=20 >> sub-type fields in the registry. What is not in the registry is a=20 >> clear description of the restrictions of the value field and = handling. >>=20 >> Placing the BGP Extended communities within the rest of the rules is=20 >> just unclear. Please put these two sections in and give the details=20 >> in this sections. >>=20 >> As to the deployment section, you did not consider the text I offer =20 >>below and the suggested insertion in the security section. Perhaps=20 >>you can consider that text in your next email. On whether this=20 >>deployment section is =B3DISCUSS=B2 worthy, I am still communicating = with=20 >>Benoit and Joel. >>=20 >> I wish you the peace and joy of the Christmas season, >>=20 >> Sue Hares >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Sections which must be added to clear my concerns >>=20 >> ---------------------------------------------------------------- >>=20 >> *4.4.1 Extranet Source Extended Community * >>=20 >> To facilitate this, we define a new Transitive Opaque Extended=20 >> Community, the "Extranet Source" Extended Community. >>=20 >> The value field of this extended community is all zeros. >>=20 >> *Restrictions: *This value field MUST be set to zero upon = origination, >> MUST be ignored upon reception and MUST be passed unchanged by=20 >> intermediate routers. >>=20 >> *Additional Restrictions: *A Route Reflector MUST NOT add/remove the=20 >> Extranet Source Extended Community from the VPN-IP routes reflected=20 >> by the Route Reflector, including the case where VPN-IP routes=20 >> received via IBGP are reflected to EBGP peers (inter-AS option (c), = see >> [RFC6513] Section 10). >>=20 >> *4.4.2 Extranet Separation Extended community * >>=20 >> ** >>=20 >> We define a new Transitive Opaque Extended Community, the "Extranet=20 >> Separation" Extended Community. This Extended Community is used only = >> when extranet separation is being used. >>=20 >> *Restrictions:* Its value field MUST be set to zero upon=20 >> origination, MUST be ignored upon reception, and MUST be >>=20 >> passed unchanged by intermediate routers. >>=20 >> * Restrictions on Adding/deleting this community:* ?? (Eric =AD=20 >> please add something here). >>=20 >> *Comments that could be put in a Security section: * >>=20 >> ** >>=20 >> Whenever a VPN is provisioned, there is a risk that provisioning=20 >> errors will result in an unintended cross-connection of VPNs, which=20 >> would create a security problem for the customers. Extranet can be=20 >> particularly tricky, as it intentionally cross-connects VPNs, but in=20 >> a manner that is intended to be strictly limited by policy. If one=20 >> is connecting two VPNs that have overlapping address spaces, one has=20 >> to be sure that the inter-VPN traffic isn't to/from the part of the=20 >> address space that is in the overlap. The draft discusses a lot of=20 >> the corner cases, and a lot of the scenarios in which things can go wrong. >>=20 >> *From:*BESS [ mailto:bess-bounces@ietf.org] *On Behalf Of *Eric C=20 >> Rosen >> *Sent:* Tuesday, December 22, 2015 2:08 PM >> *To:* Susan Hares; 'Benoit Claise'; 'The IESG' >> *Cc:* draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder';=20 >> aretana@cisco.com; bess-chairs@ietf.org;=20 >> martin.vigoureux@alcatel-lucent.com; = bess@ietf.org >> *Subject:* Re: [bess] Benoit Claise's Discuss on >> draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT) >>=20 >> On 12/22/2015 12:51 PM, Susan Hares wrote: >>=20 >> Eric: >>=20 >> Thank you for revisions in version -05 of your document. =20 >> Unfortunately it does not resolve either of the two points I raised. >>=20 >> 1)*On the BGP Extended Communities*, I feel your specification is=20 >> *unclear and warrants change on the DISCUSS* Criteria due to=20 >> interoperability issues. >>=20 >>=20 >> I've explained why I don't think this is correct. In particular, I =20 >>don't think it is wise to mention the value of the "Transitive Opaque = >>Extended Community Type" codepoint, as this can be found in the IANA =20 >>registry for Transitive Extended Community types, and implementers =20 >>should really be encouraged to consult the registries for the=20 >>codepoints. >>=20 >>=20 >> 2)I=B9ve given you 2 small sections to add to your document at the=20 >> beginning of section 4.4. to resolve this DISCUSS point. >>=20 >>=20 >> Note that the codepoint you mention for Transitive Opaque Extended=20 >> Community Type is not correct. Unnecessary last minute changes do=20 >> tend to introduce errors. >>=20 >>=20 >> 3)You need to just fill in one part below on RR restrictions for=20 >> *Extranet Separation Extended community*. >>=20 >>=20 >> I will add some text saying that RRs must not add or remove this EC. >>=20 >>=20 >> 2) *On the deployment section:* I given text and examples =AD but I=20 >> think you still misunderstand what I am looking for. >>=20 >>=20 >> Perhaps. >>=20 >>=20 >> Since you are an author of academic papers, >>=20 >>=20 >> I am not. >>=20 >>=20 >> consider I am looking for an operator-based =B3abstract=B2 that = focuses=20 >> the reader on the key points.I am sure you can create one for this=20 >> document, but I not clear why you object to it the concept. >>=20 >>=20 >> It seems to me that you are asking for something that could be titled = >> "An Operator's Guide to Provisioning Extranet MVPN". While that=20 >> might be useful, it is not within the scope of the current document. = >> As I've said, I am not aware of any IETF requirement that requires=20 >> such a thing to be included. >>=20 >>=20 >> will you please let me know that you have read my suggested text=20 >> insertions on both these topics. >>=20 >>=20 >> I have. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 =20 ------=_NextPart_000_00E1_01D19CAF.9D1E17E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Alvaro: =

 

There were two=A0 portions to my comment:=A0 = Deployment considerations and easily found BGP-Community definitions. = =A0The text fits 95% of my desired work.=A0 I have two small suggested = changes in each category.=A0 =A0I have included these below. =A0I can = live with either of these suggested changes being rejected. =

 

I asked John Scudder (my IDR Co-chair) regarding = the textural flow in this document.=A0=A0 John seems to follow = Eric’s writing style with ease.=A0 You might want to pass the = textual change for deployments I suggested below by John as well as = Thomas and Martin.=A0 =A0It may also be useful for to have John Scudder = read through the text to make sure we have not damaged Eric’s flow = and style.=A0 =A0=A0

=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Deployment considerations:

 

The = text reads a bit harsh now in the "VPN security violations", = and may I suggest the following addition in

Paragraph 12.=A0

 

/Old = We use the term "VPN security violation" to refer to any = situation in

which a packet is = delivered to a particular VPN, even though, by

policy, it should not be delivered to that = VPN.

/

 

New =

/We use the term "VPN = security violation" to refer to any situation in

which a packet is delivered to a particular VPN, = even though, by

policy, it should = not be delivered to that VPN.

 

A bit = of context on VPN technology may put the

"VPN security violation" in context.=A0 = Any application

of the technology = based on=A0 [RFC4364] requires

that an operator pay special

attention to configurations of = RTs,

any manual configuration of = VRFs, and the

intended data = paths.

Please see the section 9 = on security

considerations for = additional details.=A0

/

 

Clearly Distinguishable BGP Communities: =

 

Could I suggest just one white space changes to = version 7 for the BGP Aspect? =A0

 

Section 4.4.1

 

Old/

=A0 To = facilitate this, we define a new Transitive Opaque = Extended

=A0=A0 Community (see = [RFC4360], [RFC7153], and Section 9 of this document)

=A0=A0 the "Extranet Source" Extended = Community.=A0 When a CE router

=A0=A0 advertises (via BGP) a route to a PE router, = and the AFI/SAFI of the

=A0=A0 = route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet = Source

=A0=A0 Extended Community = MAY be attached to the route.=A0 The value field of

=A0=A0 the Extended Community MUST be set to = zero.=A0 By placing this Extended

=A0=A0 Community on a particular route, a CE router = indicates to a PE router

=A0=A0 = that the procedures of Sections 4.1, 4.2, and 4.3 are to be = applied

=A0=A0to that route.=A0 = That is, the CE router may use this Extended

=A0=A0 Community to indicate to the PE router that = a particular route is to

=A0=A0 be = treated as a route that matches the address of an extranet = source,

=A0=A0 and exported = accordingly to other VPNs.=A0 A PE router that = interprets

=A0=A0 this Extended = Community MUST ignore the contents of the value field.

/

New/ =

=A0=A0To facilitate this, we = define a new Transitive Opaque Extended

=A0=A0 Community (see [RFC4360], [RFC7153], and = Section 9 of this document)

=A0=A0 = the "Extranet Source" Extended Community.=A0 When a CE = router

=A0=A0 advertises (via BGP) = a route to a PE router, and the AFI/SAFI of the

=A0=A0 route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, = the Extranet Source

=A0=A0 = Extended Community MAY be attached to the route.=A0 The value field = of

=A0=A0 the Extended Community = MUST be set to zero.

 

=A0 = =A0By placing this Extended Community on a particular route, a CE router = indicates to a PE router

=A0=A0 = that the procedures of Sections 4.1, 4.2, and 4.3 are to be = applied

=A0=A0 to that route.=A0 = That is, the CE router may use this Extended

=A0=A0 Community to indicate to the PE router that = a particular route is to

=A0=A0 be = treated as a route that matches the address of an extranet = source,

=A0=A0 and exported = accordingly to other VPNs.=A0 A PE router that = interprets

=A0=A0 this Extended = Community MUST ignore the contents of the value field.

/

 

This = add white-space with textual change, but a spacing helps the person = easily see the definition of the extended community.

 

Sue =

 

-----Original Message-----
From: Alvaro Retana = (aretana) [mailto:aretana@cisco.com]
Sent: Thursday, April 21, 2016 = 5:28 PM
To: Susan Hares; Benoit Claise (bclaise); = joelja@bogus.com
Cc: 'Eric C Rosen'; = draft-ietf-bess-mvpn-extranet@ietf.org; 'John G. Scudder'; = bess-chairs@ietf.org; bess@ietf.org; Martin Vigoureux; 'The = IESG'
Subject: Re: [bess] Benoit Claise's Discuss on = draft-ietf-bess-mvpn-extranet-04: (with DISCUSS and COMMENT)

 

Sue:

 

Hi!=A0 = Can you please take a look at this?

 

Thanks!

 

Alvaro.

 

On = 4/12/16, 3:29 PM, "Martin Vigoureux" <martin.vigoureux@nokia.co= m> wrote:

 

>Dear all,

> 

>we took the opportunity of this IETF meeting to = discuss with Sue, Joel

>and = Benoit, and with Eric.

> 

>Sue has had two requests:

>1/ to add some text clarifying the encoding and = processing of the

>Extended = Communities this document is defining.

>Eric had already integrated this text in the = document (v06) and more

>specifically in Sections 4.4.1, 4.4.2 (for the = Extranet Source Extended

>Community) and 4.5 (for the Extranet Separation = Extended Community).

>The text = on RR fitted more naturally in 4.4.2 than in 4.4.1, thus the = split.

> 

>We have reviewed that with Sue and my = understanding of our discussion

>is that this is acceptable.

> 

>2/ to add some text covering risks of = mis-configurations Eric has added

>the paragraph quite soon in the document (the = Overview section), such

>that = the reader is aware. Following Thomas' suggestion to enhance that =

>text with other cases of = incorrect configurations, Eric has also added

>some text to the Security Considerations = section.

>Since the document = describes a tool-set, rather than trying to describe

>all the possible usages of these tools, the = preferred approach was to

>give a form of warning on risks of = misconf.

> 

>Our understanding is that the addition of this = paragraph would meet

>Sue's = expectations.

> 

>Version 07, which incorporates the above, is = available.

> 

>Sue, please review the changes and let us know = if our understanding is

>correct or not, and thus if you consider your = points addressed.

> 

>Thank you all

> 

>Best regards,

>Martin & Thomas

> 

>Le 23/12/2015 16:13, Susan Hares a =E9crit = :

>> Eric:

>> 

>> *To clear my objection to this draft*, = please add these sections to make

>> it clear what the content of the BGP = values and their handling.=A0=A0=A0 We

>> disagree on what the BGP registry document = states, but that point is

>> not worth holding up this document.=A0 = People can find the type and

>> sub-type fields in the registry.=A0 What = is not in the registry is a

>> clear description of the restrictions of = the value field and handling.

>> 

>> Placing the BGP Extended communities = within the rest of the rules is

>> just unclear. Please put these two = sections in and give the details

>> in this sections.

>> 

>> As to the deployment section, you did not = consider the text I offer=A0

>>below and the suggested insertion in the = security section.=A0 Perhaps

>>you=A0 can consider that text in your next = email.=A0 On whether this

>>deployment=A0 section is =B3DISCUSS=B2 = worthy, I am still communicating with

>>Benoit and Joel.

>> 

>> I wish you the peace and joy of the = Christmas season,

>> 

>> Sue Hares

>> 

>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>> 

>> Sections which must be added to clear my = concerns

>> 

>> = ----------------------------------------------------------------

>> 

>> *4.4.1 Extranet Source Extended Community = *

>> 

>>=A0=A0=A0=A0 To facilitate this, we define = a new Transitive Opaque Extended

>> Community, the "Extranet Source" = Extended Community.

>> 

>>=A0=A0=A0=A0 The value field of this = extended community is all zeros.

>> 

>> *Restrictions: *This value field MUST be = set=A0 to zero upon origination,

>>=A0=A0 MUST be ignored upon reception and = MUST=A0 be passed unchanged by

>> intermediate routers.

>> 

>> *Additional Restrictions: *A Route = Reflector MUST NOT add/remove the

>> Extranet Source Extended=A0 Community from = the VPN-IP routes reflected

>> by the Route Reflector,=A0 including the = case where VPN-IP routes

>> = received via IBGP are reflected to EBGP peers (inter-AS option (c), = see

>> [RFC6513]=A0=A0 = Section 10).

>> 

>> *4.4.2 Extranet Separation Extended = community *

>> 

>> **

>> 

>> We define a new Transitive Opaque Extended = Community, the "Extranet

>> Separation" Extended Community.=A0 = This Extended Community is used only

>> when extranet separation is being = used.

>> 

>> *Restrictions:*=A0 Its value field MUST be = set to zero upon

>> = origination, MUST be ignored upon reception, and MUST = be

>> 

>>=A0=A0=A0=A0 passed unchanged by = intermediate routers.

>> 

>> *=A0 Restrictions on Adding/deleting this = community:*=A0 ??=A0 (Eric =AD

>> please add something = here).

>> 

>> *Comments that could be put in a Security = section: *

>> 

>> **

>> 

>> Whenever a VPN is provisioned, there is a = risk that provisioning

>> = errors will result in an unintended cross-connection of VPNs, which =

>> would create a security = problem for the customers.=A0 Extranet can be

>> particularly tricky, as it intentionally = cross-connects VPNs, but in

>> a manner that is intended to be strictly = limited by policy.=A0 If one

>> is connecting two VPNs that have = overlapping address spaces, one has

>> to be sure that the inter-VPN traffic = isn't to/from the part of the

>> address space that is in the overlap.=A0 = The draft discusses a lot of

>> the corner cases, and a lot of the = scenarios in which things can go wrong.

>> 

>> *From:*BESS [mailto:bess-bounces@ietf.= org] *On Behalf Of *Eric C

>> Rosen

>> *Sent:* Tuesday, December 22, 2015 2:08 = PM

>> *To:* Susan Hares; = 'Benoit Claise'; 'The IESG'

>> *Cc:* draft-ietf-bess-mvpn-extr= anet@ietf.org; 'John G. Scudder';

>> aretana@cisco.com<= /a>; bess-chairs@ietf.org;

>> martin.vigoureux@alcatel-= lucent.com; bess@ietf.org<= o:p>

>> *Subject:* Re: [bess] = Benoit Claise's Discuss on

>> draft-ietf-bess-mvpn-extranet-04: (with = DISCUSS and COMMENT)

>> 

>> On 12/22/2015 12:51 PM, Susan Hares = wrote:

>> 

>> Eric:

>> 

>> Thank you for revisions in version -05 of = your document.=A0

>> = Unfortunately it does not resolve either of the two points I = raised.

>> 

>> 1)*On the BGP Extended Communities*, I = feel your specification is

>> *unclear and warrants change on the = DISCUSS* Criteria due to

>> = interoperability issues.

>> 

>> 

>> I've explained why I don't think this is = correct.=A0 In particular, I=A0

>>don't think it is wise to mention the value = of the "Transitive Opaque=A0

>>Extended Community Type" codepoint, as = this can be found in the IANA=A0

>>registry for Transitive Extended Community = types, and implementers=A0

>>should really be encouraged to consult the = registries for the

>>codepoints.

>> 

>> 

>> 2)I=B9ve given you 2 small sections to add = to your document at the

>> = beginning of section 4.4. to resolve this DISCUSS = point.

>> 

>> 

>> Note that the codepoint you mention for = Transitive Opaque Extended

>> Community Type is not correct.=A0 = Unnecessary last minute changes do

>> tend to introduce errors.

>> 

>> 

>> 3)You need to just fill in one part below = on RR restrictions for

>> = *Extranet Separation Extended community*.

>> 

>> 

>> I will add some text saying that RRs must = not add or remove this EC.

>> 

>> 

>> 2) *On the deployment section:*=A0 I given = text and examples =AD but I

>> think you still misunderstand what I am = looking for.

>> 

>> 

>> Perhaps.

>> 

>> 

>> Since you are an author of academic = papers,

>> 

>> 

>> I am not.

>> 

>> 

>> consider I am looking for an = operator-based =B3abstract=B2 that focuses

>> the reader on the key points.I am sure you = can create one for this

>> = document, but I not clear why you object to it the = concept.

>> 

>> 

>> It seems to me that you are asking for = something that could be titled

>> "An Operator's Guide to Provisioning = Extranet MVPN".=A0 While that

>> might be useful, it is not within the = scope of the current document.=A0

>> As I've said, I am not aware of any IETF = requirement that requires

>> such a thing to be = included.

>> 

>> 

>> will you please let me know that you have = read my suggested text

>> = insertions on both these topics.

>> 

>> 

>> I have.

>> 

>> 

>> 

>> 

>> 

>> 

>> 

 

------=_NextPart_000_00E1_01D19CAF.9D1E17E0-- From nobody Fri Apr 22 13:33:36 2016 Return-Path: X-Original-To: bess@ietf.org Delivered-To: bess@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AC12DE6E; Fri, 22 Apr 2016 13:33:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422203332.7710.71836.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 13:33:32 -0700 Archived-At: Cc: aretana@cisco.com, bess-chairs@ietf.org, draft-ietf-bess-mvpn-extranet@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org Subject: [bess] Joel Jaeggli's No Objection on draft-ietf-bess-mvpn-extranet-07: (with COMMENT) 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, 22 Apr 2016 20:33:33 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-bess-mvpn-extranet-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the frank discussion in buenos Aires and the proposed edits. I think they address the concerns raised in the opsdir review. was: Discuss Sue Hares performed the opsdir review. benoit holds the discuss for the points she raised. Status: Not ready, three major concerns and two editorial nits: Major concerns: 1) Specification of the Extranet Source Extended Community and Extra Source extended Community Please provide the type of detail as show in RFC 4360 sections 3.1, 3.2, and 3.3. was discuss After further discussion related to the ops dir review, I'm going to have to echo Benoit and the Opsdir reviewers concern. 2) Why is there no Deployment considerations section? The whole draft is a set of rules for handling policy, BGP A-D routes, tunnel set-up, and PIM Join/leaves in the case of an intra net. Unless these rules are followed exactly, traffic may flow into a VPN it is not suppose to. If the customer and the SP must coordinate on setting up filters, the procedure is outside the document. An error in any of these set-ups is considered a “security violation”. Milo Medin stated “with enough trust” a rock can fly to the moon. However, the NASA flights were fragile and risky. In the journey to the moon, there was no other choice. Instrumentation has 4-5 backups. In this set-up, one has to ask “is there another choice” to this whole design that seem fragile addition of extranets to an intra-AS multicast design. If the design is not fragile, then there should be a deployment section indicating how to manage the RTs, RDs, and policy set-up. Perhaps experience with the Intra-As has shown deployment tips that would make this less fragile. If so, it would be good to include an operations consideration section. If a new class of tools provides monitoring or provisioning, mentioning these would be useful. If yang modules are being developed, that would be useful. Places that indicate issues with violated constraint: p. 11, 12, 19 (2.3.2 – a priori knowledge, inability to detect), , p. 25 last paragraph (violation of constraints will cause things to not work. However, only policy can control), p. 27 4.2.2 (1st paragraph, Route Reflector must not change), p. 31 (5.1, first paragraph), 3) Is security section really a security section? It seems more like “do this policy” or this will fail. It should get a stronger review from the security directorate From nobody Fri Apr 22 15:58: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 487C112DDA1; Fri, 22 Apr 2016 15:57:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422225756.7610.28883.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 15:57:56 -0700 Archived-At: Cc: draft-ietf-bess-mvpn-extranet@ietf.org, The IESG , aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, rfc-editor@rfc-editor.org Subject: [bess] Protocol Action: 'Extranet Multicast in BGP/IP MPLS VPNs' to Proposed Standard (draft-ietf-bess-mvpn-extranet-07.txt) X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.17 List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 22:57:57 -0000 The IESG has approved the following document: - 'Extranet Multicast in BGP/IP MPLS VPNs' (draft-ietf-bess-mvpn-extranet-07.txt) as Proposed Standard This document is the product of the BGP Enabled ServiceS Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/ Technical Summary This Document specifies procedures enabling for multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is referred to as "extranet MVPN" Working Group Summary Nothing worth noting. The consensus is solid, specially among the people who have reviewed the document. Document Quality The Document Shepherd is aware of two implementations. In general I found the document (relatively) not hard to follow, if you read it end-to-end — it may be harder for someone to jump in and read/review a specific section without the benefit of building up to it. Since its first version the Document has received attention from several reviewers which are acknowledged. Personnel Martin Vigoureux is the Document Shepherd Alvaro Retana is the Responsible AD From nobody Sun Apr 24 09:32:18 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 C9C0C12B02B; Sun, 24 Apr 2016 09:32:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160424163216.6978.75575.idtracker@ietfa.amsl.com> Date: Sun, 24 Apr 2016 09:32:16 -0700 Archived-At: Cc: draft-ietf-bess-pta-flags@ietf.org, aretana@cisco.com, martin.vigoureux@nokia.com, bess-chairs@ietf.org, bess@ietf.org Subject: [bess] Alexey Melnikov's No Objection on draft-ietf-bess-pta-flags-02: (with COMMENT) 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, 24 Apr 2016 16:32:17 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-bess-pta-flags-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Can you please clarify how extended flags are encoded on the wire? I don't think this is clear from the document. From nobody Mon Apr 25 23:58: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 7E81512B044 for ; Mon, 25 Apr 2016 23:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POidRifjPnD7 for ; Mon, 25 Apr 2016 23:58:20 -0700 (PDT) Received: from BLU004-OMC1S28.hotmail.com (blu004-omc1s28.hotmail.com [65.55.116.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6E61200A0 for ; Mon, 25 Apr 2016 23:58:20 -0700 (PDT) Received: from BLU436-SMTP154 ([65.55.116.8]) by BLU004-OMC1S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 25 Apr 2016 23:58:19 -0700 X-TMN: [g0jcdhWC2IwQ0NllCHr+FmW/zHWivogz7Az4kw1K5yc=] X-Originating-Email: [li_zhenqiang@hotmail.com] Message-ID: Date: Tue, 26 Apr 2016 14:58:18 +0800 From: "li_zhenqiang@hotmail.com" To: thomas.morin , bess References: <5706D4BA.9060908@orange.com>, , <570E3FCF.4000408@orange.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_001_NextPart828251638771_=----" X-OriginalArrivalTime: 26 Apr 2016 06:58:18.0820 (UTC) FILETIME=[037B4040:01D19F89] Archived-At: Subject: [bess] Do 4PE routers need both IPv4 and IPv6 next hop information? 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, 26 Apr 2016 06:58:22 -0000 ------=_001_NextPart828251638771_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIEV2ZXJ5b25lLA0KDQpBcyB0YWxrZWQgaW4gSUVURiA5NSBtZWV0aW5nIGluIEJ1ZW5vcyBB aXJlcywgYW5kIHN1Z2dlc3RlZCBieSBvdXIgQ2hhaXJzLCBJIHdhbnQgdG8ga25vdyB5b3VyIG9w aW5pb24sIGVzcGVjaWFsbHkgdGhlIGV4cGVydHMgZnJvbSB0aGUgdmVuZG9ycywgYWJvdXQgNFBF IHJvdXRlcnMuDQpEbyA0UEUgcm91dGVycyBuZWVkIGJvdGggSVB2NCBhbmQgSVB2NiBuZXh0IGhv cCBpbmZvcm1hdGlvbiB0byBpbnN0YWxsIHRoZWlyIElQdjQgYW5kIElQdjYgcm91dGluZyB0YWJs ZXMgd2hlbiB0aGV5IHJlY2VpdmUgSVB2NCByb3V0ZXMgZnJvbSBvdGhlciA0UEUgcm91dGVycz8g T3IgdGhleSBvbmx5IG5lZWQgSVB2NiBuZXh0IGhvcCBpbmZvcm1hdGlvbj8NCg0KU2luY2UgUkZD NTU0OSBjYW4gb25seSBjb252ZXkgSVB2NCBvciBJUHY2IG5leHQgaG9wIGZvciBJUHY0IHJvdXRl cywgYnV0IG5vdCBib3RoLCBJIHN1Ym1pdCBkcmFmdCBkcmFmdC1saS1iZXNzLTRwZSB0byBzb2x2 ZSB0aGlzIHByb2JsZW0uIDRQRSBJIHRoaW5rIGlzIGEgc2NlbmFyaW8gZm9yIG15IGRyYWZ0LiBB bnkgb3RoZXIgc2NlbmFyaW9lcyB0aGF0IG5lZWQgYm90aCBJUHY0IGFuZCBJUHY2IG5leHQgaG9w cz8NCg0KRm9yIHlvdXIgcmVmZXJlbmNlLCBSRkM1NTQ5IGlzIGhlcmUsIGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL3JmYy9yZmM1NTQ5LnR4dCwgZHJhZnQtbGktYmVzcy00cGUgaXMgaGVyZSwg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGktYmVzcy00cGUtMDEudHh0DQoNClRoYW5r IHlvdSB2ZXJ5IG11Y2gNCg0KDQoNCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbQ0KIA0KRnJvbTog VGhvbWFzIE1vcmluDQpEYXRlOiAyMDE2LTA0LTEzIDIwOjQ3DQpUbzogbGlfemhlbnFpYW5nQGhv dG1haWwuY29tOyBiZXNzDQpTdWJqZWN0OiBSZTogW2Jlc3NdIG1pbnV0ZXMgb2Ygb3VyIElFVEYg OTUgbWVldGluZw0KSGksDQoNCkkndmUgdXBkYXRlZCB0aGUgbWludXRlcy4NClRoYW5rcyBmb3Ig dGhlIHByZWNpc2lvbi4NCg0KQmV5b25kIHRoaXMgbWludXRlIGFkanVzdG1lbnQsIEkgdW5kZXJz dGFuZCB0aGF0IHRoZSBrZXkgdGhpbmcgeW91IG5lZWQgdG8gY2xhcmlmeSBpcyB3aGF0IGlzIG1p c3Npbmcgb3IgcHJvYmxlbWF0aWMgaW4gUkZDNTU0OS4NCg0KVGhhbmsgeW91LA0KDQotVGhvbWFz DQoNCg0KMjAxNi0wNC0xMywgbGlfemhlbnFpYW5nQGhvdG1haWwuY29tOg0KZm9yIGRyYWZ0LWxp LWJlc3MtNHBlLTAxOg0KUGxlYXNlIGFkZCBteSByZXNwb25zZSB0byBjb21tZW50cyBmcm9tIEtl eXVyIGFuZCBXaW06IDRQRSByb3V0ZXJzIG5lZWQgSVB2NCBuZXh0IGhvcCBpbmZvcm1hdGlvbiB0 byBpbnN0YWxsIHRoZWlyIElQdjQgcm91dGluZyB0YWJsZS4NCg0KVGhhbmtzIGFuZCBCZXN0IFJl Z2FyZHMsDQoNCg0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tDQogDQpGcm9tOiBUaG9tYXMgTW9y aW4NCkRhdGU6IDIwMTYtMDQtMDggMDU6NDQNClRvOiBCRVNTDQpTdWJqZWN0OiBbYmVzc10gbWlu dXRlcyBvZiBvdXIgSUVURiA5NSBtZWV0aW5nDQpIaSBldmVyeW9uZSwNCiANCldlIGhhdmUganVz dCBwb3N0ZWQgZHJhZnQgbWludXRlcyBmb3IgdG9kYXkncyBtZWV0aW5nLg0KIA0KWW91IGNhbiBy ZWFkIHRoZW0gYXQgDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVz L21pbnV0ZXMtOTUtYmVzcw0KIA0KUGxlYXNlIHNlbmQgYW55IGNvbW1lbnRzIHlvdSBtYXkgaGF2 ZSBvbiB0aGVzZSBtaW51dGVzLg0KIA0KTWFueSBtYW55IHRoYW5rcyB0byBHdW50ZXIgZm9yIGhp cyBtaW51dGUgdGFraW5nIQ0KIA0KLVRob21hcy9NYXJ0aW4NCiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpCRVNTIG1haWxpbmcgbGlzdA0KQkVTU0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQogDQoN Cg== ------=_001_NextPart828251638771_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A = =0A =0A
Hi, Everyone,

As talked= in IETF 95 meeting in Buenos Aires, and suggested by our Chairs, I want t= o know your opinion, especially the experts from the vendors, about 4PE ro= uters.
Do 4PE routers need both IPv4 and IPv6 next hop informati= on to install their IPv4 and IPv6 routing tables when they receive IPv4 ro= utes from other 4PE routers? Or they only need IPv6 next hop information?<= /div>

Since RFC5549 can only convey IPv4 or IPv6 next h= op for IPv4 routes, but not both, I submit draft draft= -li-bess-4pe to solve this problem. 4PE I think is a scenario for my draft= . Any other scenarioes that need both IPv4 and IPv6 next = hops?

For your reference,= RFC5549 is here, https://www.rfc-editor.org/rfc/rfc5549.txt, draft-li-bess-4pe is here, https://www.ietf.= org/id/draft-li-bess-4pe-01.txt

<= span style=3D"font-size: 10.5pt; line-height: 1.5; background-color: windo= w;">Thank you very much
=0A

=0A
<= span>
li_zhenqiang@hotmail.com
=0A
 <= /div>
Date: 2016-04= -13 20:47
Subject: Re: [bess] minutes of our IETF 95 = meeting
= =0A =0A =0A =0A =0A
Hi,
=0A =
=0A I've updated the minutes.
=0A Thanks for the precis= ion.
=0A
=0A Beyond this minute adjustment, I understand = that the key thing you=0A need to clarify is what is missing or probl= ematic in RFC5549.
=0A
=0A Thank you,
=0A
=0A= -Thomas
=0A
=0A
=0A 2016-04-13, li_= zhenqiang@hotmail.com:
=0A
=0A
=0A =0A = =0A
for draft-li-= bess-4pe-01:
=0A
Please add my response= to comments from Keyur and= Wim: 4PE routers need I= Pv4 next hop information to install their IPv4 routing table.
= =0A

=0A
=0A
Thanks and Best Regards,=0A
=0A
=0A =0A =
=0A
=0A
 
=0A =0A
= =0A =0A
= Date: 2016-04-08 05:44
=0A
To: BESS<= /div>=0A
Subject: [bess] minutes of our IETF 9= 5 meeting
=0A
=0A
=0A
=0A =
Hi everyone,
=0A
 
=0A We have just posted draft minutes for today's meeting.
=0A =
 
=0A
You can read them at
=0A = =0A
 
=0A =
Please send any comments you may have on these minutes.
=0A =
 
=0A
Many many thanks to Gunter for h= is minute taking!
=0A
 
=0A
-Th= omas/Martin
=0A
 
=0A
_________= ______________________________________
=0A
BESS mailing= list
=0A =0A =0A  
=0A
=0A
=0A = =0A
=0A =0A
=0A ------=_001_NextPart828251638771_=------ From nobody Tue Apr 26 09:22:33 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 A735712D504; Tue, 26 Apr 2016 09:22:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426162229.30108.32637.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 09:22:29 -0700 Archived-At: Cc: draft-ietf-bess-pta-flags@ietf.org, aretana@cisco.com, martin.vigoureux@nokia.com, bess-chairs@ietf.org, bess@ietf.org Subject: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-bess-pta-flags-02=3A_=28with_COMMENT=29?= 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, 26 Apr 2016 16:22:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-bess-pta-flags-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-pta-flags/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not important but why is the Extension flag bit 1 and not bit 0? From nobody Tue Apr 26 12:29: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 165BD12D102; Tue, 26 Apr 2016 12:29:27 -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 xuOuOKnmDrMN; Tue, 26 Apr 2016 12:29:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F5B12B00F; Tue, 26 Apr 2016 12:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/TP6sd1bCO1M0aeVzpf5rB5Jgsx+Ytx8aBT56PaxIGo=; b=cZr+0tQETfBL3IolKJ896glJN8MrtPoMZ0ZGAhRfWrRH37kGjCBYczR6IyhQMkleL1sOR4sbww80C+V+Vp4cSpoA/LV2LwUlY/CRKbx22Y++RQh80rXrnq7soWnuo0HTieELG/slwI/QiR+shuYh7yeHJVd0yFCjVNyl9apRl7E= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.186] (66.129.241.12) by BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) with Microsoft SMTP Server (TLS) id 15.1.466.19; Tue, 26 Apr 2016 19:29:06 +0000 To: Mirja Kuehlewind , The IESG References: <20160426162229.30108.32637.idtracker@ietfa.amsl.com> From: Eric C Rosen Message-ID: <995e95c2-ccd3-3dce-e80c-5e80a72e95b2@juniper.net> Date: Tue, 26 Apr 2016 15:29:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160426162229.30108.32637.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM2PR09CA0030.namprd09.prod.outlook.com (10.160.127.40) To BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) X-MS-Office365-Filtering-Correlation-Id: c69cb31e-01f9-4bb1-7e45-08d36e09092f X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 2:abh4S8GycgbW072z9gxYHr/Inulq9jekHmrl9Mj9pfBFqJeA/Bq3+v8VZYrySEc6Lvc8FJGx6ByyspJasxiBBP1Q29Itq6E3YMzpVbYiJB4wdUKkm+EajEE9263hLkERJOrH6AUhyT7TCZGy5TcZIWSGl9bGX3YgPo0+OIQb10xWDUtglD8TvlR8KMjAlHYH; 3:S6n6921papisS6a2mhxgYYBc9gw2uGEoBjeGqatJx4p3q8f9sOxWnzbh4JsJJ/UHSo7tPRjkIkw1YmJyBio+2He7t7SJUylMpQJbXYNrbo4EiLjWydmXOKR+psFKp4Pi; 25:7B6+CE1CYJikyI8yJyP0fj+9vpwo+rI14+zhiY+m38Jh0Q+tvIZD6ylmW5fLrkD9uUE8rYFtkc7DFbUMubTlSu15Qjf92CodosIKywG5aEiU9FJAK9PAQpKxIQtweEDjYuDIGVz4aXklO45JRfDxSDrsYEsKfbyM/9DDA1Z9UkKyhRKFD6jZ2JdxLQzhffVxwI/fLH0AAqbaM3SZT7ijg8Dh0C6vsdsLPkhwmVrscsWsZ4xNCqBDz7idoZQAdLEGanW/9mmh0JSNevso8Seg814BQkmOfG/jxvUOmm51TJi/mgOX64fGs7clpQk1XO00m62MJSoXgml+wzzaN8tfUQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB789; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 20:DqDvhbruuJAsdD8XnMgoikFhsimt5Flyesl2yItIwxUoJnMJi6rfjpqLBhv7OD3wCtnGAv2ssffsicGDSfXm4NlnYtldotHOvEy7Z2u73ibAsm4O4xgPfVNJopcd4BFa4eR0dpQgB8LNP0MiRFZNSNsrTmBR2KzIxTAoz/5FZCJGsQ6s4X7VwmzKY6KQcSWOVjgb9Ls5iH0pZrewns4hIHyk2GZGjkuA6Nv8cQqWpB+SjzGHcOcts9DRnHtbinyDUAepofsrJJpCjCI+yy4cpeetozWB2KeFNm8g2eUGliSrAy+3yJGQlv684yRV6EOBdoLiRNsfiw/sYyeU+PLOvguJkmgaGIFo8NEilO55IaxQr1fFWQbXmZktzt0SOgXVVKa/BiCvScAfET3+8CRqEqCN1nN1JJzWNB5J81sx9/PsRZxv6bVFpvhh232T+LEGVAplPHBQc4l2HUJ/zamvkGqPnswaDsHyPwuaE3jDgyIY8oHszzQb4fgyiyntXRKc; 4:N/Kwf0+hsD+yQYt6WZ6wOjjT9nIImN66UzSDmo5b0ZB3sp0j6uhmD5230tBQ3zg/XTC9K+r8yP3gNkSN5X60Mwh4WOM2J894Ezi2S+TtVR3EY1fm2kYGDLGx02uNOXpuA7Uub3XCXzpEsupvTyfCQ0ur5zb+H+DOV41Y4IxxdTniIsvvSR/1pe2VI8B+IrekgHSWHRGoLs1Uth6SVfu1iXnEND2EUOuKhfgvHFi+yFVnILdsDXGCsnut2KHKjBOhoZH3TslHO9If373yNfczSNVf5p4VHrebqKn4epcZomx5J+GthiIwOaHUAEIdvvD0FE2hQzBWRf8KdzgQFUrTdXS5MXi7yD5BIYmIRrRzp5UsAg14opag7i7xkKXh4u069o4rBt5gzY1t6RX2EaLaq3MFuWnZzvQCSnA13HlsqZI= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR05MB789; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB789; X-Forefront-PRVS: 0924C6A0D5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(6049001)(24454002)(377454003)(65956001)(230700001)(66066001)(65806001)(47776003)(230783001)(1096002)(6116002)(586003)(81166005)(3846002)(50986999)(558084003)(50466002)(23676002)(33646002)(4326007)(77096005)(2950100001)(5008740100001)(5004730100002)(2906002)(224313004)(189998001)(92566002)(224303003)(64126003)(42186005)(54356999)(76176999)(36756003)(83506001)(4001350100001)(97736004)(5001770100001)(86362001)(31686004)(31696002)(65826006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB789; H:[172.29.35.186]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI3ODk7MjM6WHJUQ3NCa0VCTzdFU2ZrM3kwRSsxdHFocXpR?= =?utf-8?B?ekV2RDR5WHhIa0RuUlM4L09NTHpnVTdNT09Rdi8zWnpEUm1ibmlzR083UUl6?= =?utf-8?B?czJUcUZWamo3U3V1eTU5RTgyNmxOaGdWc1RVdW4wSFJLWjExYjJLN25ZbXJq?= =?utf-8?B?OHkya0ZuMGhqN01ZVnlDekZNSHNPcnRFRFFuRHhzWVkwWUtzSDFVQ3ZxODlD?= =?utf-8?B?K2VRQ0VlR1RiTzc4bkEycHBFem84VVpWc3hydWdvRHFubWJMR0RyZ3FCT0Rs?= =?utf-8?B?Zk5CWW9SMkg2S0pBRkFzWFI5dWQyRXJDMm9BU2EyNVNJMWNCZzVkNCs4aWNW?= =?utf-8?B?aW5IRGZzdTlzSHoybmUwSWR6UnN4SEwyZXdHZnA1Ni9lYVVoZURmbUpDbmRu?= =?utf-8?B?bjFtT3krT2lHbXlZTWNxbWdXSmxLMHkvalpLSjdBa1FTNFRVdWJJRmZBV1FR?= =?utf-8?B?eHVwdG4zVDJ5ckUxdkhjNXR3dElQY1d2WE5lVEFuLzl3VDZmWjVoazE2Zzhv?= =?utf-8?B?eUFraXcwVFNIUTYwemF3M3pnOTJ4VEd6MktyWlFYWFdkMm5qTy94ZE1LOFNu?= =?utf-8?B?OEduWnk5d3V1RXJKVE5mNWk4VzVhTmc5VC9qSXB3TGpqc3BRNVdyQkhtNVVL?= =?utf-8?B?UnNxZGY4T09rZGtpWStSNy9Kc0ZrQ2QvNTFKRlVQM1E1UnA1TnU4UXJjc0dz?= =?utf-8?B?cC9TMFV3bjNtZGl0aHRLMFNZRHFSY25zUGJCR2xDakZScmt4L2MyU2RqSWVL?= =?utf-8?B?cFpva21NUkdvYzBPbm94V0xiWXk2QzhmcUgrSmJTMXRoWFV3L1pBM0tBZyt5?= =?utf-8?B?RHV5UVdzYWZzcWpMejFIZnNZb2xkLzE1Qk1mUkJPdVZhMWRXR1dTQm1tR3BZ?= =?utf-8?B?cjRzdU12NXd5K3djSFVSWEw4SzZOZUd2eloxbVUzWTJxY3cwZmtWSmtxSFEy?= =?utf-8?B?U0loclYwWnZGTnVsR2ZmZXg2Q3RlU2dCTzB5c3RqUm5XaXRySFJudjJCUFF3?= =?utf-8?B?UnhsVUlTUjJ6ci94N1R3QS9aZlhiVmE1VFJVTW1IOXh6WjROc2ZZeFhTZEpC?= =?utf-8?B?ejN1aHlOejRwT3U2bHBpOFZhemhIakhpL1lORGJkOWxjVTlNOGQwWFBsOVhx?= =?utf-8?B?UkhKdkxKSUVCdTBqRWk2VDFGRXdjWWRQcXlpV3FvKytqeTJyN0dJeEhWbExx?= =?utf-8?B?U2VNcW8rWHhOVEhJbk5hd0tKMmUzanE4bFhHbTBCNFkxWHR4L0l2RTVMakNn?= =?utf-8?B?QVdpWXFKT3oxdFROc3BaYzBrZXhvcnRaTDhYZ3pQcVFaVnRsR0NYbUlDUzlD?= =?utf-8?B?bzY2SFNEMExPOHY1WS90b2V6Z1VxRHVrV3oxQ2ZZMEVYcWpYRXNwczhtajNX?= =?utf-8?B?dGpDQmpOUWhoaGJwMWdaRWIwSWNjOUxkMXVlSlUwSGFCRmxRSU1lZm5NcjZo?= =?utf-8?B?ZzJoaWFZRDl3aXJNTE9vN1VhTDVURW4wc1hISGxNNXUyTlEzT1VJSHN6SFJz?= =?utf-8?B?YnJCODFJMlhyaEFpQysrS3A5Z09lcldMampoMjZwdWt5ZCtHb0ZjNGEwUUw2?= =?utf-8?B?WVpaUVBkUExnSlV0OVFjTkxpejg5aC9ONkVVQmNyWWoxWG95MkxBeXY3VXY4?= =?utf-8?B?UzJyck1WUS9SL1FhVVBUaVIxb1pwVHJMS3RZY1VRSTRnVURBNTVlUEFGendx?= =?utf-8?Q?Dg6psQE3kcfh0Jkx4=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 5:Ggs357CI0L8cf7cq/2mYM7pNgFWz4SdcGZWGuq5nSxqRlQ5fo8bQY0CvEgHGew1nTs3MTObkgpGONINJw++HcVKDdVDR7wKczpX6iK1hiZ1fRbbc708zwAkWXP7uu7dlBpPj9bFGFs8zLC64aWWVII7uCG0EB7w8VGKVl9MamOFMsJ0028sLE4a2AeE2LbYc; 24:LReO0Hlg8wcxg3ncD/gg5qsb/p/6BNqOniQvrnYCQO+fAmRBb5SuHmwSrqW+DNnzIpmoo6aIfAKWuw9eTyfPSg0uQ94Y++IXpN/mWGRDsYg=; 7:dGyoYVILleXkSechwhh8dqzYhoLp9NvHPtauAPJDm7zyo5aQV/lvFNw1HnUVmzb7FJLOBXB2ywWqTBBcaMzfZ4DkIZLHIrVqzkthD3HScNk57jkFg0DTWBSZRqBkg7VI78tBxfVAA7YouNA6NgywvPWhCm2IVKVTp1KIlMgkbz644fLIuH/z0gnbh2ui4MkQYslO9VRUv/Nd31FQeJACEw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2016 19:29:06.2865 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB789 Archived-At: Cc: draft-ietf-bess-pta-flags@ietf.org, aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@nokia.com, bess@ietf.org Subject: Re: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-bess-pta-flags-02=3A_=28with_COMMENT=29?= 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, 26 Apr 2016 19:29:27 -0000 On 4/26/2016 12:22 PM, Mirja Kuehlewind wrote: > Not important but why is the Extension flag bit 1 and not bit 0? There is reason to believe that bit 0 is already in use in one or more deployments. Hopefully, it will get properly registered once the registry is created! From nobody Thu Apr 28 09:22: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 8F00D12D98E for ; Thu, 28 Apr 2016 09:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjRoTmTB-QrG for ; Thu, 28 Apr 2016 09:22:09 -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 D3D2712D8C7 for ; Thu, 28 Apr 2016 09:18:23 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 867D1747EF374; Thu, 28 Apr 2016 16:18:18 +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 u3SGILSo021058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Apr 2016 16:18:21 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 u3SGID4o027709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Apr 2016 18:18:19 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.80]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 28 Apr 2016 18:17:23 +0200 From: "Henderickx, Wim (Nokia - BE)" To: "li_zhenqiang@hotmail.com" , "thomas.morin" , bess Thread-Topic: [bess] Do 4PE routers need both IPv4 and IPv6 next hop information? Thread-Index: AQHRn4kLm7DqOBfgr0m21vmBFCLAep+fHneA Date: Thu, 28 Apr 2016 16:17:22 +0000 Message-ID: <37D5F472-D6F3-49D6-B526-A3BB36119410@alcatel-lucent.com> References: <5706D4BA.9060908@orange.com> <570E3FCF.4000408@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.40] Content-Type: multipart/alternative; boundary="_000_37D5F472D6F349D6B526A3BB36119410alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Do 4PE routers need both IPv4 and IPv6 next hop information? 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, 28 Apr 2016 16:22:11 -0000 --_000_37D5F472D6F349D6B526A3BB36119410alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gc3VwcG9ydCBhIHY2IE1QTFMgbmV0d29yayB3ZSBqdXN0IG5lZWQgYSB2NiBOZXh0LWhvcCBm b3IgVjQgcHJlZml4ZXMgYXMgZGVzY3JpYmVkIGluIFJGQzU1NDkNCg0KRnJvbTogQkVTUyA8YmVz cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpiZXNzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhh bGYgb2YgImxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhvdG1h aWwuY29tPiIgPGxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTxtYWlsdG86bGlfemhlbnFpYW5nQGhv dG1haWwuY29tPj4NCkRhdGU6IFR1ZXNkYXkgMjYgQXByaWwgMjAxNiBhdCAwMTo1OA0KVG86ICJ0 aG9tYXMubW9yaW4iIDx0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbTxtYWlsdG86dGhvbWFzLm1vcmlu QG9yYW5nZS5jb20+PiwgYmVzcyA8YmVzc0BpZXRmLm9yZzxtYWlsdG86YmVzc0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBbYmVzc10gRG8gNFBFIHJvdXRlcnMgbmVlZCBib3RoIElQdjQgYW5kIElQdjYg bmV4dCBob3AgaW5mb3JtYXRpb24/DQoNCkhpLCBFdmVyeW9uZSwNCg0KQXMgdGFsa2VkIGluIElF VEYgOTUgbWVldGluZyBpbiBCdWVub3MgQWlyZXMsIGFuZCBzdWdnZXN0ZWQgYnkgb3VyIENoYWly cywgSSB3YW50IHRvIGtub3cgeW91ciBvcGluaW9uLCBlc3BlY2lhbGx5IHRoZSBleHBlcnRzIGZy b20gdGhlIHZlbmRvcnMsIGFib3V0IDRQRSByb3V0ZXJzLg0KRG8gNFBFIHJvdXRlcnMgbmVlZCBi b3RoIElQdjQgYW5kIElQdjYgbmV4dCBob3AgaW5mb3JtYXRpb24gdG8gaW5zdGFsbCB0aGVpciBJ UHY0IGFuZCBJUHY2IHJvdXRpbmcgdGFibGVzIHdoZW4gdGhleSByZWNlaXZlIElQdjQgcm91dGVz IGZyb20gb3RoZXIgNFBFIHJvdXRlcnM/IE9yIHRoZXkgb25seSBuZWVkIElQdjYgbmV4dCBob3Ag aW5mb3JtYXRpb24/DQoNClNpbmNlIFJGQzU1NDkgY2FuIG9ubHkgY29udmV5IElQdjQgb3IgSVB2 NiBuZXh0IGhvcCBmb3IgSVB2NCByb3V0ZXMsIGJ1dCBub3QgYm90aCwgSSBzdWJtaXQgZHJhZnQg ZHJhZnQtbGktYmVzcy00cGUgdG8gc29sdmUgdGhpcyBwcm9ibGVtLiA0UEUgSSB0aGluayBpcyBh IHNjZW5hcmlvIGZvciBteSBkcmFmdC4gQW55IG90aGVyIHNjZW5hcmlvZXMgdGhhdCBuZWVkIGJv dGggSVB2NCBhbmQgSVB2NiBuZXh0IGhvcHM/DQoNCkZvciB5b3VyIHJlZmVyZW5jZSwgUkZDNTU0 OSBpcyBoZXJlLCBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTU0OS50eHQsIGRy YWZ0LWxpLWJlc3MtNHBlIGlzIGhlcmUsIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxp LWJlc3MtNHBlLTAxLnR4dDxodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1saS1iZXNzLTRw ZS0wMS50eHQsPg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb208bWFpbHRvOmxpX3poZW5xaWFu Z0Bob3RtYWlsLmNvbT4NCg0KRnJvbTogVGhvbWFzIE1vcmluPG1haWx0bzp0aG9tYXMubW9yaW5A b3JhbmdlLmNvbT4NCkRhdGU6IDIwMTYtMDQtMTMgMjA6NDcNClRvOiBsaV96aGVucWlhbmdAaG90 bWFpbC5jb208bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT47IGJlc3M8bWFpbHRvOmJl c3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Jlc3NdIG1pbnV0ZXMgb2Ygb3VyIElFVEYgOTUg bWVldGluZw0KSGksDQoNCkkndmUgdXBkYXRlZCB0aGUgbWludXRlcy4NClRoYW5rcyBmb3IgdGhl IHByZWNpc2lvbi4NCg0KQmV5b25kIHRoaXMgbWludXRlIGFkanVzdG1lbnQsIEkgdW5kZXJzdGFu ZCB0aGF0IHRoZSBrZXkgdGhpbmcgeW91IG5lZWQgdG8gY2xhcmlmeSBpcyB3aGF0IGlzIG1pc3Np bmcgb3IgcHJvYmxlbWF0aWMgaW4gUkZDNTU0OS4NCg0KVGhhbmsgeW91LA0KDQotVGhvbWFzDQoN Cg0KMjAxNi0wNC0xMywgbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlh bmdAaG90bWFpbC5jb20+Og0KZm9yIGRyYWZ0LWxpLWJlc3MtNHBlLTAxOg0KUGxlYXNlIGFkZCBt eSByZXNwb25zZSB0byBjb21tZW50cyBmcm9tIEtleXVyIGFuZCBXaW06IDRQRSByb3V0ZXJzIG5l ZWQgSVB2NCBuZXh0IGhvcCBpbmZvcm1hdGlvbiB0byBpbnN0YWxsIHRoZWlyIElQdjQgcm91dGlu ZyB0YWJsZS4NCg0KVGhhbmtzIGFuZCBCZXN0IFJlZ2FyZHMsDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVucWlh bmdAaG90bWFpbC5jb20+DQoNCkZyb206IFRob21hcyBNb3JpbjxtYWlsdG86dGhvbWFzLm1vcmlu QG9yYW5nZS5jb20+DQpEYXRlOiAyMDE2LTA0LTA4IDA1OjQ0DQpUbzogQkVTUzxtYWlsdG86YmVz c0BpZXRmLm9yZz4NClN1YmplY3Q6IFtiZXNzXSBtaW51dGVzIG9mIG91ciBJRVRGIDk1IG1lZXRp bmcNCkhpIGV2ZXJ5b25lLA0KDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGRyYWZ0IG1pbnV0ZXMgZm9y IHRvZGF5J3MgbWVldGluZy4NCg0KWW91IGNhbiByZWFkIHRoZW0gYXQNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk1L21pbnV0ZXMvbWludXRlcy05NS1iZXNzDQoNClBsZWFzZSBz ZW5kIGFueSBjb21tZW50cyB5b3UgbWF5IGhhdmUgb24gdGhlc2UgbWludXRlcy4NCg0KTWFueSBt YW55IHRoYW5rcyB0byBHdW50ZXIgZm9yIGhpcyBtaW51dGUgdGFraW5nIQ0KDQotVGhvbWFzL01h cnRpbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K QkVTUyBtYWlsaW5nIGxpc3QNCkJFU1NAaWV0Zi5vcmc8bWFpbHRvOkJFU1NAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCg0KDQo= --_000_37D5F472D6F349D6B526A3BB36119410alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <93370DB0DD6E7D41AAAA7702C2EC1526@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRvIHN1cHBvcnQgYSB2NiBNUExTIG5ldHdvcmsgd2UganVzdCBuZWVkIGEgdjYgTmV4dC1o b3AgZm9yIFY0IHByZWZpeGVzIGFzIGRlc2NyaWJlZCBpbiBSRkM1NTQ5PC9kaXY+DQo8ZGl2Pg0K PGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QkVTUyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJlc3MtYm91bmNlc0BpZXRmLm9yZyI+YmVzcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24g YmVoYWxmIG9mICZxdW90OzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20i PmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzps aV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvYT4mZ3Q7 PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5 IDI2IEFwcmlsIDIwMTYgYXQgMDE6NTg8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+VG86IDwvc3Bhbj4mcXVvdDt0aG9tYXMubW9yaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+dGhvbWFzLm1vcmluQG9yYW5nZS5jb208L2E+Jmd0 OywgYmVzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlc3NAaWV0Zi5vcmciPmJlc3NAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+W2Jlc3NdIERvIDRQRSByb3V0ZXJzIG5lZWQgYm90aCBJUHY0IGFuZCBJUHY2IG5leHQgaG9w IGluZm9ybWF0aW9uPzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHN0eWxl PmJvZHkgeyBsaW5lLWhlaWdodDogMS41OyB9YmxvY2txdW90ZSB7IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMC41ZW07IH1kaXYuZm94ZGl2MjAxNjA0 MjYxMjA2MzgxOTYwNTggeyB9Ym9keSB7IGZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTog 5b6u6L2v6ZuF6buROyBjb2xvcjogcmdiKDAsIDAsIDApOyBsaW5lLWhlaWdodDogMS41OyB9PC9z dHlsZT4NCjxkaXY+DQo8ZGl2PjxzcGFuPjwvc3Bhbj5IaSwgRXZlcnlvbmUsPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyB0YWxrZWQgaW4gSUVURiA5NSBtZWV0aW5nIGluIEJ1ZW5v cyBBaXJlcywgYW5kIHN1Z2dlc3RlZCBieSBvdXIgQ2hhaXJzLCBJIHdhbnQgdG8ga25vdyB5b3Vy IG9waW5pb24sIGVzcGVjaWFsbHkgdGhlIGV4cGVydHMgZnJvbSB0aGUgdmVuZG9ycywgYWJvdXQg NFBFIHJvdXRlcnMuPC9kaXY+DQo8ZGl2PkRvIDRQRSByb3V0ZXJzIG5lZWQgYm90aCBJUHY0IGFu ZCBJUHY2IG5leHQgaG9wIGluZm9ybWF0aW9uIHRvIGluc3RhbGwgdGhlaXIgSVB2NCBhbmQgSVB2 NiByb3V0aW5nIHRhYmxlcyB3aGVuIHRoZXkgcmVjZWl2ZSBJUHY0IHJvdXRlcyBmcm9tIG90aGVy IDRQRSByb3V0ZXJzPyBPciB0aGV5IG9ubHkgbmVlZCBJUHY2IG5leHQgaG9wIGluZm9ybWF0aW9u PzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2luY2UgUkZDNTU0OSBjYW4gb25seSBj b252ZXkgSVB2NCBvciBJUHY2IG5leHQgaG9wIGZvciBJUHY0IHJvdXRlcywgYnV0IG5vdCBib3Ro LCBJIHN1Ym1pdCBkcmFmdCZuYnNwOzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2Jh KDAsIDAsIDAsIDApOyBmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsiPmRyYWZ0 LWxpLWJlc3MtNHBlIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gNFBFIEkgdGhpbmsgaXMgYSBzY2Vu YXJpbw0KIGZvciBteSBkcmFmdC4gQW55IG90aGVyJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogd2lu ZG93OyI+c2NlbmFyaW9lcyB0aGF0IG5lZWQgYm90aCBJUHY0IGFuZCBJUHY2IG5leHQgaG9wcz88 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1o ZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogd2luZG93OyI+PGJyPg0KPC9zcGFuPjwvZGl2 Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7 IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPkZvciB5b3VyIHJlZmVyZW5jZSwgUkZDNTU0OSBp cyBoZXJlLCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUt aGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPjwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTU0OS50eHQsIiBzdHlsZT0iZm9udC1z aXplOiAxMC41cHQ7IGxpbmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsi Pmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1NTQ5LnR4dCw8L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9y OiB3aW5kb3c7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBs aW5lLWhlaWdodDogMS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aW5kb3c7Ij5kcmFmdC1saS1iZXNz LTRwZQ0KIGlzIGhlcmUsJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogd2luZG93OyI+PC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxpLWJlc3MtNHBlLTAxLnR4dCwi IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1j b2xvcjogd2luZG93OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtbGktYmVzcy00cGUt MDEudHh0PC9hPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxp bmUtaGVpZ2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPjxicj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDog MS41OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aW5kb3c7Ij5UaGFuayB5b3UgdmVyeSBtdWNoPC9zcGFu PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0id2lkdGg6IDIxMHB4OyBoZWln aHQ6IDFweDsiIGNvbG9yPSIjYjVjNGRmIiBzaXplPSIxIiBhbGlnbj0ibGVmdCI+DQo8ZGl2Pjxz cGFuPg0KPGRpdiBzdHlsZT0iTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTogdmVyZGFuYTsgRk9O VC1TSVpFOiAxMHB0Ij4NCjxkaXY+PGEgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWls LmNvbSI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+ PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7IG1hcmdpbi1sZWZ0OiAwLjVlbTsiPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxkaXYgc3R5bGU9IlBBRERJTkctUklHSFQ6IDhweDsgUEFERElO Ry1MRUZUOiA4cHg7IEZPTlQtU0laRTogMTJweDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAw MDAwMDsgQkFDS0dST1VORDogI2VmZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1U T1A6IDhweCI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzp0aG9tYXMu bW9yaW5Ab3JhbmdlLmNvbSI+VGhvbWFzIE1vcmluPC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwv Yj4mbmJzcDsyMDE2LTA0LTEzJm5ic3A7MjA6NDc8L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86YmVzc0BpZXRmLm9yZyI+YmVzczwvYT48 L2Rpdj4NCjxkaXY+PGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtiZXNzXSBtaW51dGVzIG9mIG91 ciBJRVRGIDk1IG1lZXRpbmc8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFz cz0iRm94RGl2MjAxNjA0MjYxMjA2MzgxOTYwNTgiPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJl Zml4Ij5IaSw8YnI+DQo8YnI+DQpJJ3ZlIHVwZGF0ZWQgdGhlIG1pbnV0ZXMuPGJyPg0KVGhhbmtz IGZvciB0aGUgcHJlY2lzaW9uLjxicj4NCjxicj4NCkJleW9uZCB0aGlzIG1pbnV0ZSBhZGp1c3Rt ZW50LCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUga2V5IHRoaW5nIHlvdSBuZWVkIHRvIGNsYXJpZnkg aXMgd2hhdCBpcyBtaXNzaW5nIG9yIHByb2JsZW1hdGljIGluIFJGQzU1NDkuPGJyPg0KPGJyPg0K VGhhbmsgeW91LDxicj4NCjxicj4NCi1UaG9tYXM8YnI+DQo8YnI+DQo8YnI+DQoyMDE2LTA0LTEz LCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86bGlfemhl bnFpYW5nQGhvdG1haWwuY29tIj4NCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvYT46PGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6QkxVNDM2LVNNVFAxNjRFQUQ1QTcxQzVBRTYw NkJGQTU3OUZDOTYwQHBoeC5nYmwiIHR5cGU9ImNpdGUiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDAuNWVtOyI+DQo8ZGl2PmZvciZuYnNw OzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7 IHdpZG93czogMTsgZm9udC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsi PmRyYWZ0LWxpLWJlc3MtNHBlLTAxOjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4+PC9zcGFuPlBs ZWFzZSBhZGQgbXkgcmVzcG9uc2UgdG8gY29tbWVudHMgZnJvbSZuYnNwOzxzcGFuIHN0eWxlPSJs aW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdpZG93czogMTsgZm9u dC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPktleXVyIGFuZA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7IHdpZG93czogMTsgZm9udC1zaXplOiAxMC41cHQ7IGJhY2tncm91bmQtY29sb3I6IHdpbmRv dzsiPldpbTogNFBFIHJvdXRlcnMgbmVlZCBJUHY0IG5leHQgaG9wIGluZm9ybWF0aW9uIHRvIGlu c3RhbGwgdGhlaXIgSVB2NCByb3V0aW5nIHRhYmxlLjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLDwvZGl2Pg0KPGhyIHN0eWxlPSJ3 aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIgY29sb3I9IiNiNWM0ZGYiIGFsaWduPSJsZWZ0IiBz aXplPSIxIj4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFN SUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6DQogICAgICAgICAgICAxMHB0Ij4NCjxkaXY+PGEgY2xh c3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbSI+bGlfemhlbnFpYW5nQGhvdG1haWwuY29tPC9hPjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t Ym90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwLjVlbTsiPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAgICAgICAg IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdiBzdHlsZT0iUEFERElORy1S SUdIVDogOHB4OyBQQURESU5HLUxFRlQ6IDhweDsgRk9OVC1TSVpFOg0KICAgICAgICAgICAgMTJw eDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsgQkFDS0dST1VORDogI2VmZWZlZjsN CiAgICAgICAgICAgIFBBRERJTkctQk9UVE9NOiA4cHg7IFBBRERJTkctVE9QOiA4cHgiPg0KPGRp dj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzp0aG9tYXMubW9yaW5Ab3JhbmdlLmNvbSI+VGhvbWFzIE1vcmluPC9hPjwvZGl2Pg0KPGRpdj48 Yj5EYXRlOjwvYj4mbmJzcDsyMDE2LTA0LTA4Jm5ic3A7MDU6NDQ8L2Rpdj4NCjxkaXY+PGI+VG86 PC9iPiZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmJlc3NAaWV0 Zi5vcmciPkJFU1M8L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1tiZXNzXSBt aW51dGVzIG9mIG91ciBJRVRGIDk1IG1lZXRpbmc8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj5IaSBldmVyeW9uZSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldlIGhh dmUganVzdCBwb3N0ZWQgZHJhZnQgbWludXRlcyBmb3IgdG9kYXkncyBtZWV0aW5nLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+WW91IGNhbiByZWFkIHRoZW0gYXQgPC9kaXY+DQo8ZGl2 PjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL3Byb2NlZWRpbmdzLzk1L21pbnV0ZXMvbWludXRlcy05NS1iZXNzIj5odHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21pbnV0ZXMtOTUtYmVzczwvYT48L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlBsZWFzZSBzZW5kIGFueSBjb21tZW50cyB5b3UgbWF5 IGhhdmUgb24gdGhlc2UgbWludXRlcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1h bnkgbWFueSB0aGFua3MgdG8gR3VudGVyIGZvciBoaXMgbWludXRlIHRha2luZyE8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi1UaG9tYXMvTWFydGluPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzwvZGl2Pg0KPGRpdj5CRVNTIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj48YSBjbGFzcz0ibW96 LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86QkVTU0BpZXRmLm9yZyI+QkVTU0Bp ZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3M8L2E+PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_37D5F472D6F349D6B526A3BB36119410alcatellucentcom_--