From nobody Fri Apr 1 02:02:21 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B468312D0EA; Fri, 1 Apr 2016 02:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nus2YxZ4ILrW; Fri, 1 Apr 2016 02:02:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80D912D0BB; Fri, 1 Apr 2016 02:02:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A90E764; Fri, 1 Apr 2016 11:02:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ef8dE2PSE8pk; Fri, 1 Apr 2016 11:01:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 1 Apr 2016 11:02:11 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8608120050; Fri, 1 Apr 2016 11:02:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nYYlau6nEVKJ; Fri, 1 Apr 2016 11:02:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44AEF20046; Fri, 1 Apr 2016 11:02:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5A8093A6F1CB; Fri, 1 Apr 2016 11:02:07 +0200 (CEST) Date: Fri, 1 Apr 2016 11:02:07 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160401090207.GA50653@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 09:02:17 -0000 Operational state often has a different lifetime than config. Hence, keeping config and operational state together in the same structure (with the same naming) causes you problems down the road. /js On Thu, Mar 31, 2016 at 06:44:06PM +0000, Rajiv Asati (rajiva) wrote: > > While working on MPLS LDP yang model (https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang), we noticed the possible confusion around structuring intended config, applied config and derived state *. > > On one hand, one may have 'intended-config’ (RW) and ‘applied-config’ (RO) in the same construct (container), and ‘derived state’ (RO) in a separate construct (container). > > This keeps config together, but doesn’t help operational state, which requires > Both Applied-config and derived-state. > > On the other hand hand, one may have ‘intended-config’ in one construct (container), and ‘applied-config’ and ‘derived state’ in a separate construct (container). > > This simplifies figuring operational-state, but divides the config types. > > There are pros & cons either way. It would be good to have some guidance/text around guiding one over another, so that other models can leverage. Otherwise, we are going to end up with yet one more discrepancy (among various protocols YANG models), & confusing if not inefficient modeling. > > Perhaps, we ditch both of the above approaches, and settle on keeping all three of them in the same construct. It might simplify the organization a bit. Of course, that also has 2 options - have all the data types in intended-config, and then in applied-config and then in derived-state. Or have intended-config, applied-config and derived-state for each data type. Latter might be slightly better, given that not every data type will have all three. > > > Thoughts? > > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > > * https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs > https://tools.ietf.org/html/draft-openconfig-netmod-opstate > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 1 08:12:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF7A12D184; Fri, 1 Apr 2016 08:12: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 IFEKXFzOSRWK; Fri, 1 Apr 2016 08:12:19 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED6512D0A8; Fri, 1 Apr 2016 08:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=263; q=dns/txt; s=iport; t=1459523539; x=1460733139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JH7LpWqkooXzZjZhWcCWAVatLU/WyU5yaI2SFOQm7ag=; b=clsqpKf/5/CnnwZxNAv40nQW+A0nt3aTUFpECNVilGnGs5RVl/w5I107 J4v2xO2gPIwmUL9s7hItH25uS2yzOmFZ1XF6HbdOl2wcdqpxKiRJzZWGa HmEvcLiEL+RnFS5SS/HatsEgjSKP8LKuhyGN0dYrP7nFYSLq3Oxgwim0V U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D4AQDajv5W/51dJa1dg0GBVrkBgg8BD?= =?us-ascii?q?YFyhg0CgUQ4FAEBAQEBAQFlJ4RBAQEBAwE6PwULAgEINhAyJQEBBAENDYgXCMQ?= =?us-ascii?q?vAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYehEaKFAEEl3kBjgCBVwEVhE2IWo8XA?= =?us-ascii?q?R4BAUKDZ4hUAX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,427,1454976000"; d="scan'208";a="255525547" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Apr 2016 15:12:18 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u31FCHBf030501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Apr 2016 15:12:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 10:12:17 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 1 Apr 2016 10:12:17 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" , "pce@ietf.org" , "mpls@ietf.org" Thread-Topic: Slides for joint MPLS/PCE/TEAS Yang session Thread-Index: AdGJzIBJAjqTFc6SR6KqAkKLpYwjeACXEumg Date: Fri, 1 Apr 2016 15:12:17 +0000 Message-ID: <35b41ff9300b4d51bfbf3a04793205a8@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.167] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [mpls] Slides for joint MPLS/PCE/TEAS Yang session X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 15:12:21 -0000 All, Thanks to those who have sent slides already. Final reminder for those who = haven't :) Cheers Matt > All, >=20 > A reminder on this... if you're presenting, please send slides to me and > the chairs by Friday. >=20 > Cheers >=20 > Matt From nobody Fri Apr 1 09:44:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:32 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [mpls] [Idr] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [mpls] [Idr] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:29 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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 Fri Apr 1 18:03:43 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C412D1D5; Fri, 1 Apr 2016 18:03:41 -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 q3Q9BRYYB40t; Fri, 1 Apr 2016 18:03:40 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97B012D13C; Fri, 1 Apr 2016 18:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5917; q=dns/txt; s=iport; t=1459559019; x=1460768619; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JCtaiOfZ8cpwNyFgtIr2A9cADKg1YfMbbfgUopYjIAQ=; b=ctGMliWSc/upNVudIGS443PAJN0F0RJNBZgBXNLOuzYEybEKoe0eufYW XR5dD70Z62NE0uJk/Z8LGYOh0R/WsxpPoTzkcuclU36y1ps7gcXBe3H4s Ge0Vrargo7SZEdlsS6YPTcu6VPCAMsu8jVlH/mviKCvn1Ai4HZ21LLAz7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgD/Gf9W/4QNJK1dgmtMU28OBrkAg?= =?us-ascii?q?g8BDYFyIYVsAoFCOBQBAQEBAQEBZSeEQQEBAQR5EAIBCBEDAQIoBzIUCQgCBAE?= =?us-ascii?q?NBYgnDsRkAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGHoRGhF4NCYUgBY1Lii8Bj?= =?us-ascii?q?geBZoRNhz+BG4YbiH4BHgEBQoNnbIdofgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,428,1454976000"; d="scan'208,217";a="256538200" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Apr 2016 01:03:38 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3213cpY026309 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Apr 2016 01:03:38 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 1 Apr 2016 20:03:37 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 1 Apr 2016 20:03:37 -0500 From: "Tarek Saad (tsaad)" To: "Tarek Saad (tsaad)" , "mpls@ietf.org" Thread-Topic: MPLS session Agenda for IETF95 Buenos Aires Thread-Index: AQHRg/Ld0L3J40IiE0Kx+8vpnaheN591/9SA Date: Sat, 2 Apr 2016 01:03:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.255.214] Content-Type: multipart/alternative; boundary="_000_D32491D38AEB1tsaadciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls-chairs@ietf.org" Subject: Re: [mpls] MPLS session Agenda for IETF95 Buenos Aires X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 01:03:42 -0000 --_000_D32491D38AEB1tsaadciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, This is a reminder that if you are presenting at MPLS session to please sen= d the slides to me and the chairs. Otherwise, if not, please update the lis= t and chairs with status of your draft as per below. Regards, Tarek and MPLS WG chairs From: Tarek Saad > Date: Tuesday, March 22, 2016 at 12:25 AM To: "mpls@ietf.org" > Cc: "mpls-chairs@ietf.org" > Subject: MPLS session Agenda for IETF95 Buenos Aires Hi WG, The MPLS and (TEAS and PCE) Joint session Agenda for IETF95 is published at= : https://www.ietf.org/proceedings/95/agenda/agenda-95-mpls Please review and let the chairs and myself know of any discrepancies. Note that a written status report is expected for WG drafts that will not b= e presented at the WG session. The status report is expected 1 week prior t= o the WG meeting and needs to include the 3 sections (mostly fits 1 slide): ID name: Current status: Open issues: Next steps: For drafts to be presented, please send the slides by Friday, April 1st. Pl= ease direct the slides and the written status reports to myself, and to the= MPLS WG chairs. Regards, Tarek and MPLS WG chairs --_000_D32491D38AEB1tsaadciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <40134F03853F6741B8F7FA6DFF4C915F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi WG,

This is a reminder that if you are presenting at MPLS session to pleas= e send the slides to me and the chairs. Otherwise, if not, please update th= e list and chairs with status of your draft as per below.

Regards,
Tarek and MPLS WG chairs

From: Tarek Saad <tsaad@cisco.com>
Date: Tuesday, March 22, 2016 at 12= :25 AM
To: "mpls@ietf.org" <mpls@i= etf.org>
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: MPLS session Agenda for IE= TF95 Buenos Aires

Hi WG,

The MPLS and (TEAS and PCE) Joint session Agenda for IETF95 is published at= :
Please review and let the chairs and myself know of any discrepancies.

Note that a written status report is expected for WG drafts that will not b= e presented at the WG session. The status report is expected 1 week prior to the WG meeting and needs to include the 3 sec= tions (mostly fits 1 slide):
ID name:
Current status:
Open issues:
Next steps:

For drafts to be presented, please s= end the slides by Friday, April 1st. Please direct the slides and the writt= en status reports to myself, and to the MPLS WG chairs.

Regards,
Tarek and MPLS WG chairs


--_000_D32491D38AEB1tsaadciscocom_-- From nobody Sat Apr 2 19:19:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FBF12D501; Sat, 2 Apr 2016 19:19:12 -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 FC-iin7zWOcj; Sat, 2 Apr 2016 19:19:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEB112D0F7; Sat, 2 Apr 2016 19:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10603; q=dns/txt; s=iport; t=1459649950; x=1460859550; h=from:to:cc:subject:date:message-id:mime-version; bh=JrUW1mH6wgRQzD/lqt2IU+IzE+eE+xaj9xAb8DuH/T8=; b=mToaBOhX1o28lBFoWhxGfzAoIal8o4WL1t0gBMIdDBq/+ezuhVTpPxUZ KD9gDKhwdlKq+lwS0AXE8EaDvwemXVkWUbWWW6w+OKg2HzS3zkd2XmtEH Sg9sxDrwd75LXwyxUCwGyzmxDFepuEB7kFRM5Dwbop+nJtcJhf3LDC/vO 8=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AgAUfQBX/4wNJK1cgzdTgQO5DIIPD?= =?us-ascii?q?oFyHYVwgSY4FAEBAQEBAQFlJ4REBCNWEgEPOwI0JwQBDROIGbMSkRMBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQENCIYggXUIh0qCQiuCKwWTGIRpAYMfgWaJAo8PjxkBH?= =?us-ascii?q?gFDg2eIFH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,434,1454976000"; d="asc'?scan'208,217";a="256009815" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2016 02:19:09 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u332J89B018492 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Apr 2016 02:19:09 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 2 Apr 2016 22:19:08 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Sat, 2 Apr 2016 22:19:08 -0400 From: "Carlos Pignataro (cpignata)" To: "mpls-chairs@tools.ietf.org" , "draft-saad-mpls-static-yang@ietf.org" Thread-Topic: MPLS-RT review of draft-saad-mpls-static-yang-02 Thread-Index: AQHRjU8zUVXa2yWz/ECZLAj/geOfaA== Date: Sun, 3 Apr 2016 02:19:08 +0000 Message-ID: <6B7C44D8-896F-4563-BBD1-406D9478F78B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.232.173] Content-Type: multipart/signed; boundary="Apple-Mail=_0B4D849D-63C9-43C6-B77E-02E222C6FB84"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: mpls Subject: [mpls] MPLS-RT review of draft-saad-mpls-static-yang-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 02:19:12 -0000 --Apple-Mail=_0B4D849D-63C9-43C6-B77E-02E222C6FB84 Content-Type: multipart/alternative; boundary="Apple-Mail=_27BD5F01-36A8-4930-854C-5667D38DA3FB" --Apple-Mail=_27BD5F01-36A8-4930-854C-5667D38DA3FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Authors, I have been selected as an MPLS Review Team reviewer for = draft-saad-mpls-static-yang-02. This document specifies two separate YANG data models: =E2=80=9Cbase = MPLS=E2=80=9D and =E2=80=9Cstatic LSPs=E2=80=9D. http://www.yangvalidator.com/ gives not = warnings or errors, and idnits is clean. I have one generic and some specific comments about it: First, it=E2=80=99s not clear why this document combines two seemingly = separate sub-documents. Unless there are strong technical reasons, I=E2=80= =99d recommend the authors consider splitting this into two independent = documents: MPLS Base, and Statis LSP respectively. Specifically, if: Note, it is expected that other MPLS YANG models to augment the "ietf-mpls" base model to define specific data to other MPLS technologies (e.g. MPLS LDP or MPLS RSVP-TE). Then it makes sense to have an independent -base. The document is (i.e., the sub-documents are) useful, and coherent. Now, some specific comments: 2.2.1. MPLS Base Module typedef percent { type uint16 { range "0 .. 100"; } description "Percentage"; } RFC 3031 does not speak to percentages of usage. I=E2=80=99m not sure = how this is used. grouping interface-mpls { description "MPLS interface properties grouping"; leaf enabled { type boolean; description "'true' if mpls encapsulation is enabled on the interface. 'false' if mpls encapsulation is enabled on the interface."; } } Seems like a =E2=80=9Cnot=E2=80=9D is missing :-) 2.2.2. MPLS Static LSP YANG Module revision "2016-03-21" { description "Initial revision"; reference "RFC 3031: A YANG Data Model for MPLS Static"; } RFC 3031 does not contain the word =E2=80=9CStatic=E2=80=9D. I know what = static LSPs are, but what=E2=80=99s the Normative reference to it? leaf loadshare { type mpls:percent; description "The percentage of total load tto carry on this path"; } It is not clear to me how this % is used. Also a typo, =E2=80=9Ctto". leaf index { type uint32; description "The index of the label, lower indices are closer to the top"; } Question: Does this model allow the creation of a Label Stack, in which = there is a label with index 1, a label with index 5, and nothing defined = in between? Also, what is an index of value 4294967295 (uint32)? I hope these are useful! =E2=80=94 Carlos. --Apple-Mail=_27BD5F01-36A8-4930-854C-5667D38DA3FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Authors,

I = have been selected as an MPLS Review Team reviewer = for draft-saad-mpls-static-yang-02.

This document specifies = two separate YANG data models: =E2=80=9Cbase MPLS=E2=80=9D and =E2=80=9Cst= atic LSPs=E2=80=9D.

http://www.yangvalidator.com/ gives not warnings or = errors, and idnits is clean.

I have one generic and some specific = comments about it:

First, it=E2=80=99s not clear why this document combines two = seemingly separate sub-documents. Unless there are strong technical = reasons, I=E2=80=99d recommend the authors consider splitting this into = two independent documents: MPLS Base, and Statis LSP = respectively.

Specifically, if:
  =  Note, it is expected that other MPLS YANG models to augment = the
   "ietf-mpls" base model to define = specific data to other MPLS
  =  technologies (e.g.  MPLS LDP or MPLS = RSVP-TE).

Then it makes sense to have an independent -base.

The document is (i.e., = the sub-documents are) useful, and coherent.

Now, some specific comments:

2.2.1.  MPLS Base = Module

     typedef percent {
       type uint16 {
         range "0 .. 100";
       }
  =      description "Percentage";
  =    }

RFC 3031 does not speak to percentages of usage. I=E2=80=99m = not sure how this is used.

     grouping interface-mpls = {
       description "MPLS = interface properties grouping";
    =    leaf enabled {
      =    type boolean;
      =    description
      =      "'true' if mpls encapsulation is enabled on = the
            = interface. 'false' if mpls encapsulation is enabled
            on the = interface.";
       }
     }

Seems like a =E2=80=9Cnot=E2=80=9D is = missing :-)

2.2.2.  MPLS Static LSP YANG Module

  =    revision "2016-03-21" {
    =    description
      =    "Initial revision";
    =    reference
        =  "RFC 3031: A YANG Data Model for MPLS Static";
     }

RFC 3031 does not contain the word = =E2=80=9CStatic=E2=80=9D. I know what static LSPs are, but what=E2=80=99s = the Normative reference to it?

      =  leaf loadshare {
        =  type mpls:percent;
      =    description
      =      "The percentage of total load tto carry on this = path";
       }

It is not clear to me = how this % is used.

Also a typo, =E2=80=9Ctto".

      =    leaf index {
      =      type uint32;
    =        description
  =            "The index of the label, lower = indices are closer to
        =       the top";
      =    }

Question: Does this model allow the creation of a Label = Stack, in which there is a label with index 1, a label with index 5, and = nothing defined in between?

Also, what is an index of value 4294967295 = (uint32)?

I = hope these are useful!

=E2=80=94 Carlos.

= --Apple-Mail=_27BD5F01-36A8-4930-854C-5667D38DA3FB-- --Apple-Mail=_0B4D849D-63C9-43C6-B77E-02E222C6FB84 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXAH2WAAoJEIXgpQGOZny9c+cP+gMqoMeC35cIa97x6hGrK4VC Y5m14euM2PdpWLER/lj9yeYwZ1ntvwJIL/O1BcZ+oDAdK7n46ZTDZAtPiTW6Yycf yYQLTAIxqGLr2RuRczp6TqrveJYrF0KeczFxvYKX0YfYfI74dDVHu0VXWtZpBIYc 4FlRRUSVRJf4ELwcubmRIYWjYoQlnJNLY/hincqiRI9xEwPAwydSJtw0gbAEuAFr EVxxJLGfoyNHBmEiJ7EMw25C6DuISdcKDEP5W7okweuz3/8Bz3tKCLN1P6BG2/X+ 9I/bq8ewQdbB5mfE4ixglBDNbRaQAy4ONmIdgNe1q+wh5i4c98ks9PxfrEy5PrJi n4xo1vmokFsWGAG3+SY7284rtTwzucZ5qDkxQ/3KaAGcNAHBlJBwzHJ7Fph2jp5W I+cu3ARxB7WdHlzv3rMz1zgV/ZuiNH1DNKEq5ZdKtgBT29kp3s1mL4evcSZZmAj3 /IK7vY8e3MHeFY75ihH0gmZAMu6F7lGUZZdJ5vxyRDNSV/75ymDyXoEcrdIaGjHz sTAMW9rrjJxeQJRfMWwfVSk+5HnGPbbX1mIys6S4rxlg3/VJuv1ZpmAqrlXRKaUD 8anzuZrnz476wMbxrUpCaM/riBDuxqHdFnnpenLjH6vRId8aaybaqyBzTQTJdVkd qlZ6T38Ke+bgT2MLdppT =Q5Pi -----END PGP SIGNATURE----- --Apple-Mail=_0B4D849D-63C9-43C6-B77E-02E222C6FB84-- From nobody Mon Apr 4 08:09:43 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2512D78A; Mon, 4 Apr 2016 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=jcucchiara@mindspring.com header.d=mindspring.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 rLUpDbdGkD5T; Mon, 4 Apr 2016 08:09:36 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFB12D724; Mon, 4 Apr 2016 08:09:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MygzPr+zgZb6FBxH1RvETUH8btSmpb5L1ZRY9qD33xPsXlNtbsNElxhQUqQCjFgB; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [72.93.239.57] (helo=JoanTower) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1an67l-0006wp-KB; Mon, 04 Apr 2016 11:09:05 -0400 From: "Joan Cucchiara" To: "Loa Andersson" , , , Date: Mon, 4 Apr 2016 11:10:49 -0400 Message-ID: <00a901d18e84$2c19a340$844ce9c0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGOgu3jx1rdAtVCTCy7UrFLqFTuiw== Content-Language: en-us X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654dda0a30e53f1c0b99b09c09edee31f90676ae045857c2f36350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.93.239.57 Archived-At: Cc: mib-doctors@ietf.org Subject: [mpls] Review of draft-ietf-mpls-tp-linear-protection-mib-07 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 15:09:40 -0000 Comments for draft-ietf-mpls-tp-linear-protection-mib-07.txt Authors, Lots of work went into this draft. The early MIB Doctor review comments have been incorporated, so thank you for that. These comments are arranged in 3 sections: MIB compiler outputs, General Comments which are observations that apply to several places in the MIB and should be checked for throughout the MIB. The last section is for specific comments. Please take these comments as part of the last call. Thanks, -Joan Compiles cleanly with smilint smicng flagged some errors Output from smicng E: f(MPLS-LSP-MIB.my), (370,4) Row "mplsLpsConfigEntry" may not have columns with MAX-ACCESS of read-write if any column is read-create E: f(MPLS-LSP-MIB.my), (378,15) Index item "mplsLpsConfigDomainIndex" must be defined with syntax that includes a range E: f(MPLS-LSP-MIB.my), (907,4) Item "mplsLpsMeConfigDomainIndex" has invalid value for MAX-ACCESS When looking at the MIB, I see that there do appear to be some potential errors: mplsLpsConfigCommand OBJECT-TYPE SYNTAX MplsLpsCommand MAX-ACCESS read-write <---- should be read-create because row created using RowStatus STATUS current In general, indices should specify a range so this is why it was flagged by compiler. Looking at this specific index would like to understand how the value is supposed to be assigned? If this is assigned by an operator, perhaps there should be a mechanism for the operator to choose a value (for example, by using a IndexIntegerNextFree object)? Please clarify. mplsLpsConfigDomainIndex OBJECT-TYPE SYNTAX Unsigned32 mplsLpsMeConfigDomainIndex <--- name implies that this is an index but it is NOT included in the INDEX clause for this table. Please clarify what is intended. General Comments: ===================== * There are mentions of there being two MIB Modules in this document, but there is only one MIB Module. I have tried to note these statements under specific comments, but please check for such statements. If the intention is to create two MIB Modules, that is fine, but currently, there is only one. * The relationships of these Tables is not clear. MplsLpsConfigTable has an INDEX but how the operator is supposed to choose a value for this index is not specified. The MplsLpsMeConfigTable indexing is confusing. Although the document states that this table is an extension of the MPLSOamIdMeTable, the name of the object, mplsLpsMeConfigDomainIndex is confusing because it suggests this is an INDEX (as does the status of not-accessible). Please clarify. Since the indexing for these Tables is confusing to me, then please realize that this MIB may have additional comments during the next review once the indexing is clarified. * In general more REFERENCE Clauses could/should be added throughout MIB. Objects such as mplsLpsMeConfigDomainIndex, mplsLpsMeStatusCurrent, mplsLpsConfigMode, mplsLpsConfigProtectionType, etc. This was also mentioned during the early MIB Dr. review. * Some of the objects use Integer32 but they probably should use Unsigned32. In other words, if the objects can only take on values 0 and above, then they should use Unsigned32. e.g. mplsLpsConfigSdBadSeconds, mplsLpsConfigSdGoodSeconds, mplsLpsConfigWaitToRestore, mplsLpsConfigHoldOff, etc. Please check all the Integer32 objects to see if they should be Unsigned32. *) Date is same a previous version. This should be updated for every revision of the document. Please update. LAST-UPDATED and REVISION clauses "201512060000Z" -- December 06, 2015 *) Only FullCompliance is done for this MIB Module. As you probably are aware, not all operators want to configure using SNMP, if there is not a ReadOnly Compliance available, then they will not be compliant with the MIB. I think a ReadOnly Compliance for a MIB is useful and would like to understand why this MIB doesn't have one. Could the authors please clarify? Specific Comments: Section 1. Introductions Mentions multiple MIB Modules but there is only one. Please clarify the text: "However, since the MIB modules ..." <-- plural Section 4. As mentioned before there is only 1 MIB module. Please update. "This document specifies a MIB module for the Label Edge Router (LER) that supports MPLS TP Linear protection and a MIB module that defines textual conventions....." Section 5.1 Textual Conventions * I don't see a separate MIB Module for TCs. Please clarify. Section 5.4 The Table Structure * The mplsLpsConfigTable "The protection domain is identified by mplsLpsConfigGroupName." This statement does not seem to be entirely accurate given the MIB design for 2 reasons, 1. there doesn't seem to be an object mplsLpsConfigGroupName and 2. the INDEX is mplsLpsConfigDomainIndex Unsigned32 (which also appears in the mplsLpsMeConfigEntry with a status of not-accessible (and I think you intend for it to be an object)? As a reviewer, this is confusing because the relationship with these tables is unclear and so it is very difficult to review the MIB Module. Please clarify the relationship with these tables and to the mplsOamIdMeTable in the MPLS-OAM-ID-STD-MIB. "The other attributes in this table", do you mean objects? * The mplsLpsStatusTable There is no mention that the mplsLpsStatusTable's Entries have an AUGMENTS relationship with the mplsLpsConfigTable Entries. Please add. 6.1 Relationship to the MPLS OAM maintenance identifier MIB Module The title needs to be capitalized correctly, Relationship to the MPLS OAM Maintenance Identifier MIB Module Please update this section to use RFC7697 (and in Informative References also) instead of draft-ietf-mpls-tp-oam-id-mib. As mentioned above, the mplsLpsMeConfigTable has an object mplsLpsMeConfigDomainIndex which is (not-accessible). Is this supposed to be an INDEX, or is this an object? I am confused by what is intended. 7. Example of Protection switching configuration for MPLS-TP TE tunnel (Please change title: Example of Protection Switching Configuration) * I am unclear how mplsLspConfigEntry is actually configured for use in this example. Is an operator supposed to randomly choose an INDEX value? Would an IndexNext object be useful to use in conjunction with this INDEX? MIB Module ------------ (general comment: the DESCRIPTION clauses could be more readable if consistency was used. Sometimes the value is listed on the side and the description follows on the same line and sometimes the value is listed on a single line and the description follows a couple of lines after. Please be consistent.) * mplsLpsConfigDomainName -- Is there a DEFAULT value for this object? The string size is 1..32 with no option of 0 length string, so wanted to check about a default value? Under what circumstances can this value be modified? Please give a REFERENCE. * mplsLpsConfigMode - Needs REFERENCE (and please try to be specific). Under what circumstances can this be modified? * mplsLpsConfigWaitToRestore Why is this not in minutes? If someone configures this to be 30 seconds is that valid? Doesn't seem so based on the DESCRIPTION. Please clarify. * mplsLpsConfigHoldOff What is meant by "Can be configured in steps of 100?" Is this 100 milliseconds? If so then maybe a better unit choice would be centiseconds. Please clarify. *mplsLpsConfigCommand is read-write. Is this supposed to be read-create? *mplsLpsConfigRowStatus -- I think there is some conflicting advice given to the operator. Several objects say that it is fine to change the value of the object when RowStatus is active, but this is not specified consistently. Limiting the values of RowStatus in the Conformance Section may be the way to go. Please clarify. *mplsLpsMeConfigState is a read-create. This is probably okay, but again, that depends on if mplsLpsMeConfigDomainIndex is an INDEX for this table given that it has a status of not-accessible, etc. *mplsLpsMeStatusSwitchoverSeconds Needs a units clause for Seconds Notifications There are a couple Notifications that are send when values of certain counters increment. Maybe this is valid, but it seems suspect. If a management stations needs information on counters, why can't it just retrieve them at that point? I don't see any counter discontinuity objects, so was wondering about that too. * mplsLpsEventFopTimOut Notification Please rename this to mplsLpsEventFopTimeout * Compliance/Conformance Section of the MIB Module Currently, there is only FullCompliance. Why is there no ReadOnlyCompliance? --- end of comments --- From nobody Mon Apr 4 12:57:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72A512D852; Mon, 4 Apr 2016 12:57:09 -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 1JFPSSRNgoRz; Mon, 4 Apr 2016 12:57:07 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D7E12D64E; Mon, 4 Apr 2016 12:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4300; q=dns/txt; s=iport; t=1459799827; x=1461009427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e/hHVts3lRt2j0pc9FY5+oyiKHyRnpuuuzfsOO4bI00=; b=F+PrnIw6hgD7KTdJKNBe6NriEKd0rz+ybJS99qvree5kCCUTJNkvWlHx xXdr3U+Z6gFxF7EOYnb1JzkrcKsOpARZMP2aGlR0/on26OHvDppFOu4rI KANyxm/T3qr5db9DOxgJvyMPshnOQmHo4gycqIGD3jrtjzcSMhL20PlHU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAkxgJX/4UNJK1aA4M3U30GuyEBD?= =?us-ascii?q?YFyFwqFIkoCHIEeOBQBAQEBAQEBZSeEQQEBAQMBAQEBIBE6CwUHAgICAQgOAgE?= =?us-ascii?q?DAQIBAgIfBwICAhkMCxUICAIEDgWIHwgOrHyRUQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARUEeIUkgXWCVYRVCyaCOSuCKwWYAQGFcogVgWiETYhajxkBHgEBQoIygTV?= =?us-ascii?q?shyh+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="255851151" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 19:57:06 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34Jv6iU006598 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 19:57:06 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:57:05 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 14:57:05 -0500 From: "Rajiv Asati (rajiva)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ91JyyAgAUq7AA= Date: Mon, 4 Apr 2016 19:57:05 +0000 Message-ID: References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> In-Reply-To: <20160401090207.GA50653@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.12.15] Content-Type: text/plain; charset="utf-8" Content-ID: <0A7EB26C856AB44FA6227A80EE87FF60@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 19:57:10 -0000 SGkgSnVlcmdlbiwNCg0KPiBPcGVyYXRpb25hbCBzdGF0ZSBvZnRlbiBoYXMgYSBkaWZmZXJlbnQg bGlmZXRpbWUgdGhhbiBjb25maWcuIEhlbmNlLA0KDQoNCkhtbS4uQ291bGQgeW91IHBsZWFzZSBj bGFyaWZ5IHRoZSBhYm92ZSBhIGJpdCBtb3JlPw0KDQotLSANCkNoZWVycywNClJhaml2IA0KDQoN Cg0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1ZXJnZW4g U2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KUmVw bHktVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPg0KRGF0ZTogRnJpZGF5LCBBcHJpbCAxLCAyMDE2IGF0IDU6MDIgQU0NClRvOiBS YWppdiBBc2F0aSA8cmFqaXZhQGNpc2NvLmNvbT4NCkNjOiAibmV0bW9kQGlldGYub3JnIiA8bmV0 bW9kQGlldGYub3JnPiwgIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtuZXRtb2RdIFlBTkcgLSBJbnRlbmRlZC1Db25maWcgJiBBcHBsaWVkLUNvbmZpZyAmIERl cml2ZWQtU3RhdGUgJiBPcGVyYXRpb25hbC1zdGF0ZS4uLmdycnJyLi4uICEhDQoNCj5PcGVyYXRp b25hbCBzdGF0ZSBvZnRlbiBoYXMgYSBkaWZmZXJlbnQgbGlmZXRpbWUgdGhhbiBjb25maWcuIEhl bmNlLA0KPmtlZXBpbmcgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZSB0b2dldGhlciBpbiB0 aGUgc2FtZSBzdHJ1Y3R1cmUNCj4od2l0aCB0aGUgc2FtZSBuYW1pbmcpIGNhdXNlcyB5b3UgcHJv YmxlbXMgZG93biB0aGUgcm9hZC4NCj4NCj4vanMNCj4NCj5PbiBUaHUsIE1hciAzMSwgMjAxNiBh dCAwNjo0NDowNlBNICswMDAwLCBSYWppdiBBc2F0aSAocmFqaXZhKSB3cm90ZToNCj4+IA0KPj4g V2hpbGUgd29ya2luZyBvbiBNUExTIExEUCB5YW5nIG1vZGVsIChodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmF6YS1tcGxzLWxkcC1tbGRwLXlhbmcpLCB3ZSBub3RpY2VkIHRoZSBw b3NzaWJsZSBjb25mdXNpb24gYXJvdW5kIHN0cnVjdHVyaW5nIGludGVuZGVkIGNvbmZpZywgYXBw bGllZCBjb25maWcgYW5kIGRlcml2ZWQgc3RhdGUgKi4NCj4+IA0KPj4gT24gb25lIGhhbmQsIG9u ZSBtYXkgaGF2ZSAnaW50ZW5kZWQtY29uZmln4oCZIChSVykgYW5kIOKAmGFwcGxpZWQtY29uZmln 4oCZIChSTykgaW4gdGhlIHNhbWUgY29uc3RydWN0IChjb250YWluZXIpLCBhbmQg4oCYZGVyaXZl ZCBzdGF0ZeKAmSAoUk8pIGluIGEgc2VwYXJhdGUgY29uc3RydWN0IChjb250YWluZXIpLiANCj4+ IA0KPj4gCVRoaXMga2VlcHMgY29uZmlnIHRvZ2V0aGVyLCBidXQgZG9lc27igJl0IGhlbHAgb3Bl cmF0aW9uYWwgc3RhdGUsIHdoaWNoIHJlcXVpcmVzDQo+PiAJQm90aCBBcHBsaWVkLWNvbmZpZyBh bmQgZGVyaXZlZC1zdGF0ZS4NCj4+IA0KPj4gT24gdGhlIG90aGVyIGhhbmQgaGFuZCwgb25lIG1h eSBoYXZlIOKAmGludGVuZGVkLWNvbmZpZ+KAmSBpbiBvbmUgY29uc3RydWN0IChjb250YWluZXIp LCBhbmQg4oCYYXBwbGllZC1jb25maWfigJkgYW5kIOKAmGRlcml2ZWQgc3RhdGXigJkgaW4gYSBz ZXBhcmF0ZSBjb25zdHJ1Y3QgKGNvbnRhaW5lcikuIA0KPj4gDQo+PiAJVGhpcyBzaW1wbGlmaWVz IGZpZ3VyaW5nIG9wZXJhdGlvbmFsLXN0YXRlLCBidXQgZGl2aWRlcyB0aGUgY29uZmlnIHR5cGVz Lg0KPj4gDQo+PiBUaGVyZSBhcmUgcHJvcyAmIGNvbnMgZWl0aGVyIHdheS4gSXQgd291bGQgYmUg Z29vZCB0byBoYXZlIHNvbWUgZ3VpZGFuY2UvdGV4dCBhcm91bmQgZ3VpZGluZyBvbmUgb3ZlciBh bm90aGVyLCBzbyB0aGF0IG90aGVyIG1vZGVscyBjYW4gbGV2ZXJhZ2UuIE90aGVyd2lzZSwgd2Ug YXJlIGdvaW5nIHRvIGVuZCB1cCB3aXRoIHlldCBvbmUgbW9yZSBkaXNjcmVwYW5jeSAoYW1vbmcg dmFyaW91cyBwcm90b2NvbHMgWUFORyBtb2RlbHMpLCAmIGNvbmZ1c2luZyBpZiBub3QgaW5lZmZp Y2llbnQgbW9kZWxpbmcuDQo+PiANCj4+IFBlcmhhcHMsIHdlIGRpdGNoIGJvdGggb2YgdGhlIGFi b3ZlIGFwcHJvYWNoZXMsIGFuZCBzZXR0bGUgb24ga2VlcGluZyBhbGwgdGhyZWUgb2YgdGhlbSBp biB0aGUgc2FtZSBjb25zdHJ1Y3QuIEl0IG1pZ2h0IHNpbXBsaWZ5IHRoZSBvcmdhbml6YXRpb24g YSBiaXQuIE9mIGNvdXJzZSwgdGhhdCBhbHNvIGhhcyAyIG9wdGlvbnMgLSBoYXZlIGFsbCB0aGUg ZGF0YSB0eXBlcyBpbiBpbnRlbmRlZC1jb25maWcsIGFuZCB0aGVuIGluIGFwcGxpZWQtY29uZmln IGFuZCB0aGVuIGluIGRlcml2ZWQtc3RhdGUuIE9yIGhhdmUgaW50ZW5kZWQtY29uZmlnLCBhcHBs aWVkLWNvbmZpZyBhbmQgZGVyaXZlZC1zdGF0ZSBmb3IgZWFjaCBkYXRhIHR5cGUuIExhdHRlciBt aWdodCBiZSBzbGlnaHRseSBiZXR0ZXIsIGdpdmVuIHRoYXQgbm90IGV2ZXJ5IGRhdGEgdHlwZSB3 aWxsIGhhdmUgYWxsIHRocmVlLg0KPj4gDQo+PiANCj4+IFRob3VnaHRzPyANCj4+IA0KPj4gLS0g DQo+PiBDaGVlcnMsDQo+PiBSYWppdiBBc2F0aQ0KPj4gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlciwg Q2lzY28NCj4+IA0KPj4gDQo+PiAqIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDQ+DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZQ0KPj4gDQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcg bGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldG1vZA0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0K From nobody Mon Apr 4 13:44:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19B12D815; Mon, 4 Apr 2016 13:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 FRH7c151dO0n; Mon, 4 Apr 2016 13:44:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F075012D869; Mon, 4 Apr 2016 13:43:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B36F254; Mon, 4 Apr 2016 22:43:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ak8rj3oQdGtg; Mon, 4 Apr 2016 22:43:54 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 4 Apr 2016 22:43:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15EB720045; Mon, 4 Apr 2016 22:43:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0h34jNDHhV4b; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CA8F20043; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D7EE3A70C01; Mon, 4 Apr 2016 22:43:57 +0200 (CEST) Date: Mon, 4 Apr 2016 22:43:56 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160404204356.GA57133@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 20:44:01 -0000 On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiva) wrote: > Hi Juergen, > > > Operational state often has a different lifetime than config. Hence, > > > Hmm..Could you please clarify the above a bit more? > The classic example: When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Obviously, I can also have operational state of an interface that has not been configured yet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Apr 4 14:28:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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 Mon Apr 4 15:16:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B17E12D8D7; Mon, 4 Apr 2016 15:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jl9iwtL8y6yN; Mon, 4 Apr 2016 15:16:09 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B9A12D8CC; Mon, 4 Apr 2016 15:16:09 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-b9-5702e7830277 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.C7.22441.387E2075; Tue, 5 Apr 2016 00:15:31 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:16:08 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byA== Date: Mon, 4 Apr 2016 22:16:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPlG7zc6Zwg/e9shafHl5itjiw6SCj xbrLp9gsbi1dyWqx5PY9dovPf7YxOrB57Jx1l91jyZKfTB5fLn9mC2CO4rJJSc3JLEst0rdL 4Mq4tPMxS8Edg4q56xIbGJdpdzFyckgImEh8uT2NBcIWk7hwbz1bFyMXh5DAUUaJXTvnsEI4 yxglZv49ww5SxSZgJPFiYw+YLSLgJbFi8ipmkCJmgXYmiYMP9oGNEhawlXj9/Q1UkZPEhyuL WSFsPYnDazaBxVkEVCSWfZkLVs8r4Ctx8eBLZhCbEeiM76fWMIHYzALiEreezGeCOE9AYsme 88wQtqjEy8f/WCFsJYmPv+ezQ9TnS/SvbWaHmCkocXLmE5YJjMKzkIyahaRsFpIyiLiOxILd n9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7S4ICc33chwEyMwso5JsDnuYNzb63mIUYCDUYmH d8EpxnAh1sSy4srcQ4wSHMxKIrz7HjKFC/GmJFZWpRblxxeV5qQWH2KU5mBREuf1jvwXJiSQ nliSmp2aWpBaBJNl4uCUamDM2Gzw/4e8oJfHB383ua4fTQvXex/IE9R4FXP6l9bXXf33/YVZ C9+F6T88Nr20/YqfX2qOZ1jrFAfXny97VlzrfNi34Meh5N9SNpLJht/O+CQ9O77qo9yZ5XmH by4VEGbTSu1f+88kbXZaDuPOTQePVmxf2s1XJ7Lim9lvBusX/+trxU7ZrLisxFKckWioxVxU nAgAIqprH6gCAAA= Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd-chairs@ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:16:11 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

·         BFD on MC-LAG interfaces in IP network<= o:p>

·         BFD on MC-LAG interfaces in IP/MPLS netwo= rk

 

Greatly appreciate your reviews, comments, questions= and suggestions.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF11221A3CCEDeusaamb103erics_-- From nobody Mon Apr 4 15:23:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83712D8BE; Mon, 4 Apr 2016 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 dWzUQcHxFOPG; Mon, 4 Apr 2016 15:23:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB84F12D190; Mon, 4 Apr 2016 15:23:12 -0700 (PDT) Received: from [172.29.97.1] (unknown [66.129.239.15]) by slice.pfrc.org (Postfix) with ESMTPSA id 88B831E384; Mon, 4 Apr 2016 18:27:16 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F" From: Jeffrey Haas In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Date: Mon, 4 Apr 2016 19:23:05 -0300 Message-Id: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:23:14 -0000 --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Working Group, These documents reasonably extend the existing BFD on LAG mechanism and = would be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the = other co-authors state whether there's any known IPR on these documents? -- Jeff > On Apr 4, 2016, at 7:16 PM, Gregory Mirsky = wrote: >=20 > Dear All, > two new drafts, related to RFC 7130, were published before the = meeting: > =C2=B7 BFD on MC-LAG interfaces in IP network = > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network = > =20 > Greatly appreciate your reviews, comments, questions and suggestions. > =20 > Regards, > Greg --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Working Group,

These documents reasonably extend the existing BFD on LAG = mechanism and would be reasonably in charter for BFD to pick = up.

Greg, = given that adoption seems a reasonable course, could you and the other = co-authors state whether there's any known IPR on these = documents?

-- = Jeff

On = Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear = All,
two new = drafts, related to RFC 7130, were published before the meeting:
=C2=B7         BFD on = MC-LAG interfaces in IP network
=C2=B7         BFD on = MC-LAG interfaces in IP/MPLS network
 
Greatly appreciate your reviews, = comments, questions and suggestions.
 
Regards,
        = Greg

= --Apple-Mail=_FEE1AF2A-A2AE-4E9C-B4FF-7333D4D8EF4F-- From nobody Mon Apr 4 15:31:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAE112D8D7; Mon, 4 Apr 2016 15:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cBjfku9MEed7; Mon, 4 Apr 2016 15:31:33 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E84E12D594; Mon, 4 Apr 2016 15:31:33 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-1d-5702e524af96 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C9.54.30335.425E2075; Tue, 5 Apr 2016 00:05:25 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:31:32 -0400 From: Gregory Mirsky To: Jeffrey Haas Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTA= Date: Mon, 4 Apr 2016 22:31:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyuXRPoK7qU6Zwg9M7+C0+PbzEbHFg00FG i/0H37JarLt8is3i1tKVrBaf/2xjdGDz2DnrLrvHkiU/mTwu925l9fhy+TNbAEsUl01Kak5m WWqRvl0CV8acrrnMBStSK87uWsXSwHgiqYuRk0NCwERiSm8rM4QtJnHh3no2EFtI4CijxPRD Pl2MXED2MkaJyUdmMIEk2ASMJF5s7GEHsUUEFCXm/+9kAyliFpjFJDHv7k+wbmEBR4nv868x QxQ5SXy4spgVwraS+LBoPQuIzSKgIrFw+S6wOK+Ar8S6r6uZITbXS5zdvgdsGaeAjcTDp9fB bEag676fWgNmMwuIS9x6Mp8J4moBiSV7zkN9ICrx8vE/VghbSeLj7/nsEPX5EmvmLYHaJShx cuYTlgmMorOQjJqFpGwWkrJZjBxAcU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvoqRo7S4 ICc33chgEyMwIo9JsOnuYLw/3fMQowAHoxIP74JTjOFCrIllxZW5hxglOJiVRHj3PWQKF+JN SaysSi3Kjy8qzUktPsQozcGiJM7bGPwvTEggPbEkNTs1tSC1CCbLxMEp1cDYm73ztVinHEfr 0a+WfckPdLm2N7icYi986a2f+nK+t8XD9ra351Xm7uc8GFta9lt6R/I81iOvni6w9hXU4Njt cnuakcPZY3Xx336ycBdyuJlqp2QILhQWr2079+NPy9yqMzKZ0wXOpviofJuTUFVWJvsvs87g ZcuLlxqzuM8u7TFv53qnvV2JpTgj0VCLuag4EQAVidT+xAIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:31:41 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwNCndlIGhhdmUgbm90IGV4cGVjdGVkIHRoaXMgcXVlc3Rpb24gdGhhdCBlYXJseSDi mLoNClllcywgdGhlcmXigJlzIElQUiBhc3NvY2lhdGVkIHdpdGggdGhlc2UgZHJhZnRzIHRoYXQg d291bGQgYmUgcHJvcGVybHkgZGlzY2xvc2VkIGFmdGVyIHRoZSBtZWV0aW5nLg0KDQogICAgICAg ICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0K DQpGcm9tOiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZ10NClNlbnQ6IE1vbmRh eSwgQXByaWwgMDQsIDIwMTYgMzoyMyBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5DQpDYzogcnRnLWJm ZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWct aXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxzLWNoYWlyc0Bp ZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pDQpTdWJqZWN0OiBSZTogVHdv IG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcw0KDQpXb3Jr aW5nIEdyb3VwLA0KDQpUaGVzZSBkb2N1bWVudHMgcmVhc29uYWJseSBleHRlbmQgdGhlIGV4aXN0 aW5nIEJGRCBvbiBMQUcgbWVjaGFuaXNtIGFuZCB3b3VsZCBiZSByZWFzb25hYmx5IGluIGNoYXJ0 ZXIgZm9yIEJGRCB0byBwaWNrIHVwLg0KDQpHcmVnLCBnaXZlbiB0aGF0IGFkb3B0aW9uIHNlZW1z IGEgcmVhc29uYWJsZSBjb3Vyc2UsIGNvdWxkIHlvdSBhbmQgdGhlIG90aGVyIGNvLWF1dGhvcnMg c3RhdGUgd2hldGhlciB0aGVyZSdzIGFueSBrbm93biBJUFIgb24gdGhlc2UgZG9jdW1lbnRzPw0K DQotLSBKZWZmDQoNCk9uIEFwciA0LCAyMDE2LCBhdCA3OjE2IFBNLCBHcmVnb3J5IE1pcnNreSA8 Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nv bi5jb20+PiB3cm90ZToNCg0KRGVhciBBbGwsDQp0d28gbmV3IGRyYWZ0cywgcmVsYXRlZCB0byBS RkMgNzEzMCwgd2VyZSBwdWJsaXNoZWQgYmVmb3JlIHRoZSBtZWV0aW5nOg0K4oCiICAgICAgICAg QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQIG5ldHdvcms8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwPg0K4oCiICAgICAg ICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4N Cg0KR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgcmV2aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBh bmQgc3VnZ2VzdGlvbnMuDQoNClJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0K --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHls ZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBKZWZmLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj53ZSBoYXZlIG5vdCBleHBlY3RlZCB0aGlzIHF1ZXN0aW9uIHRoYXQgZWFybHkNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgdGhlcmXigJlzIElQUiBh c3NvY2lhdGVkIHdpdGggdGhlc2UgZHJhZnRzIHRoYXQgd291bGQgYmUgcHJvcGVybHkgZGlzY2xv c2VkIGFmdGVyIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmVmZnJleSBIYWFzIFttYWlsdG86amhh YXNAcGZyYy5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJpbCAwNCwgMjAxNiAz OjIzIFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gcnRn LWJmZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1s YWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxzLWNoYWly c0BpZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRl cmZhY2VzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V29y a2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZXNlIGRvY3VtZW50cyByZWFzb25hYmx5IGV4dGVuZCB0aGUgZXhpc3RpbmcgQkZEIG9uIExB RyBtZWNoYW5pc20gYW5kIHdvdWxkIGJlIHJlYXNvbmFibHkgaW4gY2hhcnRlciBmb3IgQkZEIHRv IHBpY2sgdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkdyZWcsIGdpdmVuIHRoYXQgYWRvcHRpb24gc2VlbXMgYSByZWFzb25hYmxlIGNvdXJz ZSwgY291bGQgeW91IGFuZCB0aGUgb3RoZXIgY28tYXV0aG9ycyBzdGF0ZSB3aGV0aGVyIHRoZXJl J3MgYW55IGtub3duIElQUiBvbiB0aGVzZSBkb2N1bWVudHM/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIEplZmY8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEFwciA0LCAyMDE2LCBhdCA3OjE2IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlYXIgQWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHdvIG5ldyBkcmFmdHMsIHJlbGF0ZWQgdG8gUkZDIDcxMzAs IHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0aGUgbWVldGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5CRkQNCiBvbiBNQy1MQUcgaW50ZXJmYWNlcyBpbiBJUCBuZXR3b3JrPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj7C tzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1i ZmQtbWMtbGFnLW1wbHMtMDAiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPkJGRA0KIG9uIE1D LUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5k IHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjI1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF11221A3CD69eusaamb103erics_-- From nobody Mon Apr 4 15:44:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A712D8E6; Mon, 4 Apr 2016 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ0JstDY8hIz; Mon, 4 Apr 2016 15:44:31 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A419A12D8D3; Mon, 4 Apr 2016 15:44:31 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-1c-5702ee28737a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 56.39.22441.82EE2075; Tue, 5 Apr 2016 00:43:52 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 4 Apr 2016 18:44:29 -0400 From: Jeff Tantsura To: Gregory Mirsky Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5w== Date: Mon, 4 Apr 2016 22:44:28 +0000 Message-ID: <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXRPlK7GO6Zwg+lLTS0+PbzEbHFg00FG i/0H37JarLt8is3i1tKVrBaf/2xjdGDz2DnrLrvHkiU/mTwu925l9fhy+TNbAEsUl01Kak5m WWqRvl0CV8ajWx3sBStCK+Z2tTA1ME7w6WLk5JAQMJE4eWsaC4QtJnHh3nq2LkYODiGBo4wS Z9W7GLmAzGWMEt0vnzGD1LAJGEj8/3YcrF4EyL69bDkzSBGzwF4miRUbD4ElhAUcJY63zIQq cpL4cGUxK4y9eM83sDiLgIrEvfWf2UFsXgF7iZs/j7BBbDvIKPHifxcTSIJTwE9idXMLWBEj 0HXfT60BizMLiEvcejKfCeJqAYkle84zQ9iiEi8f/2OFqEmWWLxtKivEAkGJkzOfsExgFJmF pH0WkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhFZfAEj+ypGjtLigpzcdCPDTYzA2Dsm wea4g3Fvr+chRgEORiUe3gWnGMOFWBPLiitzDzFKcDArifDue8gULsSbklhZlVqUH19UmpNa fIhRmoNFSZzXO/JfmJBAemJJanZqakFqEUyWiYNTqoFxVtmO4idb+blOPfuYwrqZ6fYmPeZl 9jd4Hyn1dfAI2CU+2HXfovmgypYUxz18X5afYkryfRg2LSp8zyktwxW2TIm57odTDx1qW77I 8+XrwFOT63/Onj/LosDtxrInnUnZ1QxzouX+7HgYt/m5eZVGh/HHyybmF6z2fTi1tbtj3bkv T6IDhdasU2Ipzkg01GIuKk4EAMlmkH65AgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:44:34 -0000 --_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there=92s IPR associated with these drafts that would be properly disc= losed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: =95 BFD on MC-LAG interfaces in IP network =95 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Thanks!

IPR will be disclosed ASAP, we are pushing l= egal.

Regards,
Jeff

On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Jeff,

we have not expected this= question that early J

Yes, there=92s IPR associ= ated with these drafts that would be properly disclosed after the meeting.<= o:p>

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Jeffrey = Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Working Group,

 

These documents reasonably extend the existing BFD o= n LAG mechanism and would be reasonably in charter for BFD to pick up.=

 

Greg, given that adoption seems a reasonable course,= could you and the other co-authors state whether there's any known IPR on = these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&g= t; wrote:

 

Dear All,

two new drafts, related to RFC 7130, we= re published before the meeting:

=B7&nbs= p;        BFD on MC-LAG interfaces in IP network

=B7&nbs= p;        BFD on MC-LAG interfaces in IP/MPLS network

 

Greatly appreciate your reviews, commen= ts, questions and suggestions.

 

Regards,

      &nb= sp; Greg

 

--_000_33673FCF6DF94E0F9BA295D670259F76ericssoncom_-- From nobody Tue Apr 5 05:05:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:29:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: "mpls@ietf.org" , BESS , "idr@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:30:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582B112D94B; Tue, 5 Apr 2016 06:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 Ug-n10O9Nk3J; Tue, 5 Apr 2016 06:30:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C431E12D961; Tue, 5 Apr 2016 06:29:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79ABE1E83B; Tue, 5 Apr 2016 09:33:52 -0400 (EDT) Date: Tue, 5 Apr 2016 09:33:52 -0400 From: Jeffrey Haas To: Gregory Mirsky Message-ID: <20160405133352.GA13701@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 13:30:07 -0000 Greg (and Jeff T.): On Mon, Apr 04, 2016 at 10:31:30PM +0000, Gregory Mirsky wrote: > Hi Jeff, > we have not expected this question that early ☺ > Yes, there’s IPR associated with these drafts that would be properly disclosed after the meeting. The ADs have been prodding us extra hard about IPR recently. :-) A relevant section from BCP 79: : 6.2.2. Timing of Disclosure Under Section 6.1.2 : : The IPR disclosure required pursuant to section 6.1.2 must be made as : soon as reasonably possible after the Contribution is published in an : Internet Draft or RFC, unless the required disclosure is already on : file. Participants who realize that the IPR will be or has been : incorporated into a submission to be published in an Internet Draft, : or is seriously being discussed in a working group, are strongly : encouraged to make at least a preliminary disclosure. That : disclosure should be made as soon after coming to the realization as : reasonably possible, not waiting until the document is actually : posted or ready for posting. Thus it's okay to just note on the mailing list that you're aware of IPR and that a formal declaration should be getting filed at some point in the future. -- Jeff From nobody Tue Apr 5 07:26:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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 Tue Apr 5 13:39:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2138912D83F; Tue, 5 Apr 2016 13:39:54 -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, 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, WEIRD_PORT=0.001] 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 NJgFweibG8OL; Tue, 5 Apr 2016 13:39:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A73412D836; Tue, 5 Apr 2016 13:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=167; q=dns/txt; s=iport; t=1459888792; x=1461098392; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=WVWCRG/07R8i/JECQKKyX1vZhmrvOu1BXWANo/5HLaY=; b=CDUoaQYJplAAgOZkDIrKXBBB3qwdrhcl6MXLjpJDtLZv6fhoW2GZzfal 6sMrZvnC1kwo4TwGbT0KEijyyHIL2Sa3ntQm3YUCKypglabuNra/+uNS2 jvcTabjzEPctHXUo5AYslsvJoveMIHLtRfksR/LcLTy/8a0G5pUivL6CJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAgA8IgRX/5hdJa1egzdTfQEFuzMBD?= =?us-ascii?q?YFyI4ULVQEJgUU4FAEBAQEBAQFlJ4REBDo/EgE+QiYBBAENDYgfDsBeAQEBAQE?= =?us-ascii?q?BBAEBAQEBG4YgjmAFmAEBgSqESIgOgVkBY4xZjxkBHgEBQoNpbYc4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,445,1454976000"; d="scan'208";a="257705357" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2016 20:39:51 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u35KdpnZ004393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Apr 2016 20:39:51 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 15:39:49 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 15:39:50 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" , "pce@ietf.org" , "mpls@ietf.org" Thread-Topic: Etherpad for joint Yang session Thread-Index: AdGPezP81oAQhYhiRwGOO5CHHpt21A== Date: Tue, 5 Apr 2016 20:39:49 +0000 Message-ID: <3b86206d701d40b5846991ebd6a63d17@XCH-RCD-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.240.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [mpls] Etherpad for joint Yang session X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 20:39:54 -0000 All, It's at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas?useMonospa= ceFont=3Dtrue, for those who would like to help take notes :) Cheers Matt From nobody Tue Apr 5 14:40:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C89A12D8A5 for ; Tue, 5 Apr 2016 14:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvY8AvY_eOni for ; Tue, 5 Apr 2016 14:40:37 -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 7D95B12D87C for ; Tue, 5 Apr 2016 14:40:35 -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 u35LeUee012773; Tue, 5 Apr 2016 22:40:30 +0100 Received: from 950129200 (dhcp-b176.meeting.ietf.org [31.133.177.118]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u35LeQuX012730 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 5 Apr 2016 22:40:29 +0100 From: "Adrian Farrel" To: "'Tarek Saad \(tsaad\)'" Date: Tue, 5 Apr 2016 22:40:24 +0100 Message-ID: <05bc01d18f83$c57bfce0$5073f6a0$@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: AdGPg8LnS/Q238/OTT2W31FDp3LJKA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22242.003 X-TM-AS-Result: No--15.525-10.0-31-10 X-imss-scan-details: No--15.525-10.0-31-10 X-TMASE-MatchedRID: p0L1Z1x7Q+ISgM/Uj2D7Z5YsKSXWWrsH7f6JAS2hKPgqZxxkqEcpQKXW QHlyUw5BDk4QqkUOED38vxPePJS2/EHWbmeNr66RJXKk/roE/RBAq6/y5AEOOkuCjz4ggdtwr5c H6L5+Gu/hfzyvfuuotXxXxESuqtFrfjm4FmbDbT1oMLOoNHsM9n+ogtHzaKWZKejUeeGx1kqJcp skrgVsKetV/7BI68ecNjRCMbQ8PqrmzYT8cOkbWemc4/pDEQa2fS0Ip2eEHny+qryzYw2E8H2PY bDNMTe9KrauXd3MZDUD/dHyT/Xh7Q== Archived-At: Cc: mpls@ietf.org Subject: [mpls] My question about "static LSP" in TEAS today X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:40:39 -0000 Hi, I probably wasn't clear in my question. To restate, my question is why is the static LSP model modelling an end-to-end LSP and not just a single "cross connect"? Alternatively, what is the difference between an LSP provisioned by a control plane, and an LSP provisioned by the management plane? And we might even bring in "soft permanent LSPs" that are a stitching together of some static segments and some dynamic segments. (You might look at the LSR MIB module that can be used to provision [aka model] static LSPs.) When you model maybe you need to think about what is the purpose of modelling. There are three things going on: What is the user/application asking for? What state is held in the network? What does the data plane have? In this case there is no control plane, but there is still distributed state installed in the network. You said that this is not a data plane model, which is fine. So you are modelling either the state in the network or the user's request. Now, there may be protocol state (such as parameters of RSVP-TE that exist to keep the protocol on side) that are special, but the parameters that describe the state that applies to the LSP are surely identical regardless of how the LSP was set up. That is, the LSP is a sequence interfaces and labels as well as some information about reserved resources. I think I'm rambling. What I am trying to say is that an LSP is an LSP. Cheers, Adrian From nobody Tue Apr 5 15:16:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19DA12D9DC for ; Tue, 5 Apr 2016 15:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 cRaxPYITMHMa for ; Tue, 5 Apr 2016 15:16:37 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 3C44112D9F2 for ; Tue, 5 Apr 2016 15:16:33 -0700 (PDT) Received: (qmail 15651 invoked by uid 0); 5 Apr 2016 22:16:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy1.mail.unifiedlayer.com with SMTP; 5 Apr 2016 22:16:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id emGV1s0042SSUrH01mGYYZ; Tue, 05 Apr 2016 16:16:32 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=M3ZuGdgw_WQ_UY_NvEgA:9 a=ZLQGR1iwBc2ZVOZL:21 a=bSRAwGi2EVjKxk_Z:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To; bh=kXDTUC2KO27BlsvyV+M1trRS61z81+7bnhxw4JJSwPU=; b=UaaSh2mS6ObVcGe3L5WRzhbfntkwCcs/MnrlkTfW3S3gEmgi6w4eK6IiHBxj3uptE5cGPiADjf Gk3RUI1qLlq6ASOcYvEr8yvA65Cq0X28WvDAJjgqF9xt9HxP9nX2Az; Received: from box313.bluehost.com ([69.89.31.113]:56483 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anZGu-0005AZ-Ma; Tue, 05 Apr 2016 16:16:29 -0600 To: mpls@ietf.org, PCE WG List , TEAS WG From: Lou Berger Message-ID: <57043936.40307@labn.net> Date: Tue, 5 Apr 2016 18:16:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [mpls] Raw notes from joint session X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 22:16:42 -0000 Here are the raw notes from today's session. Please review and correct (at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-teas). Just a reminder the notes should only cover what was actually said at mics in the session, and these are input to the final minutes. Recordings of the session are also available. Thanks to Matt and all others who contributed to the notes and the successful meeting! Lou (+ cast of many co-chairs) > > > TEAS/MPLS/PCE Yang Agenda For IETF 95 > Version: Mar 31, 2016 > > Tuesday, April 5th, 2016 > 17:30 - 19:10 - Tuesday Afternoon Session III > Room: Atlantico B > Presentation Start Time Duration Information > 0 17:30 10 Title: Administrivia > Draft: > Presenter: Chairs > 11 17:40 10 Title: YANG Data Model for TE Topologies > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-11.pptx > Presenter: Xufeng Liu Pavan Beeram: guidance at last IETF was to separate out packet-specific stuff and publish as a separate TEAS document and share details on the MPLS WG list. Loa Andersson: Model will support multi-layer (work in progress). Two approaches are considered "transition link" and "inter layer lock". > 12 17:50 15 Title: A YANG Data Model for Resource Reservation Protocol (RSVP) > A YANG Data Model for Traffic Engineering Tunnels and Interfaces > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp/ > Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-12.pptx > Presenter: Tarek Saad Dhruv Dhody: in PCE WG our aim was to have a generic PCEP Yang. What's the ietf-te-PCC you have? Tarek Saad: Dhruv Dhody: We can discuss offline, but should that belong in IETF-PCEP? Tarek Saad: OK, let's talk about that Cyril Margaria: Where's the source in the tunnels? Tarek Saad: data needs to be globally scoped to model the network, and it's keyed by name. We thought that the name can be made global by prepending the source router name or id. All implementations seem to support name-based tunnels. Cyril: is this in the draft? Tarek Saad: the key in teh draft is a string. we can make this clearer if need be. Dhruv: I'd like to thank the authors for taking comments form PCEP and making a generic ietf-te . ? Tarek Saad: we thought about embedding a distinuisher in the tunnel name but we decided it was unnecessary Pawel Brzozowski: Name can be globally unique - are you saying the source isn't valuable? Tarek Saad: no, but the name is sufficient for a unique key. Pawel Brzozowski: So the source ID doesn't have to be part of the key Tarek Saad: we have the source in the model Lou Berger: Naming: you didn't want to use PSC, so you used MPLS. That will lead to confusion as we have some base models that are MPLS that will be used for non-packet stuff. I appreciate that PSC is GMPLS-centric term - maybe just use "packet"? Tarek Saad: other models will use this too Lou Berger: I think MPLS as packet will lead to confusion, but I'm interesting in what other folks have to say. I think having MPLS implicitly be PSC will cause confusion Adrian Farrel: suppose there was another box for RSVP/GMPLS... Lou Berger: GMPLS-packet is an augmentation Tarek Saad: Yes, for bidirectional Lou Berger: I'd hope bidir would be part of the core as it applies to everything except traditional RSVP-TE Lou Berger: I'll back up: until you have GMPLS in this picture I don't understand it. I still think you need a term for packet other than MPLS. Loa Andersson: question to Lou: what's the cause of the confusion by using MPLS and why is packet better? Lou Berger: I think we'll end up with a bunch of technology-specific models, which will look like GMPLS. until we see how it all fits together i dont' really understand it. So I'd like to see the authors proposal for this. Jon Hardwick: we should take this offline as we need to keep to schedule Lou Berger: OK. As TEAS chair I'd like to see a GMPLS module. Lou Berger: another thing: you have a use-case for the schema mount idea that we (routing design team) think is likely to happen. Please take this to netmod and say that their restrictions are too extreme for your use-case - that would be useful information Igor Bryskin: I agree with Lou that 'MPLS' is confusing. I like to call PSC PSC - we should use the right names for each technology. Things like MPLS are ambiguous. Tarek Saad: we went away from PSC becasue ti was confusing. Qeustion now is between packet and MPLS. > 13 18:05 10 Title: A YANG Data Model for MPLS Base and Static LSPs > Draft: https://datatracker.ietf.org/doc/draft-saad-mpls-static-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-13.pptx > Presenter: Tarek Saad Adrian Farrel: Static LSP... I'm trying to work out whether what you describe is an end-to-end LSP or an LSP as seen at one node Tarek Saad: End-to-end. We have the notion of in- and out-segment so we're defining exposed swap and pop... but for the LSP we have an operation that applies on head/transit/egress Adrian Farrel: So it's a bit like an explicit route with labels Tarek Saad: Yes Adrian Farrel: So when I use the model, what's different between a static LSP and a RSVP-TE signaled one? Tarek Saad: Static is config-driven Adrian Farrel: But from the point of view of a user who doesn't understand the difference, how does the model look different? Tarek Saad: What we're trying to model is what operations need to be invoked on invoming/outgoing labels. RSVP has a lot of state and timers, etc. In the data-plane they'll look alike but we aren't modeling that yet Adrian Farrel: I understand the data-plane and what coders have to do, but when you request an LSP from the management plane, isn't the information all the same? Tarek Saad: The interface we're exposing is a data model. But this is mostly config-driven. Jon: please take to the list Dhruv Dhody: IETF-TE works at the controller. Is MPLS static LSP only for the device or can it be used at the controller too? Tarek Saad: controller can provision an LSP using this? ? (inaudible) George Swallow: you mentioned multiple labels. Have you considered how a SR LSP would look? And are you engaging with SPRING WG? Tarek Saad: It's still a static LSP. George Swallow: Or it could be a stack of labels. Tarek Saad: We think the operations we've defined (impose/swap/pop) also cover SR Lou Berger: From a chair's perspective you have at least a couple of models here and you should consider separating them Tarek Saad: OK, thanks. Jon Hardwick: The right list is MPLS. OK? Lou Berger: I think it should be the list for the WG that owns the draft. And if the intent is that it should cover TE and non-TE then MPLS is the right list. > (~18:25) > 17 18:50 10 Title: Yang Data Model for LSP-PING > Draft: https://datatracker.ietf.org/doc/draft-zheng-mpls-lsp-ping-yang-cfg/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-17.pptx > Presenter: Guangying Zheng (no questions) > (~18:34) > 15 18:30 10 Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP) > Draft: https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-15.pptx > Presenter: Dhruv Dhody Tarek Saad: I see that the ietf-device model we've introduced is a fit to be augmented by this. Dhruv Dhody: Yes for the first part, but when you come to PCE it's PCE stuff. We can figure this out but the feeling is this belongs in IETF-TE rather than in PCEP. Lou Berger: As NETMOD chair, I'll say that this whole topic is an open one and the WG is trying to come up with a solution. I have no idea if we'll succeed, but we hope to have a better idea by Berlin. The objective right now is that model writers won't have to do anything to support opstate - there will be tooling to provide the elements we need. That's the hope. Dhruv Dhody: So keep drafts as they are for now? Lou Berger: Don't go decorating your models with intended/applied if you haven't already done so. If you have, don't change it back. Jon Hardwick: we should talk about this in PCE WG tomorrow. (~18:41) > 16 18:40 10 Title: YANG Models for the Northbound Interface of a Transport Network Controller: Requirements, Functions, and a List of YANG Models > Draft: https://datatracker.ietf.org/doc/draft-zhang-ccamp-transport-ctrlnorth-yang/ > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-16.pptx > Presenter: Xian Zhang Cyril Margaria: the service model looks a lot like tunnel information. Why not use that? Xian Zhang: the reason we do it separately is that for the tunnel model there's a lot of stuff the client doesn't need. Cyril Margaria: but those aren't mandatory Tarek Saad: I would expect that some of these would be augmentations to TE-tunnel. Xian Zhang: So do you think these things are generic? Lou Berger: What we're seeing here is specific to a specific technology - it's in CCAMP. What here is technology-specific? Xian Zhang: Not a lot. But the use-case we focus on is technology-specific which is why the draft is in CCAMP Lou Berger: OK. I think the details belong in TEAS. Do the CCAMP chairs want to say anything? Adrian Farrel: I'm interested by the scheduling piece of this. We have work going on in TEAS around scheduling LSPs from a control-pane point of view. What I see here is a very generic scheduling policy - you could schedule anything in the IETF with this. Someone probably needs to talk to the right person about whether this should be a separate model. Xian Zhang: I'm not writing my own schedule paths - I'm using pre-existing ones Rajiv Asati: if it's related to northbound, so we really need to have the specifics in the model that describes every node where the service needs to be instantiated? Can we abstract the details out Xian Zhang: you're right to some extent. Some use-cases (e.g. #2) need to expose technology-specific info. We'd need a use-case for the abstracted version. (~18:52) > 14 18:15 15 Title: YANG Data Model for MPLS LDP and mLDP > Draft: https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang > Slides: https://www.ietf.org/proceedings/95/slides/slides-95-teas-14.pptx > Presenter: Rajiv Asati Loa Andersson: I'm a bit split as I'm an author of LDP and also a member of the design team. I don't think we're doing anything more strict than in RFC 5036. What's stricter is that we're getting away from the rather loose concept that we've had since then. Lou Berger: Did you hear Andy's talk in NETMOD yesterday? Rajiv Asati: Yes Lou Berger: There's a guideline update happening, so please send that to Andy Rajiv Asati: I sent a mail this morning Jeff T: Could we have a goal for the yang design team to come up with this by Berlin? This quesiton comes up over and over again Lou Berger: it's an AI for netmod at this point. One of the changes from yesterday to now is that this is now a specific deliverable. Rajiv Asati: even if there's no recommendation, pros and cons would be nice. Lou Berger: I'd like specific guidelines. NETMOD is the right place for that conversation. ============ Jon: I think that was a really useful session. Special mention to Matt for the agenda. That's the end of the agenda. Please come to PCE tomorrow :) > Adjourn 19:10 > > > Notes from Haomian and Matt From nobody Tue Apr 5 18:44:36 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3F12D572 for ; Tue, 5 Apr 2016 18:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPqoj7SYJQZC for ; Tue, 5 Apr 2016 18:44:33 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 C711C12D173 for ; Tue, 5 Apr 2016 18:44:32 -0700 (PDT) Received: by mail-ob0-x232.google.com with SMTP id j9so21675619obd.3 for ; Tue, 05 Apr 2016 18:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nZE8444f7FuflXVCJ/tiX14Xa9RMACyksftDeyzjcsI=; b=LcjZSbTJ08t4fjAYLpej8/ncaD7k8wMQ7htrO0EQjEyv6JZQ/J0KpQfpKI9Q7pBxyp FL/5fXItUtGhJ+bFQd9y2mG4gWO5nrAPWrlcoj4c1uxkA9u8oIpT07tihbOZzuIpx7w2 kQlZclYw7JErNw8FpYw/eh3L498ygHERzna4b8bvJ9UBqor6OFv1Z88xjKLk9WwdcES0 iqLzPWViFahJQBG1dgKrrk8TWsHirM6WcPnH/1EA2qJOpHXuHQuPxVtUIGuPjXANivo4 2GvZxYXzhtoqbmcAz3rpAfRYwXS6rXcJxAC6OnmhBRb1v8O3fusX8r+kUZ1JX65fZdni Bymg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nZE8444f7FuflXVCJ/tiX14Xa9RMACyksftDeyzjcsI=; b=RnEa65O/d9xZ31HttYMEZsyD3iS8/hzGmXn6/k8+nk5rFTsSelVDU+IyVWF1yXHEa2 YCH8LpzaJfefgXAGcLXhoHx54QvgFh4O4KM1uwjQQjcwSmE3MAKiYxtt5qRPDduFwgTi RT3gpPxRX+Bgf2M1Vgw5L0acKsHQGOwaoGgCiXQR5EpkG+ANirgtDILGAZXM2aU2s04r sfPMs9GJR7ZDmkELCjO9eKMnOvkORZBJhcV5p/dI/o6p/JW+v+hV2IKWbSIj6VuB7m9E XS+LaqJ2k4dMGfu6rDI3nKSzRmG2bLwMtVIfdcEYLZgz5ua9dKH9qP8Dxu1yAeTJcwNb 9SaA== X-Gm-Message-State: AD7BkJK0VXV3ZShqEib+nkMWZ5fFHl9whRuvvKoUSM2U8i3uoSYXaz5F7DBtanAIKoKjs7QP+prIXWJ4M4qFjQ== X-Received: by 10.60.233.104 with SMTP id tv8mr7522761oec.60.1459907072184; Tue, 05 Apr 2016 18:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.242.35 with HTTP; Tue, 5 Apr 2016 18:44:12 -0700 (PDT) In-Reply-To: <05bc01d18f83$c57bfce0$5073f6a0$@olddog.co.uk> References: <05bc01d18f83$c57bfce0$5073f6a0$@olddog.co.uk> From: "Andrew G. Malis" Date: Tue, 5 Apr 2016 22:44:12 -0300 Message-ID: To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113686a6716fe3052fc71ac8 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] My question about "static LSP" in TEAS today X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 01:44:35 -0000 --001a113686a6716fe3052fc71ac8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adrian, This stirs memories of the good old ATM MIB of yore =E2=80=A6 we modeled cross-connects and interfaces, and stitched PVCs (static LSPs as the kids call them now) by matching labels (VPI/VCI) from one interface to the connected interface in the next switch. In the case of SVCs (now dynamic LSPs), we modeled the SVC as a single network-wide cross-connect. Cheers, Andy On Tue, Apr 5, 2016 at 6:40 PM, Adrian Farrel wrote: > Hi, > > I probably wasn't clear in my question. To restate, my question is why is > the > static LSP model modelling an end-to-end LSP and not just a single "cross > connect"? Alternatively, what is the difference between an LSP provisione= d > by a > control plane, and an LSP provisioned by the management plane? And we > might even > bring in "soft permanent LSPs" that are a stitching together of some stat= ic > segments and some dynamic segments. > > (You might look at the LSR MIB module that can be used to provision [aka > model] > static LSPs.) > > When you model maybe you need to think about what is the purpose of > modelling. > There are three things going on: > > What is the user/application asking for? > What state is held in the network? > What does the data plane have? > > In this case there is no control plane, but there is still distributed > state > installed in the network. > You said that this is not a data plane model, which is fine. > So you are modelling either the state in the network or the user's reques= t. > Now, there may be protocol state (such as parameters of RSVP-TE that exis= t > to > keep the protocol on side) that are special, but the parameters that > describe > the state that applies to the LSP are surely identical regardless of how > the LSP > was set up. That is, the LSP is a sequence interfaces and labels as well > as some > information about reserved resources. > > I think I'm rambling. What I am trying to say is that an LSP is an LSP. > > Cheers, > Adrian > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113686a6716fe3052fc71ac8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

This stirs memories of the good= old ATM MIB of yore =E2=80=A6 we modeled cross-connects and interfaces, an= d stitched PVCs (static LSPs as the kids call them now) by matching labels = (VPI/VCI) from one interface to the connected interface in the next switch.=

In the case of SVCs (now dynamic LSPs), we modele= d the SVC as a single network-wide cross-connect.

= Cheers,
Andy


On Tue, Apr 5, 2016 at 6:40 PM, Adrian Farr= el <adrian@olddog.co.uk> wrote:
Hi,

I probably wasn't clear in my question. To restate, my question is why = is the
static LSP model modelling an end-to-end LSP and not just a single "cr= oss
connect"? Alternatively, what is the difference between an LSP provisi= oned by a
control plane, and an LSP provisioned by the management plane? And we might= even
bring in "soft permanent LSPs" that are a stitching together of s= ome static
segments and some dynamic segments.

(You might look at the LSR MIB module that can be used to provision [aka mo= del]
static LSPs.)

When you model maybe you need to think about what is the purpose of modelli= ng.
There are three things going on:

What is the user/application asking for?
What state is held in the network?
What does the data plane have?

In this case there is no control plane, but there is still distributed stat= e
installed in the network.
You said that this is not a data plane model, which is fine.
So you are modelling either the state in the network or the user's requ= est.
Now, there may be protocol state (such as parameters of RSVP-TE that exist = to
keep the protocol on side) that are special, but the parameters that descri= be
the state that applies to the LSP are surely identical regardless of how th= e LSP
was set up. That is, the LSP is a sequence interfaces and labels as well as= some
information about reserved resources.

I think I'm rambling. What I am trying to say is that an LSP is an LSP.=

Cheers,
Adrian

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

--001a113686a6716fe3052fc71ac8-- From nobody Tue Apr 5 19:28:26 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F112D172; Tue, 5 Apr 2016 19:28:24 -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 AfuyxLO8kafP; Tue, 5 Apr 2016 19:28:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A750B12D0BF; Tue, 5 Apr 2016 19:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5299; q=dns/txt; s=iport; t=1459909702; x=1461119302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QD+V+v94BEKqxMYQ155vG5/ykJxAURFDWb29czlx7Aw=; b=AT+6wHM7MRwHos/g1CCVP7qQxLsdJt3wiXakR4sQ6/oV3FplbwkGnG93 AaNmuHrPFkykGCDe2xRa4fJR1jVKy3Tf1/i8zOInepYxR7ZA4dSSu8D4+ fz7BOJ6ZrXomKMvIwuQZkqgUf7I9wzRCcPLprfN2JS/PqAaDUwp/KMQPH E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgACdARX/4gNJK1ZA4M3U322SoJjg?= =?us-ascii?q?g8BDYFyHYVwAoFGOBQBAQEBAQEBZSeEQgEBBHkOAgIBCA4CJQYEBxsXFBECBA4?= =?us-ascii?q?FiCfAQwEBAQEBAQEBAQEBAQEBAQEBAQEBARUEhhyBdQiCToRgHQmCZIIrBZMFh?= =?us-ascii?q?HwBjgqBZ4RNhCCEOo8bAR4BAUKCMoE1bIg3AQEB?= X-IronPort-AV: E=Sophos; i="5.24,446,1454976000"; d="scan'208,217"; a="88676911" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 02:28:03 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u362S3Bv018292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 02:28:03 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 21:28:03 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 21:28:03 -0500 From: "Rajiv Asati (rajiva)" To: Juergen Schoenwaelder Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ91JyyAgAUq7ACAAFAoAIABnqmd Date: Wed, 6 Apr 2016 02:28:03 +0000 Message-ID: <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> , <20160404204356.GA57133@elstar.local> In-Reply-To: <20160404204356.GA57133@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_473C6D05BC3540698931665F0122A32Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 02:28:24 -0000 --_000_473C6D05BC3540698931665F0122A32Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Juergen, Thanks for the clarity. I somewhat agree. Different lifetime shouldn't real= ly cause any impact. One nit, When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Depends. If LC itself is removed, then all the related interfaces would be = removed from the running-config. And reinserting the LC may not bring their= individual conf back (ignoring the notifications). Obviously, I can also have operational state of an interface that has not been configured yet. Yes. Cheers, Rajiv Asati Distinguished Engineer, Cisco Services On Apr 4, 2016, at 5:44 PM, Juergen Schoenwaelder > wrote: On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiva) wrote: Hi Juergen, Operational state often has a different lifetime than config. Hence, Hmm..Could you please clarify the above a bit more? The classic example: When I pull out a configured interface, the operational state of this interface is gone but not the config - if I put the interface back, it should come up configured as before. Obviously, I can also have operational state of an interface that has not been configured yet. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --_000_473C6D05BC3540698931665F0122A32Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Juer= gen,

Thanks for the clarity. I somewhat agree. Different lifetime shouldn't real= ly cause any impact. 

One nit, 

When I pull out a configured interface, th= e operational state of this
interface is gone but not the config - if I put the interface back, it
should come up configured as before. 

Depends. If LC itself is removed, then all the related interfaces woul= d be removed from the running-config. And reinserting the LC may not bring = their individual conf back (ignoring the notifications). 

Obviously, I can also have
operational state of an interface that has not been configured yet.<= /font>

Yes. 

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On Apr 4, 2016, at 5:44 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:

On Mon, Apr 04, 2016 at 07:57:05PM +0000, Rajiv Asati (rajiv= a) wrote:
Hi Juergen,

Operational state often has a different lif= etime than config. Hence,


Hmm..Could you please clarify the above a b= it more?


The classic example:

When I pull out a configured interface, the operational state of this=
interface is gone but not the config - if I put the interface back, i= t
should come up configured as before. Obviously, I can also have
operational state of an interface that has not been configured yet.

/js

--
Juergen Schoenwaelder         = ;  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587        = ; Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103      &= nbsp;  <http://ww= w.jacobs-university.de/>
--_000_473C6D05BC3540698931665F0122A32Aciscocom_-- From nobody Tue Apr 5 20:15:34 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3017412D0E8 for ; Tue, 5 Apr 2016 20:15:32 -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 Ac5vIZdnpbjR for ; Tue, 5 Apr 2016 20:15:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D624C12D0DB for ; Tue, 5 Apr 2016 20:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3679; q=dns/txt; s=iport; t=1459912516; x=1461122116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+sylShOUtxyMfKQuogbrxe0LdrqnrhfK0Y6vDNKwGCE=; b=O/PTDL7F79OU+xOwNwfnSvtWnUif8w6WpVMqVZc0eyPcUKxGu4Z67NYd UVH1z0s9Bp9dHTKbRwa52C+DegJEKRCxSQTw5kXL4r5QN/2fUxo6xVTAN X5m/IG0P3CH/xU7kePx1+b35l6SsXBJsL12NnFhh06rEIReM4X6RX9yT9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AQDLfgRX/5FdJa1cgzeBUAa5KIIPA?= =?us-ascii?q?Q2BcoYNAoFHOBQBAQEBAQEBZSeEQgEBBHkQAgEIRjIlAQEEDgWIJ8BSAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAReGIIRLhD2FWAWNTYo0AY4Kjw6PGwEeAQFCggQZgUpsh?= =?us-ascii?q?zl+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,446,1454976000"; d="scan'208";a="94204444" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2016 03:15:14 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u363FD15030118 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 03:15:14 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Apr 2016 23:15:12 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 5 Apr 2016 23:15:13 -0400 From: "Tarek Saad (tsaad)" To: Adrian Farrel Thread-Topic: My question about "static LSP" in TEAS today Thread-Index: AdGPg8LnS/Q238/OTT2W31FDp3LJKAANz7AA Date: Wed, 6 Apr 2016 03:15:12 +0000 Message-ID: References: <05bc01d18f83$c57bfce0$5073f6a0$@olddog.co.uk> In-Reply-To: <05bc01d18f83$c57bfce0$5073f6a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.214.66] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7CBAA2F1C2B9C64AA570BEA3FEB99875@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] My question about "static LSP" in TEAS today X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 03:15:33 -0000 Hi Adrian, Thanks. Let me clarify my answer inline too.. On 2016-04-05, 6:40 PM, "Adrian Farrel" wrote: >Hi, > >I probably wasn't clear in my question. To restate, my question is why is >the >static LSP model modelling an end-to-end LSP and not just a single "cross >connect"? Alternatively, what is the difference between an LSP >provisioned by a >control plane, and an LSP provisioned by the management plane? And we >might even >bring in "soft permanent LSPs" that are a stitching together of some >static >segments and some dynamic segments. Yes, we started thinking of stitching of static LSP with dynamic LSP, and we think it can be modelled with defining the respective mpls static cross-connect that is doing the stitching, but more clarification on static entries below. > >(You might look at the LSR MIB module that can be used to provision [aka >model] >static LSPs.) Yes, I think the static LSP model is inline with that (and to certain extent inspired from the MIB LSR).. So, the model allows for a list of MPLS cross-connect entries (that are keyed by =B3name=B2) and that resemble the cross-connects of the named static LSP on every LER/LSR traversed. So, to instantiate a static LSP named foo (in its simplest form) that is traversing an ingress/transit/egress, the operator to provisions the following entries on the respective device: on ingress LER, operator provisions using YANG/NETCONF: lsp name foo in-segment=3D=B310.0.0.0/8=B2 out-segment=3D16000 operation=3Dimpose-and-forward out-inteface=3Dif1 on transit LSR, operator provisions (assuming UHP) using YANG/NETCONF: lsp name foo in-segment=3D16000 out-segment=3D16000 operation=3Dswap-and-forward out-inteface=3Dif2 on egress LER, operator provisions (assuming UHP) using YANG/NETCONF: lsp name foo in-segment=3D16000 out-segment=3Dnone operation=3Dpop-and-lookup =20 Once provisioned, it is expected this configuration state will persist, hence =B3static" > >When you model maybe you need to think about what is the purpose of >modelling. >There are three things going on: > >What is the user/application asking for? >What state is held in the network? There will be configuration state held for the LSP on each traversed mpls node. >What does the data plane have? The data plane will have the respective MPLS cross-connects/rewrite programmed. Yes, this practically is indistinguishable (for example) from those created dynamically using a signalling protocol. > >In this case there is no control plane, but there is still distributed >state >installed in the network. Yes, configuration state in this case. >You said that this is not a data plane model, which is fine. >So you are modelling either the state in the network or the user's >request. User=B9s request. >Now, there may be protocol state (such as parameters of RSVP-TE that >exist to >keep the protocol on side) that are special, but the parameters that >describe >the state that applies to the LSP are surely identical regardless of how >the LSP >was set up. That is, the LSP is a sequence interfaces and labels as well >as some >information about reserved resources. > >I think I'm rambling. What I am trying to say is that an LSP is an LSP. IMO, there=B9s a difference between the two. For example, it is expected that the statically created LSP properties on a device will never change = =8B including the in/out label and in/out interface.. which is not the case for dynamically singled LSPs. Regards, Tarek > >Cheers, >Adrian > From nobody Tue Apr 5 23:29:11 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867412D63D; Tue, 5 Apr 2016 23:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VrL-YLlSqCph; Tue, 5 Apr 2016 23:29:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD12A12D72E; Tue, 5 Apr 2016 23:29:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 15707F6E; Wed, 6 Apr 2016 08:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BEVJv9YTTCfp; Wed, 6 Apr 2016 08:28:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Apr 2016 08:29:03 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CD6720045; Wed, 6 Apr 2016 08:29:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0fscBIUp6jNm; Wed, 6 Apr 2016 08:29:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26F4020043; Wed, 6 Apr 2016 08:29:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E7A03A72C5A; Wed, 6 Apr 2016 08:28:59 +0200 (CEST) Date: Wed, 6 Apr 2016 08:28:59 +0200 From: Juergen Schoenwaelder To: "Rajiv Asati (rajiva)" Message-ID: <20160406062858.GA60806@elstar.local> Mail-Followup-To: "Rajiv Asati (rajiva)" , "netmod@ietf.org" , "mpls@ietf.org" References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 06:29:11 -0000 On Wed, Apr 06, 2016 at 02:28:03AM +0000, Rajiv Asati (rajiva) wrote: > Hi Juergen, > > Thanks for the clarity. I somewhat agree. Different lifetime shouldn't really cause any impact. > > One nit, > > When I pull out a configured interface, the operational state of this > interface is gone but not the config - if I put the interface back, it > should come up configured as before. > > Depends. If LC itself is removed, then all the related interfaces would be removed from the running-config. And reinserting the LC may not bring their individual conf back (ignoring the notifications). Assuming LC means line card if not discard the following (and explain what LC means). I believe the answer here is that systems treat this differently and there is no universal answer. Some systems seem to store line card config on the line card itself, other systems associate config with the physical location of a port or interface, yet others associate config with a name of an interface (which may not indicate the physical location of an interface). Since implementations really differ here, we support multiple implementation options in the interfaces data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 6 06:51:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFB212D5AD for ; Wed, 6 Apr 2016 06:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZLlPCV3UxDk for ; Wed, 6 Apr 2016 06:51:42 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718A012D5C4 for ; Wed, 6 Apr 2016 06:51:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u36DpZ4C024942; Wed, 6 Apr 2016 14:51:35 +0100 Received: from 950129200 (dhcp-b176.meeting.ietf.org [31.133.177.118]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u36DpWQt024880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2016 14:51:34 +0100 From: "Adrian Farrel" To: "'Tarek Saad \(tsaad\)'" References: <05bc01d18f83$c57bfce0$5073f6a0$@olddog.co.uk> In-Reply-To: Date: Wed, 6 Apr 2016 14:51:29 +0100 Message-ID: <078c01d1900b$6e1c8d60$4a55a820$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMEfdU07zIuFgpCnDD5Vj+l40Xc0wKuaC/VnQGjF7A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22242.007 X-TM-AS-Result: No--37.048-10.0-31-10 X-imss-scan-details: No--37.048-10.0-31-10 X-TMASE-MatchedRID: 0lhM5bBmjEOnykMun0J1wpJEUO2qIzlLkKAa/khZ3iTIvQIyugvKdTco lL66pGxavxjd8HDxJA7Oxo/f0SVhOAdNdS6cTLNYR+GtoiXVeDGGm/9Tv2/OgfgnJH5vm2+g5ee hiA0K53Qcm7TGmQXc1T0gMbrUmb4fQ+WOkQmWrLrsEjYqO+DyaLuesBT0pDFRInzOyTDR1uuWuL +jYTRdpowZrvRON7G4XXI3bMiDYvRBmRZWSonyTpYsKSXWWrsHgGa+oYp5i6prH7R0RhorDPIX6 6Noho9rqnea6Euo4wToRMmmVPjOW62Uzgqgb39dQz/LkQyz8mYxRS4RlA/AFpps2hiiMFB2qJlo 5lQZWaox6UfuqGepQT/RglLb5RzWEO6iheizlV4wo+sXt0rns2PIqSS8BzKh2nVuImEjI1Fdrb7 MTVw/5ZBOEhVhRWupFyCVjv7dlo5gRbV6VSX3KAPZZctd3P4BjLOy13Cgb4+e9toQ6h6LE8VJIR TDvqF7XCZPbUFnBYEYLjS0c7/5NXMtRMwL8VEPoMfp2vHck9Uzc8FC0MEwTxRZ/9wBMhGsLMRTl XcK2C3rLST+tNFoDBDkRVnCZf/d8FQaUkGHmlcXKqR+w9a7ULLdiE6f8zQxgrAXgr/AjP36p2mn E2PRyeXrs80uTFi5hJqfnrAnMyq4mqWVDqxbtOLz1o40byIqL34I8IpvQcKYFp2iw4hoIWf6W69 0ONYWr8RjrZqN+Iefb6bl1YfU92gwIvLATTKBRjjVhf+j/wpKdDgyPBo71yq2rl3dzGQ1A/3R8k /14e0= Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] My question about "static LSP" in TEAS today X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:51:45 -0000 Tarak, Thanks for the exchange. I think we can jump to the bottom line. Both data models are for the user/application to request or view an LSP. You are correct that *normally* the user requests a static LSP in detail = that includes the nodes, interfaces, labels, and resources. You are correct that *normally* a user requests a control-plane operated = LSP using at most nodes and links (interfaces) and resources. That is, a user does not *normally* specify what labels to use. However, use cases exist where: - the user of the control plane does specify the labels to use (and the control plane supports signaling these labels) - the user of the management plane for static LSPs does not specify the labels to use and this information is either - pulled out of the network nodes and then passed to the other network nodes - determined by some software component (people may=20 call this an orchestrator or controller) More interesting, however, is that we are *modelling* the LSP not just facilitating write-action requests for an LSP. Once the LSP has been installed, it has the same information regardless = of how it was instantiated, and the data model must report all of that = information. The user wants to know all of this information. This debate may come down to some more clarity about what we are trying = to achieve. I don't have a strong opinion about what we are trying to do, = but I think it is clear=20 that it isn't clear :-)=20 Like Andy, I recall the ATM MIB modules. And of course, I know a little = bit about the MPLS and GMPLS MIB modules. I can explain what we were trying = to achieve with them. I don't claim that you must model the same stuff in = the same way, but I do claim that the MPLS MB modules supported static LSPs as = well as RSVP-TE LSPs. Cheers, Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com] > Sent: 06 April 2016 04:15 > To: Adrian Farrel > Cc: mpls@ietf.org > Subject: Re: My question about "static LSP" in TEAS today >=20 > Hi Adrian, >=20 > Thanks. Let me clarify my answer inline too.. >=20 > On 2016-04-05, 6:40 PM, "Adrian Farrel" wrote: >=20 > >Hi, > > > >I probably wasn't clear in my question. To restate, my question is = why is > >the > >static LSP model modelling an end-to-end LSP and not just a single = "cross > >connect"? Alternatively, what is the difference between an LSP > >provisioned by a > >control plane, and an LSP provisioned by the management plane? And we > >might even > >bring in "soft permanent LSPs" that are a stitching together of some > >static > >segments and some dynamic segments. >=20 > Yes, we started thinking of stitching of static LSP with dynamic LSP, = and > we think it can be modelled with defining the respective mpls static > cross-connect that is doing the stitching, but more clarification on > static entries below. >=20 > > > >(You might look at the LSR MIB module that can be used to provision = [aka > >model] > >static LSPs.) >=20 > Yes, I think the static LSP model is inline with that (and to certain > extent inspired from the MIB LSR).. So, the model allows for a list of > MPLS cross-connect entries (that are keyed by =B3name=B2) and that = resemble > the cross-connects of the named static LSP on every LER/LSR traversed. >=20 > So, to instantiate a static LSP named foo (in its simplest form) that = is > traversing an ingress/transit/egress, the operator to provisions the > following entries on the respective device: >=20 > on ingress LER, operator provisions using YANG/NETCONF: > lsp name foo > in-segment=3D=B310.0.0.0/8=B2 > out-segment=3D16000 > operation=3Dimpose-and-forward > out-inteface=3Dif1 >=20 >=20 >=20 > on transit LSR, operator provisions (assuming UHP) using YANG/NETCONF: > lsp name foo > in-segment=3D16000 > out-segment=3D16000 > operation=3Dswap-and-forward > out-inteface=3Dif2 >=20 >=20 > on egress LER, operator provisions (assuming UHP) using YANG/NETCONF: > lsp name foo > in-segment=3D16000 > out-segment=3Dnone > operation=3Dpop-and-lookup >=20 >=20 >=20 > Once provisioned, it is expected this configuration state will = persist, > hence =B3static" >=20 > > > >When you model maybe you need to think about what is the purpose of > >modelling. > >There are three things going on: > > > >What is the user/application asking for? > >What state is held in the network? > There will be configuration state held for the LSP on each traversed = mpls > node. >=20 > >What does the data plane have? >=20 > The data plane will have the respective MPLS cross-connects/rewrite > programmed. Yes, this practically is indistinguishable (for example) = from > those created dynamically using a signalling protocol. >=20 > > > >In this case there is no control plane, but there is still = distributed > >state > >installed in the network. >=20 > Yes, configuration state in this case. >=20 > >You said that this is not a data plane model, which is fine. > >So you are modelling either the state in the network or the user's > >request. >=20 > User=B9s request. >=20 >=20 > >Now, there may be protocol state (such as parameters of RSVP-TE that > >exist to > >keep the protocol on side) that are special, but the parameters that > >describe > >the state that applies to the LSP are surely identical regardless of = how > >the LSP > >was set up. That is, the LSP is a sequence interfaces and labels as = well > >as some > >information about reserved resources. > > > >I think I'm rambling. What I am trying to say is that an LSP is an = LSP. > IMO, there=B9s a difference between the two. For example, it is = expected > that the statically created LSP properties on a device will never = change =8B > including the in/out label and in/out interface.. which is not the = case > for dynamically singled LSPs. >=20 > Regards, > Tarek >=20 > > > >Cheers, > >Adrian > > From nobody Wed Apr 6 07:08:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E9A12D5EA; Wed, 6 Apr 2016 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5NrXcHBMJ2n; Wed, 6 Apr 2016 07:08:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0106.outbound.protection.outlook.com [207.46.100.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4270B12D65D; Wed, 6 Apr 2016 07:08:18 -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=eWfKRYoT+KNPzKmX7/z9dLoOcfmGR8JLE2ANKXZQH4E=; b=Bi14qzIRPUJDzoyd3eBjEKE5MJg8WAR3LOqtkC51pOmNuoAus3Hr14IrKVydzzqlCzGSin/Zuehy75zyHFQa3lwulQxu7kAxbZbr3N14KYAlZ8NU43IIZv7gcxoxAyEA6XA1vcpKP5XABOh7kATWz0v/f0nzx5QuQsKpPqe+twc= Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1606.namprd05.prod.outlook.com (10.160.203.155) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 14:08:17 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0447.028; Wed, 6 Apr 2016 14:08:17 +0000 From: Gert Grammel To: Juergen Schoenwaelder , "Rajiv Asati (rajiva)" Thread-Topic: [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! Thread-Index: AQHRi31NmlAQiI8k5U+2ghmHbAtBnJ9001qAgAVt/oCAAA0XAIAB8nqAgABDUICAAE4FgA== Date: Wed, 6 Apr 2016 14:08:17 +0000 Message-ID: References: <6A55F6E8-8A67-459D-BAB6-CC41F8D7BF30@cisco.com> <20160401090207.GA50653@elstar.local> <473C6D05-BC35-4069-8931-665F0122A32A@cisco.com> <20160406062858.GA60806@elstar.local> In-Reply-To: <20160406062858.GA60806@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 4b106438-2c23-46a5-b2fd-08d35e24e6f8 x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1606; 5:kRtRjuPN4ycbI37rDI30wJrCp5uxYzXZpQE9V89RVCtQvjUBw9p7FTs78Qp9uBUGmo5Fr28xnIA/VG46rY6ANluL/1CuKCS6ulnsdY9zyOGrNqyk2KCo350ShSepYMLdh8+XIiOF4DiWxQf6z2qX3g==; 24:ZSAXNPc1T+YCRLTJKH0ij8h9HBelwb3OjDevHieFb1I1wO6LTJcFWMzgUj3byo4kEZVsZfSFR0gB6GJkoJUUozlbCFoYL6RrEeJWgD9Iczs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1606; 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)(6055026); SRVR:BY1PR0501MB1606; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1606; x-forefront-prvs: 0904004ECB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(15975445007)(77096005)(99286002)(93886004)(2950100001)(2900100001)(83506001)(11100500001)(106116001)(19580405001)(122556002)(86362001)(5002640100001)(50986999)(87936001)(81166005)(54356999)(19580395003)(6116002)(1220700001)(66066001)(3660700001)(5001770100001)(4001350100001)(586003)(76176999)(3846002)(189998001)(1096002)(102836003)(5004730100002)(2906002)(3280700002)(5008740100001)(36756003)(10400500002)(4326007)(92566002)(225543005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1606; H:BY1PR0501MB1605.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2016 14:08:17.4857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1606 Archived-At: Cc: "mpls@ietf.org" , "netmod@ietf.org" Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !! X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 14:08:33 -0000 This case is another reason why the intended config should not be touched by the server. Juergen is right that there are lots of different implementations. It is the implementer=B9s choice where to put configuratio= n state. Typically if a server supports rollback, the state is stored in a database, otherwise it is often stored directly on HW. Both versions survive a reboot. If you remove the LC (=3DLine Card?) the result is either a) intended =3D config !=3D active in case of a central config repository o= r b) intended !=3D config =3D active in case of config stored on LC a) is a case that is often tolerated or even desired, as it allows to pre-configure HW before it becomes physically available. B) is an error condition. Gert On 2016-06-04 03:28, "netmod on behalf of Juergen Schoenwaelder" wrote: >On Wed, Apr 06, 2016 at 02:28:03AM +0000, Rajiv Asati (rajiva) wrote: >> Hi Juergen, >>=20 >> Thanks for the clarity. I somewhat agree. Different lifetime shouldn't >>really cause any impact. >>=20 >> One nit, >>=20 >> When I pull out a configured interface, the operational state of this >> interface is gone but not the config - if I put the interface back, it >> should come up configured as before. >>=20 >> Depends. If LC itself is removed, then all the related interfaces would >>be removed from the running-config. And reinserting the LC may not bring >>their individual conf back (ignoring the notifications). > >Assuming LC means line card if not discard the following (and explain >what LC means). I believe the answer here is that systems treat this >differently and there is no universal answer. Some systems seem to >store line card config on the line card itself, other systems >associate config with the physical location of a port or interface, >yet others associate config with a name of an interface (which may not >indicate the physical location of an interface). Since implementations >really differ here, we support multiple implementation options in the >interfaces data model. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Apr 6 08:37:36 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395DA12D542; Wed, 6 Apr 2016 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, SPF_PASS=-0.001, 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 v4eHF2aMAY-5; Wed, 6 Apr 2016 08:37:31 -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 1B5F412D528; Wed, 6 Apr 2016 08:37:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLQ92283; Wed, 06 Apr 2016 15:37:28 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 16:37:27 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 23:37:21 +0800 From: Xuxiaohu To: "spring@ietf.org" Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vg== Date: Wed, 6 Apr 2016 15:37:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.198.226] 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.0A090205.57052D39.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c66893d3ade0d7a0417cd6f057135152 Archived-At: Cc: "mpls@ietf.org" Subject: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:37:34 -0000 Hi all, According to suggestions from SPRING co-chairs, I would clarify the intenti= on of this draft (https://tools.ietf.org/html/draft-xu-spring-islands-conne= ction-over-ip-05) as follows. If I understood the current MPLS-SR specification (https://tools.ietf.org/h= tml/draft-ietf-spring-segment-routing-mpls) correctly, the IGP next-hop for= a given /32 or /128 prefix FEC (i.e., node segment prefix) is taken as the= next-hop of the received MPLS packet belonging to that FEC. When the IGP n= ext-hop for that FEC is a non-MPLS node, the outgoing label for that FEC is= lacked. As a result, the received MPLS packet belonging to that FEC would = be dropped BY DEFAULT according to the following specification as quoted fr= om RFC3031: "3.22. Lack of Outgoing Label When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. It is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding, based on its network layer header. However, in general this is not a safe procedure: - If the packet has been following an explicitly routed LSP, this could result in a loop. - The packet's network header may not contain enough information to enable this particular LSR to forward it correctly. Unless it can be determined (through some means outside the scope of this document) that neither of these situations obtains, the only safe procedure is to discard the packet." In the T-LDP or L-BGP case, the next-hop for the MPLS packet belong to a gi= ven prefix FEC is not the IGP next-hop of that FEC anymore. For instance, i= n the T-LDP case, the next-hop is the T-LDP peer, and in the L-BGP case, th= e next-hop is the L-BGP peer. As a result, if T-LDP peers or L-BGP peers ar= e not directly connected and are separated by an IP network, the LSP signal= ed by T-LDP or L-BGP could be transported over that IP network.=20 The situation in MPLS-SR is a little bit complex since the outgoing label f= or a given /32 or /128 prefix FEC could be learnt either from the IGP next-= hop of that FEC or the originator of that FEC due to the IGP flooding prope= rty. In the former case, the IGP next-hop for a given FEC is taken as the n= ext-hop of the received MPLS packet belonging to that FEC; in the latter ca= se, the originator of that FEC is taken as the next-hop of the MPLS packet = belonging to that FEC. The former case is straightforward to understand and= has been described in the current MPLS-SR draft. the latter case is a bit = hard to understand and has not been described in the current MPLS-SR drafts= . In fact, the latter case belongs to the "remote label distribution peer" = case as defined in RFC3031, see below: "When two LSRs are IGP neighbors, we will refer to them as "local label distribution peers". When two LSRs may be label distribution peers, but are not IGP neighbors, we will refer to them as "remote label distribution peers." In a word, this draft (https://tools.ietf.org/html/draft-xu-spring-islands-= connection-over-ip-05) describes the remote label distribution peer mode wh= ich is useful for incremental deployment purpose. I would like to hear from SPRING and MPLS WGs whether the remote label dist= ribution peer mode is valid for MPLS-SR and whether we need a draft to desc= ribe the remote label distribution peer mode for MPLS-SR. Best regards, Xiaohu= From shahram.davari@broadcom.com Wed Apr 6 08:21:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACD12D618 for ; Wed, 6 Apr 2016 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=broadcom.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 ZLHhCW-4e-Hh for ; Wed, 6 Apr 2016 08:21:56 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 4717112D838 for ; Wed, 6 Apr 2016 08:18:05 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t10so60655588ywa.0 for ; Wed, 06 Apr 2016 08:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to; bh=ubWiCP+SqR4Xaf+0FDg9fh6ruu/+Q8qKvp7hQKSd3xE=; b=QTnGr71wP07xj4t44Vvko0IecAIxZSZh2W1keKYn2vinKYq9JkHBLhmVpFKbVrPGIb 2TkELoS8PdvOGk/yeZnZ3muaLtf9Wnzbjnc6KtxBqxSbPWD2yCWnloDRy5efPOoEeFhG 553dp6uFpnAYlrAgbQf9mzZ5/gohrNUv6qVZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=ubWiCP+SqR4Xaf+0FDg9fh6ruu/+Q8qKvp7hQKSd3xE=; b=STCii01rk+D+1+1eNIxIQre7Y2GP5PdBOqAdlajWrICvdZT4DlKbkQliS4cfuE+uHJ ytPhS7tBueGOZtBh5JJBQx7ZkKBcEDgVRarDwGqgvvCV/PJLxnVX67b1tJCRiCx1ught 2RhlMeNqYi2m7wiyPE4HJLdD0RR0nav0KYvn+ibXw7FQM9xp8x5Cmp/cXkSjnV4QB8/j cdLxkdMz4TGwpliqHBYjX7V9kKOnElGzIJ0WfTT5egwisH8m0AqzlkNxbLQHiPD5z6Wj kaboe3z7JejBzc0ffXZQH4MJPKMkYFppFdLoIXL0OX5iiiBe08/RtFb0k7HCMlJW0aMP Q61g== X-Gm-Message-State: AD7BkJITNTv6zervJFDE+fbKbxeI3WDb5MdjClGheUY2/uuUrF0VuQAYdmHD3nVb2bZNIVKbeQpL27FydIijPJvQ X-Received: by 10.129.94.194 with SMTP id s185mr11691117ywb.93.1459955884316; Wed, 06 Apr 2016 08:18:04 -0700 (PDT) From: Shahram Davari MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdGQFuNkf/yMV093SV+3R9XQ02JvMg== Date: Wed, 6 Apr 2016 08:18:02 -0700 Message-ID: <7b798c1472931d52a65218b896fa67de@mail.gmail.com> To: mpls@ietf.org Content-Type: multipart/alternative; boundary=001a1147086ee00760052fd277ee Archived-At: X-Mailman-Approved-At: Wed, 06 Apr 2016 13:02:49 -0700 Subject: [mpls] Why draft-turaga-mpls-test-labels-00 ? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 15:28:35 -0000 --001a1147086ee00760052fd277ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I just want to repeat my comments in today=E2=80=99s meeting. There are exi= sting solutions to the problem stated in this draft. Specifically one can use RFC6374 (MPLS LM) using Section OAM . The MPLS LM uses HW counters and the MPLS LM packets are sent Very infrequently by CPU (every minute or more). Any degradation of the connection between two adjacent routers can be easily detected, With infrequent CPU processing time. So I don=E2=80=99t support this draft and think we should not invent new s= olutions when reasonable existing solutions exist. Thx Shahram --001a1147086ee00760052fd277ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

=C2=A0

I just want to repeat my comments in toda= y=E2=80=99s meeting. There are existing solutions to the problem stated in = this draft.

=C2=A0

Spec= ifically one can use RFC6374 (MPLS LM) using Section OAM . The MPLS LM uses= HW counters and the MPLS LM packets are sent

Ver= y infrequently by CPU (every minute or more). Any degradation of the connec= tion between two adjacent routers can =C2=A0be easily detected,

With infrequent CPU processing time.

=C2=A0

So I don=E2=80=99t support this=C2=A0 d= raft and think we should not invent new solutions when reasonable existing = solutions exist.

=C2=A0

Thx

Shahram

=C2=A0

=

=C2=A0

--001a1147086ee00760052fd277ee-- From nobody Wed Apr 6 13:19:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B464F12D7D5; Wed, 6 Apr 2016 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 FMjZz3hOiZoF; Wed, 6 Apr 2016 13:18:59 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 9CBFC12D74C; Wed, 6 Apr 2016 13:18:59 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u36KGYRE028647; Wed, 6 Apr 2016 16:18:51 -0400 Received: from mdwvexchht01.ciena.com (lin1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 222xgqxmmv-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Apr 2016 16:18:51 -0400 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 6 Apr 2016 16:18:50 -0400 Received: from ONWVEXCHHT04.ciena.com (10.128.6.44) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.389.2; Wed, 6 Apr 2016 16:18:50 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT04.ciena.com ([::1]) with mapi; Wed, 6 Apr 2016 16:18:50 -0400 From: "Shah, Himanshu" To: Jeff Tantsura , Gregory Mirsky Date: Wed, 6 Apr 2016 16:18:46 -0400 Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5//9BFOg Message-ID: <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> In-Reply-To: <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22244.002 X-TM-AS-Result: No--27.908000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-06_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1604060294 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:19:02 -0000 --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO, WG should wait till IPR are disclosed and reviewed before making prog= ress on these drafts. Thanks, Himanshu From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, April 04, 2016 6:44 PM To: Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; rtg-bfd@ietf.org Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMHO, WG = should wait till IPR are disclosed and reviewed before making progress on t= hese drafts.

&nbs= p;

Thanks,

=

Himanshu

=  

= From:= mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura
<= b>Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
= Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; rtg-bfd@ietf.org
Subject: Re: [mpls] Two ne= w drafts on (micro-)BFD over MC-LAG interfaces

<= /div>

 

Hi= Jeff,

 

Thanks!

 

IPR will be disclosed ASAP, we are pushing legal.

Regards, =

Jeff


On Apr 4, 2016, a= t 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

= Hi Jeff,

we have no= t expected this question that early J

Yes, there’s IPR associated with these drafts that would= be properly disclosed after the meeting.

 

&nb= sp;            =    Regards,

&nbs= p;            &= nbsp;           &nbs= p;      Greg

 

 

Working Group,

 

These doc= uments reasonably extend the existing BFD on LAG mechanism and would be rea= sonably in charter for BFD to pick up.

 

Greg, given = that adoption seems a reasonable course, could you and the other co-authors= state whether there's any known IPR on these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky = <gregory.mirsky@ericsson.= com> wrote:

 

Dear All,

two new drafts, related to RFC 7130, were published before the m= eeting:

· &nb= sp;      =  BFD on MC-LAG interfaces in IP n= etwork

 

Greatly apprecia= te your reviews, comments, questions and suggestions.

=

 

Regards,<= o:p>

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> &n= bsp;      Greg

 

= --_000_40746B2300A8FC4AB04EE722A593182BA8809AB1ONWVEXCHMB04cie_-- From nobody Wed Apr 6 13:48:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990B612D5E3; Wed, 6 Apr 2016 13:48:47 -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 69DyZ_ovCo18; Wed, 6 Apr 2016 13:48:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C50312D58C; Wed, 6 Apr 2016 13:48:44 -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=EIfqJz2CN9hxxtQ9uaEXsUcE6UUoP7rz+wmqvfcNoco=; b=YODEdA4yohgpSgmNmlE11o22RB1+FzdgF7PGHQU0Rg7TDt9x6hIb0/q/a1eaWzPPHEpnIR2ilfsk8QPGxHbJlbdB06VuBOO8fSH/eQATrJTSgRh52d4LXOyOWGQJ8sC3jlr1yQZJ2ag/Ixq/6UxdKmy/fO70HhQdok5xpAS3ffE= 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 CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 20:48:27 +0000 To: Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> From: Eric C Rosen Message-ID: <57057618.8020604@juniper.net> Date: Wed, 6 Apr 2016 16:48:24 -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: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: SN1PR11CA0026.namprd11.prod.outlook.com (10.164.10.36) To CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) X-MS-Office365-Filtering-Correlation-Id: b268b78d-e198-4ffc-0fb5-08d35e5cce60 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 2:zlOnuBnKQX5dDLkY/n44itHxUvqbfSSMnZY5qYsAhU6ads6Wv89e0iTLKpT8WHt19WooEivelkcG2/VbflA225CvL2Xr5KmbS7B7y95uw+pV4Pv4BdfBPT4GSfoMFPKYUzIMQuQGG6Cv94TAL9yuOATJgOwu+IQ/LTkDiWPClABh0kkqnycCdg++JHK+wekm; 3:pUG4ig795OOeFtvkMK11e55ymg5fDH0iHhlJOV9RffBvpXld7ovb1L1/QBH0mEq6sjycKhIOgDfE/ggsPctzuaxMNVSCzAhDIx4dWQglgKwmMZu+rDoffDA/2zf22dzU; 25:8CyO8z2iYukwujeWRv2Miqr7BXXHXso4MY1G80gwlnQiFqXdMAA3JOtOJGx1A8FgcbjM1qvf4YWUeIXRiJtKoKiRlhHfosgb1TI/trkVDr4zUFnMMFApo7lYQkihlyqKClwEJgG5EMZIUfRk4UrB54PN8Seyqo8uMkXOFLd8OKsGwqznSEqNcAr1A8DLu6w269G2hvHwnHc6Sn+Eak9CEor98Pbc9k4h1/yBHm28j8G+jGkM+XrsPJrVNK3T1oh3Ys+MEeI9SHoCX4hG3FI5UlW86aEqiultkFPD+DuL18A5AG4AE2Fw3yDwpnIaiap6jUKNMLTaxB5k/xghE8le9IeN+hOOZGcXrpNdrJ+Fh0bsM9lMcl15uUWHqmMeeiwtsTVl9CWhQeEbzi5hHxXW6KZGvvfPzRNBMQHcOtNv+vGwaGjceJXAsHl5VktQUqivsqnXC0N/MBpnDu1YaPDmcQBA9czjsaxxzii0lgo/V3lMtEe4jECKDjlVqxtTFCD9rXSOO9xe5cxe1y/xH4uLpDqKdcMb57VdSkLvnKjSFa4LHb1p9wpbxaN978qVPTDs7lYzxWYS3m04b6qeWb8FBuPheGZVzhbVnl6/RBdqAsI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB793; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 20:tJ99vAZhP9Ggfw4ihzFkOVvdwCzV+TuLln6U1zJDggF22V0858JcienZ0Cu1aLEZgoOGzPUhsfk/gzfDJl7I07i8BCNM9ezBxAb19KcEAEnknLOSTTHdGKEgEmy2jWoXmOvcaGD+HsRrzODHar3VzM/R1jsb6+4WPFWzk724BH++9a/hbfKPBFZeXl1973LTlKQnnQOhFqp+hA8eAgb9QtpHXR8qEGdgf+NfooFihtVWykL2aUNP113ulncNTA33kYG+cmYzbP83TvB7f6tYgISCm7KG/ksZEU3vQTqHQ6hUpMjCbF6D3SLhTcEyO6twVgRYnstF69py1msg3jNSerBUCswSyMe06gomXy2eAj7SVDEWrlGrsDJ4c/PzS2njXY7JkXqe4/UXcJo17yjGWurSGeSZrusqp+/1Cc6NBedQvG3tEB0FZVUrMCKq5doyCku1IPj1OOMWwZLctvWRBPymQmkrxMXLMqzpGf26odCrO0K6dHbdqJG+cO4fEAmt; 4:7/1/kV4N5BwPzPW1TRTAEzTfBAZgChUenKY4j636dK72WJU4fiCU5aRztY8pmmxG0ZM7hH6M5mwS67C9eBILADPUH4uDgNPq/vOUrN45L+rDNB9SkK1TKRzq9G+ypGCRCkNofywYwYUOX5FneksOWDV3MHq2HkNqcRAMaOoOrSDSr8jkNoBTUxRm4SKtBm1LQGTI1xXQITvxyZxGFt9hwfMMHmYqsk2jm33BHj1ij+3xKpXdeOrJNxsbAW/zn3xrKyOlRtpjdOGrM6e1fTOzWkoNiicjrxTesMzWTTOZ80xog0IsOefS69hyiNleUpe8NSCm0OdNJ9OcqKdmo9bJcl5TMGSnWLwgyAwNF7TihgeMb3vGMaLvF2y3HyeGkpWODtquPK09VqiRAOgke53Zrg== 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)(6055026); SRVR:CO2PR05MB793; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB793; X-Forefront-PRVS: 0904004ECB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(77096005)(5001770100001)(4001350100001)(189998001)(122286003)(59896002)(50466002)(1096002)(83506001)(6116002)(3846002)(586003)(2950100001)(65806001)(36756003)(230700001)(64126003)(65956001)(66066001)(47776003)(117636001)(4326007)(230783001)(92566002)(86362001)(54356999)(87266999)(2906002)(65816999)(50986999)(99136001)(81166005)(23746002)(42186005)(5004730100002)(2501003)(5008740100001)(76176999)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB793; H:[172.29.33.33]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CO2PR05MB793; 23:hdgHqhHRKlpTjBI7WnoNAHVfY308Q/CoZR22N5?= =?Windows-1252?Q?CPi5aTbhD5vMQgee+zMmPnnvOhu39t+pNpWrbKMl11BvLXvSru2gUSWR?= =?Windows-1252?Q?FRd/TXzkn2Z+7fQUqocKLs/Qm4TWwSEDdQKiS4ZlnghhW4yB/sDQqdgW?= =?Windows-1252?Q?3LmFtSYpk19n9Vnu7zqo9+p2Pk+GgXFiBhEWGUYqXMc3N1GTivGMiEhl?= =?Windows-1252?Q?+zuJ88xpMfj3NsdHR/EvuOtrtkOFgX3naDoc1p+menYbHUUc30m4943M?= =?Windows-1252?Q?J4KoEgE1SDlfl92HzQytnqdZIm/EudHWr3zWLSHTqpadb72RRS0HODAE?= =?Windows-1252?Q?DgaPcels/jnyrqe3VO2D9Uop6pmcB0UFQmcL3qrnLG6UeuBMWR/kxRiL?= =?Windows-1252?Q?0j2wD4YB6qNylvP3oPxW2zaukTnLS/s1ByhHOvAotzgSROIfo28StmSg?= =?Windows-1252?Q?oxJ03dCaJYiLEHuNaiYCPF7Af5O2DlMn8qw7cE1TT6T1/tTOQlxBxMul?= =?Windows-1252?Q?L3iUihBGnZVwPV9rQB6jUd5Gpfh+ZH/GmUPyCOsEK5X0++5URNV4SGrQ?= =?Windows-1252?Q?EBd1ibbuMiL3siSeauw0QtwwNIqw8IAzw49dB7rmac+GXVkQRjP6xqnO?= =?Windows-1252?Q?k2+smJZbXakXdau+twlaLX+0OcFWzd7Oe2EwoLl6xm8WfR951hpJuBED?= =?Windows-1252?Q?DdsoYSTOwKU69ljVCMROWj+ANLhaSkspCEI8yDO9GAkhdq9ecEs7INMb?= =?Windows-1252?Q?ebnGDTR49F7fQeB7rr+zKoDi7d6q9yPHsZWZftJViX0e29xiGRjGtiDf?= =?Windows-1252?Q?5hNnEAZl9JPYuqg4hUF8Eful2wg3Kho4/3Mxy0UASKYixnaPpDvvSp2N?= =?Windows-1252?Q?TYf10WKwAkAUuGkTXPz/Ni1gaupxkkp247PzF0Oen3QVhn7WNQiwcvpc?= =?Windows-1252?Q?v/oRctiaESXJCyP84b8SVdcmQ9COW9irWmdV7nJHwcb8cGnpP73GLE++?= =?Windows-1252?Q?D0i2VuP+B60VASYOSgawltJ50qdqho6buSc4qDeNMd0NBlq+y9tyalL+?= =?Windows-1252?Q?TP6U6X9kc9FUuQ1mqcTUsXga9TrRjbp70oRzNREfJFNQO1a734rNSiyL?= =?Windows-1252?Q?NGZApNSF/4l4gW49xAivtb08vwfobh6IUuPnO/tfb8fkdQCc1BpidnlB?= =?Windows-1252?Q?2VJNGPXTOZkzdRY2pS7UGWcR8k2++wNiSaXP7Sbm1lf7c7nvse?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 5:JE2VI1Nu/LOr3prt4L0e4AUCNIxif0cXXonA3hOQNRrVysUnTF5hXBysFLJNy3z5+v5J7p49hdA/dUWr/AUF09Q2O0vadW8AKx+R20Zzkhs1d83AS4IUBE/5UDIdLWz1GUnHAiBnEalAqAQJGyZoLQ==; 24:/ETnA7QGQRtNv2WE7sXzqH5nEtZMr1XGwSIR4m4U+o2k4B+AcTkVmwpALaq3zFWPXX11osXsn6I2AYD0RqdKkyhZtOpMGDOQVXqIlm9Xqa4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2016 20:48:27.4744 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB793 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:48:47 -0000 On 4/6/2016 11:37 AM, Xuxiaohu wrote: > The situation in MPLS-SR is a little bit complex since the outgoing label for a given /32 or /128 prefix FEC could be learnt either from the IGP next-hop of that FEC or the originator of that FEC due to the IGP flooding property. In the former case, the IGP next-hop for a given FEC is taken as the next-hop of the received MPLS packet belonging to that FEC; in the latter case, the originator of that FEC is taken as the next-hop of the MPLS packet belonging to that FEC ... the latter case belongs to the "remote label distribution peer" case as defined in RFC3031 I don't believe this is correct. In SR, the fact that label L was advertised by node N does not imply that a packet with L at the top of the stack needs to be tunneled to N. In the typical case, the packet would just follow the IGP best path, and all the intermediate nodes would be expected to recognize the label at the top of the stack. If the intermediate nodes are expected to recognize the label, this is not the "remote label distribution peer case". You seem to be positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to transport packets from one to the other. It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't. In BIER, we do accommodate this sort of situation, where some of the nodes in the BIER domain do not support BIER. But I don't know whether that sort of scenario needs to be supported for MPLS-SR. Do you have a particular use case in mind? From nobody Wed Apr 6 15:40:21 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3595812D6C8; Wed, 6 Apr 2016 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkI5MsjYrvjv; Wed, 6 Apr 2016 15:40:15 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115C512D71A; Wed, 6 Apr 2016 15:40:11 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-64-570590248a7b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 33.75.22441.42095075; Thu, 7 Apr 2016 00:39:32 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Wed, 6 Apr 2016 18:40:09 -0400 From: Gregory Mirsky To: "Shah, Himanshu" , Jeff Tantsura Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byAAI06KAAAgpRTD//4Gh5//9BFOg//nhuCA= Date: Wed, 6 Apr 2016 22:40:08 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3EBAA@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A3CD69@eusaamb103.ericsson.se> <33673FCF-6DF9-4E0F-9BA2-95D670259F76@ericsson.com> <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182BA8809AB1@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyuXRPlK7KBNZwg4YDYhYHNh1ktNi1cTWj xbrLp9gsbi1dyWrx+c82RgdWj7M3/7F4LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZK15+ ZymY0cFYMWX1JsYGxi+VXYwcHBICJhK7X5V2MXICmWISF+6tZ+ti5OIQEjjKKHF38QcWCGcZ o8TpQxeYQKrYBIwkXmzsYQexRQRCJDbteMQIUsQs8IRRYuOJnywgCWEBR4nv868xQxQ5SXy4 spgVwvaT2Ni3BayZRUBFYtqlPYwgNq+Ar8Td889ZIbbtY5L4dvUlWDMnUMPK5TfAGhiB7vt+ ag3YFcwC4hK3nsxngrhbQGLJnvPMELaoxMvH/1ghbCWJOa8hjmAWyJc4uesK1DJBiZMzn7BM YBSdhWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMHKXFBTm56UaGmxiB MXhMgs1xB+PeXs9DjAIcjEo8vAtyWcKFWBPLiitzDzFKcDArifAm9bKGC/GmJFZWpRblxxeV 5qQWH2KU5mBREuf1jvwXJiSQnliSmp2aWpBaBJNl4uCUamDkDd60PDput2X1KvPiNVrO33Lk z0UWXEq0sch9NV/lY3TVK+F56u+UPvHwrReZxC76myeF7Y5tkWreioRmx6lGAUZbJsz7LtZS vmd1StyHxcvlzimKbRXge5FbrxN9rdBDP8BW8Jv3r+D387YrXdygVMxxvdj01K9Ld3c7PLO7 eTynRtRauVWJpTgj0VCLuag4EQCYnSllvQIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 22:40:18 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, the IPR Disclosures should be published in a day or two. In the meantime, w= hat in particular you suggest the WG should look into - importance of the p= roblem, terms of the Disclosures or claims of the invention? Regards, Greg From: Shah, Himanshu [mailto:hshah@ciena.com] Sent: Wednesday, April 06, 2016 1:19 PM To: Jeff Tantsura; Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; rtg-bfd@ietf.org Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces IMHO, WG should wait till IPR are disclosed and reviewed before making prog= ress on these drafts. Thanks, Himanshu From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura Sent: Monday, April 04, 2016 6:44 PM To: Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls= -chairs@ietf.org; rtg-bfd@ietf.org Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Jeff, Thanks! IPR will be disclosed ASAP, we are pushing legal. Regards, Jeff On Apr 4, 2016, at 7:31 PM, Gregory Mirsky > wrote: Hi Jeff, we have not expected this question that early :) Yes, there's IPR associated with these drafts that would be properly disclo= sed after the meeting. Regards, Greg From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Monday, April 04, 2016 3:23 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Ali= a Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Working Group, These documents reasonably extend the existing BFD on LAG mechanism and wou= ld be reasonably in charter for BFD to pick up. Greg, given that adoption seems a reasonable course, could you and the othe= r co-authors state whether there's any known IPR on these documents? -- Jeff On Apr 4, 2016, at 7:16 PM, Gregory Mirsky > wrote: Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Himanshu,

the IPR Disclosures shoul= d be published in a day or two. In the meantime, what in particular you sug= gest the WG should look into – importance of the problem, terms of the Disclosures or claims of the invention?

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Shah, Hi= manshu [mailto:hshah@ciena.com]
Sent: Wednesday, April 06, 2016 1:19 PM
To: Jeff Tantsura; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; rtg-bfd@ietf.org
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

IMHO, WG should wait till I= PR are disclosed and reviewed before making progress on these drafts.<= /o:p>

 

Thanks,

Himanshu

 

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, April 04, 2016 6:44 PM
To: Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org; rtg-bfd@ietf.= org
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interf= aces

 

Hi Jeff,

 

Thanks!

 

IPR will be disclosed ASAP, we are pushing legal.
Regards,

Jeff


On Apr 4, 2016, at 7:31 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Jeff,

we have not expected this= question that early J

Yes, there’s IPR as= sociated with these drafts that would be properly disclosed after the meeti= ng.

 <= /p>

    &= nbsp;           Regards,<= /span>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: Jeffrey = Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 04, 2016 3:23 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Working Group,

 

These documents reasonably extend the existing BFD o= n LAG mechanism and would be reasonably in charter for BFD to pick up.=

 

Greg, given that adoption seems a reasonable course,= could you and the other co-authors state whether there's any known IPR on = these documents?

 

-- Jeff

 

On Apr 4, 2016, at 7:16 PM, Gregory Mirsky <gregory.mirsky@ericsson.com&g= t; wrote:

 

Dear All,

two new drafts, related to RFC 7130, we= re published before the meeting:

 

Greatly appreciate your reviews, commen= ts, questions and suggestions.

 

Regards,

      &nb= sp; Greg

 

--_000_7347100B5761DC41A166AC17F22DF11221A3EBAAeusaamb103erics_-- From nobody Wed Apr 6 16:57:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6D412D161; Wed, 6 Apr 2016 16:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, SPF_PASS=-0.001, 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 k8uuq9K9hNKY; Wed, 6 Apr 2016 16:57:04 -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 02D7B12D15B; Wed, 6 Apr 2016 16:57:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLR20989; Wed, 06 Apr 2016 23:57:00 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 00:56:59 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 07:56:56 +0800 From: Xuxiaohu To: Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAC0wMo= Date: Wed, 6 Apr 2016 23:56:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5383EC@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> In-Reply-To: <57057618.8020604@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.116] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5705A24D.0143, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae67004a65fe6487a6f4468fd7610936 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:57:08 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBZb3VyIG9ic2VydmF0 aW9uIGlzIGNvcnJlY3QgdGhhdCBJJ20gIHBvc2l0aW5nIGEgY2FzZSB3aGVyZSB0d28gbm9kZXMg YXJlIGluIHRoZSBzYW1lIElHUCBkb21haW4sIGFuZCBzYW1lIFNQUklORyBkb21haW4sIGJ1dCB0 aGVyZSBpcyBubyBMU1AgdGhhdCBjYW4gYmUgdXNlZCB0bw0KdHJhbnNwb3J0IHBhY2tldHMgZnJv bSBvbmUgdG8gdGhlIG90aGVyLg0KDQpPbmUgcGFydGljdWxhciB1c2UgY2FzZSBpbiBtaW5kIGlz IHRoZSBNUExTLVNSIGJhc2VkIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgd2hlcmUgdGhlIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCBpcyByZXByZXNlbnRlZCBieSBhIHN0YWNrIG9mIGxhYmVscyAo c2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zZmMtdXNpbmctbXBscy1z cHJpbmcpLiBJbiBvdGhlciB3b3JkcywgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGhlYWRlciBpcyBy ZWFsaXplZCBpbiB0aGUgZm9ybSBvZiBhbiBNUExTIGxhYmVsIHN0YWNrLiBPbmUgb2YgdGhlIG1h am9yIHJlcXVpcmVtZW50IGZvciB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gaGVhZGVyIGlzIHRyYW5z cG9ydC1pbmRlcGVuZGFuY3kuIFRoYXQgbWVhbnMgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGhlYWRl ciBpbiB0aGUgZm9ybSBvZiBhbiBNUExTIGxhYmVsIHN0YWNrIHNob3VsZCBiZSBhYmxlIHRvIGJl IHRyYW5zcG9ydGVkIG92ZXIgSVAgbmV0d29ya3MuIFRvIG1lZXQgdGhlIGFib3ZlIHJlcXVpcmVt ZW50LCBvbmUgTVBMUy1TUiBub2RlIChlLmcuLCBzZXJ2aWNlIGNsYXNzaWZpZXIgb3IgU0ZGKSBz aG91bGQgYmUgYWJsZSB0byBmb3J3YXJkIGEgcmVjZWl2ZWQgTVBMUyBwYWNrZXQgdG8gYW5vdGhl ciBNUExTLVNSIG5vZGUgKGUuZy4sIFNGRikgd2hpY2ggaXMgaW5kaWNhdGVkIGJ5IHRoZSB0b3Ag bGFiZWwgb2YgdGhlIHJlY2VpdmVkIHBhY2tldCB2aWEgYW4gSVAtYmFzZWQgdHVubmVsLCB3aGVu IHRoZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0aGUgbGF0dGVyIE1QTFMtU1Igbm9kZSBpcyBhIG5v bi1NUExTIG5vZGUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEVyaWMgQyBSb3NlbiBbZXJvc2VuQGp1 bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTbE6jTUwjfI1SA0OjQ4DQrK1bz+yMs6IFh1eGlhb2h1 OyBzcHJpbmdAaWV0Zi5vcmcNCrOty806IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbXBsc10g Q2xhcmlmaWNhdGlvbiBvbiB0aGUgbW90aXZhdGlvbiBvZiBkcmFmdC14dS1zcHJpbmctaXNsYW5k cy1jb25uZWN0aW9uLW92ZXItaXAtMDUNCg0KT24gNC82LzIwMTYgMTE6MzcgQU0sIFh1eGlhb2h1 IHdyb3RlOg0KPiBUaGUgc2l0dWF0aW9uIGluIE1QTFMtU1IgaXMgYSBsaXR0bGUgYml0IGNvbXBs ZXggc2luY2UgdGhlIG91dGdvaW5nIGxhYmVsIGZvciBhIGdpdmVuIC8zMiBvciAvMTI4IHByZWZp eCBGRUMgY291bGQgYmUgbGVhcm50IGVpdGhlciBmcm9tIHRoZSBJR1AgbmV4dC1ob3Agb2YgdGhh dCBGRUMgb3IgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMgZHVlIHRvIHRoZSBJR1AgZmxvb2Rp bmcgcHJvcGVydHkuIEluIHRoZSBmb3JtZXIgY2FzZSwgdGhlIElHUCBuZXh0LWhvcCBmb3IgYSBn aXZlbiBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSByZWNlaXZlZCBNUExTIHBh Y2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUM7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIG9yaWdp bmF0b3Igb2YgdGhhdCBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSBNUExTIHBh Y2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUMgLi4uIHRoZSBsYXR0ZXIgY2FzZSBiZWxvbmdzIHRv IHRoZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIiBjYXNlIGFzIGRlZmluZWQgaW4g UkZDMzAzMQ0KDQpJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBjb3JyZWN0LiAgSW4gU1IsIHRoZSBm YWN0IHRoYXQgbGFiZWwgTCB3YXMNCmFkdmVydGlzZWQgYnkgbm9kZSBOIGRvZXMgbm90IGltcGx5 IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2YNCnRoZSBzdGFjayBuZWVkcyB0byBi ZSB0dW5uZWxlZCB0byBOLiAgSW4gdGhlIHR5cGljYWwgY2FzZSwgdGhlIHBhY2tldA0Kd291bGQg anVzdCBmb2xsb3cgdGhlIElHUCBiZXN0IHBhdGgsIGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBu b2Rlcw0Kd291bGQgYmUgZXhwZWN0ZWQgdG8gcmVjb2duaXplIHRoZSBsYWJlbCBhdCB0aGUgdG9w IG9mIHRoZSBzdGFjay4gIElmDQp0aGUgaW50ZXJtZWRpYXRlIG5vZGVzIGFyZSBleHBlY3RlZCB0 byByZWNvZ25pemUgdGhlIGxhYmVsLCAgdGhpcyBpcyBub3QNCnRoZSAicmVtb3RlIGxhYmVsIGRp c3RyaWJ1dGlvbiBwZWVyIGNhc2UiLg0KDQpZb3Ugc2VlbSB0byBiZSBwb3NpdGluZyBhIGNhc2Ug d2hlcmUgdHdvIG5vZGVzIGFyZSBpbiB0aGUgc2FtZSBJR1ANCmRvbWFpbiwgYW5kIHNhbWUgU1BS SU5HIGRvbWFpbiwgYnV0IHRoZXJlIGlzIG5vIExTUCB0aGF0IGNhbiBiZSB1c2VkIHRvDQp0cmFu c3BvcnQgcGFja2V0cyBmcm9tIG9uZSB0byB0aGUgb3RoZXIuICAgSXQgd291bGQgYmUgc29tZXdo YXQgdW51c3VhbA0KdG8gaGF2ZSBhbiBJR1AgZG9tYWluIGluIHdoaWNoIHNvbWUgbm9kZXMgc3Vw cG9ydCBNUExTIGFuZCBzb21lIGRvbid0Lg0KSW4gQklFUiwgd2UgZG8gYWNjb21tb2RhdGUgdGhp cyBzb3J0IG9mIHNpdHVhdGlvbiwgd2hlcmUgc29tZSBvZiB0aGUNCm5vZGVzIGluIHRoZSBCSUVS IGRvbWFpbiBkbyBub3Qgc3VwcG9ydCBCSUVSLiAgQnV0IEkgZG9uJ3Qga25vdyB3aGV0aGVyDQp0 aGF0IHNvcnQgb2Ygc2NlbmFyaW8gbmVlZHMgdG8gYmUgc3VwcG9ydGVkIGZvciBNUExTLVNSLiAg RG8geW91IGhhdmUgYQ0KcGFydGljdWxhciB1c2UgY2FzZSBpbiBtaW5kPw== From nobody Thu Apr 7 05:07:34 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BE112D825; Thu, 7 Apr 2016 05:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvuSNg2hQ3N7; Thu, 7 Apr 2016 05:07:24 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7EB0E12D810; Thu, 7 Apr 2016 05:07:21 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id l6so22506136wml.1; Thu, 07 Apr 2016 05:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=lvn9ful5xEwJ0ePdz5+gyHmG5hDUKtFBsWV2UH2qNL8=; b=CEdp0zwW0VH00A0hCpoctsA/tcnZQ4mpJevh2/HVSc6+CRx3jtn8BInCludU/OTLoB mF973A0sfusHo71Gvxu887zrDRM2CnNclXeuEL0q63qEg3D36HQblfxd0OZLTlH7j1At jtC7mOHN3lULKYk4w3ah3o5agOgiUOVdEoZt3CJ5ztcWS0+nRZqBiU69V2aparKPy0Al 0NVl7xC47ceXMlh3AgWIyeDMHghWqpC7qQoah8j7u2JTvHVVFbh1xUJeazCDacAxJUrY VAmyj0gApvsSYGGrJ9/Bozv1YFCalX0+C6O9/TQ5rc7tvB+u8Udi1XMmOWwCMNHDMZvf 8Q/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=lvn9ful5xEwJ0ePdz5+gyHmG5hDUKtFBsWV2UH2qNL8=; b=mwy3dVIFjUSni+VPvW3iGgGD+9ku0RKFRPmFJV3mwTX0pv2CQk75gmqvNGjpmf0M1w ccV5uRYQZg4hDug2EPQwJA7Dpvq3s4SJxbYyKdBZk6E25oyGHLsaEJf4s5K/IrZ+1R0m Lbg+s+i58XE8p0zH79gAxxf2+4jmw/AWXm0LGtKll92jqXNTnDhhvhz3JMO+X/AqonNN pV/4Ep1UO4M6fIwrwcxQU84Wf6X/VdJYb8hd1VyHix3R9HmqO/3XZ9PXHDGHTzp42h22 4pv/7cAMusy+AQTZ/smAfsToVz3rSChLZ28wX/brrzPDkT4rsvMygPSXsBBPIvtfo44V E8XA== X-Gm-Message-State: AD7BkJLSpBhirMjTbPGUGRV67va9h8G98PytVwRvVxZV++BZDNuGevMqzsRLZB0Tx8782g== X-Received: by 10.194.20.193 with SMTP id p1mr3295200wje.87.1460030839961; Thu, 07 Apr 2016 05:07:19 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id cb2sm8200106wjc.16.2016.04.07.05.07.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 05:07:18 -0700 (PDT) To: Benoit Claise , The IESG References: <20160107094835.20273.74075.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <57064D75.5010208@gmail.com> Date: Thu, 7 Apr 2016 13:07:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160107094835.20273.74075.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010901050207020501000102" Archived-At: Cc: mpls@ietf.org, evyncke@cisco.com, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Benoit Claise's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:07:27 -0000 This is a multi-part message in MIME format. --------------010901050207020501000102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad t= hat there is no alignment. At the very minimum, in the terminology and co= ncepts. From RFC 5357 +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ Something I already mentioned to the RFC 6374 authors in the past when do= ing my OPS-DIR review. Sigh... SB> That is water that passed under the bridge a long time ago. Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR= review: This short I-D is quite clear and easy to understand, security & manageab= ility sections are correct. I found nothing in this framework document wh= ich could cause operational issues EXCEPT: as I am unsure of the usual PLDM procedures, what is the expected be= havior when a PLDM message (incl a URO) is received by a PLDM node which = does not support this object type? If it is well defined in PLDM, then th= ere is no problem of course. SB> Section 3.5 or RFC6374 states: "Upon receipt of a query message including an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code." SB> That the error case is well handled in the base protocol. Can a reply be fragmented? Should the reply contains the DF bit for IPv= 4? Probably worth mentioning what to do over fragmentation. SB> Given the short size of the messages, I cannot imagine this will ever= happen but in any case SB> I cannot see why fragmentation at the IP layer would introduce any pa= rticular problem. What is the expected behavior when the URO contains an IPv6 address and= the PLDM responder only has IPv4 address(es)? SB> I have updated the text as follows to address this point: When the requested return path is an IP forwarding path and this method i= s in use, the destination IP address and UDP port is copied from the URO.= The source IP address and the source UDP Port of Response packet is left= to discretion of the Responder subject to the normal management and secu= rity considerations. If the Querier has included URO(s) for only one IP a= ddress family and a return path of that type is not available, then the q= uery message MUST be discarded, and the operator SHOULD be informed of th= e error through the management system using the normal rate limited appro= ach. If the Responder is configured to only respond with a single respons= e, and a path using the IP address family in the first URO is not availab= le, the Responder MAY search the UROs for the first URO specifying a retu= rn address family for which it does have a path, and use the parameters i= n that URO to respond. If the responder is designed or configured not to = search for a URO that it can respond to, then the operator SHOULD be inf= ormed of the error through the management system using the normal rate li= mited approach. Small nits: in introduction, I guess you meant "internally be forwarded" rather = than "internally forwarded" SB> Fixed Section 4.3, when selecting the source address, you may want to refe= r to RFC 6724 SB> Surely the router is either aware of this or in is not and in either = case it is really part of the IP service in the router rather than a part= of this protocol. --------------010901050207020501000102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 
And we're now redoing the OWAMP/TWAMP protocols ... This is kind of sad that there is no alignment. At the very minimum, in the terminology and concepts.
>From RFC 5357

         +----------------+               +-------------------+
         | Session-Sender |<-TWAMP-Test-->| Session-Reflector |
         +----------------+               +-------------------+
           ^                                     ^
           |                                     |
           |                                     |
           |                                     |
           |  +----------------+<----------------+
           |  |     Server     |
           |  +----------------+
           |    ^
           |    |
           | TWAMP-Control
           |    |
           v    v
         +----------------+
         | Control-Client |
         +----------------+


Something I already mentioned to the RFC 6374 authors in the past when doing my OPS-DIR review. Sigh...

SB> That is water that passed under the bridge a long time ago.


Anyway, please engage in the discussion regarding Eric Vyncke's OPS DIR review:
This short I-D is quite clear and easy to understand, security & manageability sections are correct. I found nothing in this framework document which could cause operational issues EXCEPT:

    as I am unsure of the usual PLDM procedures, what is the expected behavior when a PLDM message (incl a URO) is received by a PLDM node which does not support this object type? If it is well defined in PLDM, then there is no problem of course.


SB> Section 3.5 or RFC6374 states:

   "Upon receipt of a query message including an unrecognized mandatory
   TLV object, the recipient MUST respond with an Unsupported Mandatory
   TLV Object error code."

SB> That the error case is well handled in the base protocol.

Can a reply be fragmented? Should the reply contains the DF bit for IPv4? Probably worth mentioning what to do over fragmentation.

SB> Given the short size of the messages, I cannot imagine this will ever happen but in any case
SB> I cannot see why fragmentation at the IP layer would introduce any particular problem.

What is the expected behavior when the URO contains an IPv6 address and the PLDM responder only has IPv4 address(es)?

SB> I have updated the text as follows to address this point:

When the requested return path is an IP forwarding path and this method is in use, the destination IP address and UDP port is copied from the URO. The source IP address and the source UDP Port of Response packet is left to discretion of the Responder subject to the normal management and security considerations. If the Querier has included URO(s) for only one IP address family and a return path of that type is not available, then the query message MUST be discarded, and the operator SHOULD be informed of the error through the management system using the normal rate limited approach. If the Responder is configured to only respond with a single response, and a path using the IP address family in the first URO is not available, the Responder MAY search the UROs for the first URO specifying a return address family for which it does have a path, and use the parameters in that URO to respond. If the responder is designed or configured not to search for a URO that it can respond to,  then t
he operator SHOULD be informed of the error through the management system using the normal rate limited approach. 

Small nits:

    in introduction, I guess you meant "internally be forwarded" rather than "internally forwarded"

SB> Fixed

    Section 4.3, when selecting the source address, you may want to refer to RFC 6724

SB> Surely the router is either aware of this or in is not and in either case it is really part of the IP service in the router rather than a part of this protocol.
--------------010901050207020501000102-- From nobody Thu Apr 7 05:12:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59C512D84E; Thu, 7 Apr 2016 05:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oym2yucYe7Ap; Thu, 7 Apr 2016 05:12:10 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C3A12D83C; Thu, 7 Apr 2016 05:12:05 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id n3so20958003wmn.1; Thu, 07 Apr 2016 05:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3Mp4IRzYDTk4chvFxdc9VTVvecpu8DtW0bvMw69BUJw=; b=CiAGmMZ0zE72Kstnam1S/JBg1f/9vQMUJ4pYui+WjiN77QRepKT3wywCj2SzpUXefL f72Y0FZp4qbSjdVVkwZEdcaVzb+uu3DxtdLYLjiyecdl9AzRvbuBBre+w6wt3ORDfiZD Bksh91CkLTgzDKeuxWy0ZkJfPqW0hETH95k6ZMFHR721MwMXDPSqn98rwaVmF/pkcAo5 x4B10WSpPXC5NxNyzaZvPggM0axHxVKQ1zZ5B5Huui1aOJCdfQEQCHvldgRCvXF1nLmT QjFJ/PewH66QbaW6F3jm8Cexn3/p9BeyncTu7miJKorM4060c1Jyq9wQQLwnzk66HU19 noIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3Mp4IRzYDTk4chvFxdc9VTVvecpu8DtW0bvMw69BUJw=; b=CDTmvnizRGGwf19BFD3S3lB1SFgECX0ImymiFybt5KmtWssMh31CvGLUGxNNp7NKOO 5DyWAnIZk90jN1el6zYdxcR3dP5YJP+91cqFd0lZpTz4RFUTW1ZnVEDR+uamdSQPBcSf gtclWbXx5Ii1+i0NPH3qYN6XMqdd9GY3gkP1Rd886m3b0KPauLeR/Ccin7R7dx5TDCXa 4cGg3UzMTjk0yzQeWUtoOMLvSsEHwM5Aqh1rZQC1lM6nmwO7dKvpA+KHW5w9CyrkBlvs oBX4uWmISjsSrHlj2SbYEMwWArz18wWDRjNJy99Whq4UyTsRDqWr2JdwhagXiTQDuM+g h8ng== X-Gm-Message-State: AD7BkJKeVe5K/GWA1FwyY8Yaru1ymuOue6D6QPFKaOowNv9muFfVZvU8fIH8Wd0vvUCOaQ== X-Received: by 10.28.125.8 with SMTP id y8mr30852649wmc.87.1460031124130; Thu, 07 Apr 2016 05:12:04 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m134sm8678123wmd.14.2016.04.07.05.12.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 05:12:03 -0700 (PDT) To: Alia Atlas , The IESG References: <20160105163714.22863.53937.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <57064E91.2090609@gmail.com> Date: Thu, 7 Apr 2016 13:12:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160105163714.22863.53937.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Alia Atlas' Yes on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:12:12 -0000 I have worked through the RFC2119 language and think it is now right. I interpret a SHOULD as a caveated MUST so when the caveats are provided in one part of the text it can be (with a MUST) I think it is safe to use SHOULD elsewhere. Anyway I have had another go at making the intent clearer. Stewart On 05/01/2016 16:37, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: Yes > > 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-mpls-rfc6374-udp-return-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The introduction uses a MUST for the receiver to use the URO, but the > later text uses SHOULD. > Could you please clarify and make them the same? > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 7 05:15:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837A912D7FD; Thu, 7 Apr 2016 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOFTWJF9_PIF; Thu, 7 Apr 2016 05:15:26 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6402212D6FD; Thu, 7 Apr 2016 05:15:25 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id l6so3848617wml.3; Thu, 07 Apr 2016 05:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uOEXXOpMEX9w7ZXAZ4C9K/S8XW9hUaTt/E3DeDO3jLY=; b=h3E8HEGN2LD1ORAAoXjJwxgo+8TXeLd+WlUI0yzgobb4AaWXompj72iqowTEnrnOuf Ta4hQ8qKOeetXT5pedWPV4KJy9vEJreo6gv4/KjcpGyRrYaCSSUVvFLwN7Uazt7m1oXj YMgnGUFvfXWU2u0MbmgmcSW3MPGTwwrwy69GfhRVZhJ8hj+Mpm9PhCIZPvOOZXC0ktqD 5cMMtcg/oIhAMhl+mEGENEh8a2SK90l7Gn3ad4b9t9xYXjrhAYURppd2CyubtAbQ/6ID dQbn4efbrzi+aIT9xKvbOZthe5kh3Pf/lEo/Ae8iYqHA+jCDbuIWepjaB/F37MHwFcpQ RtDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uOEXXOpMEX9w7ZXAZ4C9K/S8XW9hUaTt/E3DeDO3jLY=; b=OKwYYYmfB5K1+CPNhVEDtmdUU0obzSW9Cu7dA9NPpQRIo0TW6xLf0Rh7ll5/ziA4Ry E664Ls1FUEkbJtXEEfKL8MXwNkbF+brLf3+Tm1VWA6DUTme2D/2O3Sjuotn3pmwL7xtH ID6graQYk/WZBtpHr3TVB4ygRZ+t15eq75NVWlIYml5siQ7CjfrFo6ZICblcWQqCyhBj tGAMnKj8kSYrgxPY50t5irkTmOuB/1Ls4LLbswd5kX/h9x8PHxaVbQWfBocHG3cph37V riAwXE18NBHurh7jXz0VRVR/Ht9DuzHGp0GkYUvEGBNd/QGmDVnqXEVBwiK4tS/Im87U aPHQ== X-Gm-Message-State: AD7BkJKwrBK/vfYhbP31un9+yXREFJ2ueLCrSRf7KTkQZJ0TUVtPOw8XoSmAoltqE529Bg== X-Received: by 10.194.133.161 with SMTP id pd1mr3574016wjb.66.1460031324446; Thu, 07 Apr 2016 05:15:24 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id l124sm8653894wmf.11.2016.04.07.05.15.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 05:15:23 -0700 (PDT) To: Spencer Dawkins , The IESG References: <20160107043320.4920.88068.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <57064F5A.2050401@gmail.com> Date: Thu, 7 Apr 2016 13:15:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160107043320.4920.88068.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 12:15:29 -0000 On 07/01/2016 04:33, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would be fine keeping the to-be-deleted text explaining alternatives > that were not selected, especially if it was moved to an appendix. If > anyone ever wonders about the alternatives, that would mean they didn't > have to dig through e-mail archives to see what was considered and why > the alternatives were rejected. > > I'm not understanding why > > When the MPLS-PLDM Response is requested out-of-band by setting the > Control Code of the MPLS-PLDM query to "Out-of-band Response > Requested", and the URO is present, the responder SHOULD send the > response back to querier on the specified destination UDP port at the > specified destination IP address contained in the URO. > > is a SHOULD. Could you help me with that? > > There are certain conditions where such a response is not possible. These are described in the text. I take SHOULD to mean "MUST unless there are extenuating circumstances" and MUST to mean "Unconditionally do". Stewart From nobody Thu Apr 7 06:15:14 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFDF12D93D for ; Thu, 7 Apr 2016 06:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cFWEGNdbz5P for ; Thu, 7 Apr 2016 06:15:12 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661EC12D61C for ; Thu, 7 Apr 2016 06:15:06 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-ec-57065d332890 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.59.22441.33D56075; Thu, 7 Apr 2016 15:14:27 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 09:15:04 -0400 From: Eric Gray To: "mpls@ietf.org" Thread-Topic: YANG Data Model for MPLS LDP and mLDP Thread-Index: AdGQz39OiiwIKDo0Sh2KJ/9vN87vVg== Date: Thu, 7 Apr 2016 13:15:03 +0000 Message-ID: <95E28899-03A5-4941-B87B-34B14443E360@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-08B79AE5-A831-48DE-B4F0-DBBE5378A46B"; protocol="application/pkcs7-signature" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPlK5xLFu4weXF4ha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxso7J9gL1jpXfHr8k6WBca99FyMnh4SAicTF9Z/YIGwxiQv3 1gPZXBxCAkcZJdYsmM8O4SxjlFh3cT07SBWbgIbEsTtrGUFsEQFliSMTu1lBbGEBPYmHGxYw Q8SNJd4susUEYetJ7Do2DyzOIqAiMXnlK7A4r4C9xO8nG8FmMgJt/n5qDVicWUBc4taT+UwQ F4lIPLx4Guo6UYmXj/+xghzELDCZUeLDjPlsEIMEJU7OfMIygVFwFpL+WcjqZiGpm8XIAZSI l1hz0BmiXl5i+9s5zBBhHYnJCxkhwtoSyxa+ZoawNSQ6v01khbAVJaZ0P2SHsK0lZvw6yAZh m0q8PvqREVnNAkaeVYwcpcUFObnpRoabGIGxdUyCzXEH495ez0OMAhyMSjy8CvtZw4VYE8uK K3MPMaoAtT7asPoCoxRLXn5eqpII7+FwtnAh3pTEyqrUovz4otKc1OJDjNIcLErivN6R/8KE BNITS1KzU1MLUotgskwcnFINjPPqnh+ceuzA7CD5HcXPkl9NflOaPbvAUNHaI9pt1z+H0x4b W3tua2xIXpUSwDD/fuG0YuGKTv8E1Skr55zMrfzUuK3HIdKrhnFKLqtGq8beuGNCGtonS81X 6Law992Y2DenbfaTDwdnrP4qxf552v65PO82Pn7A5ys5pYFLyX7dI98cNsYZU5VYijMSDbWY i4oTAQZPIby1AgAA Archived-At: Subject: [mpls] YANG Data Model for MPLS LDP and mLDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 13:15:13 -0000 --Apple-Mail-08B79AE5-A831-48DE-B4F0-DBBE5378A46B Content-Type: multipart/alternative; boundary=Apple-Mail-1ADC8E0C-2149-4060-8679-28A296F5E133 Content-Transfer-Encoding: 7bit --Apple-Mail-1ADC8E0C-2149-4060-8679-28A296F5E133 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Folks, Tuesday evening, at the joint TEAS/MPLS/PCE meeting, Rajiv presented the wor= k he and his co-authors had done on a draft related to MPLS LDP and mLDP. =20= The draft is at: https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-y= ang (or at https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang). The slides can be found at: https://www.ietf.org/proceedings/95/slides/slide= s-95-teas-14.pptx=20 Afterwards, several people discussed the fact that there is something not-qu= ite right about the definition of "peer" they would be using in their models= . Specifically, while the definitions shown are closely related to the definit= ions originally used in RFC 5036 (and RFC 3036 before that), they do not qui= te fit when considering LDP graceful restart (RFC 3478) - because the peer r= elationship survives the session relationship when using graceful restart - i= .e. - the labels distributed by a peer remain valid for some time after the s= ession ends. In fact, with LDP graceful restart, the intention is that the l= abels previously distributed by the peer would remain valid until explicitly= withdrawn in the next (or a subsequent) session. After some discussion, both after the meeting and earlier today, it seems li= kely this may be only one example of a case where the draft may not adequate= ly address the implications of LDP graceful restart. -- Eric Gray Sent from my iPad= --Apple-Mail-1ADC8E0C-2149-4060-8679-28A296F5E133 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PC9kaXY+ PGRpdj5Gb2xrcyw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+VHVlc2RheSBldmVuaW5nLCBhdCB0 aGUgam9pbnQgVEVBUy9NUExTL1BDRSBtZWV0aW5nLCBSYWppdiBwcmVzZW50ZWQgdGhlIHdvcmsg aGUgYW5kIGhpcyBjby1hdXRob3JzIGhhZCBkb25lIG9uIGEgZHJhZnQgcmVsYXRlZCB0byBNUExT IExEUCBhbmQgbUxEUC4gJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhl IGRyYWZ0IGlzIGF0OiZuYnNwOzxmb250IGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhemEtbXBscy1sZHAtbWxkcC15YW5nJUMyJUEwIiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhemEtbXBscy1sZHAtbWxkcC15YW5nJm5i c3A7PC9hPiZuYnNwOyg8L2ZvbnQ+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEo MjU1LCAyNTUsIDI1NSwgMCk7Ij5vciBhdCA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJhemEtbXBscy1sZHAtbWxkcC15YW5nIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcmF6YS1tcGxzLWxkcC1tbGRwLXlhbmc8L2E+PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4pLjwvc3Bhbj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBzbGlkZXMgY2FuIGJlIGZvdW5kIGF0OiZuYnNw Ozxmb250IGNvbG9yPSIjMDAwMDAwIiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUs IDI1NSwgMjU1LCAwKTsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk1L3NsaWRlcy9zbGlkZXMtOTUtdGVhcy0xNC5wcHR4IiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRp bmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtdGVhcy0xNC5wcHR4PC9hPiZuYnNwOzwvZm9udD48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFmdGVyd2FyZHMsIHNldmVyYWwgcGVvcGxlIGRpc2N1c3Nl ZCB0aGUgZmFjdCB0aGF0IHRoZXJlIGlzIHNvbWV0aGluZyBub3QtcXVpdGUgcmlnaHQgYWJvdXQg dGhlIGRlZmluaXRpb24gb2YgInBlZXIiIHRoZXkgd291bGQgYmUgdXNpbmcgaW4gdGhlaXIgbW9k ZWxzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3BlY2lmaWNhbGx5LCB3aGlsZSB0aGUgZGVm aW5pdGlvbnMgc2hvd24gYXJlIGNsb3NlbHkgcmVsYXRlZCB0byB0aGUgZGVmaW5pdGlvbnMgb3Jp Z2luYWxseSB1c2VkIGluIFJGQyA1MDM2IChhbmQgUkZDIDMwMzYgYmVmb3JlIHRoYXQpLCB0aGV5 IGRvIG5vdCBxdWl0ZSBmaXQgd2hlbiBjb25zaWRlcmluZyBMRFAgZ3JhY2VmdWwgcmVzdGFydCAo UkZDIDM0NzgpIC0gYmVjYXVzZSB0aGUgcGVlciByZWxhdGlvbnNoaXAgc3Vydml2ZXMgdGhlIHNl c3Npb24gcmVsYXRpb25zaGlwIHdoZW4gdXNpbmcgZ3JhY2VmdWwgcmVzdGFydCAtIGkuZS4gLSB0 aGUgbGFiZWxzIGRpc3RyaWJ1dGVkIGJ5IGEgcGVlciByZW1haW4gdmFsaWQgZm9yIHNvbWUgdGlt ZSBhZnRlciB0aGUgc2Vzc2lvbiBlbmRzLiBJbiBmYWN0LCB3aXRoIExEUCBncmFjZWZ1bCByZXN0 YXJ0LCB0aGUgaW50ZW50aW9uIGlzIHRoYXQgdGhlIGxhYmVscyBwcmV2aW91c2x5IGRpc3RyaWJ1 dGVkIGJ5IHRoZSBwZWVyIHdvdWxkIHJlbWFpbiB2YWxpZCB1bnRpbCBleHBsaWNpdGx5IHdpdGhk cmF3biBpbiB0aGUgbmV4dCAob3IgYSBzdWJzZXF1ZW50KSBzZXNzaW9uLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+QWZ0ZXIgc29tZSBkaXNjdXNzaW9uLCBib3RoIGFmdGVyIHRoZSBtZWV0aW5n IGFuZCBlYXJsaWVyIHRvZGF5LCBpdCBzZWVtcyBsaWtlbHkgdGhpcyBtYXkgYmUgb25seSBvbmUg ZXhhbXBsZSBvZiBhIGNhc2Ugd2hlcmUgdGhlIGRyYWZ0IG1heSBub3QgYWRlcXVhdGVseSBhZGRy ZXNzIHRoZSBpbXBsaWNhdGlvbnMgb2YgTERQIGdyYWNlZnVsIHJlc3RhcnQuPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj4tLTwvZGl2PjxkaXY+RXJpYyBHcmF5PC9kaXY+PGRpdj48YnI+PGJyPlNl bnQgZnJvbSBteSBpUGFkPC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-1ADC8E0C-2149-4060-8679-28A296F5E133-- --Apple-Mail-08B79AE5-A831-48DE-B4F0-DBBE5378A46B Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5zCCBeMw ggPLoAMCAQICEQCYS4jmwxNQqniBrBdU7S3YMA0GCSqGSIb3DQEBBQUAMDoxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyMB4XDTE0MTIzMTE5 MjAyNloXDTE3MTIzMTE5MjAyNVowYDERMA8GA1UECgwIRXJpY3Nzb24xEjAQBgNVBAMMCUVyaWMg R3JheTElMCMGCSqGSIb3DQEJARYWZXJpYy5ncmF5QGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHRUVS SUdSQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIlMl/jl+AkgaIjIzEpXGCYxvFXz 17v9ZSd3zfUuH1OafZMyy0aZpBog39btvM7ZVrihvhjDL1h0oKHLFbEFIOuhIsDdXVU5NFAwVcNn VYT1NstvHkQQ19tNoL6oxlh6/fdhQ18VQNIvKMjfykuILypr2Uf1FSa5/ApNS7yvh9qXXflmsS76 PTa7GAb5uqW3IX8b/H/OvzUtR9lvSgd8E5j/SmcARHReBJn9VKmg2roZUKtiW4Qp989K8/zUI3F5 hVT+Cf08H5vBjc4+2axzQ4ae2JH5Fe9OZP/yCiB3yreKqop4UMdNl+aJuolFnCm4PTO8AgmQHT+i Vn/coKeWQLsCAwEAAaOCAbwwggG4MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3Qu dGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAo BggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0 cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2Vy MCEGA1UdEQQaMBiBFmVyaWMuZ3JheUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIP AgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQ9QnvpKIwR U4CeORX8hs167SV3YTAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNVHQ8BAf8E BAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAEKhCmOeiE9igJ2BRf2YSEA551K3eJ+L308zxUrg8ETH 4FiplFJ6n8J2Qpw8wsT/ZIBbjIsGyXL8J0Wfloo00157bAijqK8x/9DMJBzonMAZk+MdtbWSzvK7 iHMDGHiz11e8MHoVL0bsbgmeiqaRp0F5bO9FOmSC1ZHDVFP8BeYqxObPizR2CA0cwxKclQTrrDvo 9jES0vbIRgE0oE2Omtl9nYtmEk68jo+92ofY/lRM4u8bLcP923rN8kWNcM4krzw4ionp62OhqY1u OY91+F2d3+6SzoF81quKTJyP6HHnZ0+nXfR0qApb1EVL1b4fluhJ8fXwjTZszOdnqbX1Ei7tzno8 d/DpAOrXHB9iUXOGJxFbfCAPUxoG0ipVu93s2AnIDM4CRrodUrkrFd2Gwd84pUDBajxdisQxx1aM HU20ldi/s/hETTvOJrdy3JeGcWwndKtlsh9np5sX32+W9ucUtgWVsouQO4OmJXiOrsQKFd0fyhx2 OecgIvpASRMSU2S+/Aa2o65u82PlwC0tKu5+JWig084SP6461K0vXHUgOFOGINdHv3NUNY+RrbaB +rf86h1FyjwhBPgQYgLK4RfKCeg8X3imQSTaSn2MMbBOcOB498v6FOcR7O6dSWskXliiFXP+HqeR rHHVHMCUWVGKABPNv/aCNqe3MizGf9OTMYICmTCCApUCAQEwTzA6MREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIRAJhLiObDE1CqeIGsF1Tt LdgwCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTYwNDA3MTMxNTAxWjAjBgkqhkiG9w0BCQQxFgQU1ZMTOiRmP+Qinb5fy17ypEZjDVswXgYJ KwYBBAGCNxAEMVEwTzA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIRAJhLiObDE1CqeIGsF1TtLdgwYAYLKoZIhvcNAQkQAgsxUaBPMDox ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy AhEAmEuI5sMTUKp4gawXVO0t2DANBgkqhkiG9w0BAQEFAASCAQCFnrBCWSzfNw4y35Wk0tnajET8 joqVAuf8kO9850mu29PRl9mCsY+iLpWrsLhPbdkLGb6vxZiE2ZPcYTLW8b48JkZLejBePezkjXaf wzwzn95VDm2kh0Fc+apfZoNyG94Wv8q3bE7b3rOknH+1B1k17rHGtjCoSIA3lbVYz7snoxWCZAvX TANxWa3AGHRHASkAYswP28jXdvtodUgSz0ugWhsTNu9Mofd/4VZ+58ChWVEVNPPX/LWuKxzgpc7A Tr2QGUUFIIiURDdHYLf+1CtkSC0URP6wMWaiMgrMEULALQNKPBgnouSsvSBU1DSp+eI0JVVyUreH Omw7Kexp6VpUAAAAAAAA --Apple-Mail-08B79AE5-A831-48DE-B4F0-DBBE5378A46B-- From nobody Thu Apr 7 07:36:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084412DA26; Thu, 7 Apr 2016 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFMxO_QfNExF; Thu, 7 Apr 2016 07:36:37 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 36F0E12D81B; Thu, 7 Apr 2016 07:20:35 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id y144so4858690wmd.0; Thu, 07 Apr 2016 07:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KV973vaeOsi9tNw8xu4EOBb7l90l6wAASnnzDlDoX+s=; b=TPdP6He8DaSE78Bd0WTrV//Qsekev95mKRSgszORTIUJge79NERXpgqvSJSDvoPv7l VZpDzLznPumN+DTZYceCng/+WMoOvQGIJh+CDJu08oHmBMk233j9wmqnfJ55TXaC1lV+ u+GO0yJmndmGViQr32FOcAKGJ5+srnxlyb/nt4Fb25nM5h5R9rpYMrAqAIkjaT2iuXm9 cFNQoSTbHNDbY2fYb3drQW0ymcH/QHy4RXHvdl+TTXG6Fk6RHCRae2I3OxaNW41xu5NS Oyhf0qXjX7o9Q1zwLNB3cfY+9M5Zji3V1c6i76c5x06Fmc/gACqgzPYIihZ2UrF68yDo PMHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KV973vaeOsi9tNw8xu4EOBb7l90l6wAASnnzDlDoX+s=; b=C4qFrxYUqQtln7Nn3dkLwGK/KBienD1MZKV9/cj0m/FT3ruzOfKWN2rS+T4Ez2LZAl nC5c9BYs3feZp+N04z8rRkf/hrnbTBLpnVXE2nA9ygFsJ5VTz58os5FrrCo8F2twERs/ hkAhrMKSwHKwuKOzifOrbNVPLJB5k/OJJX4gX+bgKCK3iAnvaP2BZ9UQN3K7GWF3IRPi vnGXgYDKBq17Ug/Lg9BYK7X4H83caJphqEbbmFnIjvigSL/mwhy/PkHhnv1ovGYe1YFK 8lMtRclfA/A/X3ZnfuV3sGTOMltuT4kNKhm049vwEWFqb3cA2LOxaPwP+CKHITa8Sdh8 H4kA== X-Gm-Message-State: AD7BkJIEMK8/RnX6QlpopF+tiPTWnXI9DOEOBmyYzdqsCDmTZUOWnfcMhxNzLJcwz+wasA== X-Received: by 10.28.220.213 with SMTP id t204mr4586210wmg.42.1460038833685; Thu, 07 Apr 2016 07:20:33 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id p189sm30549199wmb.7.2016.04.07.07.20.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 07:20:32 -0700 (PDT) To: Stephen Farrell , The IESG References: <20160105170104.3818.25141.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <57066CAF.4040002@gmail.com> Date: Thu, 7 Apr 2016 15:20:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160105170104.3818.25141.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Stephen Farrell's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 14:36:41 -0000 On 05/01/2016 17:01, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > There were changes that seem to have been agreed as as > result of the secdir review. [1] Some of those could I > think nearly but not quite be discuss level, but as they > aren't and the discussion seems to have started, I'll > ballot no-objection but I do hope that the promised > changes get made, and I'd recommend cycling back to the > secdir reviewer (Sandy Murphy) as it wasn't clear to me > that the discussion reached closure just before the > holidays. > > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg06296.html I have added text on the need to check the validity of the IP address to avoid Dos attacks and some text on default addresses. > > - Could this be used as a way to nicely disguise a DoS? > I'm not sure if that's new to this or not though. See above > > - Thanks for the applicability statement in the security > considerations. Makes me wonder about MPLS/UDP but sure. > > - Saving a single bit to distinguish address families via > length seems unwise here, as everywhere. Considering the difficulty of getting IPv6 deployed, I really doubt that that we will see a new IP family. - Stewart From nobody Thu Apr 7 08:10:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D40712D66B; Thu, 7 Apr 2016 08:10:36 -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 ti3UsL1mIm2F; Thu, 7 Apr 2016 08:10:34 -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 B73B212D1CF; Thu, 7 Apr 2016 07:57:21 -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 7F6B51802AC8; Thu, 7 Apr 2016 16:57:19 +0200 (CEST) To: "mpls@ietf.org" References: <56ECBFC0.4000205@pi.nu> From: Loa Andersson Message-ID: <57067545.6090203@pi.nu> Date: Thu, 7 Apr 2016 22:57:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56ECBFC0.4000205@pi.nu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mpls-tp-linear-protection-mib@ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] Closed - draft-ietf-mpls-tp-linear-protection-mib X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:10:36 -0000 Working Group, This wglc is closed. We have had both support and comments that needs to be addressed, the authors has promised to address the comments in a new version of the draft. /Loa On 2016-03-19 10:56, Loa Andersson wrote: > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-tp-linear-protection-mib. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. > > All the authors and contributors have stated on the working group > mailing list that they are not aware of any IPRs that relates to this > draft. > > Note 1: The document shepherd has agreed with the MIB-doctor to do a > further review as part of the wglc. > > Note 2: When we progress MIB modules today it is often asked if we > should do a YANG model instead. Nothing in this document stops us from > doing a YANG model, but we have clear operator interest to have the MIB > module progressed. > > This working group last call ends April 05, 2016. > > /Loa > for the MPLS wg chairs > From nobody Thu Apr 7 08:26:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884CE12D5C4; Thu, 7 Apr 2016 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Wp--8RYsdGNh; Thu, 7 Apr 2016 08:26:20 -0700 (PDT) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (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 ED20212D19B; Thu, 7 Apr 2016 08:16:53 -0700 (PDT) Received: by mail-wm0-f65.google.com with SMTP id l6so5135214wml.3; Thu, 07 Apr 2016 08:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tPSwjfNaAqtQTXci30sx6e4RoC37k4TBqshwmvy/ww0=; b=dXfjhAHEPuNMQdk36w9+pcLa8HA4eb3LHF6gE2cUoVO+8KUEjydKG/GLM3Brt6naWl fJqYDn2xSR31bOixv90oM7xTMsZLGBS0SmfYDPr6CYZbJZ/qiE+wZ/rfnnFfjunpu7pe OPNe7yaa8x9lxxfs+7VWQMm9/ut4dzPmxW27BD4LHHwfdH41A9v73XTfr0OCZsbdcuWt KcnuRlI4EDcr56aLqjw1C/JzD+P9ACydJAZHRhRm06QsJXvXZDeOWR781OLbK+DkHS1H LBQadymUejEc9P0hU+bCcNZRy9xwweRl6v9Bz8e+P5v74268/GEisdBjC5SFiTPtWWuE ojKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tPSwjfNaAqtQTXci30sx6e4RoC37k4TBqshwmvy/ww0=; b=OMQhv3J3T6DJnevxDXvJzqIPO04FDBPE6UAy2O0kbOwyTUa7ps4X0PZ9X4IsCdvJNz ffj/XkOJBD8M9qK/ehk/20E7b8yPpRWDRKmw7tUkG+3Gm4fc8Ne1ohueMQyE2AzLcxZ2 IT4mB6FHFpVpym+NbCB/UbuwKG6KzClBGM/021HRS1hmynELsyqVJWr6uwCzVUcVnCUg mgHmy1R9Bsp3Qa2nBI3YAEdTh0G3GmyaowQUhiawFVSxQwn4Zkk00T1jKnalQ60p+9bU U1Pa6lHVaj4ltCguFNM5JifsTEbRDAjO/z/UAzl67Ejk69fPg6AB3n5uez42Fq4i7RWj Ufeg== X-Gm-Message-State: AD7BkJLnPcHZ4ZERZo5eJIjRyMTqvJjcf2tFBp7+iLjVeGjF1AulrOu6gkl8Whvc2LmLNw== X-Received: by 10.28.148.8 with SMTP id w8mr30865297wmd.29.1460042162374; Thu, 07 Apr 2016 08:16:02 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i11sm8950414wjn.36.2016.04.07.08.16.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 08:16:01 -0700 (PDT) To: Alvaro Retana , The IESG References: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <570679AF.2030101@gmail.com> Date: Thu, 7 Apr 2016 16:15:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:26:22 -0000 On 05/01/2016 03:10, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The text related to when the URO is used of not clear, and I think it > could even result in technical incompatibility. I don't think that this > main concern raises to the level of a DISCUSS since it should be resolved > easily (but it might be close). In short, it is not completely clear > when the URO should be considered in light of the rules in RFC6374; it is > not completely clear if the rules in RFC6374 always take precedence. This text only considers operation when the URO is used. There are no procedures specified on how to use the address object in RFC6374, and if anyone every writes them (which I honestly doubt) they will be responsible for the disambiguation of the proceedures. > Here are the specifics of my concern: > > Section 4.2. (Receiving an MPLS PM Query Request) says that "in addition" > to the processing in RFC6374, "with a URO present, then the responder > SHOULD use that IP address and UDP port to send MPLS-PLDM response back > to querier." RFC6374 says that the "Source Address of a query message > SHOULD be used as the destination for an out-of-band response unless some > other out-of-band response mechanism has been configured, and unless a > Return Address object is present, in which case the Return Address > specifies the target of the response." Several questions/observations: > > * What does the phrase "in addition" mean in 4.2? I'm interpreting it as > adding rules to what RFC6374 says. IOW, this document seems to be > updating what RFC6374 says (or at least adding extra rules if the URO is > present). Is that the intent? It is not updating it in the formal IETF sense, it is adding an extra mechanism, but in that latter sense it is updating the protocol. > > * As far as I can tell, there is no restriction for having both a Return > Address object and the URO in the same query, right? If so, and if the > intent is *not* to update RFC6374, then it seems (from the text in > RFC6374) that the URO would never be used (if a Return Address object is > also present). I have added the following text which should resolve any ambiguity: To prevent any ambiguity as to which address the Responder needs to reply to, an MPLS-PLDM message containing a URO MUST NOT include an RFC6374 Return Address TLV (TLV 1). Additionally, the method of constructing the return address from the Source Address TLV (TLV 130) described in Section 3.5.2 of RFC6374 MUST NOT be used to construct to an Query message that contains a URO. > > * Nitpicking a little at the meaning/interpretation of "configuration". > RFC6374 mentions (from above) "some other out-of-band response mechanism > has been configured", but as you imply in (i.e as I interpret) Section 5. > (Manageability Considerations) the mechanism in this document is > signaling, not configuration: "Nothing in this document precludes the > use of a configured UDP/IP return path in a deployment in which > configuration is preferred to signalling." Yes, you could configure the > system to prefer the URO signaling.. Indeed, but I cannot see any interoperability issues. > > * The point with all this is that it is not clear what exactly is meant, > and that the current text can result in more than one (defensible) > interpretation. Hopefully the additional text resolves the ambiguity. > > * Small nit from the text quoted above in section 4.2: the response may > in fact not go back to the querier. > I cannot see the problem with the text, but of course the response may not go back to the querier. That is a design intention. > > I have a couple of other minor comments: > > 1. Section 3. (Solution Overview) says (in the first sentence) that if > the URO "is present in a MPLS-PLDM Query, the responder MUST use the IP > address and UDP port in the URO to reply back to the querier". Clearly > related to the comments above, but also an incomplete statement: as > explained in 4 and 4.1, the Control Code should also be set to > "Out-of-band Response Requested". Comments/questions: > * [Nit] I don't think there's anything explicitly wrong with that > first sentence, but it just doesn't sound right because of the > conditional MUST ("unless configured otherwise"). You might want to > consider something like this instead: "This document specifies that if > the Control Code of the MPLS-PLDM query is set to "Out-of-band Response > Requested", and a UDP Return Object (URO) is present in a MPLS-PLDM > Query, the responder SHOULD use the IP address and UDP port in the URO to > reply back to the querier." It now says SHOULD > * What happens the URO is received in a query that doesn't have the > correct Control Code? It follows the error handling in RFC6374, and responds using the URO. Do you think that this is ambiguous? > > 2. Section 3.1. (UDP Return Object) > * What happens if the URO contains an address not supported by the > receiver? This would be a normal misdelivery-discard. There is now some additional security text about being more careful with the address you use, but if you configure a wrong address the packet will go in the bit bucket as normal. > * "The URO MUST NOT appear in a response." What should the receiver > do if it does? Should it ignore the URO or the whole datagram? I think that this a matter for the implementer. There is no interoperability issue that I can see. > > 3. s/MPLS-PM (and MPLS PM)/MPLS-PLDM > > Done - Stewart From nobody Thu Apr 7 08:34:21 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54FF12D0A6; Thu, 7 Apr 2016 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 Lx73q-nxrLgo; Thu, 7 Apr 2016 08:34:19 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A042C12D0CE; Thu, 7 Apr 2016 08:29:53 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id a140so22308607wma.2; Thu, 07 Apr 2016 08:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=tPSwjfNaAqtQTXci30sx6e4RoC37k4TBqshwmvy/ww0=; b=dXfjhAHEPuNMQdk36w9+pcLa8HA4eb3LHF6gE2cUoVO+8KUEjydKG/GLM3Brt6naWl fJqYDn2xSR31bOixv90oM7xTMsZLGBS0SmfYDPr6CYZbJZ/qiE+wZ/rfnnFfjunpu7pe OPNe7yaa8x9lxxfs+7VWQMm9/ut4dzPmxW27BD4LHHwfdH41A9v73XTfr0OCZsbdcuWt KcnuRlI4EDcr56aLqjw1C/JzD+P9ACydJAZHRhRm06QsJXvXZDeOWR781OLbK+DkHS1H LBQadymUejEc9P0hU+bCcNZRy9xwweRl6v9Bz8e+P5v74268/GEisdBjC5SFiTPtWWuE ojKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=tPSwjfNaAqtQTXci30sx6e4RoC37k4TBqshwmvy/ww0=; b=TDdnBmyIKMHmX7NA6PKzCmHYPcRSLvozuhU57BMVB7zuCR0cRdMbLUrIZ/ao9pSRBt gyP7gYslbBcvCG/gffZp+AHG000MzlDjwzmYbJYivFEw+xASvpWd1LSLPdk0SLe/CY7d Brmlkrv45vRdrTsjiP7GKQ35iCI7Ohfepm7JdvPmmepJSbltyno2+VhN/YVyD3QeFdyx jqHhUg3COLk5cOdB8UykkAzzOb7uNaKKmrJQ8QO+RgLSpcWoJVz7Q61/mtBXuhWOwzeL c8JnoqUKHZPBinMsftgLX042UjsPNRHz7TjG6LgyHeGiN3vGQ7mPgBmcrBUveKNav5Ae yPtw== X-Gm-Message-State: AD7BkJJCXb6b2U0fho9+be3HnkRjSFtuIVsgCgFNj7CzbUee79xJy0emqQFWXFgmf+f71g== X-Received: by 10.28.148.8 with SMTP id w8mr30865297wmd.29.1460042162374; Thu, 07 Apr 2016 08:16:02 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id i11sm8950414wjn.36.2016.04.07.08.16.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 08:16:01 -0700 (PDT) To: Alvaro Retana , The IESG References: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> From: Stewart Bryant Message-ID: <570679AF.2030101@gmail.com> Date: Thu, 7 Apr 2016 16:15:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:34:20 -0000 On 05/01/2016 03:10, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The text related to when the URO is used of not clear, and I think it > could even result in technical incompatibility. I don't think that this > main concern raises to the level of a DISCUSS since it should be resolved > easily (but it might be close). In short, it is not completely clear > when the URO should be considered in light of the rules in RFC6374; it is > not completely clear if the rules in RFC6374 always take precedence. This text only considers operation when the URO is used. There are no procedures specified on how to use the address object in RFC6374, and if anyone every writes them (which I honestly doubt) they will be responsible for the disambiguation of the proceedures. > Here are the specifics of my concern: > > Section 4.2. (Receiving an MPLS PM Query Request) says that "in addition" > to the processing in RFC6374, "with a URO present, then the responder > SHOULD use that IP address and UDP port to send MPLS-PLDM response back > to querier." RFC6374 says that the "Source Address of a query message > SHOULD be used as the destination for an out-of-band response unless some > other out-of-band response mechanism has been configured, and unless a > Return Address object is present, in which case the Return Address > specifies the target of the response." Several questions/observations: > > * What does the phrase "in addition" mean in 4.2? I'm interpreting it as > adding rules to what RFC6374 says. IOW, this document seems to be > updating what RFC6374 says (or at least adding extra rules if the URO is > present). Is that the intent? It is not updating it in the formal IETF sense, it is adding an extra mechanism, but in that latter sense it is updating the protocol. > > * As far as I can tell, there is no restriction for having both a Return > Address object and the URO in the same query, right? If so, and if the > intent is *not* to update RFC6374, then it seems (from the text in > RFC6374) that the URO would never be used (if a Return Address object is > also present). I have added the following text which should resolve any ambiguity: To prevent any ambiguity as to which address the Responder needs to reply to, an MPLS-PLDM message containing a URO MUST NOT include an RFC6374 Return Address TLV (TLV 1). Additionally, the method of constructing the return address from the Source Address TLV (TLV 130) described in Section 3.5.2 of RFC6374 MUST NOT be used to construct to an Query message that contains a URO. > > * Nitpicking a little at the meaning/interpretation of "configuration". > RFC6374 mentions (from above) "some other out-of-band response mechanism > has been configured", but as you imply in (i.e as I interpret) Section 5. > (Manageability Considerations) the mechanism in this document is > signaling, not configuration: "Nothing in this document precludes the > use of a configured UDP/IP return path in a deployment in which > configuration is preferred to signalling." Yes, you could configure the > system to prefer the URO signaling.. Indeed, but I cannot see any interoperability issues. > > * The point with all this is that it is not clear what exactly is meant, > and that the current text can result in more than one (defensible) > interpretation. Hopefully the additional text resolves the ambiguity. > > * Small nit from the text quoted above in section 4.2: the response may > in fact not go back to the querier. > I cannot see the problem with the text, but of course the response may not go back to the querier. That is a design intention. > > I have a couple of other minor comments: > > 1. Section 3. (Solution Overview) says (in the first sentence) that if > the URO "is present in a MPLS-PLDM Query, the responder MUST use the IP > address and UDP port in the URO to reply back to the querier". Clearly > related to the comments above, but also an incomplete statement: as > explained in 4 and 4.1, the Control Code should also be set to > "Out-of-band Response Requested". Comments/questions: > * [Nit] I don't think there's anything explicitly wrong with that > first sentence, but it just doesn't sound right because of the > conditional MUST ("unless configured otherwise"). You might want to > consider something like this instead: "This document specifies that if > the Control Code of the MPLS-PLDM query is set to "Out-of-band Response > Requested", and a UDP Return Object (URO) is present in a MPLS-PLDM > Query, the responder SHOULD use the IP address and UDP port in the URO to > reply back to the querier." It now says SHOULD > * What happens the URO is received in a query that doesn't have the > correct Control Code? It follows the error handling in RFC6374, and responds using the URO. Do you think that this is ambiguous? > > 2. Section 3.1. (UDP Return Object) > * What happens if the URO contains an address not supported by the > receiver? This would be a normal misdelivery-discard. There is now some additional security text about being more careful with the address you use, but if you configure a wrong address the packet will go in the bit bucket as normal. > * "The URO MUST NOT appear in a response." What should the receiver > do if it does? Should it ignore the URO or the whole datagram? I think that this a matter for the implementer. There is no interoperability issue that I can see. > > 3. s/MPLS-PM (and MPLS PM)/MPLS-PLDM > > Done - Stewart From nobody Thu Apr 7 10:31:06 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2A12D1A3; Thu, 7 Apr 2016 10:31:05 -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: <20160407173105.19716.48445.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 10:31:05 -0700 Archived-At: Subject: [mpls] The MPLS WG has placed draft-ijln-mpls-rfc5036bis in state "Candidate for WG Adoption" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:31:05 -0000 The MPLS WG has placed draft-ijln-mpls-rfc5036bis in state Candidate for WG Adoption (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-ijln-mpls-rfc5036bis/ From nobody Thu Apr 7 10:33:44 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A10812D54B; Thu, 7 Apr 2016 10:33: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: <20160407173343.19696.39201.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 10:33:43 -0700 Archived-At: Subject: [mpls] The MPLS WG has placed draft-rosen-mpls-rfc3107bis in state "Candidate for WG Adoption" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:33:43 -0000 The MPLS WG has placed draft-rosen-mpls-rfc3107bis in state Candidate for WG Adoption (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-rosen-mpls-rfc3107bis/ From nobody Thu Apr 7 10:35:51 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42B12D59F; Thu, 7 Apr 2016 10:35:49 -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: <20160407173549.19741.92515.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 10:35:49 -0700 Archived-At: Subject: [mpls] The MPLS WG has placed draft-saad-mpls-static-yang in state "Candidate for WG Adoption" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:35:50 -0000 The MPLS WG has placed draft-saad-mpls-static-yang in state Candidate for WG Adoption (entered by Loa Andersson) The document is available at https://datatracker.ietf.org/doc/draft-saad-mpls-static-yang/ From nobody Thu Apr 7 10:40:17 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF23B12D5D0; Thu, 7 Apr 2016 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 IznpSBdWNGjQ; Thu, 7 Apr 2016 10:40:01 -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 2BD3412D5A1; Thu, 7 Apr 2016 10:39:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGZ94521; Thu, 07 Apr 2016 17:39:56 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 18:39:55 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 01:39:49 +0800 From: Xuxiaohu To: Tony Przygienda , "bier@ietf.org" Thread-Topic: The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqA== Date: Thu, 7 Apr 2016 17:39:49 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.198.246] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57069B6D.013A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76c0900cb14475b246c81dcc3d30b04a Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:40:05 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QXMgZm9yIHRoZSBmaXJzdCBuaWJibGUgaXNzdWUsIHdpbGwgaXQgdmlvbGF0ZSB0aGUgbGF5ZXJp bmcgcHJpbmNpcGxlIG9mIG5ldHdvcmsgcHJvdG9jb2wgc3RhY2tzIGlmIHRoZSBmaXJzdCBuaWJi bGUgb2YgYW55IG5ldyBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggY291bGQgYmUgYW4gTVBM UyBwYXlsb2FkKSBpcyB1c2VkIGFzIHRoZSAiTVBMUyBwYXlsb2FkIHR5cGUiIGZpZWxkPyB3b3Vs ZG4ndCBpdCAgYmUgbW9yZSByZWFzb25hYmxlIGFuZCBzdXN0YWluYWJsZSB0byBmaXggdGhlIHBy b2JsZW0gKGkuZS4sIHRoZSBsYWNrIG9mIGEgcHJvdG9jb2wgZmllbGQgaW4gdGhlIE1QTFMgaGVh ZGVyKSBieSB0aGUgTVBMUyBoZWFkZXIgaXRzZWxmPw0KDQoNCg0KQnkgdGhlIHdheSwgc2luY2Ug aXQncyBjbGFpbWVkIHRoYXQgdGhlIE5TSCBpcyB0cmFuc3BvcnQtaW5kZXBlbmRhbnQsIGl0IG1l YW5zIHRoZSBOU0ggc2hvdWxkIGJlIGFibGUgdG8gYmUgdHJhbnNwb3J0ZWQgb3ZlciBNUExTLiBI b3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZSBmaXJzdCBuaWJibGUgaXNzdWUgaGFzIG5vdCBiZSBj b25zaWRlcmVkIGluIHRoZSBjdXJyZW50IE5TSCBkcmFmdC4gQXMgYSByZXN1bHQsIHdoZW4gZW5j YXBzdWxhdGluZyBOU0ggb3ZlciBNUExTLCB0aGUgTlNIIG1heSBiZSBtaXMtaW50ZXJwcmV0ZWQg YXMgSVAgaGVhZGVyLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQpYaWFvaHUNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEJJRVIgW2JpZXItYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBUb255IFByenlnaWVuZGEgW3RvbnlzaWV0ZkBnbWFpbC5jb21dDQq3osvN yrG85DogMjAxNsTqNNTCNcjVIDIyOjM2DQrK1bz+yMs6IGJpZXJAaWV0Zi5vcmcNCtb3zOI6IFtC aWVyXSBjb21tZW50cyBvbiBkcmFmdC13YW5nLWJpZXItZXRoZXJuZXQtMDENCg0KYWZ0ZXIgcmVh ZGluZw0KDQphKSBmaXJzdCBuaWJibGU6IHJlZmVyIHRvIE1QTFMgZW5jYXBzIGFzICJ0aGUgc2Ft ZSB2YWx1ZSIgdG8ga2VlcCBpbiBzeW5jDQpiKSByZWZlciB0byBhbGwgb3RoZXIgcG9zc2libGUg ZmllbGRzIHRvIE1QTFMgZW5jYXBzIHRvIGtlZXAgaW4gc3luYyB3aGVuIGRlc2NyaWJpbmcgaW5z dGVhZCBvZiByZXBlYXRpbmcNCmMpIHlvdSBuZWVkIHRvIGRlc2NyaWJlIHdoaWNoIGtpbmQgb2Yg ZXRoZXIgTUFDcyBhcmUgYWxsb3dlZCwgZXNwZWNpYWxseSBvbiBicm9hZGNhc3QgbWVkaWEsIGku ZS4gaXMgaXQgYWx3YXlzIHAycCBvciBjYW4geW91IHRha2UgYWR2YW50YWdlIG9mIHRoZSBicm9h ZGNhc3QgPw0KZCkgRmlndXJlIDQ6IHVzZSB0aGUgYXJjaGl0ZWN0dXJlL01QTFMgZW5jb2Rpbmcg Zm9yIHRoZSBsZW5ndGgsIGRvbid0IGludmVudCBhIG5ldyBvbmUNCmUpIHdobyB3aWxsIG9idGFp biBhIG5ldyBldGhlciB0eXBlIGZyb20gSUVFRT8gQXMgZmFyIEkgdW5kZXJzdGFuZCwgbm90IGEg dHJpdmlhbCBwcm9jZXNzIGFsYmVpdCB3ZSBoYXZlIHNldmVyYWwgbGlhaXNvbnMgd2l0aCBJRUVF DQoNCi0tDQpXZaGvdmUgaGVhcmQgdGhhdCBhIG1pbGxpb24gbW9ua2V5cyBhdCBhIG1pbGxpb24g a2V5Ym9hcmRzIGNvdWxkIHByb2R1Y2UgdGhlIGNvbXBsZXRlIHdvcmtzIG9mIFNoYWtlc3BlYXJl OyBub3csIHRoYW5rcyB0byB0aGUgSW50ZXJuZXQsIHdlIGtub3cgdGhhdCBpcyBub3QgdHJ1ZS4N CqGqUm9iZXJ0IFdpbGVuc2t5DQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

As for the first nibble issue, will it violate the layering principle of= network protocol stacks if the first nibble of any new encapsulation heade= r (which could be an MPLS payload) is used as the "MPLS payload t= ype" field? wouldn't it  be more reasonable and sustainable to fix the problem (i.e., the lack of a protocol= field in the MPLS header) by the MPLS header itself?

 

By the way, since it's claimed that the NSH is transport-independant, it= means the NSH should be able to be transported over MPLS. However, it seem= s that the first nibble issue has not be considered in the current NSH= draft. As a result, when encapsulating NSH over MPLS, the NSH may be mis-interpreted as IP header.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: BIER [bier-bounces@iet= f.org] =B4=FA=B1=ED Tony Przygienda [tonysietf@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA4=D4=C25=C8=D5 22:36
=CA=D5=BC=FE=C8=CB: bier@ietf.org
=D6=F7=CC=E2: [Bier] comments on draft-wang-bier-ethernet-01

after reading 

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync 
b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating 
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don't = invent a new one 
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE 

--
We=A1= =AFve heard that a million monkeys at a million keyboards could produce the= complete works of Shakespeare; now, thanks to the Internet, we know that i= s not true.
= =A1=AARobert Wilensky
--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871CNKGEML515MBXchi_-- From nobody Thu Apr 7 10:47:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0012D566; Thu, 7 Apr 2016 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 i8VbxXjZ-Ll2; Thu, 7 Apr 2016 10:46:58 -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 6EB0C12D0EF; Thu, 7 Apr 2016 10:46:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGZ94898; Thu, 07 Apr 2016 17:46:54 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 18:46:54 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 01:46:46 +0800 From: Mach Chen To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+Z Date: Thu, 7 Apr 2016 17:46:46 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.126] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57069D0F.0030, 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: 8a58d68ce27ac53c3e71cd40464a12f0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd-chairs@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 17:47:00 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is correct, = the idea is to use multicast destination address other than unicast address= when  sending BFD packets over LAG links. And actually this idea= has been proposed in https:/= /tools.ietf.org/html/draft-chen-bfd-interface-00 (the predecessor = of RFC 7130). And at that time, the co-authors of RFC 7130 did discuss=  the idea of using multicast destination address, but for some reason I forget now(I may need to reiterate the discussions o= n the archive), the idea was abandoned, although I still think multicast de= stination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

=B7=          BFD on MC-LAG interfaces in IP netw= ork

=B7=          BFD on MC-LAG interfaces in IP/MP= LS network

 

Greatly appreciate your reviews, comments, questions= and suggestions.

 

Regards,

   &nbs= p;    Greg

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F040FSZXEMA510MBXchi_-- From nobody Thu Apr 7 11:01:40 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D70D212D525; Thu, 7 Apr 2016 11:01:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160407180136.10054.85473.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 11:01:36 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-spring-entropy-label-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:01:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Entropy labels for source routed tunnels with label stacks Authors : Sriganesh Kini Kireeti Kompella Siva Sivabalan Stephane Litkowski Rob Shakir Jeff Tantsura Filename : draft-ietf-mpls-spring-entropy-label-03.txt Pages : 11 Date : 2016-04-07 Abstract: Source routed tunnels with label stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. This can be applied to the Multi Protocol Label Switching (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to improve load balancing. This document examines and describes how ELs are to be applied to source routed tunnels with label stacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-spring-entropy-label-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 Thu Apr 7 11:07:48 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AC612D65C; Thu, 7 Apr 2016 11:07:44 -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: <20160407180744.10073.12621.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 11:07:44 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc6374-udp-return-path-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:07:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : RFC6374 UDP Return Path Authors : Stewart Bryant Siva Sivabalan Sagar Soni Filename : draft-ietf-mpls-rfc6374-udp-return-path-05.txt Pages : 9 Date : 2016-04-07 Abstract: RFC6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management responses over an IP/UDP return path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc6374-udp-return-path-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc6374-udp-return-path-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 11:43:05 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB70612D195; Thu, 7 Apr 2016 11:43:00 -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: <20160407184300.10081.96406.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 11:43:00 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ijln-mpls-rfc5036bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 18:43:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : LDP Specification Authors : Xia Chen Loa Andersson Nic Leymann Ina Minei Kamran Raza Filename : draft-ijln-mpls-rfc5036bis-02.txt Pages : 141 Date : 2016-04-07 Abstract: The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ijln-mpls-rfc5036bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ijln-mpls-rfc5036bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ijln-mpls-rfc5036bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 12:05:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D212D1B8; Thu, 7 Apr 2016 12:05:08 -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 fVBZa1b6S_Ol; Thu, 7 Apr 2016 12:05:05 -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 AEC0312D542; Thu, 7 Apr 2016 12:05:05 -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 5985318013CB; Thu, 7 Apr 2016 21:05:03 +0200 (CEST) To: "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" From: Loa Andersson Message-ID: <5706AF5A.5070108@pi.nu> Date: Fri, 8 Apr 2016 03:04:58 +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: Subject: [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:05:08 -0000 Working Group, The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready to be considered for working adoption. The document been through MPLS-RT review. We will do an IPR poll prior to the start of the adoption poll. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR disclosure filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 7 15:39:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEF712D169; Thu, 7 Apr 2016 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, SPF_PASS=-0.001, 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 Cm-rP-DqUkkv; Thu, 7 Apr 2016 15:39:49 -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 7A80F12D118; Thu, 7 Apr 2016 15:39:48 -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 CHA09445; Thu, 07 Apr 2016 22:39:46 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 23:39:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 06:39:41 +0800 From: Xuxiaohu To: Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT4= Date: Thu, 7 Apr 2016 22:39:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> In-Reply-To: <57057618.8020604@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.222] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5706E1B3.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0e4d05dc9241ebb9e9634874a34d1850 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:39:50 -0000 SGkgRXJpYywNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8 /sjLOiBFcmljIEMgUm9zZW4gW2Vyb3NlbkBqdW5pcGVyLm5ldF0NCreiy83KsbzkOiAyMDE2xOo0 1MI3yNUgNDo0OA0KytW8/sjLOiBYdXhpYW9odTsgc3ByaW5nQGlldGYub3JnDQqzrcvNOiBtcGxz QGlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRp b24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCk9u IDQvNi8yMDE2IDExOjM3IEFNLCBYdXhpYW9odSB3cm90ZToNCj4gVGhlIHNpdHVhdGlvbiBpbiBN UExTLVNSIGlzIGEgbGl0dGxlIGJpdCBjb21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBm b3IgYSBnaXZlbiAvMzIgb3IgLzEyOCBwcmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIg ZnJvbSB0aGUgSUdQIG5leHQtaG9wIG9mIHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9yIG9mIHRo YXQgRkVDIGR1ZSB0byB0aGUgSUdQIGZsb29kaW5nIHByb3BlcnR5LiBJbiB0aGUgZm9ybWVyIGNh c2UsIHRoZSBJR1AgbmV4dC1ob3AgZm9yIGEgZ2l2ZW4gRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0 LWhvcCBvZiB0aGUgcmVjZWl2ZWQgTVBMUyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDOyBp biB0aGUgbGF0dGVyIGNhc2UsIHRoZSBvcmlnaW5hdG9yIG9mIHRoYXQgRkVDIGlzIHRha2VuIGFz IHRoZSBuZXh0LWhvcCBvZiB0aGUgTVBMUyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDIC4u LiB0aGUgbGF0dGVyIGNhc2UgYmVsb25ncyB0byB0aGUgInJlbW90ZSBsYWJlbCBkaXN0cmlidXRp b24gcGVlciIgY2FzZSBhcyBkZWZpbmVkIGluIFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRo aXMgaXMgY29ycmVjdC4gIEluIFNSLCB0aGUgZmFjdCB0aGF0IGxhYmVsIEwgd2FzDQphZHZlcnRp c2VkIGJ5IG5vZGUgTiBkb2VzIG5vdCBpbXBseSB0aGF0IGEgcGFja2V0IHdpdGggTCBhdCB0aGUg dG9wIG9mDQp0aGUgc3RhY2sgbmVlZHMgdG8gYmUgdHVubmVsZWQgdG8gTi4gIEluIHRoZSB0eXBp Y2FsIGNhc2UsIHRoZSBwYWNrZXQNCg0KW1hpYW9odV0gVGhlIEZFQyBhc3NvY2lhdGVkIHRoZSBh Ym92ZSBsYWJlbCBMIGlzIHRoZSAvMzIgb3IgMTI4LyBwcmVmaXggb2Ygbm9kZSBOLiBXaGVuIHRo ZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0aGF0IEZFQyBpcyBhIG5vbi1NUExTIG5vZGUsIHRoZSBM U1IgcmVjZWl2aW5nIHRoZSBhYm92ZSBNUExTIHBhY2tldCB3aXRoIHRvcCBsYWJlbCBvZiBMIGlz IGRlc2lyZWQgdG8gZm9yd2FyZCB0aGF0IE1QTFMgcGFja2V0IHRvd2FyZHMgbm9kZSBOIHZpYSBh biBJUC1iYXNlZCB0dW5uZWwuIEluIHRoaXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0aGUgcmVtb3Rl IHBlZXIgZm9yIHRoYXQgRkVDLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQp3b3VsZCBq dXN0IGZvbGxvdyB0aGUgSUdQIGJlc3QgcGF0aCwgYW5kIGFsbCB0aGUgaW50ZXJtZWRpYXRlIG5v ZGVzDQp3b3VsZCBiZSBleHBlY3RlZCB0byByZWNvZ25pemUgdGhlIGxhYmVsIGF0IHRoZSB0b3Ag b2YgdGhlIHN0YWNrLiAgSWYNCnRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgYXJlIGV4cGVjdGVkIHRv IHJlY29nbml6ZSB0aGUgbGFiZWwsICB0aGlzIGlzIG5vdA0KdGhlICJyZW1vdGUgbGFiZWwgZGlz dHJpYnV0aW9uIHBlZXIgY2FzZSIuDQoNCllvdSBzZWVtIHRvIGJlIHBvc2l0aW5nIGEgY2FzZSB3 aGVyZSB0d28gbm9kZXMgYXJlIGluIHRoZSBzYW1lIElHUA0KZG9tYWluLCBhbmQgc2FtZSBTUFJJ TkcgZG9tYWluLCBidXQgdGhlcmUgaXMgbm8gTFNQIHRoYXQgY2FuIGJlIHVzZWQgdG8NCnRyYW5z cG9ydCBwYWNrZXRzIGZyb20gb25lIHRvIHRoZSBvdGhlci4gICBJdCB3b3VsZCBiZSBzb21ld2hh dCB1bnVzdWFsDQp0byBoYXZlIGFuIElHUCBkb21haW4gaW4gd2hpY2ggc29tZSBub2RlcyBzdXBw b3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQpJbiBCSUVSLCB3ZSBkbyBhY2NvbW1vZGF0ZSB0aGlz IHNvcnQgb2Ygc2l0dWF0aW9uLCB3aGVyZSBzb21lIG9mIHRoZQ0Kbm9kZXMgaW4gdGhlIEJJRVIg ZG9tYWluIGRvIG5vdCBzdXBwb3J0IEJJRVIuICBCdXQgSSBkb24ndCBrbm93IHdoZXRoZXINCnRo YXQgc29ydCBvZiBzY2VuYXJpbyBuZWVkcyB0byBiZSBzdXBwb3J0ZWQgZm9yIE1QTFMtU1IuICBE byB5b3UgaGF2ZSBhDQpwYXJ0aWN1bGFyIHVzZSBjYXNlIGluIG1pbmQ/ From nobody Thu Apr 7 18:28:05 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1512D1CF; Thu, 7 Apr 2016 18:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 Rh_BvNwswAxz; Thu, 7 Apr 2016 18:28:03 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A7812D126; Thu, 7 Apr 2016 18:28:02 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-92-570702dbe1cd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id E8.5A.30335.BD207075; Fri, 8 Apr 2016 03:01:15 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 21:28:01 -0400 From: Uma Chunduri To: Xuxiaohu , Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ9/Rn2w Date: Fri, 8 Apr 2016 01:28:00 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRPc2E3u4wcazBhbrNnxgtri1dCWr xfELvxkttp5fxejA4tFy5C2rx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DK6H90iLXglHLF nT8bGRsYryh1MXJySAiYSCy93skKYYtJXLi3nq2LkYtDSOAoo8SdjxOZIJxljBLvZs9lBKli E9CT+Dj1JzuILSKQIzHx0TKgDg4OZgFliVN3ZUDCwgJpEnNmHGOBKEmXuH3/I1iJiICRxJ+N +SBhFgEViRnz74NN5BXwlbi0fT7U3iOMEl9/tYAlOAXCJHpfnmUGsRmBjvt+ag0TiM0sIC5x 68l8JoijBSSW7DnPDGGLSrx8/A/qGSWJOa+vMUPUa0nMa/gN1asoMaX7ITvEYkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSNHaXFBTm66kcEmRmAMHZNg093BeH+65yFGAQ5GJR7eB22s 4UKsiWXFlbmHGCU4mJVEeN+ysIcL8aYkVlalFuXHF5XmpBYfYpTmYFES520M/hcmJJCeWJKa nZpakFoEk2Xi4JRqYLSWy+RarBZ/4/jEVfe5Sj/unp0owrZLJZ0zT3Xu5bBfpd3y++o9l3/w PSYc6Rl82lg73GmDzeU5XqKO73j89cVXsbyabuhyxUnMa+mniwem1JgG3v6m/eijjXKEd8w1 mVJHxtc/l2VsTChg3y6+p0T4s8PBoPVGmnXOQbIPd2+YUP67K3qDpBJLcUaioRZzUXEiAMGm Jc2dAgAA Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:28:05 -0000 PiBJdCB3b3VsZCBiZSBzb21ld2hhdCB1bnVzdWFsDQo+IHRvIGhhdmUgYW4gSUdQIGRvbWFpbiBp biB3aGljaCBzb21lIG5vZGVzIHN1cHBvcnQgTVBMUyBhbmQgc29tZSBkb24ndC4NCg0KTWF5IGJl IHRydWUgd2l0aCBub24tU1IgYW5kIHRyYWRpdGlvbmFsICBNUExTLiANCkJ1dCB3aXRoIFNSIEkg YW0gd29ya2luZyB3aXRoIG9uZSBjdXN0b21lciB3aGVyZSBNUExTIChhcyBTUiBkYXRhIHBsYW5l KSBpcyBicm91Z2h0IGludG8gdGhlaXIgcHVyZSBJR1AtSVAgZG9tYWluLg0KV2l0aCBzdGF0aWMg UFcgbGFiZWxzIChpbm5lciBsYWJlbCkgIGN1cnJlbnRseSBwdXJlIHNvZnQgR1JFIGVuY2FwIGlz IGJlaW5nIHVzZWQgKGZvciB0cmFuc3BvcnQpICBidXQgU1IgaXMgYmVpbmcgcGxhbm5lZCBmcm9t IEVQRyB0byBjZWxsIHNpdGUgcm91dGVycyBldmVudHVhbGx5LiANClBsYW5uaW5nIHNsb3cgdXBn cmFkZSBmb3Igc29tZSBvZiB0aGUgTUJIIG5vZGVzIHdpdGggU1ItTVBMUyBkYXRhIHBsYW5lLiAg SW4gdGhpcyBjYXNlIGl0cyBxdWl0ZSBwb3NzaWJsZSB0byB1c2UgKGluIGZ1dHVyZSkgbm9uLXNo b3J0ZXN0IHBhdGggU1IgbGFiZWwgc3RhY2suDQpUaHghDQotLQ0KVW1hIEMuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAx NiAzOjQwIFBNDQpUbzogRXJpYyBDIFJvc2VuOyBzcHJpbmdAaWV0Zi5vcmcNCkNjOiBtcGxzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRp b24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCkhp IEVyaWMsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogRXJpYyBDIFJvc2VuIFtlcm9zZW5AanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNsTqNNTC N8jVIDQ6NDgNCsrVvP7IyzogWHV4aWFvaHU7IHNwcmluZ0BpZXRmLm9yZw0Ks63LzTogbXBsc0Bp ZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSBDbGFyaWZpY2F0aW9uIG9uIHRoZSBtb3RpdmF0aW9u IG9mIGRyYWZ0LXh1LXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcC0wNQ0KDQpPbiA0 LzYvMjAxNiAxMTozNyBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+IFRoZSBzaXR1YXRpb24gaW4gTVBM Uy1TUiBpcyBhIGxpdHRsZSBiaXQgY29tcGxleCBzaW5jZSB0aGUgb3V0Z29pbmcgDQo+IGxhYmVs IGZvciBhIGdpdmVuIC8zMiBvciAvMTI4IHByZWZpeCBGRUMgY291bGQgYmUgbGVhcm50IGVpdGhl ciBmcm9tIA0KPiB0aGUgSUdQIG5leHQtaG9wIG9mIHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9y IG9mIHRoYXQgRkVDIGR1ZSB0byB0aGUgDQo+IElHUCBmbG9vZGluZyBwcm9wZXJ0eS4gSW4gdGhl IGZvcm1lciBjYXNlLCB0aGUgSUdQIG5leHQtaG9wIGZvciBhIA0KPiBnaXZlbiBGRUMgaXMgdGFr ZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSByZWNlaXZlZCBNUExTIHBhY2tldCANCj4gYmVsb25n aW5nIHRvIHRoYXQgRkVDOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBvcmlnaW5hdG9yIG9mIHRo YXQgRkVDIA0KPiBpcyB0YWtlbiBhcyB0aGUgbmV4dC1ob3Agb2YgdGhlIE1QTFMgcGFja2V0IGJl bG9uZ2luZyB0byB0aGF0IEZFQyAuLi4gDQo+IHRoZSBsYXR0ZXIgY2FzZSBiZWxvbmdzIHRvIHRo ZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIiBjYXNlIA0KPiBhcyBkZWZpbmVkIGlu IFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgY29ycmVjdC4gIEluIFNSLCB0aGUg ZmFjdCB0aGF0IGxhYmVsIEwgd2FzIGFkdmVydGlzZWQgYnkgbm9kZSBOIGRvZXMgbm90IGltcGx5 IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrIG5lZWRzIHRvIGJl IHR1bm5lbGVkIHRvIE4uICBJbiB0aGUgdHlwaWNhbCBjYXNlLCB0aGUgcGFja2V0DQoNCltYaWFv aHVdIFRoZSBGRUMgYXNzb2NpYXRlZCB0aGUgYWJvdmUgbGFiZWwgTCBpcyB0aGUgLzMyIG9yIDEy OC8gcHJlZml4IG9mIG5vZGUgTi4gV2hlbiB0aGUgSUdQIG5leHQtaG9wIHRvd2FyZHMgdGhhdCBG RUMgaXMgYSBub24tTVBMUyBub2RlLCB0aGUgTFNSIHJlY2VpdmluZyB0aGUgYWJvdmUgTVBMUyBw YWNrZXQgd2l0aCB0b3AgbGFiZWwgb2YgTCBpcyBkZXNpcmVkIHRvIGZvcndhcmQgdGhhdCBNUExT IHBhY2tldCB0b3dhcmRzIG5vZGUgTiB2aWEgYW4gSVAtYmFzZWQgdHVubmVsLiBJbiB0aGlzIGNh c2UsIHRoZSBub2RlIE4gaXMgdGhlIHJlbW90ZSBwZWVyIGZvciB0aGF0IEZFQy4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCg0Kd291bGQganVzdCBmb2xsb3cgdGhlIElHUCBiZXN0IHBhdGgs IGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBub2RlcyB3b3VsZCBiZSBleHBlY3RlZCB0byByZWNv Z25pemUgdGhlIGxhYmVsIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrLiAgSWYgdGhlIGludGVybWVk aWF0ZSBub2RlcyBhcmUgZXhwZWN0ZWQgdG8gcmVjb2duaXplIHRoZSBsYWJlbCwgIHRoaXMgaXMg bm90IHRoZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIGNhc2UiLg0KDQpZb3Ugc2Vl bSB0byBiZSBwb3NpdGluZyBhIGNhc2Ugd2hlcmUgdHdvIG5vZGVzIGFyZSBpbiB0aGUgc2FtZSBJ R1AgZG9tYWluLCBhbmQgc2FtZSBTUFJJTkcgZG9tYWluLCBidXQgdGhlcmUgaXMgbm8gTFNQIHRo YXQgY2FuIGJlIHVzZWQgdG8NCnRyYW5zcG9ydCBwYWNrZXRzIGZyb20gb25lIHRvIHRoZSBvdGhl ci4gICBJdCB3b3VsZCBiZSBzb21ld2hhdCB1bnVzdWFsDQp0byBoYXZlIGFuIElHUCBkb21haW4g aW4gd2hpY2ggc29tZSBub2RlcyBzdXBwb3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQpJbiBCSUVS LCB3ZSBkbyBhY2NvbW1vZGF0ZSB0aGlzIHNvcnQgb2Ygc2l0dWF0aW9uLCB3aGVyZSBzb21lIG9m IHRoZSBub2RlcyBpbiB0aGUgQklFUiBkb21haW4gZG8gbm90IHN1cHBvcnQgQklFUi4gIEJ1dCBJ IGRvbid0IGtub3cgd2hldGhlciB0aGF0IHNvcnQgb2Ygc2NlbmFyaW8gbmVlZHMgdG8gYmUgc3Vw cG9ydGVkIGZvciBNUExTLVNSLiAgRG8geW91IGhhdmUgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlIGlu IG1pbmQ/DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Thu Apr 7 19:23:19 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FC612D1DA; Thu, 7 Apr 2016 19:23: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: <20160408022315.10081.77696.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 19:23:15 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:23:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-07.txt Pages : 27 Date : 2016-04-07 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 7 19:28:01 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277F612D122; Thu, 7 Apr 2016 19:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7TbevQWPhaH; Thu, 7 Apr 2016 19:27:55 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC11312D50E; Thu, 7 Apr 2016 19:27:54 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-db-570717035afe Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id FC.A0.22441.30717075; Fri, 8 Apr 2016 04:27:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 22:27:53 -0400 From: Gregory Mirsky To: Lou Berger , Loa Andersson , "mpls-chairs@ietf.org" Thread-Topic: [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt Thread-Index: AQHRfv7AabajoYyQ8ESTiHRUKGeJAJ9a/5YwgABc5ID//77vIIABKK6A///XwlCAAEa4AIAADf4QgA3+coD///fdoAAJpv8AAAA/DDAACChiAAKQw23g Date: Fri, 8 Apr 2016 02:27:51 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A3FD70@eusaamb103.ericsson.se> References: <20160315210754.7666.49708.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A0D437@eusaamb103.ericsson.se> <56E88F6B.8010506@labn.net> <7347100B5761DC41A166AC17F22DF11221A0D5AC@eusaamb103.ericsson.se> <56E951B5.2050803@labn.net> <7347100B5761DC41A166AC17F22DF11221A0DE4E@eusaamb103.ericsson.se> <56E96B46.1060706@labn.net> <7347100B5761DC41A166AC17F22DF11221A0E248@eusaamb103.ericsson.se> <56F5342F.2080002@labn.net> <7347100B5761DC41A166AC17F22DF11221A24A46@eusaamb103.ericsson.se> <56F56E22.80801@labn.net> <7347100B5761DC41A166AC17F22DF11221A24CDF@eusaamb103.ericsson.se> <56F5A688.2080807@labn.net> In-Reply-To: <56F5A688.2080807@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/mixed; boundary="_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12Se0hTURzHObuPXc3BaZv5y+w1DaX3u1EWSS9DjCDKiqJGXdSauja1LAp7 aD56aPZwty0XmWnpLBV7irRS00Cz1x8Ls7Rg+cDQSqOS7t1ZIP33Oef3/b2+53CU8jPrz8XG J/LGeJ1ew3rTeUmPomZQfvKo2f0uP23G8V5aO2y1UFr7qyZW67xewmjThu7Ry5nwwsKfsvCv FcfZcOFSOrue2uodupvXxybzxlnLdnrHdB+10Ib2XHTgW6NZnorK92chLw7wfHhYm0MRHgMv 3pezWcibU+I6BDVleXJyKELQmX2RlVQsnguuO6fkEqtxHDjLXjMSUzgU6hrqaIlVeBt0dB31 aLZDs8uKpEJqfAxBq9PuLkTjIHhS2+hurcCRkFP8zp2sxFkM9J5cKrEXDoHv1S4kMRLHG2wq lZFmfuD8VCAjY6vhY+tzlrAvfOkcZghrwNL9liL6WMio6JKTXqOh0fyJzkG+wohSwgiZMEJG 7qeD7WE/S3gaFF3tpggHQOWFTCSIu1E4DUF6czUjuB2rRNDV3uDOUOLbCL7+UpCAVQb1Dwo9 qjwEOWfSZUQlHlqbVwpuj5eAvZhkq/E8MP8YEJkTewRCU1uAhCocBq2ZJqJYDfkl5RThmfCn 6RkS3K8QBFb7ACN4zM50ZtNkszCw2c662QcvhF9dvRRhA7w8cZclbALzhzrqf4dAdKIn97KH l0LG4/cMYQyFj1oowuOhp+CK5548iLQuYJsCnG86PIH50Jb2QG5DM24iLslk0MdFz51TgcQP Xw9s2D1Uc3qtA2EOaXwUNiyPUjK6ZFNKnAMFifN03L71AvnT8QnxvEatkKvEsGK3LuUgb0zY YUzS8yYHGsfRGj9FxJbhTUocrUvk9/K8gTf+i8o4L/9UZHh8uIx+tbhv4pTBU+tG9fUsKm1w 3bqYd+x14p6gYOeogDWdqRsyA8xZVQWTA48cKimvab5hz/i8sUBVVZrilZ8ADZG7FqzunnSm qKVvc8Sy3/UTyhIdb47o29MH9UPhB8NWjGs/+/QahHBWy9jz5+6vGhpjuaDf16nMzq393SIz BYdqaFOMbs5UymjS/QVHde0s+AMAAA== Archived-At: Cc: "mpls@ietf.org" , TEAS WG Subject: Re: [mpls] [Teas] FW: New Version Notification for draft-ietf-mpls-residence-time-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:27:58 -0000 --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, we've uploaded the new version of the draft. Per discussion with Lou have a= dded a flag to RTM_SET TLV. The flag indicates failure by a node to calcula= te distance to the next downstream RTM node. Thus the ingress node may insp= ect the RTM_SET TLVs whether any has the flag set. Appreciate your review, comments. Regards, Greg -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, March 25, 2016 1:59 PM To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org Cc: mpls@ietf.org; TEAS WG Subject: Re: [Teas] FW: New Version Notification for draft-ietf-mpls-reside= nce-time-05.txt Great, thank you. Feel free to unicast me a diff if you'd like. Lou On 3/25/2016 4:51 PM, Gregory Mirsky wrote: > Hi Lou, > I'll work on the update and will post after the meeting. > > Regards, > Greg > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, March 25, 2016 9:58 AM > To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org > Cc: mpls@ietf.org; TEAS WG > Subject: Re: [Teas] FW: New Version Notification for=20 > draft-ietf-mpls-residence-time-05.txt > > Greg, > > On 3/25/2016 12:52 PM, Gregory Mirsky wrote: >> Hi Lou, >> Greatly appreciate you've found time during these extremely busy days be= fore the IETF meeting. >> >> I agree, that there could be different ways a node can handle the RRO li= mitation. I addition to those you've suggested node may change RTM Capabili= ty state advertised in IGP-TE. I think that the choice can be left to a dev= eloper. > I think the RSVP change should be in the draft as it impacts interoperabi= lity and expected behavior. > > Once this change is made I think the draft will be ready to progress. > > Lou > >> I've published the -06 version with all updates noted in my mail before = the cut-off and if you agree with the changes perhaps Loa can start the WGL= C at the most suitable time. >> >> Regards, >> Greg >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, March 25, 2016 5:51 AM >> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >> Cc: mpls@ietf.org; TEAS WG >> Subject: Re: [Teas] FW: New Version Notification for=20 >> draft-ietf-mpls-residence-time-05.txt >> >> Greg, >> Sorry for not responding before the ID cutoff.=20 >> >> I think this is fine, but why not go a step further and have the=20 >> nodes that have the limitation indicate that RTM can't be used, e.g.,=20 >> clear the RTM_SET Attribute Flag and/or remove the RTM_SET TLV to=20 >> notify the ingress of the issue. This would allow the automatic=20 >> detection of the >> (corner) cases were there are actual issues and let RTM operate properly= in the common case. >> >> Lou >> >> On 3/16/2016 3:11 PM, Gregory Mirsky wrote: >>> Hi Lou, >>> following the discussion we propose the following new paragraph before = Section 4.7.1: >>> There are scenarios when some information is removed from an RRO due >>> to policy processing (e.g., as may happen between providers) or RRO >>> is limited due to size constraints . Such changes affect the core >>> assumption of the method to control processing of RTM packets. RTM >>> SHOULD NOT be used if it is not guaranteed that RRO contains complet= e >>> information. >>> >>> Hope that would address your concern with potential blackholed RTM pack= ets. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: Wednesday, March 16, 2016 7:19 AM >>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>> Cc: mpls@ietf.org; TEAS WG >>> Subject: Re: [Teas] FW: New Version Notification for=20 >>> draft-ietf-mpls-residence-time-05.txt >>> >>> Greg, >>> What happens when some information is removed from an RRO due to po= licy processing (e.g., as may happen between providers). Couldn't the TTL = calculation some up too small if the wrong SOs are removed, and wouldn't th= is result in a black hole of actual RTM messages? How do you cover this ca= se? >>> >>> Thanks, >>> Lou >>> >>> On 3/16/2016 10:15 AM, Gregory Mirsky wrote: >>>> Hi Lou, >>>> thank you for the detailed explanation of the case. I agree that there= could be other ways to handle it from what been described in the document.= If a node ID of the first node in the RTM_SET TLV is not found in the RRO = list, then the TTL will be set to 255 and packet will not be processed by i= ntermediate RTM-capable nodes but arrive at LSP egress LSR. Thus not all RT= M capable nodes will be accounted for in the Scratch Pad but still some nod= es may. I'll add some text to highlight this case. >>>> >>>> Regards, >>>> Greg >>>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, March 16, 2016 5:30 AM >>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>>> Cc: mpls@ietf.org; TEAS WG >>>> Subject: Re: [Teas] FW: New Version Notification for=20 >>>> draft-ietf-mpls-residence-time-05.txt >>>> >>>> Greg, >>>> >>>> Thanks for the response. See below. >>>> >>>> On March 15, 2016 6:56:34 PM Gregory Mirsky wrote: >>>> >>>>> Hi Lou, >>>>> >>>>> thank you for the most detailed comments. Please find my notes=20 >>>>> in-line tagged GIM>>. >>>>> >>>>> =20 >>>>> >>>>> Regards, >>>>> >>>>> Greg >>>>> >>>>> =20 >>>>> >>>>> -----Original Message----- >>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>> Sent: Tuesday, March 15, 2016 3:41 PM >>>>> To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org >>>>> Cc: mpls@ietf.org; TEAS WG >>>>> Subject: Re: [Teas] FW: New Version Notification for=20 >>>>> draft-ietf-mpls-residence-time-05.txt >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> Greg, >>>>> >>>>> =20 >>>>> >>>>> On 3/15/2016 5:13 PM, Gregory Mirsky wrote: >>>>> >>>>>> Hi, >>>>>> this version primarily addresses comments related to the proposed >>>>> extensions to RSVP-TE and operation of the control plane in=20 >>>>> support of Residence Time Measurement. Would appreciate the confirmat= ion from Lou. >>>>> >>>>> =20 >>>>> >>>>> I don't think I saw a response to: >>>>> >>>>>> I think this doesn't always work, e.g., when RRO is modified due=20 >>>>>> to policy or limited due to size constraints. This has to be addres= sed. >>>>>> I can see how to easily detect this situation, but not how to get=20 >>>>>> the number of non-supporting hops. I guess it's always possible=20 >>>>>> to play ttl comparison games, but that's pretty ugly too. Any=20 >>>>>> thoughts? >>>>> GIM>> The following text in Section 4.7 intended to handle the >>>>> situation you've described: >>>>> >>>>> If the node cannot find matching ID in RRO, >>>>> >>>>> then it MUST try to use ID of the next node in the RTM_SET=20 >>>>> until it >>>>> >>>>> finds the match or reaches the end of RTM_SET TLV. If match=20 >>>>> have >>>>> >>>>> been found, then the calculated value is used by the node as=20 >>>>> TTL >>>>> >>>>> value in outgoing label to reach the next RTM capable node on=20 >>>>> the >>>>> >>>>> LSP. Otherwise, the TTL value MUST be set to 255. >>>>> >>>>> In essence, the node tries to locate the closest to it downstream=20 >>>>> RTM-capable node. Otherwise, it sets TTL to 255 so that the RTM=20 >>>>> packets arrive at egress LER. >>>>> >>>> So this doesn't cover the case where there are holes in the RRO -- whi= ch I think then translates to RTM black holes. Also not covered is what ha= ppens during Resv processing if there is no room (or a policy) against addi= ng local information. >>>> >>>> Perhaps it would just be better to add a section that explicitly state= s that the defined mechanism only works in cases where full RRO is support= ed (i.e., where RRO is not limited due to size constraints or otherwise imp= acted due to policy)? -- not saying I like this, I just think it fills the = open gaps in the spec - but at the price of limiting applicability. I have= n't spent too much time thinking about this so there may be a better soluti= on out there. >>>> >>>> Lou >>>> >>>>> =20 >>>>> >>>>> Parts of Sections 4.6 and 4.7 are a bit rough and could stand a=20 >>>>> reread and editorial pass. >>>>> >>>>> GIM>> I'm trying. >>>>> >>>>> =20 >>>>> >>>>> Section 4.7 says PathErr messages are sent in response to Resv=20 >>>>> processing error. This is clearly wrong. >>>>> >>>>> GIM>> Great catch! I'm ready to update to ResvErr in -06. >>>>> >>>>> =20 >>>>> >>>>> Lou >>>>> >>>>> =20 >>>>> >>>>>> Authors always welcome comments and questions about RTM. >>>>>> Regards, >>>>>> Greg >>>>>> -----Original Message----- >>>>>> From: internet-drafts@ietf.org >>>>> [mailto:internet-drafts@ietf.org] >>>>> >>>>>> Sent: Tuesday, March 15, 2016 2:08 PM >>>>>> To: Alexander Vainshtein; Gregory Mirsky; Stefano Ruffini; John=20 >>>>>> Drake; Sasha Vainshtein; Eric Gray; Stewart Bryant; Eric Gray >>>>>> Subject: New Version Notification for=20 >>>>>> draft-ietf-mpls-residence-time-05.txt >>>>>> A new version of I-D, draft-ietf-mpls-residence-time-05.txt >>>>>> has been successfully submitted by Greg Mirsky and posted to the >>>>> IETF repository. >>>>> >>>>>> Name: draft-ietf-mpls-residence-time >>>>>> Revision: 05 >>>>>> Title: Residence Time Measurement in MPLS network >>>>>> Document date: 2016-03-15 >>>>>> Group: mpls >>>>>> Pages: 26 >>>>>> URL: =20 >>>>> https://www.ietf.org/internet-drafts/draft-ietf-mpls-residence-tim >>>>> e >>>>> - >>>>> 05 >>>>> .txt >>>>> >>>>>> Status: =20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >>>>> >>>>>> Htmlized: =20 >>>>> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-05 >>>>> >>>>>> Diff: =20 >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-0 >>>>> 5 >>>>> >>>>>> Abstract: >>>>>> This document specifies G-ACh based Residence Time Measurement=20 >>>>>> and >>>>>> how it can be used by time synchronization protocols being >>>>>> transported over MPLS domain. >>>>>> Residence time is the variable part of propagation delay of=20 >>>>>> timing >>>>>> and synchronization messages and knowing what this delay is=20 >>>>>> for each >>>>>> message allows for a more accurate determination of the delay=20 >>>>>> to be >>>>>> taken into account in applying the value included in a PTP event >>>>>> message. >>>>>> = =20 >>>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at=20 >>>>> tools.ietf.org. >>>>> >>>>>> The IETF Secretariat >>>>>> _______________________________________________ >>>>>> Teas mailing list >>>>>> Teas@ietf.org =20 >>>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 08 Apr 2016 02:27:47 GMT"; modification-date="Fri, 08 Apr 2016 02:27:47 GMT" Received: from ESESSHC006.ericsson.se (153.88.183.36) by EUSAAHC003.ericsson.se (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 7 Apr 2016 22:23:45 -0400 Received: from sessmg12.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.37) with Microsoft SMTP Server id 14.3.248.2; Fri, 8 Apr 2016 04:23:43 +0200 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by sessmg12.ericsson.net (Symantec Mail Security) with SMTP id B6.1D.04165.E2617075; Fri, 8 Apr 2016 04:23:43 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5F812D68A; Thu, 7 Apr 2016 19:23:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FC612D1DA; Thu, 7 Apr 2016 19:23:15 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" CC: "mpls@ietf.org" Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-residence-time-07.txt Thread-Index: AQHRkT2tr5n08rKQj0SHKG3eK7PZFA== Sender: mpls Date: Fri, 8 Apr 2016 02:23:15 +0000 Message-ID: <20160408022315.10081.77696.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: ESESSHC006.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA11Uf0wTdxTn27u2x4+Doy3wqIDSZRAciiCyZtkImpmQZQnLsoxlf8wVOGlj KaxXHGyLAWHqgI0qkRQirDhk8ycGkJ8lmx0lE0SBDWHK5ogoDoYRcfywQ3bXK7T4T/O593nv 83nv3esRmGTVW07QeQZar1NpFSIvHN/cG70tJlCcuqOvRqy8XtGMKRfuLouVU5MlSGk9XY8p S7p6Rco7tePiJFHys39HRO+gD71ez6C1moO0PibxYy/1mbnDeE6Zb5710py4ALV6lSBPAqh4 uNBTJ+RxIAz+2SgqQV6EhKoRQMvQKM4/nETw6Eg74h5w6iIGtsWfnSUhcLzeJuYwToXDrYFS 4XpFwb0TjiSS8odrVZM4h0VUGJyfrmSVCEJGbYL++368jgwejUxgPAYwW4wCDiM2fan3ngNT FAXPTwzivORuMJvLcd73ZWg4MoH4/PfgSkG7Ix9jbR/8sIhzVlI2f+grhpeXw2xdh4DHwWB8 3ObAPtRr0HpsQchjBqr+smE8ToTbtUvOnHB4OHjHmZMA9ulZZ04ODBe3iXjbaDB3PXHizdA2 e8qRI6S2QHP5lANLqQj4Zuq+0Ii2VLstqNqtvNqt3IywcyiAoRkmKzM2bjut16QzTLZuu442 NCH2Nq622OPa0ejCbiuiCKTwIc2UOFUiVB1k8rOsKJMQKOTkiFSUKpGmZWfkq1WMeh+Tm5al YRhNtk4RQL7ty6b7rnP6XC3NKGSkUsaGyfVwWq72ACtk4qIuIR39KaOlDeyhWhEQGFsmlnJl Gar8z2h9Ni9mRZsIXBFERpxnm6AyVQb6AE3n0Po19jj7iihzmXEUUWUFZeOIqrxwrhvJcV22 juZ/FaEk8vDwkATq6Uw6b79Gyxq6DwHkM64vf3eanyOIvEawDOXOOEYJJT0otp0Niu7TCAhP K0onfBTBvLWEyVFlMZpMd1sZmRLATbtG8ZZS8ibXjM9a1GEXTPZwwXUVl1UfKkRE06+L40jC TxxC/s51FsClqnN1G0eVB5FHOSHKjXXYygPJPTvZMj83gnNm5fakYRvlXOZr35ZhFCqX8oP6 sG8mS2NwDuPkp9FRAXtbQBYJuT1rdIYXViElJx1DOxm+WEKOc0FvZ9CxCCAHZW4SrlbiziD2 DzwshuGnpRh8udKAQWNlKQGNq8e8Ybl7yA+uGwsk0GS/GQid9tVAMFU2BEG/pT0I5mpuhMJY WX8YTMzdCIPnppPhYBprC4enAxPhUNxxSQHjt7tfgh+/vhoBpq7CSKi1dEbCqT9+iYSKlctR 0DHzMAr+/m9xK5gaV14By/fz2+C3IuMOVuriTqif79gFy6OFCWCZvvzqNHsVAtdVGFQvrkJG DvqJuKtwUmtX0bcP467CGXVehY0Lrqu4tiEvQNHzZ2dWe8afjNVmfBEfpj5UlD9saR5sPt3S EBPgb7/bnlRV2pSySxhi/OhNzScJj5Nzbj2W17eOTv/T/oB6YyaeVvmpkjoVnw+FD+zHDJ4+ 77bk1vnpmgO+DSk5ZFtOzFn6LsX/cHFsclTJB3slLXvlettYRYjnlZ/s8vK0s+K33k9X4Ixa FbsV0zOq/wFM1wxBkgYAAA== x-auditid: c1b4fb32-f79016d000001045-44-5707162dbcc3 errors-to: mpls-bounces@ietf.org x-beenthere: mpls@ietf.org list-id: Multi-Protocol Label Switching WG x-mailman-version: 2.1.17 list-post: list-archive: x-original-to: mpls@ietf.org delivered-to: mpls@ietfa.amsl.com dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1460082201; bh=DSgwCGUt+ARccYHRhq3EFD7OtXyIvf3nRsGMRcXA93k=; h=From:To:Date:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=CMq/jU+GOCmU4iAFGK/u8KL4knsh7n1Z30gFyCKfGztKiMi7IZUQ6DuFPlo/hjSfn DnpSukuP1u3K1oXL4e3TiAVVdi3Ef2tKLoKdAw+S76/IUZ/1W4arpG4NBWWwcaqcPA VhKbL9TeXj7m0MI18A8sISm0M9UdJIWBnp7aiZMg= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-07.txt Pages : 27 Date : 2016-04-07 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_002_7347100B5761DC41A166AC17F22DF11221A3FD70eusaamb103erics_-- From nobody Thu Apr 7 19:38:47 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693112D74C; Thu, 7 Apr 2016 19:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajF7MxP3DF8c; Thu, 7 Apr 2016 19:38:41 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FEE12D773; Thu, 7 Apr 2016 19:38:41 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i84so113954068ywc.2; Thu, 07 Apr 2016 19:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XhvHiiyvexnDbqAqjYkebwUb4lybHMXDG3IFTLhuTdQ=; b=m1fPUcTWjQeGDtnjsCSEoFVsXPHsDRCcUblm5UUDAjWxo4gyMIE5fWYCEbR/GwWXY5 ckR8O01z1wBkQvj9XxeIzuFhGyoAJIL4ODzWAa9fhjj29i09HGmUsgUxdVtgxMRZHvF+ v3IODXdwRdj52oIpXqfLedbogZV/GoEkAJTvyATcwLSDXQBYI8y9NcqA7ka/w3VodUyO ae86BnG6TwQpy41BHJWye5Yw1jthBmBBZhycbdS3drXzi4MxNAPj69UJh+yamp6/p8KQ rt6zPFrwPCr6A73Pkccd45rahaRsugcp28kFJHj1aGr7YhVbjpoIYpsjbOYKguCxXCd/ gtDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XhvHiiyvexnDbqAqjYkebwUb4lybHMXDG3IFTLhuTdQ=; b=cnQs6D9H6TX6bnpZhw1P2PwuMLKgI/G6u51chWgPt8n/uFLT5Z9TyypvLaGMn88Ybn WFGR+XAL5YuuGi5XUNgwhpD4DaPLqv6uB3qbGzmlnSVWaP7skco7ROKR1et9hPMB25Fm l0Jx4+4txToTm1fQj2gUW9q81lNq+ekYhuNkau/Fs9vFGpT77hiKSDcGw+Mxdi4srHU4 7IoX4Hyq/wJ+nxJoQqeFhXOFbTxi3+Ei+pkpGyAWakip3uVjBMEyREFTAssnWR6aI1gN ZWkuOQBGc6GUBHut1OdW78+oi0tKPi4Xj5JMMME1D8HuB0UhlBaVtqCM+eJDIqTK6s6v 06Vw== X-Gm-Message-State: AD7BkJKWIDw7jD8HdiGnth+n5qKOyEVNAO8gBg9EXqSEHgzvYHTa6K2auDA/R1tK4ivtufLi1jOFc9Xo9QFcbw== MIME-Version: 1.0 X-Received: by 10.129.29.3 with SMTP id d3mr3520586ywd.190.1460083120750; Thu, 07 Apr 2016 19:38:40 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Thu, 7 Apr 2016 19:38:40 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 08:08:40 +0530 Message-ID: From: Manav Bhatia To: Mach Chen Content-Type: multipart/alternative; boundary=001a11428312c14b1a052ff01772 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 02:38:44 -0000 --001a11428312c14b1a052ff01772 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe it had to do with multicast datapath (especially link local) being different from the unicast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve out a special data path for the micro-BFD packets. Using link local would have made it a lot simpler. And this is where i think the current proposal is flawed -- they use link local multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > --001a11428312c14b1a052ff01772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe it had to do with multicast datapath (especially= link local) being different from the unicast datapath in most routers. Usi= ng link local multicast IP addresses may not necessarily guarantee Unicast = IP reachability.=C2=A0

When writing 7130 we spent quite = a bit of time ensuring that we dont carve out a special data path for the m= icro-BFD packets. Using link local would have made it a lot simpler.
<= div>
And this is where i think the current proposal is flawed= -- they use link local multicast to ensure IP unicast reachability which i= s incorrect.

Cheers, Manav

On Thu, Apr 7, 2016 at 11:1= 6 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my understanding is correct, = the idea is to use multicast destination address other than unicast address= when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea= has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2= =A0(the predecessor of RFC 7130). And at=C2=A0that time, the co-authors of = RFC 7130 did discuss=C2=A0the idea of using multicast destination address, but for some reason I forget now(I may need to reiterate the discussions o= n the archive), the idea was abandoned, although I still think multicast de= stination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirs= ky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.or= g
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:rtg-bfd-chairs@ietf.org" target=3D"_blank">rtg-bfd-chairs@= ietf.org; mpl= s-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces

Dear All,

two new drafts, related to RFC 7130, were published = before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces in IP netw= ork

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces in IP/MP= LS network

=C2=A0

Greatly appreciate your reviews, comments, questions= and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Greg


--001a11428312c14b1a052ff01772-- From nobody Fri Apr 8 03:12:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC612D831; Fri, 8 Apr 2016 03:12:51 -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 X7rN4KlRouHU; Fri, 8 Apr 2016 03:12:49 -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 B7BD912D82D; Fri, 8 Apr 2016 03:12:49 -0700 (PDT) Received: from [10.10.2.96] (unknown [190.111.246.165]) (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 10DE918013C8; Fri, 8 Apr 2016 12:12:46 +0200 (CEST) To: "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" References: <5706AF5A.5070108@pi.nu> From: Loa Andersson Message-ID: <57078417.3070700@pi.nu> Date: Fri, 8 Apr 2016 18:12:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5706AF5A.5070108@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 10:12:52 -0000 WG, Sorry I had a cut and paste error in the two first paragraphs of this mail, it should have read: The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready for working group last call. We will do an IPR poll prior to the start of wglc. I apologize for the mistake! /Loa On 2016-04-08 03:04, Loa Andersson wrote: > Working Group, > > The authors of draft-ietf-mpls-app-aware-tldp has told us that > the document is ready to be considered for working adoption. > > The document been through MPLS-RT review. We will do an IPR poll > prior to the start of the adoption poll. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There is one IPR disclosure filed directly against this document. > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > > If you are on the MPLS WG email list but 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. > > > /Loa > mpls wg co-chair From nobody Fri Apr 8 04:12:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFC212D8A9; Fri, 8 Apr 2016 04:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.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 GTGy0Ix6BDjF; Fri, 8 Apr 2016 04:12:24 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (using TLSv1.2 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A2F12D6BF; Fri, 8 Apr 2016 04:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1460113943; x=1491649943; h=from:to:date:subject:message-id:references:in-reply-to: mime-version; bh=IXO5Nb85CQl6iktYsrHhflrAXHf7oALUjxhsK30S1rs=; b=eAPQUphVbHypLqCa4DuEvLgcF3yswYNqz/obBDIN8m1NT/bpk0DGgYEW AI2dA23TI12/0h8kcxPgrAgkf0IUitDhRejrrw0iWsQIrmMjlOOBIXnfg 77lxrbslYa1nXnf3P2S1JwN0YU8uld8P4W7remnYKrnv4S4Qs/5lplk0k U=; IronPort-PHdr: 9a23:dBzp/h9iXjtllP9uRHKM819IXTAuvvDOBiVQ1KB70ugcTK2v8tzYMVDF4r011RmSDdWdt68P0LCempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lSsiO0o/sjaibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwu3cYh/V008lJGYz8c6kiVqdfCnxyN2c8zNXq8x/eG0/HrH4EVn4+kxdUDU7C9h6wFsP0qi/hnutwxCfcOtf5G/R8Ezi45ql3DR7llClCMiY96yTektQ1hb1Suh/kuxhz26bVbZ2bcv1kcemVKd8ATGRdG8dcSyIEB5u4dM4GF/JENPlRtYS4u18CtTO/CBWiQuT1xWkMzjXzxakhlu8hGADcxyQhEs4A9nPOo5+9YKIKVfvwx6nBzC/YR/JbxTm775LHJEMPu/aJCPhSeM7QzQ1nMx7Mnx/Y/Yj4NiLT1O0Jsmyz8ed6VPCojSgsrAQn8Wvn/dslloSc3tFd8VvD7ygsmIs= X-IronPort-Anti-Spam-Filtered: false X-IPAS-Result: A2EgAgDokAdX/60ueqVcGgEBAYJOTIFQtVKEcwENgXOGDQKBNjgUAQEBAQEBAQECYieCLYIUAQEBAQNuBhUCAQgRAwECKAcyFAkIAQEEARKIEQEVBZx6AQGHDpwWAQEBAQEBBAEBAQEBG4YihEqEDxACAT2FNgWTGYRmBQGNLIJGhE2DKIUxjyUeAQFChANQiTkBAQE Received: from omzsmtpi03.vzbi.com ([165.122.46.173]) by omzsmtpe02.verizonbusiness.com with ESMTP; 08 Apr 2016 11:11:52 +0000 From: "Jalil, Luay" X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="658316540" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by omzsmtpi03.vzbi.com with ESMTP; 08 Apr 2016 11:11:50 +0000 Received: from FHDP1LUMXC7V32.us.one.verizon.com ([166.68.125.33]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Fri, 8 Apr 2016 07:11:49 -0400 To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Date: Fri, 8 Apr 2016 07:11:49 -0400 Thread-Topic: [E] Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AdGRh3ICUD8fn5sqTkSYhzTPNSmvCA== Message-ID: References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu> In-Reply-To: <57078417.3070700@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D32D181BC35B3luayjaliloneverizoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] [E] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:12:26 -0000 --_000_D32D181BC35B3luayjaliloneverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not aware of any Regards, Luay From: Loa Andersson > Date: Friday, April 8, 2016 at 7:12 AM To: "mpls@ietf.org" >, "draft-ietf-mpls-app-aware-tldp@ietf.org" >, "mpls-chairs@ietf.org" > Subject: [E] Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp WG, Sorry I had a cut and paste error in the two first paragraphs of this mail, it should have read: The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready for working group last call. We will do an IPR poll prior to the start of wglc. I apologize for the mistake! /Loa On 2016-04-08 03:04, Loa Andersson wrote: Working Group, The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready to be considered for working adoption. The document been through MPLS-RT review. We will do an IPR poll prior to the start of the adoption poll. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR disclosure filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair --_000_D32D181BC35B3luayjaliloneverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not aware of an= y

Regards,
Luay

From: Loa = Andersson <loa@pi.nu>
Date: Friday, April 8, 2016 at 7:12 AM
To: "mpls@ietf.org" <mpls@ietf.org&= gt;, "draft-ietf= -mpls-app-aware-tldp@ietf.org" <draft-ietf-mpls-app-aware-tldp@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: [E] Corection - [mpls] IPR poll on = draft-ietf-mpls-app-aware-tldp

WG,

Sorry I had a cut and paste error in the two first = paragraphs of this
mail, it should have read:

   The authors of draft-ietf-mpls-app-aware-tldp has told u= s that
   the document is ready for working group last = call.

   We will do an IPR poll prior to= the start of wglc.

I apologize for the mistake!

/Loa



On 2016-04-08 03:04, Loa Andersson wrote:
Working Group,

<= div> The authors of draft-ietf-mpls-app-aware-tldp has told us that
the document is ready to be considered for working adoption.
=
The document been through MPLS-RT review. We will do an IPR= poll
prior to the start of the adoption poll.

This mail starts the IPR poll.

Are you a= ware of any IPR that applies to draft-ietf-mpls-app-aware-tldp?
<= br>
If so, has this IPR been disclosed in compliance with IETF I= PR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).<= /div>

There is one IPR disclosure filed directly agains= t this document.

If you are listed as a document = author or contributor please respond to
this email regardless of= whether or not you are aware of any relevant
IPR. *The response= needs to be sent to the MPLS wg mailing list.* The
document wil= l not advance to the next stage until a response has been
receiv= ed from each author and contributor.

If you are o= n the MPLS WG email list but are not listed as an author or
cont= ributor, then please explicitly respond only if you are aware of any
<= div> IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair

--_000_D32D181BC35B3luayjaliloneverizoncom_-- From nobody Fri Apr 8 04:23:21 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD89512D14F; Fri, 8 Apr 2016 04:23:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 LsGno6pLUMqz; Fri, 8 Apr 2016 04:23:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1: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 901C712D0F8; Fri, 8 Apr 2016 04:23:17 -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=M8LVKdx0f6G1tjO1dhS+gFym9YnS31G+yIq7+Sj/kmc=; b=ftVBDJqZgCc9Rd7dqjttPPv030kvieqKydIajEndUSZz03tf0bi2xj4W/UNbK8bTIGzleaoaGl3k7Yko5Byx+DmcJ3JyCtb2QMRGHmeBcjvngw3k23tK1xzhOXX51s78LvNyupeLdlDcQbNDI8Pb0QUkFmulY9QQyVPDOkGot30= Received: from CO2PR05MB2695.namprd05.prod.outlook.com (10.166.200.7) by CO2PR05MB2695.namprd05.prod.outlook.com (10.166.200.7) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 11:22:57 +0000 Received: from CO2PR05MB2695.namprd05.prod.outlook.com ([10.166.200.7]) by CO2PR05MB2695.namprd05.prod.outlook.com ([10.166.200.7]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 11:22:56 +0000 From: Raveendra Torvi To: "Jalil, Luay" Thread-Topic: [E] Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AQHRkQBoD3A4NJLyaUK0D4PiQvpdu59/3FuAgAAQiICAAAMcZA== Date: Fri, 8 Apr 2016 11:22:56 +0000 Message-ID: References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: verizon.com; dkim=none (message not signed) header.d=none;verizon.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [107.107.59.186] x-ms-office365-filtering-correlation-id: 8e2af895-e5f0-4f57-2e6e-08d35fa022a4 x-microsoft-exchange-diagnostics: 1; CO2PR05MB2695; 5:y5LYfimyx3HLK1tVHmb5MyIssmVf5NmNF7XEf0a74+1/IpkIVDJ4p9YzNKtX48aj6noD5CIGnnFRbLbZTX1rhndQ68S5UMW6rAedZviCw+rjUEe1gGTJuUW6uwarE+E5iack05RlkxRJAWgtiqzbTg==; 24:Ezxjyoqu797Zoo6mK3pu7ao14VhHVwC6BPR+w4/3pyBYvssxCThcq5LLB3dc6nNqEd+0OIjTcYzn0UqiCqfIaNxCYrZ3lSIZl00y0ZZfIkw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB2695; 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)(6055026); SRVR:CO2PR05MB2695; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB2695; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(377424004)(36756003)(54356999)(76176999)(3660700001)(5002640100001)(86362001)(230783001)(77096005)(2906002)(99286002)(4326007)(106116001)(82746002)(2900100001)(50986999)(2950100001)(87936001)(19580395003)(19580405001)(81166005)(189998001)(10400500002)(66066001)(5008740100001)(92566002)(1096002)(586003)(83716003)(1220700001)(102836003)(5004730100002)(16236675004)(3846002)(110136002)(6116002)(3280700002)(122556002)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB2695; H:CO2PR05MB2695.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E6FBFB691AC048E5A234C46DD373068Ejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 11:22:56.9181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB2695 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] [E] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 11:23:20 -0000 --_000_E6FBFB691AC048E5A234C46DD373068Ejunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any other IPR. regards, Ravi On Apr 8, 2016, at 7:12 AM, Jalil, Luay > wrote: Not aware of any Regards, Luay From: Loa Andersson > Date: Friday, April 8, 2016 at 7:12 AM To: "mpls@ietf.org" >, "draft-ietf-mpls-app-aware-tldp@ietf.org" >, "mpls-chairs@ietf.org" > Subject: [E] Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp WG, Sorry I had a cut and paste error in the two first paragraphs of this mail, it should have read: The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready for working group last call. We will do an IPR poll prior to the start of wglc. I apologize for the mistake! /Loa On 2016-04-08 03:04, Loa Andersson wrote: Working Group, The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready to be considered for working adoption. The document been through MPLS-RT review. We will do an IPR poll prior to the start of the adoption poll. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR disclosure filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair --_000_E6FBFB691AC048E5A234C46DD373068Ejunipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am not aware of any other IPR.
regards,
Ravi

On Apr 8, 2016, at 7:12 AM, Jalil, Luay <luay.jalil@verizon.com> wrote:

Not aware of any

Regards,
Luay

From: Loa Andersson <loa@pi.nu>
Date: Friday, April 8, 2016 at 7:12= AM
To: "mpls@ietf.org" <mpls@i= etf.org>, "draft-ietf-mpls-app-aware-tldp@ietf.org" <draft-ietf-mpls-app-aware-tldp= @ietf.org>, "mpls-chairs@ietf.org&quo= t; <mpls-chairs@ietf.org>=
Subject: [E] Corection - [mpls] IPR= poll on draft-ietf-mpls-app-aware-tldp

WG,

Sorry I had a cut and paste error in the two first paragraphs of this<= /div>
mail, it should have read:

   The authors of draft-ietf-mpls-app-aware-tldp has told us= that
   the document is ready for working group last call.

   We will do an IPR poll prior to the start of wglc.

I apologize for the mistake!

/Loa



On 2016-04-08 03:04, Loa Andersson wrote:
Working Group,

The authors of draft-ietf-mpls-app-aware-tldp has told us that
the document is ready to be considered for working adoption.

The document been through MPLS-RT review. We will do an IPR poll
prior to the start of the adoption poll.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tld= p?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

There is one IPR disclosure filed directly against this document.

If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
IPR. *The response needs to be sent to the MPLS wg mailing list.* The<= /div>
document will not advance to the next stage until a response has been<= /div>
received from each author and contributor.

If you are on the MPLS WG email list but are not listed as an author o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.


/Loa
mpls wg co-chair

--_000_E6FBFB691AC048E5A234C46DD373068Ejunipernet_-- From nobody Fri Apr 8 05:39:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55612D682; Fri, 8 Apr 2016 05:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RLHWT1WQKRNR; Fri, 8 Apr 2016 05:39:37 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2448E12D823; Fri, 8 Apr 2016 05:39:17 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-0a-5707a027cc62 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.D6.30335.720A7075; Fri, 8 Apr 2016 14:12:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 08:39:15 -0400 From: Gregory Mirsky To: Manav Bhatia , Mach Chen Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oA== Date: Fri, 8 Apr 2016 12:39:14 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyuXSPt67GAvZwgzkfeSw+PbzEbHFg00FG iwtrhS0uT2pjt1h3+RSbxa2lK1ktlty+x27x+c82RgcOj52z7rJ7tBx5y+qxZMlPJo8vlz+z BbBEcdmkpOZklqUW6dslcGU8uLyOtWDGHMaK7X+72BsYW2YwdjFyckgImEgs+7iOFcIWk7hw bz1bFyMXh5DAUUaJS4sWMEM4yxglvj+8BFbFJmAk8WJjDzuILSLgJbFnyTawDmaBi0wS36Z+ YQJJCAs4Snyff40ZoshJ4sOVxUDNHGD24wOFIGEWARWJEw+OMYGEeQV8JW7eDIXY9YBRYvK+ GWC7OAUCJbqWzAa7lBHouu+n1oCNZxYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+B/WNksSc1xAn MAvkS7zt2whm8woISpyc+YRlAqPoLCSjZiEpm4WkbBbQecwCmhLrd+lDlChKTOl+yA5ha0i0 zpnLjiy+gJF9FSNHaXFBTm66kcEmRmCcHpNg093BeH+65yFGAQ5GJR7eBQLs4UKsiWXFlbmH GCU4mJVEeLcuAQrxpiRWVqUW5ccXleakFh9ilOZgURLnbQz+FyYkkJ5YkpqdmlqQWgSTZeLg lGpgNH22fE7KWRfFbRY2ZltK98kzLqk+na5WtDpUkW+99Y2KY/kKZl3sfT/qAl9OdLrWwK4Q VCc700Rk9yoTq42PTv6UVXm0TvsFy8TiH/yHZH5yT2LZnu7BIuosu1HKS+TSTTUtFsM5S0sd /MuSxKIfSPROdl6m9uE2Q4979LEq+z2HHFZwCKYpsRRnJBpqMRcVJwIADkxhhM8CAAA= Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:39:40 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Np b25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuDQpXZSBiZWxpZXZlLCBhbmQg SmVmZiBpcyBjby1hdXRob3Igb2YgUkZDIDcxMzAgdG9vLCB0aGF0IE1DLUxBRyBwcmVzZW50cyBk aWZmZXJlbnQgY2FzZSBhbmQgdGhlIGNvbXByb21pc2UgdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRv byBpcyBqdXN0aWZpZWQuIFdlIHdpbGwgYWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFs IGRpZmZlcmVuY2VzIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4g dGhlIG5leHQgdXBkYXRlLg0KV2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24gYW5kIGFsd2F5 cyB3ZWxjb21lIGNvbW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuDQoNCiAgICAgICAg ICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoN CkZyb206IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjM5IFBNDQpUbzogTWFjaCBDaGVuDQpDYzogR3Jl Z29yeSBNaXJza3k7IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LXRhbm1p ci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkLWNoYWlyc0BpZXRm Lm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29t KQ0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFH IGludGVyZmFjZXMNCg0KSSBiZWxpZXZlIGl0IGhhZCB0byBkbyB3aXRoIG11bHRpY2FzdCBkYXRh cGF0aCAoZXNwZWNpYWxseSBsaW5rIGxvY2FsKSBiZWluZyBkaWZmZXJlbnQgZnJvbSB0aGUgdW5p Y2FzdCBkYXRhcGF0aCBpbiBtb3N0IHJvdXRlcnMuIFVzaW5nIGxpbmsgbG9jYWwgbXVsdGljYXN0 IElQIGFkZHJlc3NlcyBtYXkgbm90IG5lY2Vzc2FyaWx5IGd1YXJhbnRlZSBVbmljYXN0IElQIHJl YWNoYWJpbGl0eS4NCg0KV2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2Yg dGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGgg Zm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1h ZGUgaXQgYSBsb3Qgc2ltcGxlci4NCg0KQW5kIHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3Vy cmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0gdGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3Qg dG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hhYmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC4NCg0K Q2hlZXJzLCBNYW5hdg0KDQpPbiBUaHUsIEFwciA3LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENo ZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdy b3RlOg0KDQpIaSBHcmVnIGFuZCBhbGwsDQoNCg0KDQpJIGp1c3QgaGF2ZSBxdWljayByZXZpZXcg b24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBp cyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0 IGFkZHJlc3Mgd2hlbiAgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVyIExBRyBsaW5rcy4gQW5kIGFj dHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwICh0aGUgcHJlZGVjZXNzb3Igb2Yg UkZDIDcxMzApLiBBbmQgYXQgdGhhdCB0aW1lLCB0aGUgY28tYXV0aG9ycyBvZiBSRkMgNzEzMCBk aWQgZGlzY3VzcyB0aGUgaWRlYSBvZiB1c2luZyBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVz cywgYnV0IGZvciBzb21lIHJlYXNvbiBJIGZvcmdldCBub3coSSBtYXkgbmVlZCB0byByZWl0ZXJh dGUgdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25l ZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBp cyBhIHNtYXJ0IGlkZWEuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1hY2gNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJ0Zy1iZmQgW3J0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEdy ZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnku bWlyc2t5QGVyaWNzc29uLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwNSwgMjAxNiA2OjE2 DQpUbzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IG1wbHNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpDYzogZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMt bGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMt Y2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZE IG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCkRlYXIgQWxsLA0KdHdvIG5ldyBkcmFmdHMsIHJlbGF0 ZWQgdG8gUkZDIDcxMzAsIHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0aGUgbWVldGluZzoNCg0K4oCi ICAgICAgICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQIG5ldHdvcms8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLTAwPg0K DQrigKIgICAgICAgICBCRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAvTVBMUyBuZXR3b3Jr PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxh Zy1tcGxzLTAwPg0KDQpHcmVhdGx5IGFwcHJlY2lhdGUgeW91ciByZXZpZXdzLCBjb21tZW50cywg cXVlc3Rpb25zIGFuZCBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCiAgICAgICAgR3JlZw0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9m IGRpc2N1c3Npb25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGJlbGlldmUsIGFuZCBKZWZmIGlzIGNvLWF1dGhvciBv ZiBSRkMgNzEzMCB0b28sIHRoYXQgTUMtTEFHIHByZXNlbnRzIGRpZmZlcmVudCBjYXNlIGFuZCB0 aGUgY29tcHJvbWlzZSB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ug d2lsbCBhZGQNCiBtb3JlIGRldGFpbHMgb24gdGhlIHBvdGVudGlhbCBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBmYXN0IHBhdGhzIGluIHRoZSBuZXh0IHVwZGF0ZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBhcmUgb3BlbiB0byB0aGUgZGlzY3Vz c2lvbiBhbmQgYWx3YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0aXZlIHByb3Bvc2Fs cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86 bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJp bCAwNywgMjAxNiA3OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBNYWNoIENoZW48YnI+DQo8Yj5DYzo8 L2I+IEdyZWdvcnkgTWlyc2t5OyBydGctYmZkQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFm dC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzsgcnRnLWJmZC1jaGFp cnNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBBbGlhIEF0bGFzIChha2F0bGFzQGdt YWlsLmNvbSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNy by0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGggbXVsdGljYXN0IGRhdGFwYXRo IChlc3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVudCBmcm9tIHRoZSB1bmljYXN0 IGRhdGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBsb2NhbCBtdWx0aWNhc3QgSVAg YWRkcmVzc2VzIG1heSBub3QgbmVjZXNzYXJpbHkgZ3VhcmFudGVlIFVuaWNhc3QgSVAgcmVhY2hh YmlsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmlu ZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNy by1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBsb3Qg c2ltcGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QW5kIHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBm bGF3ZWQgLS0gdGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNh c3QgcmVhY2hhYmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciA3 LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hY2guY2hlbkBodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVnIGFuZCBhbGwsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZpZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkg dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1c2UgbXVsdGljYXN0IGRl c3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0IGFkZHJlc3Mgd2hlbiZuYnNwOyZu YnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExBRyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRo aXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwPC9h PiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQgYXQmbmJzcDt0aGF0IHRp bWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRpZCBkaXNjdXNzJm5ic3A7dGhlIGlkZWEg b2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFz b24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRoZQ0KIGRpc2N1c3Npb25z IG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25lZCwgYWx0aG91Z2ggSSBzdGls bCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhIHNtYXJ0IGlkZWEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1hY2gmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFu PjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IFJ0Zy1i ZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBHcmVnb3J5 IE1pcnNreSBbPGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhy ZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRm Lm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQpydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWly c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBB bGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3byBuZXcg ZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RGVhciBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnR3byBuZXcgZHJhZnRzLCBy ZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRhcmdldD0i X2JsYW5rIj5CRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sO2NvbG9y OmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9i bGFuayI+QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3Vy IHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A40584eusaamb103erics_-- From nobody Fri Apr 8 05:42:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388D312D711; Fri, 8 Apr 2016 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVLJdZxdSAV; Fri, 8 Apr 2016 05:42:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E277D12D682; Fri, 8 Apr 2016 05:42:47 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-06-5707a720c0cb Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5D.1C.22441.027A7075; Fri, 8 Apr 2016 14:42:08 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 08:42:46 -0400 From: Gregory Mirsky To: Mach Chen , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZACgcDOA= Date: Fri, 8 Apr 2016 12:42:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyuXSPn67CcvZwg0WbjS0+PbzEbHFg00FG iwtrhS3WXT7FZnFr6UpWi89/tjE6sHnsnHWX3aPlyFtWjyVLfjJ5fLn8mS2AJYrLJiU1J7Ms tUjfLoErY0lrE2vB8viKhYcXsDUwTg7tYuTkkBAwkfh/+gQzhC0mceHeerYuRi4OIYGjjBKn 2tpYQBJCAssYJV7NFwex2QSMJF5s7GEHsUUE8iQObJ3ODNLALHCBUeLbiw1gk4QFHCW+z7/G DFHkJPHhymLWLkYOINtKYvt5c5Awi4CKxJ1jb9hAbF4BX4nDD9qZIRbPZJS4saSXESTBKRAm cWjHQ1YQmxHouu+n1jCB2MwC4hK3nsxngrhaQGLJnvNQH4hKvHz8jxXCVpKY8xrkBg6g+nyJ 15OsIHYJSpyc+YRlAqPoLCSTZiFUzUJSBVGiI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i 5CgtLsjJTTcy3MQIjMZjEmyOOxj39noeYhTgYFTi4V0gwB4uxJpYVlyZe4hRgoNZSYR36xKg EG9KYmVValF+fFFpTmrxIUZpDhYlcV7vyH9hQgLpiSWp2ampBalFMFkmDk6pBkZT8W721Zzv 2KKOym+2SDltbZH38Xvk4aP7mA6eesdlGDdJRPlZLNPh6ILzl72FTEQqDt7c5v44Iv/15BIj CV6XjEc1D3i2cFlFTbp6ZOYO99J3a50Wr6+eueb20T5d+9zYVbbeuvOfO59dsHCZsIPOPVf5 0yukVvUx9uUo5VuxftfxFXvW9FaJpTgj0VCLuag4EQA3Twt/wgIAAA== Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 12:42:50 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, many thanks for your review and the reference. Will study it in details. Wi= ll be glad to continue this work with you. Would you consider joining the a= uthors? Regards, Greg From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Thursday, April 07, 2016 10:47 AM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mach,

many thanks for your r= eview and the reference. Will study it in details. Will be glad to continue= this work with you. Would you consider joining the authors?

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Mach Che= n [mailto:mach.chen@huawei.com]
Sent: Thursday, April 07, 2016 10:47 AM
To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg and all,

 

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bounces@iet= f.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (= akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related = to RFC 7130, were published before the meeting:

·&n= bsp;        BFD on MC-LAG interfa= ces in IP network

·&n= bsp;        BFD on MC-LAG inter= faces in IP/MPLS network

 =

Greatly appreciate your = reviews, comments, questions and suggestions.

 

Regards,

        Greg

--_000_7347100B5761DC41A166AC17F22DF11221A405A9eusaamb103erics_-- From nobody Fri Apr 8 07:14:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865D112D65D; Fri, 8 Apr 2016 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 dHVVZcI4lYo3; Fri, 8 Apr 2016 07:14:38 -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 C3E6612D18C; Fri, 8 Apr 2016 07:14:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLU31349; Fri, 08 Apr 2016 14:14:35 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Apr 2016 15:14:35 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 22:14:29 +0800 From: Mach Chen To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZACgcDOAAAxeN5w== Date: Fri, 8 Apr 2016 14:14:28 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> , <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A405A9@eusaamb103.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.189] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5707BCCC.003E, 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: f61e306f4aaeb1cb7f78c1d7fc75009f Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:14:41 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for the invitation, I am glad to join and continue the work. Best regards, Mach ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, April 08, 2016 20:42 To: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls-chairs@ietf.org; = Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Mach, many thanks for your review and the reference. Will study it in details. Wi= ll be glad to continue this work with you. Would you consider joining the a= uthors? Regards, Greg From: Mach Chen [mailto:mach.chen@huawei.com] Sent: Thursday, April 07, 2016 10:47 AM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [grego= ry.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for the invitation, I am glad to join and continue the work.

 

Best regards,

Mach

 

From: Gregory Mirsky [gregory.mirsky@erics= son.com]
Sent: Friday, April 08, 2016 20:42
To: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls-chairs@iet= f.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

Hi Mach,

many thanks for your = review and the reference. Will study it in details. Will be glad to continu= e this work with you. Would you consider joining the authors?

 

   &nb= sp;            Regar= ds,

   &nb= sp;            =             &nb= sp;   Greg

 

From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Thursday, April 07, 2016 10:47 AM
To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@= ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is co= rrect, the idea is to use multicast destination address other than unicast = address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From:= Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related= to RFC 7130, were published before the meeting:

=B7   &= nbsp;     BFD on MC-LAG interf= aces in IP network

=B7   &= nbsp;     BFD on MC-LAG inte= rfaces in IP/MPLS network

 

Greatly appreciate your= reviews, comments, questions and suggestions.

 

Regards,

        Greg

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C1F0FB9SZXEMA510MBXchi_-- From nobody Fri Apr 8 08:04:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DDB12D930; Fri, 8 Apr 2016 08:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWi7JV1lPD6L; Fri, 8 Apr 2016 08:04:46 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 21BBB12D92F; Fri, 8 Apr 2016 08:04:46 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id i84so131528944ywc.2; Fri, 08 Apr 2016 08:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T3aQixiktqeCUJ/2KLCpuz9XYc5tbFgJPVvauTBE7oQ=; b=m0GjA4/lo2G/D/qgI7R9W+RPqTZWsSM29e3O5BZWdwK09klW2OLyTCeQxKqefHRpof YN2rcOFkcE1WHgaC55N3lNSn66E9XqFXbVy+SIlY2C4a3QZSdhNhmq3Pc4vKPkpbvFsO eVSN5sSJFAi1HQQRrysBJROZ7gkUgYKKiXqW/ZMaEHrI/Tjq/rDliLErwnrAOmahfqfD 9juaKvNAqWoHOolOVRSLDVkH/GjSj40FzLPMfZf5W6DugW7dxfC5R5z+ujPHw884ISQH DbDZv+HdZ/KVSz67YVXH2/E2OKCDjdssN626CFOa5PiqtXzCVUpGSidnyRH8Wg8n+r4b eRQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=T3aQixiktqeCUJ/2KLCpuz9XYc5tbFgJPVvauTBE7oQ=; b=KY0px3kVWu/6IMbFK5Rpznr/kknVvigVhh1zpIYVI+w3J38hKReXSMITYQXhtpktln pokaKFdTQ9fahm/MuyU3zCO43clj33pgJOaIP7ISJ8jmh67CM4wKdFTmFNfkvUbkM5lx EYD6lp1vPXzsfNE5y6dEuRowwaChGTJxGy4c8PjyZPllWBED/h0ZuXNBg4oho2vvJde4 6QemvifqVBlBri5WGHDznYlGb9wTcVUdILXkwH9kQ9c0Cgx+2FumUdfF2gSH4eWIlAnL ns90hKkLITYcVORl6nCOWd5fkkNx9yPmKQjrMqv0QTX/r/yX006lTETf2grnE+wSptPa PzBw== X-Gm-Message-State: AD7BkJKw9hv2qAfn2q7lA5GD6DkLfl60TzJLLSgm9pAyJNZ+yqe6+p/ndOqq84Xwb9wxzjSn2xPycNzAaE4n9w== MIME-Version: 1.0 X-Received: by 10.37.32.136 with SMTP id g130mr4888962ybg.45.1460127885285; Fri, 08 Apr 2016 08:04:45 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 08:04:45 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 20:34:45 +0530 Message-ID: From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a1143e5deede1d7052ffa8350 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:04:53 -0000 --001a1143e5deede1d7052ffa8350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end points? Ones going to router 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers must use different IP addresses so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky wrote: > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > --001a1143e5deede1d7052ffa8350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

Why cant different micro-BFD p= ackets use the IP address of the MC-LAG end points? Ones going to router 1 = will all carry the same unicast IP address. The ones going towards the othe= r router will all carry some other IP address, which would be configured al= ong with the MC-LAG configs.

In fact i would argue= that the u-bfd packets going to different routers must use different IP ad= dresses so that you can actually verify the data plane liveliness. Whats th= e point in sending a contrived IP address if the path that it takes is diff= erent from the other regular packets?

Cheers, Mana= v

= On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <gregory.mirsky@e= ricsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.<= /span>

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on the potential differences between unicast and multicast fa= st paths in the next update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.iet= f.org; rtg= -bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Un= icast IP reachability.=C2=A0

=C2=A0

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

=C2=A0

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 BFD on MC-LAG interfa= ces in IP network

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 BFD on MC-LAG inter= faces in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0


--001a1143e5deede1d7052ffa8350-- From nobody Fri Apr 8 08:50:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668212D517; Fri, 8 Apr 2016 08:50:53 -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 P8uQTMJZgNAi; Fri, 8 Apr 2016 08:50:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178E712D101; Fri, 8 Apr 2016 08:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18946; q=dns/txt; s=iport; t=1460130650; x=1461340250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6fMz7E/0vNhu6f3Ia5f9cH8Dd5oUMw0Fpokd39ey/iU=; b=W01dD/99a95hk3aNNZptaiNQu/WsPBkaPNfHDUmTyeRRY4YOzR5iUXEZ eojdVT5HEVtZ0d66ZGhaLJMmyTAYRdyiYtav7IhI6zYRQRhpTqG9fD54g yr73EALsG+mgbpoExfsYZpRHh4b+LqfN2i08hTs88nyU1GLf2nVZiO9u0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAgD/0gdX/49dJa1cgmtMU30GrmeGZ?= =?us-ascii?q?YRzAQ2BcyGFbAKBMzgUAQEBAQEBAWUnhEEBAQEEeRACAQgRAwEBARoCDAchERQ?= =?us-ascii?q?JCAEBBAENBYgSAxIOuzgNhSEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuCQ?= =?us-ascii?q?YIeDQknAoR3BY4GiU0xAYV2hiCBdYFnjSaGH4Erh1oBHgEBQoIEGYFKbFqHJD0?= =?us-ascii?q?BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208,217";a="259150790" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 15:50:48 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38FomrA009196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 15:50:48 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 10:50:47 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 10:50:47 -0500 From: "Reshad Rahman (rrahman)" To: Manav Bhatia , Gregory Mirsky Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZAB2XmwAAFPl8AAAFFQWA///JyYA= Date: Fri, 8 Apr 2016 15:50:47 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.167] Content-Type: multipart/alternative; boundary="_000_D32D4A9913B056rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 15:50:53 -0000 --_000_D32D4A9913B056rrahmanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Manav, and nothing in RFC7130 seems to preclude using differen= t unicast IP address as destination on different member links. Regards, Reshad (as individual contributor). From: Rtg-bfd > o= n behalf of Manav Bhatia > Date: Friday, April 8, 2016 at 11:04 AM To: Gregory Mirsky > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you've pointed too is justified. We wil= l add more details on the potential differences between unicast and multica= st fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: =B7 BFD on MC-LAG interfaces in IP network =B7 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_D32D4A9913B056rrahmanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <12FD2F8949168049B81EDF4EC0E0A0BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree with Manav, and nothing in RFC7130 seems to preclude using dif= ferent unicast IP address as destination on different member links.

Regards,
Reshad (as individual contributor).

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Ma= nav Bhatia <manavbhatia@gmail.c= om>
Date: Friday, April 8, 2016 at 11:0= 4 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "= rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Hi Greg,

Why cant different micro-BFD packets use the IP address of the MC-LAG = end points? Ones going to router 1 will all carry the same unicast IP addre= ss. The ones going towards the other router will all carry some other IP ad= dress, which would be configured along with the MC-LAG configs.

In fact i would argue that the u-bfd packets going to different router= s must use different IP addresses so that you can actually verify the data = plane liveliness. Whats the point in sending a contrived IP address if the = path that it takes is different from the other regular packets?

Cheers, Manav

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <= span dir=3D"ltr"> <gregor= y.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view = of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author o= f RFC 7130 too, that MC-LAG presents different case and the compromise that= you’ve pointed too is justified. We will add more details on the potential differences between unicast and mul= ticast fast paths in the next update.

We are open to the discussion and a= lways welcome comments and alternative proposals.

 

      = ;          Regards,<= /u>

      = ;            &n= bsp;            = ; Greg

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

 

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Un= icast IP reachability. 

 

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

 

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is corr= ect, the idea is to use multicast destination address other than unicast ad= dress when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From:<= /b> Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=B7         BFD on MC-LAG interfa= ces in IP network

=B7         BFD on MC-LAG inter= faces in IP/MPLS network

 

Greatly appreciate your = reviews, comments, questions and suggestions.

 

Regards,

        Greg

 


 --_000_D32D4A9913B056rrahmanciscocom_-- From nobody Fri Apr 8 09:12:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0E12D1CB; Fri, 8 Apr 2016 09:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsExwUkYxnUK; Fri, 8 Apr 2016 09:12:20 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E787012D1AB; Fri, 8 Apr 2016 09:12:19 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-ab-5707d83c4718 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.A7.22441.C38D7075; Fri, 8 Apr 2016 18:11:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 12:12:18 -0400 From: Gregory Mirsky To: Manav Bhatia Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaA= Date: Fri, 8 Apr 2016 16:12:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyuXSPt67NDfZwg+k/dSw+PbzEbHFg00FG iwtrhS0uT2pjt1h3+RSbxa2lK1ktlty+x27x+c82RgcOj52z7rJ7tBx5y+qxZMlPJo8vlz+z BbBEcdmkpOZklqUW6dslcGV869vNVvDkMWPFo5+BDYxP7jJ2MXJySAiYSNw9t4kJwhaTuHBv PRuILSRwlFHi1LIkCHsZo8TJp5ogNpuAkcSLjT3sILaIgIZE6/sDzF2MXBzMAl+ZJFqaVrGA JIQFHCW+z7/GDFHkJPHhymJWCNtP4vWhfrAFLAIqEutf3wGL8wr4Ssyc/IYZYtlrJokXN4xA bE6BQImNN+aDHccIdNz3U2vAbGYBcYlbT+ZDHS0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerz JXrezWOC2CUocXLmE5YJjKKzkIyahaRsFpKyWYwcQHFNifW79CFKFCWmdD9kh7CB3p8zlx1Z fAEj+ypGjtLigpzcdCPDTYzAGD0mwea4g3Fvr+chRgEORiUe3gUC7OFCrIllxZW5hxglOJiV RHhZrgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnNTk0tSC2CyTJxcEo1MHIe nV8nU2nStytj71vfd0tPajAUX4t2aK857PtTIEAu7KL5Hc1vvSwBE7SFshetdtj0ctH8jjW5 bPPb93OrN4VlmvyQ+X26drucCN9aS4ane48a1ehu08meyezCyq99t+ShRdgpxv0BDwsvTu3x 3esrFbpWzcOx+lx6yI8nHKVTY+e3vt8xR4mlOCPRUIu5qDgRAM+R1tHNAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:12:23 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhlIGFkdmFudGFn ZSBvZiB0aGUgTUMtTEFHIGlzIHRoYXQgdGhlcmXigJlzIG5vdGhpbmcgY2hhbmdlcyBmb3IgU0Ug d2hpY2ggc3RpbGwgc2VlcyBpdCBMQUcuIElmIG9uZSB0byB1c2UgZGlmZmVyZW50IGRlc3RpbmF0 aW9uIElQIGFkZHJlc3NlcyBvbiBTRSBzaWRlLCB0aGVuIHRoYXQgYWR2YW50YWdlIHdpbGwgYmUg bG9zdC4gT3VyIHByb3Bvc2FsIGlzIHRvIHByZXNlcnZlIGl0Lg0KDQogICAgICAgICAgICAgICAg UmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBN YW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXks IEFwcmlsIDA4LCAyMDE2IDg6MDUgQU0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IE1hY2ggQ2hl bjsgcnRnLWJmZEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnOyBtcGxz LWNoYWlyc0BpZXRmLm9yZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pDQpTdWJqZWN0 OiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNl cw0KDQpIaSBHcmVnLA0KDQpXaHkgY2FudCBkaWZmZXJlbnQgbWljcm8tQkZEIHBhY2tldHMgdXNl IHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBNQy1MQUcgZW5kIHBvaW50cz8gT25lcyBnb2luZyB0byBy b3V0ZXIgMSB3aWxsIGFsbCBjYXJyeSB0aGUgc2FtZSB1bmljYXN0IElQIGFkZHJlc3MuIFRoZSBv bmVzIGdvaW5nIHRvd2FyZHMgdGhlIG90aGVyIHJvdXRlciB3aWxsIGFsbCBjYXJyeSBzb21lIG90 aGVyIElQIGFkZHJlc3MsIHdoaWNoIHdvdWxkIGJlIGNvbmZpZ3VyZWQgYWxvbmcgd2l0aCB0aGUg TUMtTEFHIGNvbmZpZ3MuDQoNCkluIGZhY3QgaSB3b3VsZCBhcmd1ZSB0aGF0IHRoZSB1LWJmZCBw YWNrZXRzIGdvaW5nIHRvIGRpZmZlcmVudCByb3V0ZXJzIG11c3QgdXNlIGRpZmZlcmVudCBJUCBh ZGRyZXNzZXMgc28gdGhhdCB5b3UgY2FuIGFjdHVhbGx5IHZlcmlmeSB0aGUgZGF0YSBwbGFuZSBs aXZlbGluZXNzLiBXaGF0cyB0aGUgcG9pbnQgaW4gc2VuZGluZyBhIGNvbnRyaXZlZCBJUCBhZGRy ZXNzIGlmIHRoZSBwYXRoIHRoYXQgaXQgdGFrZXMgaXMgZGlmZmVyZW50IGZyb20gdGhlIG90aGVy IHJlZ3VsYXIgcGFja2V0cz8NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBGcmksIEFwciA4LCAyMDE2 IGF0IDY6MDkgUE0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208 bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgTWFuYXYsDQp0 aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Npb25zIGFyb3VuZCBS RkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuDQpXZSBiZWxpZXZlLCBhbmQgSmVmZiBpcyBjby1h dXRob3Igb2YgUkZDIDcxMzAgdG9vLCB0aGF0IE1DLUxBRyBwcmVzZW50cyBkaWZmZXJlbnQgY2Fz ZSBhbmQgdGhlIGNvbXByb21pc2UgdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRvbyBpcyBqdXN0aWZp ZWQuIFdlIHdpbGwgYWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFsIGRpZmZlcmVuY2Vz IGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4gdGhlIG5leHQgdXBk YXRlLg0KV2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24gYW5kIGFsd2F5cyB3ZWxjb21lIGNv bW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuDQoNCiAgICAgICAgICAgICAgICBSZWdh cmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206IE1hbmF2 IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbTxtYWlsdG86bWFuYXZiaGF0aWFA Z21haWwuY29tPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA3OjM5IFBNDQpUbzog TWFjaCBDaGVuDQpDYzogR3JlZ29yeSBNaXJza3k7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0 Zy1iZmRAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgZHJh ZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFp cnNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxh c0BnbWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFJlOiBUd28g bmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkkgYmVs aWV2ZSBpdCBoYWQgdG8gZG8gd2l0aCBtdWx0aWNhc3QgZGF0YXBhdGggKGVzcGVjaWFsbHkgbGlu ayBsb2NhbCkgYmVpbmcgZGlmZmVyZW50IGZyb20gdGhlIHVuaWNhc3QgZGF0YXBhdGggaW4gbW9z dCByb3V0ZXJzLiBVc2luZyBsaW5rIGxvY2FsIG11bHRpY2FzdCBJUCBhZGRyZXNzZXMgbWF5IG5v dCBuZWNlc3NhcmlseSBndWFyYW50ZWUgVW5pY2FzdCBJUCByZWFjaGFiaWxpdHkuDQoNCldoZW4g d3JpdGluZyA3MTMwIHdlIHNwZW50IHF1aXRlIGEgYml0IG9mIHRpbWUgZW5zdXJpbmcgdGhhdCB3 ZSBkb250IGNhcnZlIG91dCBhIHNwZWNpYWwgZGF0YSBwYXRoIGZvciB0aGUgbWljcm8tQkZEIHBh Y2tldHMuIFVzaW5nIGxpbmsgbG9jYWwgd291bGQgaGF2ZSBtYWRlIGl0IGEgbG90IHNpbXBsZXIu DQoNCkFuZCB0aGlzIGlzIHdoZXJlIGkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXMgZmxh d2VkIC0tIHRoZXkgdXNlIGxpbmsgbG9jYWwgbXVsdGljYXN0IHRvIGVuc3VyZSBJUCB1bmljYXN0 IHJlYWNoYWJpbGl0eSB3aGljaCBpcyBpbmNvcnJlY3QuDQoNCkNoZWVycywgTWFuYXYNCg0KT24g VGh1LCBBcHIgNywgMjAxNiBhdCAxMToxNiBQTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2Vp LmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgR3JlZyBhbmQg YWxsLA0KDQoNCg0KSSBqdXN0IGhhdmUgcXVpY2sgcmV2aWV3IG9uIHRoZSBkcmFmdHMuIElmIG15 IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgdGhlIGlkZWEgaXMgdG8gdXNlIG11bHRpY2FzdCBk ZXN0aW5hdGlvbiBhZGRyZXNzIG90aGVyIHRoYW4gdW5pY2FzdCBhZGRyZXNzIHdoZW4gIHNlbmRp bmcgQkZEIHBhY2tldHMgb3ZlciBMQUcgbGlua3MuIEFuZCBhY3R1YWxseSB0aGlzIGlkZWEgaGFz IGJlZW4gcHJvcG9zZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4t YmZkLWludGVyZmFjZS0wMCAodGhlIHByZWRlY2Vzc29yIG9mIFJGQyA3MTMwKS4gQW5kIGF0IHRo YXQgdGltZSwgdGhlIGNvLWF1dGhvcnMgb2YgUkZDIDcxMzAgZGlkIGRpc2N1c3MgdGhlIGlkZWEg b2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFz b24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRoZSBkaXNjdXNzaW9ucyBv biB0aGUgYXJjaGl2ZSksIHRoZSBpZGVhIHdhcyBhYmFuZG9uZWQsIGFsdGhvdWdoIEkgc3RpbGwg dGhpbmsgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYSBzbWFydCBpZGVhLg0KDQoN Cg0KQmVzdCByZWdhcmRzLA0KDQpNYWNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpGcm9tOiBSdGctYmZkIFtydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1i ZmQtYm91bmNlc0BpZXRmLm9yZz5dIG9uIGJlaGFsZiBvZiBHcmVnb3J5IE1pcnNreSBbZ3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+ XQ0KU2VudDogVHVlc2RheSwgQXByaWwgMDUsIDIwMTYgNjoxNg0KVG86IHJ0Zy1iZmRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll dGYub3JnPg0KQ2M6IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9y Zz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y Zz47IG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZz47IEFs aWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4pDQpT dWJqZWN0OiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZh Y2VzDQpEZWFyIEFsbCwNCnR3byBuZXcgZHJhZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJl IHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6DQoNCuKAoiAgICAgICAgIEJGRCBvbiBNQy1M QUcgaW50ZXJmYWNlcyBpbiBJUCBuZXR3b3JrPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcC0wMD4NCg0K4oCiICAgICAgICAgQkZEIG9u IE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4NCg0KR3JlYXRs eSBhcHByZWNpYXRlIHlvdXIgcmV2aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBhbmQgc3VnZ2Vz dGlvbnMuDQoNClJlZ2FyZHMsDQogICAgICAgIEdyZWcNCg0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi4gVGhl IGFkdmFudGFnZSBvZiB0aGUgTUMtTEFHIGlzIHRoYXQgdGhlcmXigJlzIG5vdGhpbmcgY2hhbmdl cyBmb3IgU0Ugd2hpY2ggc3RpbGwgc2VlcyBpdCBMQUcuIElmIG9uZSB0byB1c2UgZGlmZmVyZW50 IGRlc3RpbmF0aW9uDQogSVAgYWRkcmVzc2VzIG9uIFNFIHNpZGUsIHRoZW4gdGhhdCBhZHZhbnRh Z2Ugd2lsbCBiZSBsb3N0LiBPdXIgcHJvcG9zYWwgaXMgdG8gcHJlc2VydmUgaXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlh QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDA4LCAyMDE2IDg6 MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+Q2M6PC9iPiBNYWNo IENoZW47IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LXRhbm1pci1ydGd3 Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkLWNoYWlyc0BpZXRmLm9yZzsg bXBscy1jaGFpcnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tKTxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBN Qy1MQUcgaW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IEdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkg Y2FudCBkaWZmZXJlbnQgbWljcm8tQkZEIHBhY2tldHMgdXNlIHRoZSBJUCBhZGRyZXNzIG9mIHRo ZSBNQy1MQUcgZW5kIHBvaW50cz8gT25lcyBnb2luZyB0byByb3V0ZXIgMSB3aWxsIGFsbCBjYXJy eSB0aGUgc2FtZSB1bmljYXN0IElQIGFkZHJlc3MuIFRoZSBvbmVzIGdvaW5nIHRvd2FyZHMgdGhl IG90aGVyIHJvdXRlciB3aWxsIGFsbCBjYXJyeSBzb21lIG90aGVyIElQIGFkZHJlc3MsIHdoaWNo IHdvdWxkDQogYmUgY29uZmlndXJlZCBhbG9uZyB3aXRoIHRoZSBNQy1MQUcgY29uZmlncy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZmFj dCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcgdG8gZGlmZmVyZW50 IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3NlcyBzbyB0aGF0IHlvdSBjYW4g YWN0dWFsbHkgdmVyaWZ5IHRoZSBkYXRhIHBsYW5lIGxpdmVsaW5lc3MuIFdoYXRzIHRoZSBwb2lu dCBpbiBzZW5kaW5nIGEgY29udHJpdmVkIElQIGFkZHJlc3MgaWYgdGhlIHBhdGggdGhhdCBpdCB0 YWtlcw0KIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlciByZWd1bGFyIHBhY2tldHM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycywg TWFuYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCBBcHIgOCwgMjAxNiBhdCA2OjA5IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYW5hdiw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj50aGFuayB5b3UgZm9yIHNoYXJpbmcgaW5zaWdodCB2aWV3IG9mIGRpc2N1c3Np b25zIGFyb3VuZCBSRkMgNzEzMCwgZXh0cmVtZWx5IGhlbHBmdWwuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+V2UgYmVsaWV2ZSwgYW5kIEplZmYgaXMgY28tYXV0aG9yIG9mIFJGQyA3 MTMwIHRvbywgdGhhdCBNQy1MQUcgcHJlc2VudHMgZGlmZmVyZW50IGNhc2UgYW5kIHRoZSBjb21w cm9taXNlDQogdGhhdCB5b3XigJl2ZSBwb2ludGVkIHRvbyBpcyBqdXN0aWZpZWQuIFdlIHdpbGwg YWRkIG1vcmUgZGV0YWlscyBvbiB0aGUgcG90ZW50aWFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdW5p Y2FzdCBhbmQgbXVsdGljYXN0IGZhc3QgcGF0aHMgaW4gdGhlIG5leHQgdXBkYXRlLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYXJlIG9wZW4gdG8gdGhlIGRpc2N1c3Npb24g YW5kIGFsd2F5cyB3ZWxjb21lIGNvbW1lbnRzIGFuZCBhbHRlcm5hdGl2ZSBwcm9wb3NhbHMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXByaWwgMDcsIDIwMTYgNzozOSBQTTxicj4NCjxiPlRvOjwvYj4gTWFjaCBDaGVuPGJyPg0K PGI+Q2M6PC9iPiBHcmVnb3J5IE1pcnNreTsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9v bHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0i bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzLWNoYWly c0BpZXRmLm9yZzwvYT47IEFsaWEgQXRsYXMgKDxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFrYXRsYXNAZ21haWwuY29tPC9hPik8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGggbXVsdGljYXN0IGRhdGFwYXRoIChl c3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVudCBmcm9tIHRoZSB1bmljYXN0IGRh dGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBsb2NhbCBtdWx0aWNhc3QgSVAgYWRk cmVzc2VzIG1heSBub3QNCiBuZWNlc3NhcmlseSBndWFyYW50ZWUgVW5pY2FzdCBJUCByZWFjaGFi aWxpdHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2hlbiB3cml0aW5nIDcxMzAgd2Ugc3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1 cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBt aWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBsb2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBs b3Qgc2ltcGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFuZCB0aGlzIGlzIHdoZXJlIGkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9z YWwgaXMgZmxhd2VkIC0tIHRoZXkgdXNlIGxpbmsgbG9jYWwgbXVsdGljYXN0IHRvIGVuc3VyZSBJ UCB1bmljYXN0IHJlYWNoYWJpbGl0eSB3aGljaCBpcyBpbmNvcnJlY3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsIE1hbmF2 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUaHUsIEFwciA3LCAyMDE2IGF0IDExOjE2IFBNLCBNYWNoIENoZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hY2guY2hlbkBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVnIGFuZCBhbGws PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZpZXcgb24gdGhl IGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1 c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmljYXN0IGFkZHJl c3Mgd2hlbiZuYnNwOyZuYnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExBRyBsaW5rcy4g QW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQt aW50ZXJmYWNlLTAwPC9hPiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQg YXQmbmJzcDt0aGF0IHRpbWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRpZCBkaXNjdXNz Jm5ic3A7dGhlIGlkZWEgb2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3MsIGJ1 dCBmb3Igc29tZSByZWFzb24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVpdGVyYXRlIHRo ZQ0KIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFiYW5kb25lZCwg YWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBh IHNtYXJ0IGlkZWEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPk1hY2gmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0 bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBHcmVnb3J5IE1pcnNreSBbPGEgaHJlZj0i bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFw cmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGctYmZk QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwvYT47DQo8YSBocmVm PSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1y dGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0 Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkLWNoYWlyc0Bp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBBbGlhIEF0bGFzICg8YSBocmVm PSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWls LmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0p QkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+RGVhciBBbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnR3byBuZXcgZHJh ZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRp bmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5 bWJvbDtjb2xvcjpibGFjayI+wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRh cmdldD0iX2JsYW5rIj5CRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s O2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJn ZXQ9Il9ibGFuayI+QkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0 ZSB5b3VyIHJldmlld3MsIGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVp biI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF11221A40773eusaamb103erics_-- From nobody Fri Apr 8 09:14:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658312D5A5; Fri, 8 Apr 2016 09:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1Xb4mYfwh6Z; Fri, 8 Apr 2016 09:14:15 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351BE12D098; Fri, 8 Apr 2016 09:14:15 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-21-5707d8afc1c3 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 0F.B7.22441.FA8D7075; Fri, 8 Apr 2016 18:13:36 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Fri, 8 Apr 2016 12:14:13 -0400 From: Gregory Mirsky To: "Reshad Rahman (rrahman)" , Manav Bhatia Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4A== Date: Fri, 8 Apr 2016 16:14:13 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyuXRPoO6GG+zhBp2POCw+PbzEbHFg00FG i8uT2tgt1l0+xWZxa+lKVotrK1rZLZbcvsdu8fnPNkYHDo8pvzeyeuycdZfdY8mSn0weXy5/ ZgtgieKySUnNySxLLdK3S+DKeLrkP0vB0heMFRf/mTUwrrzI2MXIySEhYCKx+O1xZghbTOLC vfVsXYxcHEICRxkl+v/8ZodwljFKtHZ1gFWxCRhJvNjYww5iiwhESuxtOwPWwSxwkUni057D bCAJYQFHie/zrzFDFDlJfLiymBXCDpNYuGYO2GoWARWJizMegdXzCvhKPJp/gAli20Rmiebp O8EaOAUMJBrnvAezGYHu+35qDROIzSwgLnHryXwmiLsFJJbsOQ/1g6jEy8f/WCFsJYmPv+ez Q9TnSzybupAdYpmgxMmZT1gmMIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZ fAEj+ypGjtLigpzcdCPDTYzAaD0mwea4g3Fvr+chRgEORiUe3gUC7OFCrIllxZW5hxglOJiV RHhZrgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnNTk0tSC2CyTJxcEo1MDZ+ dPjQuF80bv/OVP0Q/wodBtOwwyKygZ8XqgTNX/V6ct3n+qlTz0nF/jJ71vzx+Vp3RefyyOd3 8q/zqUXPydKtXb6uInHjkue/d7vL86yNuPtk/9ktGpWeS1qWt72b4KlsMakh35Xvr7IA6+ZM Q/7oH96KZyt82Nazhwfl14apt/TJv780T4mlOCPRUIu5qDgRAFRVLPbSAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:14:18 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for your comments. Indeed, RFC 7130 is restricted and thus hardly= applicable to MC-LAG case. We realize that if this proposal is adopted it = not only enhance applicability on u-BFD but will update RFC 7130. Regards, Greg From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] Sent: Friday, April 08, 2016 8:51 AM To: Manav Bhatia; Gregory Mirsky Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; mpls-ch= airs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg-bfd-ch= airs@ietf.org Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I agree with Manav, and nothing in RFC7130 seems to preclude using differen= t unicast IP address as destination on different member links. Regards, Reshad (as individual contributor). From: Rtg-bfd > o= n behalf of Manav Bhatia > Date: Friday, April 8, 2016 at 11:04 AM To: Gregory Mirsky > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you've pointed too is justified. We wil= l add more details on the potential differences between unicast and multica= st fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: * BFD on MC-LAG interfaces in IP network * BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Reshad,

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.=

 <= /p>

    &= nbsp;            &nb= sp;            =   Greg

 <= /p>

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; = mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg= -bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

 

Regards,<= /p>

Reshad (as individual contr= ibutor).

 

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Manav Bhatia= <manavbhatia@gmail.com>=
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" <draft-tanmir= -rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia A= tlas (akatlas@gmail.com)" <= ;akatlas@gmail.com>, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <<= a href=3D"mailto:rtg-bfd-chairs@ietf.org">rtg-bfd-chairs@ietf.org> Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg,

 

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

 

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

 

Cheers, Manav

 

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:<= /p>

Hi Manav,

thank you for sharing insight view of d= iscussions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RF= C 7130 too, that MC-LAG presents different case and the compromise that you’ve pointed too is justified. We will add more details on th= e potential differences between unicast and multicast fast paths in the nex= t update.

We are open to the discussion and alway= s welcome comments and alternative proposals.

 

      &nb= sp;         Regards,

      &nb= sp;            =              Gr= eg

 

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I believe it had to do with multicast = datapath (especially link local) being different from the unicast datapath = in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability. <= o:p>

 

When writing 7130 we spent quite a bit= of time ensuring that we dont carve out a special data path for the micro-= BFD packets. Using link local would have made it a lot simpler.

 

And this is where i think the current = proposal is flawed -- they use link local multicast to ensure IP unicast re= achability which is incorrect.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach = Chen <mach.che= n@huawei.com> wrote:

Hi Greg and all,=

 

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach <= /o:p>

From: Rtg-= bfd [rtg-bfd-= bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related to RFC 7130, w= ere published before the meeting:

· &n= bsp;       BFD on MC-LAG interfaces= in IP network

· &n= bsp;       BFD on MC-LAG interfac= es in IP/MPLS network

 

Greatly appreciate your reviews, comme= nts, questions and suggestions.

 

Regards,

        Greg=

 

 

--_000_7347100B5761DC41A166AC17F22DF11221A40798eusaamb103erics_-- From nobody Fri Apr 8 09:28:37 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206B512D5B4; Fri, 8 Apr 2016 09:28:33 -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 wgBtdzdPdm8h; Fri, 8 Apr 2016 09:28:30 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2840612D57E; Fri, 8 Apr 2016 09:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26352; q=dns/txt; s=iport; t=1460132910; x=1461342510; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SjgPaxJ8j5MiDVEHbQ7RpIsthtY+Wp/a+WmSourG4ig=; b=MqBOkhC3LkM+uN8N1bBVlHvW5+U8aiFW2iw5JUWMistUrZJlmW1XaD4/ +JSuBfPYWBfbuh0JQymmVWOJtkNwsEfV5670yq9kBXfOE7BjnSxI2Dn6l cRNWKKGKzcgeoRrbIphHzDNLS85Cj5aaG0pdLLTnrq4bH47wwmnHSBtTv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgBw2wdX/4YNJK1cgmtMU30GrmeLW?= =?us-ascii?q?AENgXMhhWwCgTM4FAEBAQEBAQFlJ4RBAQEBBC1MEAIBCBEDAQEBGgIFBwchERQ?= =?us-ascii?q?JCAIEAQ0FH4dzAxIOuz0NhSEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuCQ?= =?us-ascii?q?YIeDQknAoR3BZMZhDoxAYV2hiCBdYFnjSaGH4Erh1oBHgEBQoIEGYFKbFqHJD0?= =?us-ascii?q?BfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208,217";a="257609769" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 16:28:28 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u38GSStK022743 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 16:28:28 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 11:28:27 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 11:28:27 -0500 From: "Reshad Rahman (rrahman)" To: Gregory Mirsky , Manav Bhatia Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZAB2XmwAAFPl8AAAFFQWAAAJbzID//8FyAA== Date: Fri, 8 Apr 2016 16:28:27 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.167] Content-Type: multipart/alternative; boundary="_000_D32D53C813B077rrahmanciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:28:33 -0000 --_000_D32D53C813B077rrahmanciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg, With the proposal in the draft won=92t you need a change to indicate that t= he link-local multicast address should be used? Regards, Reshad. From: Rtg-bfd > o= n behalf of Gregory Mirsky > Date: Friday, April 8, 2016 at 12:12 PM To: Manav Bhatia > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" >, "mpls@ie= tf.org" >, "mpls-= chairs@ietf.org" >, "Alia Atlas (akatlas@gmail.com)" >, "rtg-bfd@ietf.org" >, "rtg-b= fd-chairs@ietf.org" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Manav, thank you for your consideration. The advantage of the MC-LAG is that there= =92s nothing changes for SE which still sees it LAG. If one to use differen= t destination IP addresses on SE side, then that advantage will be lost. Ou= r proposal is to preserve it. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Friday, April 08, 2016 8:05 AM To: Gregory Mirsky Cc: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces Hi Greg, Why cant different micro-BFD packets use the IP address of the MC-LAG end p= oints? Ones going to router 1 will all carry the same unicast IP address. T= he ones going towards the other router will all carry some other IP address= , which would be configured along with the MC-LAG configs. In fact i would argue that the u-bfd packets going to different routers mus= t use different IP addresses so that you can actually verify the data plane= liveliness. Whats the point in sending a contrived IP address if the path = that it takes is different from the other regular packets? Cheers, Manav On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky > wrote: Hi Manav, thank you for sharing insight view of discussions around RFC 7130, extremel= y helpful. We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents dif= ferent case and the compromise that you=92ve pointed too is justified. We w= ill add more details on the potential differences between unicast and multi= cast fast paths in the next update. We are open to the discussion and always welcome comments and alternative p= roposals. Regards, Greg From: Manav Bhatia [mailto:manavbhatia@gmail.com] Sent: Thursday, April 07, 2016 7:39 PM To: Mach Chen Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.or= g; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.= org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces I believe it had to do with multicast datapath (especially link local) bein= g different from the unicast datapath in most routers. Using link local mul= ticast IP addresses may not necessarily guarantee Unicast IP reachability. When writing 7130 we spent quite a bit of time ensuring that we dont carve = out a special data path for the micro-BFD packets. Using link local would h= ave made it a lot simpler. And this is where i think the current proposal is flawed -- they use link l= ocal multicast to ensure IP unicast reachability which is incorrect. Cheers, Manav On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen > wrote: Hi Greg and all, I just have quick review on the drafts. If my understanding is correct, the= idea is to use multicast destination address other than unicast address wh= en sending BFD packets over LAG links. And actually this idea has been pro= posed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did discu= ss the idea of using multicast destination address, but for some reason I f= orget now(I may need to reiterate the discussions on the archive), the idea= was abandoned, although I still think multicast destination address is a s= mart idea. Best regards, Mach ________________________________ From: Rtg-bfd [rtg-bfd-bounces@ietf.org] o= n behalf of Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Tuesday, April 05, 2016 6:16 To: rtg-bfd@ietf.org; mpls@ietf.org Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atl= as (akatlas@gmail.com) Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces Dear All, two new drafts, related to RFC 7130, were published before the meeting: =B7 BFD on MC-LAG interfaces in IP network =B7 BFD on MC-LAG interfaces in IP/MPLS network Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --_000_D32D53C813B077rrahmanciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7421AA362D82434C88260D7BD7EAE4EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Greg,

With the proposal in the draft won=92t you need a change to indicate t= hat the link-local multicast address should be used?

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Gr= egory Mirsky <gregory.mir= sky@ericsson.com>
Date: Friday, April 8, 2016 at 12:1= 2 PM
To: Manav Bhatia <manavbhatia@gmail.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@= tools.ietf.org" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>= ;, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com>, "= rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: RE: Two new drafts on (mic= ro-)BFD over MC-LAG interfaces

Hi Manav,

thank you for your consideration. T= he advantage of the MC-LAG is that there=92s nothing changes for SE which s= till sees it LAG. If one to use different destination IP addresses on SE side, then that advantage will be lost. Our= proposal is to preserve it.

 

      = ;          Regards,=

      = ;            &n= bsp;            = ; Greg

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; rtg-bfd@ietf.org<= /a>; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-c= hairs@ietf.org; Alia Atlas (akatla= s@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Hi Greg,

 

Why cant different micro-BFD packets use the IP addr= ess of the MC-LAG end points? Ones going to router 1 will all carry the sam= e unicast IP address. The ones going towards the other router will all carr= y some other IP address, which would be configured along with the MC-LAG configs.

 

In fact i would argue that the u-bfd packets going t= o different routers must use different IP addresses so that you can actuall= y verify the data plane liveliness. Whats the point in sending a contrived = IP address if the path that it takes is different from the other regular packets?

 

Cheers, Manav

 

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view of discussions= around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RFC 7130 too= , that MC-LAG presents different case and the compromise that you=92ve pointed too is justified. We will add mor= e details on the potential differences between unicast and multicast fast p= aths in the next update.

We are open to the discussion and always welcome = comments and alternative proposals.

 

        &= nbsp;       Regards,

        &= nbsp;           &nbs= p;           Greg<= o:p>

 

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

I believe it had to do with multicast datapath (especially link lo= cal) being different from the unicast datapath in most routers. Using link = local multicast IP addresses may not necessarily guarantee Unicast IP reachability. 

 

When writing 7130 we spent quite a bit of time ensuring that we do= nt carve out a special data path for the micro-BFD packets. Using link loca= l would have made it a lot simpler.

 

And this is where i think the current proposal is flawed -- they u= se link local multicast to ensure IP unicast reachability which is incorrec= t.

 

Cheers, Manav

 

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:<= o:p>

Hi Greg and all,

 

I just have quick review on the drafts. If my understanding is corr= ect, the idea is to use multicast destination address other than unicast ad= dress when  sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the prede= cessor of RFC 7130). And at that time, the co-authors of RFC 7130 did = discuss the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

 

Best regards,

Mach 

From: Rtg-bfd [rtg-bfd-bou= nces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,

two new drafts, related to RFC 7130, w= ere published before the meeting:

=B7         BFD on MC-LAG interfa= ces in IP network

=B7         BFD on MC-LAG inter= faces in IP/MPLS network

 

Greatly appreciate your reviews, comme= nts, questions and suggestions.

 

Regards,

        Greg=

 

 

 --_000_D32D53C813B077rrahmanciscocom_-- From nobody Fri Apr 8 10:34:04 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB712D0E4; Fri, 8 Apr 2016 10:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzaRjKgBHtih; Fri, 8 Apr 2016 10:34:01 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 30A1312D6AD; Fri, 8 Apr 2016 10:34:00 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id o66so51576597ywc.3; Fri, 08 Apr 2016 10:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OciFEvJ+Pi1mb8m8lYvr4NMZKTIi7ti/Tj9W+3Lu40U=; b=Vvre+dhbLpB8dzDKymkPzL0+yVwHhenTejqmWmfruYU1rs8PABvUhCPwRbcd95wu0f yfG8zAU4up3gS4bde/aJ31o5bRcPRBvCmX/5gqaPuk0U6hLjAKB3QhR1u02zrLoYgq6E hRATfjb4hpxpp53veLvcWu/Gc8MQrAEKpTv1v+W2aEtwXCpkHlBwWPrRW+WJOGV1v7gV ZlxwkQAt8LmJBevDcg2j31vujHw6UnkNs7dQWZjL8k93Dcl9nvvlPijpH2fOFltJu/9j r5R26KDCZyl2Mbk5eosqYM7/6tiM+VvctoF4jM329ZKgm5BjrohWD+b5g9A1ClgfuD12 jfIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OciFEvJ+Pi1mb8m8lYvr4NMZKTIi7ti/Tj9W+3Lu40U=; b=Bqq2dxGXZo982Z1IkeDoPU5PT0NYzfU4312hk4mRsCgJqLYFKksk8yg8rkYnMqjb4d XKGkQDmjRpPsRe5Zne117ELnZKQVNUVMx1vZUwRUD4GbJ3m5XMHoRkHSxzaDfYiwA6s2 Qv61k3buLifs9ozevl7zZ+4tg0qm3g9onyVW82pHZHSa18FyrSCLjtz3t5wHjt2w+smn bSWCrQ7lykcoqDnvtTRM7nmZBztfr+HBWzdqMMHFlFfsZiWh7JBf6S6qCU87RDhZbrLH wU4XNF5/vQZ6k+arx+Vnvcep7ByzAkfum90Rq0ehNvFJZFnPCRmxYhoXTIEaIt8w2XI7 dmCA== X-Gm-Message-State: AD7BkJKibIlXyjdAbN2IY9aMCBk0NNZ0NPHvnSQrqWJrBjUsNkgGbeWDstXOxRPHysZ3cr9suZArxfCTpHvUkg== MIME-Version: 1.0 X-Received: by 10.129.77.65 with SMTP id a62mr5067252ywb.87.1460136839397; Fri, 08 Apr 2016 10:33:59 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 10:33:59 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 23:03:59 +0530 Message-ID: From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a1140b7daa2c76a052ffc99c3 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:34:03 -0000 --001a1140b7daa2c76a052ffc99c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, Not sure i understand how it can "update RFC 7130". Is that by using a link local mcast IP instead of a Unicast IP? We know that, that wouldnt work. Cheers, Manav On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky wrote: > Hi Reshad, > > thank you for your comments. Indeed, RFC 7130 is restricted and thus > hardly applicable to MC-LAG case. We realize that if this proposal is > adopted it not only enhance applicability on u-BFD but will update RFC 71= 30. > > > > Regards, > > Greg > > > > *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] > *Sent:* Friday, April 08, 2016 8:51 AM > *To:* Manav Bhatia; Gregory Mirsky > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; > rtg-bfd-chairs@ietf.org > > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I agree with Manav, and nothing in RFC7130 seems to preclude using > different unicast IP address as destination on different member links. > > > > Regards, > > Reshad (as individual contributor). > > > > *From: *Rtg-bfd on behalf of Manav Bhatia < > manavbhatia@gmail.com> > *Date: *Friday, April 8, 2016 at 11:04 AM > *To: *Gregory Mirsky > *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < > mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia > Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" > *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Hi Greg, > > > > Why cant different micro-BFD packets use the IP address of the MC-LAG end > points? Ones going to router 1 will all carry the same unicast IP address= . > The ones going towards the other router will all carry some other IP > address, which would be configured along with the MC-LAG configs. > > > > In fact i would argue that the u-bfd packets going to different routers > must use different IP addresses so that you can actually verify the data > plane liveliness. Whats the point in sending a contrived IP address if th= e > path that it takes is different from the other regular packets? > > > > Cheers, Manav > > > > On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > > > --001a1140b7daa2c76a052ffc99c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1140b7daa2c76a052ffc99c3-- From nobody Fri Apr 8 10:40:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552C612D95A; Fri, 8 Apr 2016 10:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mILDQc7O9gbD; Fri, 8 Apr 2016 10:40:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EAD12D55B; Fri, 8 Apr 2016 10:40: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=Q3xPUTMfKbhQrNfbU9WEYUjJ2W2Dq5xWhGyDfLDzLys=; b=Ku2MmvwT8Rm+rTOpiE8yMOZtQridmOYhTAh6LLcrIOyBgioPvlQHqfwBIKo+BvBx1g4RmoUKEhyuozZzMHIICUwAJCREzsxkJ6dq7zGIKbCw6Rao08JSmeF1agEUCENqJ3VxzrDpt6Y64Vc/jmn8JR7UXM0DdKtpsWehnojzh5s= Received: from BY2PR05MB584.namprd05.prod.outlook.com (10.141.219.153) by BY2PR05MB584.namprd05.prod.outlook.com (10.141.219.153) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 17:40:47 +0000 Received: from BY2PR05MB584.namprd05.prod.outlook.com ([10.141.219.153]) by BY2PR05MB584.namprd05.prod.outlook.com ([10.141.219.153]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 17:40:47 +0000 From: Santosh Esale To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [E] Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AQHRkQBoawA93Qr+zUa9/h13y1EDe59/3FuAgAAQiICAAAMbAP//9F+A Date: Fri, 8 Apr 2016 17:40:47 +0000 Message-ID: References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-ms-office365-filtering-correlation-id: f7db9bc6-a768-4771-bdec-08d35fd4eb60 x-microsoft-exchange-diagnostics: 1; BY2PR05MB584; 5:cKupYwGtQH3J6uknZHE9hmy5VDPUDj6F53TN5ipT3Ml7FmAtxHBRcyhhsg5QJju9/poW7Sgy/Y84XevB/06Q2D3kvMWDphRwNMFnXt0ZfUL3w0Ts5ajyV36AqhwgDxLUxwdjtGD3/wqPU0BE0iAPvg==; 24:Km5yEFznfUdQDe0dnBNPUawRBRC7ofGwjecCOJ+qliOA6LE2ZHTHy5R48aJ75+931InWoQcaR26ytcej8jLbhp3Ut/K9AAAod6bYz+dyils= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB584; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB584; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB584; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(377424004)(586003)(102836003)(3846002)(6116002)(92566002)(122556002)(2906002)(83506001)(10400500002)(230783001)(106116001)(99286002)(87936001)(2900100001)(2950100001)(66066001)(5004730100002)(77096005)(93886004)(50986999)(54356999)(81166005)(2501003)(76176999)(189998001)(5008740100001)(5001770100001)(4001350100001)(36756003)(107886002)(11100500001)(86362001)(1096002)(1220700001)(5002640100001)(164054004)(3660700001)(19580395003)(3280700002)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB584; H:BY2PR05MB584.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <362450025E5AFF45A36397321E666BEB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 17:40:47.4501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB584 Archived-At: Subject: Re: [mpls] [E] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 17:40:51 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IG90aGVyIElQUiB0aGFuIHRoZSBvbmUgdGhhdCBoYXMgYWxy ZWFkeSBiZWVuDQpkaXNjbG9zZWQuDQoNCg0KVGhhbmtzLA0KU2FudG9zaA0KT24gNC84LzE2LCA0 OjIyIEFNLCAiUmF2ZWVuZHJhIFRvcnZpIiA8cnRvcnZpQGp1bmlwZXIubmV0PiB3cm90ZToNCg0K PkkgYW0gbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIuDQo+cmVnYXJkcywNCj5SYXZpDQo+DQo+ T24gQXByIDgsIDIwMTYsIGF0IDc6MTIgQU0sIEphbGlsLCBMdWF5IDxsdWF5LmphbGlsQHZlcml6 b24uY29tPiB3cm90ZToNCj4NCj4NCj4NCj5Ob3QgYXdhcmUgb2YgYW55DQo+DQo+DQo+UmVnYXJk cywNCj5MdWF5DQo+DQo+DQo+DQo+DQo+DQo+RnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 Pg0KPkRhdGU6IEZyaWRheSwgQXByaWwgOCwgMjAxNiBhdCA3OjEyIEFNDQo+VG86ICJtcGxzQGll dGYub3JnIiA8bXBsc0BpZXRmLm9yZz4sDQo+ImRyYWZ0LWlldGYtbXBscy1hcHAtYXdhcmUtdGxk cEBpZXRmLm9yZyINCj48ZHJhZnQtaWV0Zi1tcGxzLWFwcC1hd2FyZS10bGRwQGlldGYub3JnPiwN Cj4gIm1wbHMtY2hhaXJzQGlldGYub3JnIiA8bXBscy1jaGFpcnNAaWV0Zi5vcmc+DQo+U3ViamVj dDogW0VdIENvcmVjdGlvbiAtIFttcGxzXSBJUFIgcG9sbCBvbiBkcmFmdC1pZXRmLW1wbHMtYXBw LWF3YXJlLXRsZHANCj4NCj4NCj4NCj5XRywNCj4NCj4NCj5Tb3JyeSBJIGhhZCBhIGN1dCBhbmQg cGFzdGUgZXJyb3IgaW4gdGhlIHR3byBmaXJzdCBwYXJhZ3JhcGhzIG9mIHRoaXMNCj5tYWlsLCBp dCBzaG91bGQgaGF2ZSByZWFkOg0KPg0KPg0KPiAgIFRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYt bXBscy1hcHAtYXdhcmUtdGxkcCBoYXMgdG9sZCB1cyB0aGF0DQo+ICAgdGhlIGRvY3VtZW50IGlz IHJlYWR5IGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCj4NCj4NCj4gICBXZSB3aWxsIGRv IGFuIElQUiBwb2xsIHByaW9yIHRvIHRoZSBzdGFydCBvZiB3Z2xjLg0KPg0KPg0KPkkgYXBvbG9n aXplIGZvciB0aGUgbWlzdGFrZSENCj4NCj4NCj4vTG9hDQo+DQo+DQo+DQo+DQo+DQo+DQo+T24g MjAxNi0wNC0wOCAwMzowNCwgTG9hIEFuZGVyc3NvbiB3cm90ZToNCj4+V29ya2luZyBHcm91cCwN Cj4+DQo+Pg0KPj5UaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtYXBwLWF3YXJlLXRsZHAg aGFzIHRvbGQgdXMgdGhhdA0KPj50aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJl ZCBmb3Igd29ya2luZyBhZG9wdGlvbi4NCj4+DQo+Pg0KPj5UaGUgZG9jdW1lbnQgYmVlbiB0aHJv dWdoIE1QTFMtUlQgcmV2aWV3LiBXZSB3aWxsIGRvIGFuIElQUiBwb2xsDQo+PnByaW9yIHRvIHRo ZSBzdGFydCBvZiB0aGUgYWRvcHRpb24gcG9sbC4NCj4+DQo+Pg0KPj5UaGlzIG1haWwgc3RhcnRz IHRoZSBJUFIgcG9sbC4NCj4+DQo+Pg0KPj5BcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBh cHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1hcHAtYXdhcmUtdGxkcD8NCj4+DQo+Pg0KPj5JZiBz bywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcw0KPj4oc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS4NCj4+DQo+Pg0KPj5UaGVyZSBpcyBvbmUgSVBSIGRpc2Nsb3N1cmUgZmlsZWQgZGly ZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPj4NCj4+DQo+PklmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQo+ PnRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudA0KPj5JUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0 aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuKiBUaGUNCj4+ZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5j ZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuDQo+PnJlY2VpdmVk IGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KPj4NCj4+DQo+PklmIHlvdSBhcmUg b24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9y IG9yDQo+PmNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp ZiB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPj5JUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Ns b3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4v TG9hDQo+Pm1wbHMgd2cgY28tY2hhaXINCj4NCj4NCj4NCj4NCj4NCj4NCj4NCg0K From nobody Fri Apr 8 11:25:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBB12D1B6; Fri, 8 Apr 2016 11:25:04 -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 7JRy2AazpRaQ; Fri, 8 Apr 2016 11:25:01 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D52312D0DA; Fri, 8 Apr 2016 11:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18279; q=dns/txt; s=iport; t=1460139901; x=1461349501; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1cyZjRKPxzXh4QWLnZWQrpumAGulu07/L3skIFOKguI=; b=cuZOldjV7wqbqUQ0EBXEbyNN4JtYZxbdx+5RWVVo93xlyBcK8RjEGaqf I9nsFGOMns0ONxR7pyw5baD1Dyln+rOEJnTEohpVmUff2AKLWjB5ljOnI gwNg75ugS7qi7NLiDR2z4RWUjKD+vy1fdVn+LTliK8XEDYO3vcFrwRW+k 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgAp9gdX/4wNJK1cgmtMU30GrmeGZ?= =?us-ascii?q?YRzDoFzFwEJhWwCgTM4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgSwsFCwIBBgISBic?= =?us-ascii?q?DAgIhBgsUAw4CBA4FCQWIBAMKCA6RWp0XjEINhSEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQENCIYhgXUIgk6CQYIFJgmCSiuCKwWTGYQ6MQGDI4FmbYJygy6BdYFnhE2?= =?us-ascii?q?IWYdKh1oBHgFDg2dsiDt+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="asc'?scan'208,217";a="259203294" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 18:24:59 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38IOxr1010852 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 18:24:59 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 14:24:58 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 14:24:58 -0400 From: "Carlos Pignataro (cpignata)" To: Xiaohu Xu Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A Date: Fri, 8 Apr 2016 18:24:58 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.9] Content-Type: multipart/signed; boundary="Apple-Mail=_96308AB7-A1EC-47DF-AA5E-35FBEE6ACEE6"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:25:04 -0000 --Apple-Mail=_96308AB7-A1EC-47DF-AA5E-35FBEE6ACEE6 Content-Type: multipart/alternative; boundary="Apple-Mail=_BB41A064-4BB5-4219-94E9-B998B9A81CC1" --Apple-Mail=_BB41A064-4BB5-4219-94E9-B998B9A81CC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Xiaohu, Tony, Please see inline. > On Apr 7, 2016, at 2:39 PM, Xuxiaohu wrote: >=20 > As for the first nibble issue, will it violate the layering principle = of network protocol stacks if the first nibble of any new encapsulation = header (which could be an MPLS payload) is used as the "MPLS payload = type" field? Reading draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirst = nibble=E2=80=9D is _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. = Instead, the text describes an anti-aliasing mechanism, much like RFC = 4928. The relevant text is: First nibble: The first 4 bits of the header are set to 0101; this ensures that the BIER header will not be confused with an IP header or with the header of a pseudowire packet. Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6" > wouldn't it be more reasonable and sustainable to fix the problem = (i.e., the lack of a protocol field in the MPLS header) by the MPLS = header itself? >=20 Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80=9D = needed. > By the way, since it's claimed that the NSH is transport-independant, = it means the NSH should be able to be transported over MPLS. However, it = seems that the first nibble issue has not be considered in the current = NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be = mis-interpreted as IP header. >=20 >=20 There seems to be some massive confusion on this paragraph, on a number = of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D = transport-independent. It is by charter and by design. Second, the NSH = draft does not even include the term =E2=80=9CMPLS=E2=80=9D, because it = does not define transports. The SFC Encapsulation can be used in a = transport-agnostic way. One more comment below. > Best regards, > Xiaohu >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: BIER [bier-bounces@ietf.org = ] =E4=BB=A3=E8=A1=A8 Tony Przygienda = [tonysietf@gmail.com ] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B44=E6=9C=885=E6=97=A5 = 22:36 > =E6=94=B6=E4=BB=B6=E4=BA=BA: bier@ietf.org > =E4=B8=BB=E9=A2=98: [Bier] comments on draft-wang-bier-ethernet-01 >=20 > after reading >=20 > a) first nibble: refer to MPLS encaps as "the same value" to keep in = sync One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text at = draft-ietf-bier-mpls-encapsulation-03 Since the function of the first nibble is to prevent aliasing with an IP = packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the = First Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions = of 0 and 1, referencing that RFC (see = https://tools.ietf.org/html/rfc4928#section-5). Is the intent to re-assign IPv5 at = http://www.iana.org/assignments/version-numbers/ = ? Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at: It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. Thanks, =E2=80=94 Carlos. > b) refer to all other possible fields to MPLS encaps to keep in sync = when describing instead of repeating > c) you need to describe which kind of ether MACs are allowed, = especially on broadcast media, i.e. is it always p2p or can you take = advantage of the broadcast ? > d) Figure 4: use the architecture/MPLS encoding for the length, don't = invent a new one > e) who will obtain a new ether type from IEEE? As far I understand, = not a trivial process albeit we have several liaisons with IEEE >=20 > -- > We=E2=80=99ve heard that a million monkeys at a million keyboards = could produce the complete works of Shakespeare; now, thanks to the = Internet, we know that is not true. > =E2=80=95Robert Wilensky > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls = --Apple-Mail=_BB41A064-4BB5-4219-94E9-B998B9A81CC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Xiaohu, Tony,

Please see inline.

On = Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com>= wrote:

As for the = first nibble issue, will it violate the layering principle of network = protocol stacks if the first nibble of any new encapsulation header = (which could be an MPLS payload) is used as the "MPLS payload type" = field?

Reading draft-wang-bier-ethernet-01, Section = 3, the =E2=80=9Cfirst nibble=E2=80=9D is _not_ used as an =E2=80=9CMPLS = payload type=E2=80=9D. Instead, the text describes an anti-aliasing = mechanism, much like RFC 4928. 

The relevant text is:
     First nibble: The first 4 bits of the = header are set to 0101; this
   ensures = that the BIER header will not be confused with an IP header
   or with the header of a pseudowire = packet.

Which = says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6"
wouldn't = it  be more reasonable and sustainable to fix the problem = (i.e., the lack of a protocol field in the MPLS header) by the MPLS = header itself?

 


Who says it is a *problem*? There=E2=80=99s no = =E2=80=9Cfixing=E2=80=9D needed.

By the way, = since it's claimed that the NSH is transport-independant, it means the = NSH should be able to be transported over MPLS. However, it seems that = the first nibble issue has not be considered in the current NSH = draft. As a result, when encapsulating NSH over MPLS, the NSH may be = mis-interpreted as IP header.

 



There seems to be some massive confusion on this = paragraph, on a number of levels. First, NSH is not =E2=80=9Cclaimed to = be=E2=80=9D transport-independent. It is by charter and by design. = Second, the NSH draft does not even include the term =E2=80=9CMPLS=E2=80=9D= , because it does not define transports. The SFC Encapsulation can be = used in a transport-agnostic way.

One = more comment below.

Best regards,
Xiaohu

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: BIER [bier-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Tony Przygienda = [tonysietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2016=E5=B9=B44=E6=9C=885=E6=97= =A5 22:36
=E6=94=B6=E4=BB=B6=E4=BA=BA: bier@ietf.org
=E4=B8=BB=E9=A2=98: [Bier] comments on = draft-wang-bier-ethernet-01

after = reading 

a) = first nibble: refer to MPLS encaps as "the same value" to keep in = sync 

One comment regarding the =E2=80=9CFirst nibble=E2=80= =9D text at draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to = prevent aliasing with an IP packet, in order for RFC 4928 to specify = values of 0x0 and 0x1 for the First Nibble, it had to =E2=80=9CReserve=E2=80= =9D IP protocol versions of 0 and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).
<= br class=3D"">
Is the intent to re-assign IPv5 at http://www.iana.org/assignments/version-numbers/ ?

Note that RFC 4928 says =E2=80=9CREQUIRED= =E2=80=9D at:

  =  It is REQUIRED, however, that applications depend upon = in-order
   packet delivery restrict the = first nibble values to 0x0 and 0x1.

Thanks,

=E2=80=94 Carlos.


b) refer to all = other possible fields to MPLS encaps to keep in sync when describing = instead of repeating 
c) you need to describe = which kind of ether MACs are allowed, especially on broadcast media, = i.e. is it always p2p or can you take advantage of the broadcast = ?
d) Figure 4: use the architecture/MPLS encoding = for the length, don't invent a new one 
e) who = will obtain a new ether type from IEEE? As far I understand, not a = trivial process albeit we have several liaisons with = IEEE 

-- 
We=E2=80=99ve heard = that a million monkeys at a million keyboards could produce the complete = works of Shakespeare; now, thanks to the Internet, we know that is not = true.
=E2=80=95Robert Wilensky
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Hi Greg,

Not sure i understand how it c= an "update RFC 7130". Is that by using a link local mcast IP inst= ead of a Unicast IP?

We know that, that wouldnt wo= rk.

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory= Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



= --Apple-Mail=_BB41A064-4BB5-4219-94E9-B998B9A81CC1-- --Apple-Mail=_96308AB7-A1EC-47DF-AA5E-35FBEE6ACEE6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXB/d6AAoJEIXgpQGOZny9IV4P/RByfQzOLl1CoNvhHx3Dx3Gn tmK1VJHhcJLQSQFlUxI6jsbyNpNmRexC1KnBm3/DUpGU/IaB5S0pmPqjaYqgMCYz 43dhDOpH/fornQ+Ndl0MbNI7Xcljj6O2Lulu0/FEaSd5Nvw5hQD6r/ZevRq0xSnM dyz8f39GkCsUOhyXWTgNU4w562k0gAfIfiN1U7V1oLOUBNHjvoPpRrq3FHC3MKxn g8zpHz/VMRUbFmmqrGrdcxaxEdUBOgCI2V7QZ9GX/UttrSzo+t5VgAnCJH7REmh+ WfyroOoFdEQLGgX8hlIBFy4+uOWCB4GQF9OiBt/TNKQAsQldNqVKenah31+ktBs+ RuLt5PWGwAiImbmyduW6sixG9+V4pz5Y19oC+T8ULMyAuY370k0cq7NavqJGTAAR Bm6zWVXxs3YwEXgVwmegWJyHYTt+rscQCTlOB0acVakM1rhcJGto997PK26kqSWY Lh3e/n8JLZkh53FCSorRSrBshM3Fj62vRWUvb1mrJEooMZ0fJCjIP5ejTUOA95VP CQ0++aNs3Xh7KbzfIApQjl/UE3pwri/NteNNfzEiNq550hs7E+xf6VzENSYwrb0I XZMSGPtblPS+ncAN2FjZZ4tfTZwBI1CVtvGjwJVwj2NHIQdxmQwhWgDHREUylNb5 1hl96qmJ4kXvyoNslX6m =H9Kq -----END PGP SIGNATURE----- --Apple-Mail=_96308AB7-A1EC-47DF-AA5E-35FBEE6ACEE6-- From nobody Fri Apr 8 11:43:24 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C3612D53A; Fri, 8 Apr 2016 11:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stlYrNalqw6h; Fri, 8 Apr 2016 11:43:20 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 D497C12D510; Fri, 8 Apr 2016 11:43:19 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so144987462ywa.0; Fri, 08 Apr 2016 11:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=JJGIyoJmaTvuW9lVhEbNrC+loMdeYxwsqr31FFyXnyar5oXMEK33ow9qctoHbr2Cd/ STyN11chwfU5LtCsapFOoojjqeoGZN5E/pTcemrvd1XO52duA4Q49+TA1zMPKxQ9PtWZ l1nkKmdrzIYLG+OxEXl7ZzwrllzMJx/T9tnSG76IqyXaQzHCN2gQyrh0goJO1L3jt8zI HLiq2VllX8SNpgA02//XPtdnPFS7/NPagh4IOQbiPsc1YP6I9mNkE4dflW0vAI3/G02q F1O+YdVtFAHREVYt7fR/OqEHd8ZP+3R0i8JotbC4yLvRhAN8RSrYtOkLV+xc6729BxMe kV2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BuUKHdXn2DaCPugCE0YhFDsx1ATdIuhVIP/f39XEcgk=; b=DpLyRbQf6PE4eDGV4sY2VAZHSCX7VGLKe3Nk6n1DWXiF/8VbMwUd/5bnkHY/kwJbRG 4ceJI3BOH0mibPmAdlNfZ2/Z1aomiakVqm24IXcGXOR+U/GHuLqYW4NjSRmnGxYZzH2G cn3KDo8AjdEXqC5NWy+favhWTbcaLdxGLQevV2zp88xI6uzqcpjxfJZwr8OH5FAy7ncT XeJQcBwOLVpbu+y3flLsOFlxteIHPeNeErpPHBAVTXf9aszmQ6cJf2dIUASTqlpS6lDm Sq6j+v2aZbRPr3ufHZ8qSvnjLAI1GVP1joFx2gDi1D6vCmP2EhmGulOFINhL2bfzr1tM xjWg== X-Gm-Message-State: AD7BkJLpHe0KHKeErdQP2f5XmUj8Kdg4EpqEbP+BmATwzbn1zYH13COY4lRtJ1oet4Id+i+BUDO/uxFdv13RBA== MIME-Version: 1.0 X-Received: by 10.129.159.194 with SMTP id w185mr5711357ywg.297.1460140998984; Fri, 08 Apr 2016 11:43:18 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 11:43:18 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 11:43:18 -0700 Message-ID: From: Greg Mirsky To: "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary=94eb2c0c0126910dbd052ffd91e1 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , Manav Bhatia , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 18:43:23 -0000 --94eb2c0c0126910dbd052ffd91e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Reshad, yes, link local multicast may be used in MC-LAG scenario. The draft states that it MAY be used while the broadcast has SHOULD normative. But we are all open to the discussion. Regards, Greg On Apr 8, 2016 11:28 AM, "Reshad Rahman (rrahman)" wrote: > Hi Greg, > > With the proposal in the draft won=E2=80=99t you need a change to indicat= e that > the link-local multicast address should be used? > > Regards, > Reshad. > > From: Rtg-bfd on behalf of Gregory Mirsky < > gregory.mirsky@ericsson.com> > Date: Friday, April 8, 2016 at 12:12 PM > To: Manav Bhatia > Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < > mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia > Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" > Subject: RE: Two new drafts on (micro-)BFD over MC-LAG interfaces > > Hi Manav, > > thank you for your consideration. The advantage of the MC-LAG is that > there=E2=80=99s nothing changes for SE which still sees it LAG. If one to= use > different destination IP addresses on SE side, then that advantage will b= e > lost. Our proposal is to preserve it. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com ] > > *Sent:* Friday, April 08, 2016 8:05 AM > *To:* Gregory Mirsky > *Cc:* Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Hi Greg, > > > > Why cant different micro-BFD packets use the IP address of the MC-LAG end > points? Ones going to router 1 will all carry the same unicast IP address= . > The ones going towards the other router will all carry some other IP > address, which would be configured along with the MC-LAG configs. > > > > In fact i would argue that the u-bfd packets going to different routers > must use different IP addresses so that you can actually verify the data > plane liveliness. Whats the point in sending a contrived IP address if th= e > path that it takes is different from the other regular packets? > > > > Cheers, Manav > > > > On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > > Hi Manav, > > thank you for sharing insight view of discussions around RFC 7130, > extremely helpful. > > We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents > different case and the compromise that you=E2=80=99ve pointed too is just= ified. We > will add more details on the potential differences between unicast and > multicast fast paths in the next update. > > We are open to the discussion and always welcome comments and alternative > proposals. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Thursday, April 07, 2016 7:39 PM > *To:* Mach Chen > *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) > *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > I believe it had to do with multicast datapath (especially link local) > being different from the unicast datapath in most routers. Using link loc= al > multicast IP addresses may not necessarily guarantee Unicast IP > reachability. > > > > When writing 7130 we spent quite a bit of time ensuring that we dont carv= e > out a special data path for the micro-BFD packets. Using link local would > have made it a lot simpler. > > > > And this is where i think the current proposal is flawed -- they use link > local multicast to ensure IP unicast reachability which is incorrect. > > > > Cheers, Manav > > > > On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: > > Hi Greg and all, > > > > I just have quick review on the drafts. If my understanding is correct, > the idea is to use multicast destination address other than unicast addre= ss > when sending BFD packets over LAG links. And actually this idea has been > proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the > predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 di= d > discuss the idea of using multicast destination address, but for some > reason I forget now(I may need to reiterate the discussions on the > archive), the idea was abandoned, although I still think multicast > destination address is a smart idea. > > > > Best regards, > > Mach > ------------------------------ > > *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ > gregory.mirsky@ericsson.com] > *Sent:* Tuesday, April 05, 2016 6:16 > *To:* rtg-bfd@ietf.org; mpls@ietf.org > *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; > rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( > akatlas@gmail.com) > *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces > > Dear All, > > two new drafts, related to RFC 7130, were published before the meeting: > > =C2=B7 BFD on MC-LAG interfaces in IP network > > > =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network > > > > > Greatly appreciate your reviews, comments, questions and suggestions. > > > > Regards, > > Greg > > > > > --94eb2c0c0126910dbd052ffd91e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Reshad,
yes, link local multicast may be used in MC-LAG scenario. The draft states = that it MAY be used while the broadcast has SHOULD normative. But we are al= l open to the discussion.
Regards, Greg

On Apr 8, 2016 11:28 AM, "Reshad Rahman (rr= ahman)" <rrahman@cisco.com= > wrote:
Hi Greg,

With the proposal in the draft won=E2=80=99t you need a change to indi= cate that the link-local multicast address should be used?

Regards,
Reshad.


Hi Manav,

thank you for your consideration. The advant= age of the MC-LAG is that there=E2=80=99s nothing changes for SE which stil= l sees it LAG. If one to use different destination IP addresses on SE side, then that advantage will be lost. Our= proposal is to preserve it.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= u>

=C2=A0

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Friday, April 08, 2016 8:05 AM
To: Gregory Mirsky
Cc: Mach Chen; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

Hi Greg,

=C2=A0

Why cant different micro-BFD packets use the IP addr= ess of the MC-LAG end points? Ones going to router 1 will all carry the sam= e unicast IP address. The ones going towards the other router will all carr= y some other IP address, which would be configured along with the MC-LAG configs.

=C2=A0

In fact i would argue that the u-bfd packets going t= o different routers must use different IP addresses so that you can actuall= y verify the data plane liveliness. Whats the point in sending a contrived = IP address if the path that it takes is different from the other regular packets?

=C2=A0

Cheers, Manav

=C2=A0

On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky <<= a href=3D"mailto:gregory.mirsky@ericsson.com" target=3D"_blank">gregory.mir= sky@ericsson.com> wrote:

Hi Manav,

thank you for sharing insight view of discus= sions around RFC 7130, extremely helpful.

We believe, and Jeff is co-author of RFC 713= 0 too, that MC-LAG presents different case and the compromise that you=E2=80=99ve pointed too is justified. We will a= dd more details on the potential differences between unicast and multicast = fast paths in the next update.

We are open to the discussion and always wel= come comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= /span>

=C2=A0

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do with multicast datapath (espe= cially link local) being different from the unicast datapath in most router= s. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0

=C2=A0

When writing 7130 we spent quite a bit of time ensur= ing that we dont carve out a special data path for the micro-BFD packets. U= sing link local would have made it a lot simpler.

=C2=A0

And this is where i think the current proposal is fl= awed -- they use link local multicast to ensure IP unicast reachability whi= ch is incorrect.

=C2=A0

Cheers, Manav

=C2=A0

On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,

=C2=A0

I just have quick review on the drafts. If my understanding is correct, th= e idea is to use multicast destination address other than unicast address w= hen=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0

Best regards,

Mach=C2=A0

From: Rtg-b= fd [rtg-bfd-bou= nces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= u>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfa= ces in IP network

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG inter= faces in IP/MPLS network

=C2=A0<= /u>

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0

--94eb2c0c0126910dbd052ffd91e1-- From nobody Fri Apr 8 12:01:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDED12D5DF; Fri, 8 Apr 2016 12:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvt73LMit1lG; Fri, 8 Apr 2016 12:01:20 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 24C7A12D61B; Fri, 8 Apr 2016 12:01:04 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so145518967ywa.0; Fri, 08 Apr 2016 12:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=QsHPFe5W3pkhg040xEDx3mQ/nf9+uuhRQVyMvPkyEC/aLT5sYG4upCRgh8dVE4ygBM guvCBMdIxVsStoKxKYQhI18dw/1Ym/tP/SBV6FpL1aCYFKOEZp9lsHu376lWdhYQkNLP 3F92hi6QfYm0t7cNW801SzLTnecOg8yGKZ2RyVj+ClAwww9VH0rPe3l0xrc18gDfnFaC Hi7MLUmFiTQ23tIwl4Eruw8pday9wbZASvAF47vAzW144dgh67Y9HcHpzicxdfW2hm8v wx+pJxIH8n68dCLtX1l9ufAiF9tPuVjJSNioaC4npaLp0UXHiJhZ/PVlrBg/4ouwP2in Tg3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=euJG4Y4zwsnPxPTaQ2xlW4mmIOPwK8y5Qk8Ev2buoI8=; b=kpa9wiD1eMhn91nBkoeks88UlayuXM1yCK82KIJ8Bzkl+bQ5KCnNkdUX/gsK4nUEuW EfPbiwL1Ev1Vb92Apv/WneGVuVQt2D/MZZLEIYQzJdPNfcV1k/EIp42oCCCEjxW5aZR0 rllnxjf47T9+CUF87kAhtOWD5XMJgV9tINYcE0bTApr1aDHqSblyWTr1aRR5AAVnwd/+ mtWaHzfzHny5JpUNHbnzrcJF5TENvzJFVd4dnnrd7WyGyHBytXm3bJ5dpJFgLEqPno6I 0X/4DGKawwGqWprY9DSk1uifMfzUO4y/zJ/HDlxuxXC3S1reJvNf0AARCHNfzzhL9Uv4 eXpQ== X-Gm-Message-State: AD7BkJLscjatv1B+E1rl0HVCwwriNDM4kofmnsEeWbJ5a5UI9hxT43IWmm9nWVu8EB2VyWQLsah888xfxclfHA== MIME-Version: 1.0 X-Received: by 10.13.220.197 with SMTP id f188mr5232114ywe.172.1460142064034; Fri, 08 Apr 2016 12:01:04 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 12:01:03 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Fri, 8 Apr 2016 12:01:03 -0700 Message-ID: From: Greg Mirsky To: Manav Bhatia Content-Type: multipart/alternative; boundary=94eb2c07bc900c8772052ffdd182 Archived-At: Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org, "rtg-bfd-chairs@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:01:24 -0000 --94eb2c07bc900c8772052ffdd182 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Manav, the update could be in addition of either broadcast or link local multicast or both with appropriate normative language. But I would not agree that these wouldn't work. Regards, Greg On Apr 8, 2016 12:34 PM, "Manav Bhatia" wrote: > Hi Greg, > > Not sure i understand how it can "update RFC 7130". Is that by using a > link local mcast IP instead of a Unicast IP? > > We know that, that wouldnt work. > > Cheers, Manav > > On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky < > gregory.mirsky@ericsson.com> wrote: > >> Hi Reshad, >> >> thank you for your comments. Indeed, RFC 7130 is restricted and thus >> hardly applicable to MC-LAG case. We realize that if this proposal is >> adopted it not only enhance applicability on u-BFD but will update RFC 7= 130. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >> *Sent:* Friday, April 08, 2016 8:51 AM >> *To:* Manav Bhatia; Gregory Mirsky >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; >> rtg-bfd-chairs@ietf.org >> >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I agree with Manav, and nothing in RFC7130 seems to preclude using >> different unicast IP address as destination on different member links. >> >> >> >> Regards, >> >> Reshad (as individual contributor). >> >> >> >> *From: *Rtg-bfd on behalf of Manav Bhatia < >> manavbhatia@gmail.com> >> *Date: *Friday, April 8, 2016 at 11:04 AM >> *To: *Gregory Mirsky >> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < >> mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia >> Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < >> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" >> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> Hi Greg, >> >> >> >> Why cant different micro-BFD packets use the IP address of the MC-LAG en= d >> points? Ones going to router 1 will all carry the same unicast IP addres= s. >> The ones going towards the other router will all carry some other IP >> address, which would be configured along with the MC-LAG configs. >> >> >> >> In fact i would argue that the u-bfd packets going to different routers >> must use different IP addresses so that you can actually verify the data >> plane liveliness. Whats the point in sending a contrived IP address if t= he >> path that it takes is different from the other regular packets? >> >> >> >> Cheers, Manav >> >> >> >> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < >> gregory.mirsky@ericsson.com> wrote: >> >> Hi Manav, >> >> thank you for sharing insight view of discussions around RFC 7130, >> extremely helpful. >> >> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents >> different case and the compromise that you=E2=80=99ve pointed too is jus= tified. We >> will add more details on the potential differences between unicast and >> multicast fast paths in the next update. >> >> We are open to the discussion and always welcome comments and alternativ= e >> proposals. >> >> >> >> Regards, >> >> Greg >> >> >> >> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] >> *Sent:* Thursday, April 07, 2016 7:39 PM >> *To:* Mach Chen >> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; >> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org= ; >> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) >> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> >> >> I believe it had to do with multicast datapath (especially link local) >> being different from the unicast datapath in most routers. Using link lo= cal >> multicast IP addresses may not necessarily guarantee Unicast IP >> reachability. >> >> >> >> When writing 7130 we spent quite a bit of time ensuring that we dont >> carve out a special data path for the micro-BFD packets. Using link loca= l >> would have made it a lot simpler. >> >> >> >> And this is where i think the current proposal is flawed -- they use lin= k >> local multicast to ensure IP unicast reachability which is incorrect. >> >> >> >> Cheers, Manav >> >> >> >> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote: >> >> Hi Greg and all, >> >> >> >> I just have quick review on the drafts. If my understanding is correct, >> the idea is to use multicast destination address other than unicast addr= ess >> when sending BFD packets over LAG links. And actually this idea has bee= n >> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (the >> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 d= id >> discuss the idea of using multicast destination address, but for some >> reason I forget now(I may need to reiterate the discussions on the >> archive), the idea was abandoned, although I still think multicast >> destination address is a smart idea. >> >> >> >> Best regards, >> >> Mach >> ------------------------------ >> >> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [ >> gregory.mirsky@ericsson.com] >> *Sent:* Tuesday, April 05, 2016 6:16 >> *To:* rtg-bfd@ietf.org; mpls@ietf.org >> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; >> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( >> akatlas@gmail.com) >> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces >> >> Dear All, >> >> two new drafts, related to RFC 7130, were published before the meeting: >> >> =C2=B7 BFD on MC-LAG interfaces in IP network >> >> >> =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network >> >> >> >> >> Greatly appreciate your reviews, comments, questions and suggestions. >> >> >> >> Regards, >> >> Greg >> >> >> >> >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --94eb2c07bc900c8772052ffdd182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Manav,
the update could be in addition of either broadcast or link local multicast= or both with appropriate normative language. But I would not agree that th= ese wouldn't work.
Regards, Greg

On Apr 8, 2016 12:34 PM, "Manav Bhatia"= ; <manavbhatia@gmail.com>= ; wrote:
Hi Greg,

Not sure i understand how it can "up= date RFC 7130". Is that by using a link local mcast IP instead of a Un= icast IP?

We know that, that wouldnt work.

Cheers, Manav

On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



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

--94eb2c07bc900c8772052ffdd182-- From nobody Fri Apr 8 12:31:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B828C12D516; Fri, 8 Apr 2016 12:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 PxsOUOFc9a9j; Fri, 8 Apr 2016 12:31:34 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0092.outbound.protection.outlook.com [104.47.1.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01AB12D58E; Fri, 8 Apr 2016 12:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YJZ464g5S6HzuLzW1RjymsrBHTZ9O+PX5WpBjUzTn2I=; b=cx0e1HTw7vycGxbYTEs0FTEbQlCKR7n6HKDNRxQYj1O4MPXilhl4CZrXBkAhPG4jvBeR8U8JqlYlwhBYoKrdg70GIigOuaFA1JN9dqUKCY0zp8zmACnHO9vHZXi0YbVztrrMZokIb5RjeGfGPMhRvSZHeZzz6zFQEZ19b1OnauU= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 19:31:30 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 19:31:30 +0000 From: Alexander Vainshtein To: "Carlos Pignataro (cpignata)" , Xiaohu Xu Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A///PiXs= Date: Fri, 8 Apr 2016 19:31:30 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [79.181.138.125] x-ms-office365-filtering-correlation-id: 00ab3b3b-9438-4e93-8b95-08d35fe46304 x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:rNtyABEHhCDUe2L/9LfAtLWr4zJTgk6bYn3jBsLaXKawHBRNOlWowL1TvqamfEKuZkPQU63neMo9osHDXuFO5Li5H6rtXVd3rRMYPG+emAw4tJKiDS1vGpZhPY7kqiqUGjmSRXgTGc1o8/y+lxXPEw==; 24:9O8J18ruzemFmYl3WI8DEU0r68Frh0aGgw4sH0r95qVNYdQYDQVE2ywQZX0qPVQ6z2OcOlJ3Fote+Co9NJJp5gp5QpISq3DijCdzuI+Qi6g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(52034003)(377454003)(10400500002)(11100500001)(95246002)(5008740100001)(19580405001)(19580395003)(86362001)(586003)(3846002)(164054004)(1096002)(5004730100002)(3660700001)(3280700002)(1220700001)(9686002)(102836003)(6116002)(92566002)(4326007)(33646002)(19617315012)(2906002)(50986999)(76176999)(54356999)(66066001)(16236675004)(5002640100001)(5001770100001)(15975445007)(106116001)(77096005)(189998001)(2900100001)(81166005)(87936001)(122556002)(2950100001)(51650200001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_mc51yrrf9n0wxbjsrprt9amf1460143890063emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 19:31:30.5765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 19:31:38 -0000 --_000_mc51yrrf9n0wxbjsrprt9amf1460143890063emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carlos and all, Just for the reference, IANA has defined version 5 (0101) has assigned to S= T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181= 9, but the IANA assignment still holds. Is there, just in case, any relationship between BIER and ST? Thumb typed on my cellphone Regards, Sasha -------- Original Message -------- From: "Carlos Pignataro (cpignata)" Date: Fri, April 08, 2016 9:25 PM +0300 To: Xiaohu Xu CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati= on Xiaohu, Tony, Please see inline. On Apr 7, 2016, at 2:39 PM, Xuxiaohu > wrote: As for the first nibble issue, will it violate the layering principle of ne= twork protocol stacks if the first nibble of any new encapsulation header (= which could be an MPLS payload) is used as the "MPLS payload type" field? Reading draft-wang-bier-ethernet-01, Section 3, the "first nibble" is _not_= used as an "MPLS payload type". Instead, the text describes an anti-aliasi= ng mechanism, much like RFC 4928. The relevant text is: First nibble: The first 4 bits of the header are set to 0101; this ensures that the BIER header will not be confused with an IP header or with the header of a pseudowire packet. Which says "... will not be confused with ..." wouldn't it be more reasonable and sustainable to fix the problem (i.e., t= he lack of a protocol field in the MPLS header) by the MPLS header itself? Who says it is a *problem*? There's no "fixing" needed. By the way, since it's claimed that the NSH is transport-independant, it me= ans the NSH should be able to be transported over MPLS. However, it seems t= hat the first nibble issue has not be considered in the current NSH draft. = As a result, when encapsulating NSH over MPLS, the NSH may be mis-interpret= ed as IP header. There seems to be some massive confusion on this paragraph, on a number of = levels. First, NSH is not "claimed to be" transport-independent. It is by c= harter and by design. Second, the NSH draft does not even include the term = "MPLS", because it does not define transports. The SFC Encapsulation can be= used in a transport-agnostic way. One more comment below. Best regards, Xiaohu ________________________________ ???: BIER [bier-bounces@ietf.org] ?? Tony Prz= ygienda [tonysietf@gmail.com] ????: 2016?4?5? 22:36 ???: bier@ietf.org ??: [Bier] comments on draft-wang-bier-ethernet-01 after reading a) first nibble: refer to MPLS encaps as "the same value" to keep in sync One comment regarding the "First nibble" text at draft-ietf-bier-mpls-encap= sulation-03 Since the function of the first nibble is to prevent aliasing with an IP pa= cket, in order for RFC 4928 to specify values of 0x0 and 0x1 for the First = Nibble, it had to "Reserve" IP protocol versions of 0 and 1, referencing th= at RFC (see https://tools.ietf.org/html/rfc4928#section-5). Is the intent to re-assign IPv5 at http://www.iana.org/assignments/version-= numbers/ ? Note that RFC 4928 says "REQUIRED" at: It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. Thanks, - Carlos. b) refer to all other possible fields to MPLS encaps to keep in sync when d= escribing instead of repeating c) you need to describe which kind of ether MACs are allowed, especially on= broadcast media, i.e. is it always p2p or can you take advantage of the br= oadcast ? d) Figure 4: use the architecture/MPLS encoding for the length, don't inven= t a new one e) who will obtain a new ether type from IEEE? As far I understand, not a t= rivial process albeit we have several liaisons with IEEE -- We've heard that a million monkeys at a million keyboards could produce the= complete works of Shakespeare; now, thanks to the Internet, we know that i= s not true. ?Robert Wilensky _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_mc51yrrf9n0wxbjsrprt9amf1460143890063emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Carlos and all,=0A=
Just for the reference, IANA has defined version 5 (0101) has assigned to S=
T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181=
9, but the IANA =0A=
assignment still holds.=0A=
=0A=
Is there, just in case, any relationship between BIER and ST?=0A=
Thumb typed on my cellphone=0A=
Regards,=0A=
Sasha=0A=
=0A=
-------- Original Message --------=0A=
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>=0A=
Date: Fri, April 08, 2016 9:25 PM +0300=0A=
To: Xiaohu Xu <xuxiaohu@huawei.com>=0A=
CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda&q=
uot; <tonysietf@gmail.com>=0A=
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati=
on=0A=
=0A=
Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

As for the firs= t nibble issue, will it violate the layering principle of network protocol = stacks if the first nibble of any new encapsulation header (which could be = an MPLS payload) is used as the "MPLS payload type" field?

Reading draft-wang-bier-ethernet-01, Section 3, the “first = nibble” is _not_ used as an “MPLS payload type”. Instead,= the text describes an anti-aliasing mechanism, much like RFC 4928. 

The relevant text is:
     First nibble: The first 4 bits of the h= eader are set to 0101; this
   ensures that the BIER header will not be confu= sed with an IP header
   or with the header of a pseudowire packet.

Which says “… will not be confused with …= "

wouldn't it&nbs= p; be more reasonable and sustainable to fix the problem (i.e., t= he lack of a protocol field in the MPLS header) by the MPLS header itself?<= /div>

 


Who says it is a *problem*? There’s no “fixing” need= ed.

By the way, sin= ce it's claimed that the NSH is transport-independant, it means the NSH sho= uld be able to be transported over MPLS. However, it seems that the first n= ibble issue has not be considered in the current NSH draft. As a result, when encapsulating NSH over MPLS, the = NSH may be mis-interpreted as IP header.

 



There seems to be some massive confusion on this paragraph, on a numbe= r of levels. First, NSH is not “claimed to be” transport-indepe= ndent. It is by charter and by design. Second, the NSH draft does not even = include the term “MPLS”, because it does not define transports. The SFC Encapsulation can be used in a transport-agnost= ic way.

One more comment below.

Best regards,
Xiaohu

 

发件人: BIER [bier-bounces@ietf.org] 代表 = Tony Przygienda [tonysiet= f@gmail.com]
发送时间: 2016年4月5日 22:36
收件人: bier@ietf.or= g
主题:&n= bsp;[Bier] comments on draft-wang-bier-ethernet-01

after reading 

a) first nibble: refer to MPLS encaps as "the same val= ue" to keep in sync 

One comment regarding the “First nibble” text at draf= t-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an = IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the F= irst Nibble, it had to “Reserve” IP protocol versions of 0 and = 1, referencing that RFC (see https:= //tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at http://www.iana.org/assignments/v= ersion-numbers/ ?

Note that RFC 4928 says “REQUIRED” at:

   It is REQUIRED, however, that applications dep= end upon in-order
   packet delivery restrict the first nibble valu= es to 0x0 and 0x1.

Thanks,

— Carlos.


b) refer to all other possible fields to MPLS encaps to kee= p in sync when describing instead of repeating 
c) you need to describe which kind of ether MACs are allowe= d, especially on broadcast media, i.e. is it always p2p or can you take adv= antage of the broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the len= gth, don't invent a new one 
e) who will obtain a new ether type from IEEE? As far I und= erstand, not a trivial process albeit we have several liaisons with IEEE&nb= sp;

-- 
We’ve heard that a million monk= eys at a million keyboards could produce the complete works of Shakespeare;= now, thanks to the Internet, we know that is not true.
―Robert Wilensky
______________= _________________________________
mpls mailing list
mpls@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mpls

--_000_mc51yrrf9n0wxbjsrprt9amf1460143890063emailandroidcom_-- From nobody Fri Apr 8 15:28:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F6112D6C1; Fri, 8 Apr 2016 15:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EflBJwUB4_29; Fri, 8 Apr 2016 15:28:09 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 DD88012D17A; Fri, 8 Apr 2016 15:28:08 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id o66so59690836ywc.3; Fri, 08 Apr 2016 15:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gxW+eFOid6SS3OoXP2shRdQuv2sGmLcDM3Gpf42Hqu0=; b=ZAPz/fH1Bs5G9my+27NdFFOcjnbxjTRlYtXsbP5nSFRECdrTzjGzQz9OoHXfu+S/gC 8YPE+C+rn20oQGFbui3wVXKYWy8cQ7i1JOIwErWYpj5aOZp0pACMfVmHMLikkNwI5We+ eMSf5mL2ITXg9852QWTiT1l0zmi9fvOieURvYxa5OtDBvx/tldV40oUrDsXXqLyhlzOs Op9kznwXtsrGDd+vmL1jbrCHCIpJTsfRBV79C3P1sfq05vetOsTNT/Hc/+tA5Fu/m4t9 EgguNYhoENS1X8UxMSTXtIq8CwELBfgEMnAOozqK89BJBvVpzj3+5FuEcxwpRJmNHXhL IPrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gxW+eFOid6SS3OoXP2shRdQuv2sGmLcDM3Gpf42Hqu0=; b=NS2nvuu7ZS7jfM9sNbJZqjuv6I7dntbouhe7tTmqptFeWTSL9C6RndTO/CaKdjCQB+ XY+UvI2HFotQv2LWuLrKMFJfPldnyIOOGx15iCATmCcurqWLXcaneFusxyMnSMSq4Eze QfadMue+NEsi4GASRojeigD4OBanMTMpy4nGlBeKRA/8Kcz10Cfbmoo1ZUBF7L+ELQ1s Ta6iuwiLvEZX9OE3R5Nwk8lNRwTR2h0I0iQhzCAw+qKCe0ZoI8Of4tQf0ZLxksaCOU9b nZjQaBZWtwIvVPQQDkrel5liibvDyFXaGgBDZDUsWX/Y86c9jtWq1KF/7Y7ZVCAMbn6d qO2g== X-Gm-Message-State: AD7BkJKCVo2VTVaaHv24WRtfXYtvkiFfcSkVCMuaSFe4G/6P9V1UskHOY9tV0lQEx7DcroKFvL2BJT2e0vgtRw== MIME-Version: 1.0 X-Received: by 10.129.159.194 with SMTP id w185mr6163070ywg.297.1460154487311; Fri, 08 Apr 2016 15:28:07 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 15:28:07 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 15:28:07 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> Date: Fri, 8 Apr 2016 15:28:07 -0700 Message-ID: From: Greg Mirsky To: Alexander Vainshtein Content-Type: multipart/alternative; boundary=94eb2c0c01268892a0053000b5b6 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:28:11 -0000 --94eb2c0c01268892a0053000b5b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sasha, thank you for pointing to existing IANA allocation, though stale. I wonder if there is the registry for the first nibble. We, Tony and I, had discussed the way the first nibble space managed. If there already is the registry, could you please point me to it. Regards, Greg On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" < Alexander.Vainshtein@ecitele.com> wrote: > Carlos and all, > Just for the reference, IANA has defined version 5 (0101) has assigned to= ST protocol and refers to RFC 1119. The latter has been obsoleted by RFC 1= 819, but the IANA > assignment still holds. > > Is there, just in case, any relationship between BIER and ST? > Thumb typed on my cellphone > Regards, > Sasha > > -------- Original Message -------- > From: "Carlos Pignataro (cpignata)" > Date: Fri, April 08, 2016 9:25 PM +0300 > To: Xiaohu Xu > CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda" > Subject: Re: [mpls] The first nibble issue associated with MPLS encapsula= tion > > > Xiaohu, Tony, > > Please see inline. > > On Apr 7, 2016, at 2:39 PM, Xuxiaohu wrote: > > As for the first nibble issue, will it violate the layering principle of > network protocol stacks if the first nibble of any new encapsulation head= er > (which could be an MPLS payload) is used as the "MPLS payload type" field= ? > > > Reading draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirst nibble= =E2=80=9D is > _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. Instead, the text d= escribes an > anti-aliasing mechanism, much like RFC 4928. > > The relevant text is: > First nibble: The first 4 bits of the header are set to 0101; this > ensures that the BIER header will not be confused with an IP header > or with the header of a pseudowire packet. > > Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6" > > wouldn't it be more reasonable and sustainable to fix the problem (i.e., > the lack of a protocol field in the MPLS header) by the MPLS header itsel= f? > > > > > Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80=9D n= eeded. > > By the way, since it's claimed that the NSH is transport-independant, it > means the NSH should be able to be transported over MPLS. However, it see= ms > that the first nibble issue has not be considered in the current NSH draf= t. > As a result, when encapsulating NSH over MPLS, the NSH may be > mis-interpreted as IP header. > > > > > There seems to be some massive confusion on this paragraph, on a number o= f > levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-indep= endent. It is by > charter and by design. Second, the NSH draft does not even include the te= rm > =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The SFC En= capsulation can be > used in a transport-agnostic way. > > One more comment below. > > Best regards, > Xiaohu > > > ------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* BIER [bier-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Tony Przygienda [ > tonysietf@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B44=E6=9C=885=E6=97=A5= 22:36 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* bier@ietf.org > *=E4=B8=BB=E9=A2=98:* [Bier] comments on draft-wang-bier-ethernet-01 > > after reading > > a) first nibble: refer to MPLS encaps as "the same value" to keep in sync > > > One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text > at draft-ietf-bier-mpls-encapsulation-03 > > Since the function of the first nibble is to prevent aliasing with an IP > packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the > First Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions of= 0 and 1, > referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5). > > Is the intent to re-assign IPv5 at > http://www.iana.org/assignments/version-numbers/ ? > > Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at: > > It is REQUIRED, however, that applications depend upon in-order > packet delivery restrict the first nibble values to 0x0 and 0x1. > > Thanks, > > =E2=80=94 Carlos. > > > b) refer to all other possible fields to MPLS encaps to keep in sync when > describing instead of repeating > c) you need to describe which kind of ether MACs are allowed, especially > on broadcast media, i.e. is it always p2p or can you take advantage of th= e > broadcast ? > d) Figure 4: use the architecture/MPLS encoding for the length, don't > invent a new one > e) who will obtain a new ether type from IEEE? As far I understand, not a > trivial process albeit we have several liaisons with IEEE > > -- > *We=E2=80=99ve heard that a million monkeys at a million keyboards could = produce > the complete works of Shakespeare; now, thanks to the Internet, we know > that is not true.* > =E2=80=95Robert Wilensky > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --94eb2c0c01268892a0053000b5b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder = if there is the registry for the first nibble. We, Tony and I, had discusse= d the way the first nibble space managed. If there already is the registry,= could you please point me to it.
Regards, Greg

On Apr 8, 2016 2:31 PM, "Alexander Vainshte= in" <Alexander.= Vainshtein@ecitele.com> wrote:
Carlos and all,
Just for the reference, IANA has defined version 5 (0101) has assigned to S=
T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181=
9, but the IANA=20
assignment still holds.

Is there, just in case, any relationship between BIER and ST?
Thumb typed on my cellphone
Regards,
Sasha

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <=
xuxiaohu@huawei.com>
CC: mpls@ietf.org, <=
a href=3D"mailto:bier@ietf.org" target=3D"_blank">bier@ietf.org, sfc@ietf.org, "Dr. Ton=
y Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati=
on
Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

As for the first nibble iss= ue, will it violate the layering principle of network protocol stacks if th= e first nibble of any new encapsulation header (which could be an MPLS payl= oad)=C2=A0is used as the "MPLS payload type" field?

Reading=C2=A0draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirs= t nibble=E2=80=9D is _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. = Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.= =C2=A0

The relevant text is:
=C2=A0 =C2=A0 =C2=A0First nibble: The first 4 bits of the header are s= et to 0101; this
=C2=A0 =C2=A0ensures that the BIER header will not be confused with an= IP header
=C2=A0 =C2=A0or with the header of a pseudowire packet.

Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6"= ;

wouldn't it=C2=A0 be mo= re reasonable and sustainable=C2=A0to fix the=C2=A0problem (i.e., the lack = of a protocol field in the MPLS header) by the MPLS header itself?

=C2=A0


Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80= =9D needed.

By the way, since it's = claimed that the NSH is transport-independant, it means the NSH should be a= ble to be transported over MPLS. However, it seems that the first nibble is= sue has not be considered=C2=A0in the current NSH draft. As a result, when encapsulating NSH over MPLS, the = NSH may be mis-interpreted as IP header.

=C2=A0



There seems to be some massive confusion on this paragraph, on a numbe= r of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-in= dependent. It is by charter and by design. Second, the NSH draft does not e= ven include the term =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The SFC Encapsulation can be used in a transport-agnost= ic way.

One more comment below.

Best regards,
Xiaohu

=C2=A0

=E5=8F=91= =E4=BB=B6=E4=BA=BA:=C2=A0BIER [bier-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Tony Przygienda [tonysietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:=C2=A02016=E5=B9= =B44=E6=9C=885=E6=97=A5 22:36
=E6=94=B6=E4=BB=B6=E4=BA=BA:=C2=A0bier@ietf.org
=E4=B8=BB=E9=A2=98:=C2=A0[Bier] comments on draft-wang-= bier-ethernet-01

after reading=C2=A0

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync=C2=A0

One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text at=C2=A0= draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an = IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the F= irst Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions of 0 = and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at=C2=A0http://www.iana.org/assign= ments/version-numbers/=C2=A0?

Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at:

=C2=A0 =C2=A0It is REQUIRED, however, that applications depend upon in= -order
=C2=A0 =C2=A0packet delivery restrict the first nibble values to 0x0 a= nd 0x1.

Thanks,

=E2=80=94 Carlos.


b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating=C2=A0
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don= 9;t invent a new one=C2=A0
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE=C2=A0

--=C2=A0
We=E2= =80=99ve heard that a million monkeys at a million keyboards could produce = the complete works of Shakespeare; now, thanks to the Internet, we know tha= t is not true.
= =E2=80=95Robert Wilensky
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/lis= tinfo/mpls


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

--94eb2c0c01268892a0053000b5b6-- From nobody Fri Apr 8 15:39:00 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225C12D5D0; Fri, 8 Apr 2016 15:38:58 -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 H5x3lklHNWsU; Fri, 8 Apr 2016 15:38:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895C512D540; Fri, 8 Apr 2016 15:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26832; q=dns/txt; s=iport; t=1460155135; x=1461364735; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YDiRtT4z7/PeWPK+q5IbDY56DYuoaGFxYHtujOsIkmw=; b=d8X+DsDYe/US9YsfpSEOEs9UNIaQUVKwGHjIFW5MmTnC6ITBolPe77OI 5sPVUb+3bSqff/epL9uIBaLs3uQ7qdm4O/6n3AAlxwTbdvzJbn2s33L5o T2UEL4XB1WFGffS4fXCoEBhHfNGfNbwo9QseYf/NiDBdJ8fn4coq6hwdN 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgCqMQhX/4UNJK1cgmtMU30GrnWLW?= =?us-ascii?q?AENgXMXAQuFagIcgRg4FAEBAQEBAQFlJ4RBAQEBBAEBAWsEBwwEAgEGAhEBAgE?= =?us-ascii?q?CIQcFAgIfBgsUAwYIAgQBDQUJiAkDEg6RZZ0RCIw7DYUhAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFYYghEuCQYIEEAoNCQSCQoJaBZMZhDoxAYV2gnKDLoF1gWeETYh?= =?us-ascii?q?Zh0qHWgEeAQFCg2dsAYg6fgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,454,1454976000"; d="scan'208,217"; a="91609990" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 22:38:54 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u38Mcr0q031643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 22:38:54 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 18:38:52 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 18:38:53 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky , Alexander Vainshtein Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A///PiXuAAHRmgP//0LOA Date: Fri, 8 Apr 2016 22:38:52 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.247.9] Content-Type: multipart/alternative; boundary="_000_D32DB7253F57Bcpignataciscocom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:38:58 -0000 --_000_D32DB7253F57Bcpignataciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 R3JlZywNCg0KTXkgcG9pbnQsIHNvcnJ5IGlmIEkgd2FzIG5vdCBjbGVhciwgd2FzIHRoYXQgdGhl cmUgaXMgbm8gc3VjaCBhIHRoaW5nIGFzIGEgoa5maXJzdCBuaWJibGUgcmVnaXN0cnmhry4NCg0K SW5zdGVhZCwgUkZDIDQ5MjgsIFNlY3Rpb24gNSwgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzQ5Mjgjc2VjdGlvbi01LCBzYXlzOg0KDQogICBJQU5BIGhhcyBtYXJrZWQgdGhlIHZh bHVlIDB4MSBpbiB0aGUgSVAgcHJvdG9jb2wgdmVyc2lvbiBudW1iZXIgc3BhY2UNCiAgIGFzICJS ZXNlcnZlZCIgYW5kIHBsYWNlZCBhIHJlZmVyZW5jZSB0byB0aGlzIGRvY3VtZW50IHRvIGJvdGgg dmFsdWVzDQogICAweDAgYW5kIDB4MS4NCg0KQW5kIHRoYXQgaXMgcmVmbGVjdGVkIGFzIGh0dHA6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdmVyc2lvbi1udW1iZXJzL3ZlcnNpb24tbnVtYmVy cy54aHRtbCN2ZXJzaW9uLW51bWJlcnMtMQ0KDQpUaGUgSUFOQSB0ZXh0IGluIDQ5MjggaXMgYWRk aXRpb25hbGx5IGZvbGxvd2VkIGJ5IGEgZGlzY2xhaW1lcjoNCg0KICAgTm90ZSB0aGF0IHRoaXMg ZG9jdW1lbnQgZG9lcyBub3QgaW4gYW55IHdheSBjaGFuZ2UgdGhlIHBvbGljaWVzDQogICByZWdh cmRpbmcgdGhlIGFsbG9jYXRpb24gb2YgdmVyc2lvbiBudW1iZXJzLCBpbmNsdWRpbmcgdGhlIHBv c3NpYmxlDQogICB1c2Ugb2YgdGhlIHJlc2VydmVkIG51bWJlcnMgZm9yIHNvbWUgZnV0dXJlIHB1 cnBvc2UuDQoNCkZ1cnRoZXIsIFJGQyA0Mzg1IGRvZXMgbm90IHNwZWNpZnkgdGhlIKGuZmlyc3Qg bmliYmxloa8gYXMgYSBmaWVsZC4gSW5zdGVhZCwgaXQgZGVwaWN0cyB0aGUgYWN0dWFsIGJpbmFy eSB2YWx1ZXMgZm9yIHRoZSBkaWZmZXJlbnQgQ1cgZm9ybWF0cy4gSW4gb3RoZXIgd29yZHMsIGl0 IHRha2VzIHRoZSB2YWx1ZXMgZnJvbSB0aGUgSVAgcHJvdG9jb2wgdmVyc2lvbiBudW1iZXIgYW5k IG5vdCBhcyBhIG5ldyBDVyBGaWVsZC4NCg0KVGhhbmtzLA0KDQqhqiBDYXJsb3MuDQoNClBTOiBT YXNoYSwgcXVpY2sgdHlwbywgcy8xMTE5LzExOTAvOw0KDQpGcm9tOiBHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+Pg0KRGF0ZTog RnJpZGF5LCBBcHJpbCA4LCAyMDE2IGF0IDc6MjggUE0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVp biA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tPj4NCkNjOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+IiA8c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+PiwgImJpZXJAaWV0Zi5vcmc8 bWFpbHRvOmJpZXJAaWV0Zi5vcmc+IiA8YmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9y Zz4+LCAiRHIuIFRvbnkgUHJ6eWdpZW5kYSIgPHRvbnlzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRv bnlzaWV0ZkBnbWFpbC5jb20+PiwgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+ IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+LCBYaWFvaHUgWHUgPHh1eGlh b2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgQ2FybG9zIFBpZ25h dGFybyA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+Pg0KU3Vi amVjdDogUmU6IFttcGxzXSBUaGUgZmlyc3QgbmliYmxlIGlzc3VlIGFzc29jaWF0ZWQgd2l0aCBN UExTIGVuY2Fwc3VsYXRpb24NCg0KDQpIaSBTYXNoYSwNCnRoYW5rIHlvdSBmb3IgcG9pbnRpbmcg dG8gZXhpc3RpbmcgSUFOQSBhbGxvY2F0aW9uLCB0aG91Z2ggc3RhbGUuIEkgd29uZGVyIGlmIHRo ZXJlIGlzIHRoZSByZWdpc3RyeSBmb3IgdGhlIGZpcnN0IG5pYmJsZS4gV2UsIFRvbnkgYW5kIEks IGhhZCBkaXNjdXNzZWQgdGhlIHdheSB0aGUgZmlyc3QgbmliYmxlIHNwYWNlIG1hbmFnZWQuIElm IHRoZXJlIGFscmVhZHkgaXMgdGhlIHJlZ2lzdHJ5LCBjb3VsZCB5b3UgcGxlYXNlIHBvaW50IG1l IHRvIGl0Lg0KUmVnYXJkcywgR3JlZw0KDQpPbiBBcHIgOCwgMjAxNiAyOjMxIFBNLCAiQWxleGFu ZGVyIFZhaW5zaHRlaW4iIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbTxtYWlsdG86 QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+PiB3cm90ZToNCg0KQ2FybG9zIGFuZCBh bGwsDQpKdXN0IGZvciB0aGUgcmVmZXJlbmNlLCBJQU5BIGhhcyBkZWZpbmVkIHZlcnNpb24gNSAo MDEwMSkgaGFzIGFzc2lnbmVkIHRvIFNUIHByb3RvY29sIGFuZCByZWZlcnMgdG8gUkZDIDExMTku IFRoZSBsYXR0ZXIgaGFzIGJlZW4gb2Jzb2xldGVkIGJ5IFJGQyAxODE5LCBidXQgdGhlIElBTkEN CmFzc2lnbm1lbnQgc3RpbGwgaG9sZHMuDQoNCklzIHRoZXJlLCBqdXN0IGluIGNhc2UsIGFueSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiBCSUVSIGFuZCBTVD8NClRodW1iIHR5cGVkIG9uIG15IGNlbGxw aG9uZQ0KUmVnYXJkcywNClNhc2hhDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0t LS0NCkZyb206ICJDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkiIDxjcGlnbmF0YUBjaXNjby5j b208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+DQpEYXRlOiBGcmksIEFwcmlsIDA4LCAyMDE2 IDk6MjUgUE0gKzAzMDANClRvOiBYaWFvaHUgWHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb20+Pg0KQ0M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+LCBiaWVyQGlldGYub3JnPG1haWx0bzpiaWVyQGlldGYub3JnPiwgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+LCAiRHIuIFRvbnkgUHJ6eWdpZW5kYSIgPHRvbnlzaWV0ZkBn bWFpbC5jb208bWFpbHRvOnRvbnlzaWV0ZkBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFttcGxz XSBUaGUgZmlyc3QgbmliYmxlIGlzc3VlIGFzc29jaWF0ZWQgd2l0aCBNUExTIGVuY2Fwc3VsYXRp b24NCg0KDQoNClhpYW9odSwgVG9ueSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIEFwciA3 LCAyMDE2LCBhdCAyOjM5IFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpBcyBmb3IgdGhlIGZpcnN0IG5pYmJsZSBp c3N1ZSwgd2lsbCBpdCB2aW9sYXRlIHRoZSBsYXllcmluZyBwcmluY2lwbGUgb2YgbmV0d29yayBw cm90b2NvbCBzdGFja3MgaWYgdGhlIGZpcnN0IG5pYmJsZSBvZiBhbnkgbmV3IGVuY2Fwc3VsYXRp b24gaGVhZGVyICh3aGljaCBjb3VsZCBiZSBhbiBNUExTIHBheWxvYWQpIGlzIHVzZWQgYXMgdGhl ICJNUExTIHBheWxvYWQgdHlwZSIgZmllbGQ/DQoNClJlYWRpbmcgZHJhZnQtd2FuZy1iaWVyLWV0 aGVybmV0LTAxLCBTZWN0aW9uIDMsIHRoZSChsGZpcnN0IG5pYmJsZaGxIGlzIF9ub3RfIHVzZWQg YXMgYW4gobBNUExTIHBheWxvYWQgdHlwZaGxLiBJbnN0ZWFkLCB0aGUgdGV4dCBkZXNjcmliZXMg YW4gYW50aS1hbGlhc2luZyBtZWNoYW5pc20sIG11Y2ggbGlrZSBSRkMgNDkyOC4NCg0KVGhlIHJl bGV2YW50IHRleHQgaXM6DQogICAgIEZpcnN0IG5pYmJsZTogVGhlIGZpcnN0IDQgYml0cyBvZiB0 aGUgaGVhZGVyIGFyZSBzZXQgdG8gMDEwMTsgdGhpcw0KICAgZW5zdXJlcyB0aGF0IHRoZSBCSUVS IGhlYWRlciB3aWxsIG5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIElQIGhlYWRlcg0KICAgb3Igd2l0 aCB0aGUgaGVhZGVyIG9mIGEgcHNldWRvd2lyZSBwYWNrZXQuDQoNCldoaWNoIHNheXMgobChrSB3 aWxsIG5vdCBiZSBjb25mdXNlZCB3aXRoIKGtIg0KDQp3b3VsZG4ndCBpdCAgYmUgbW9yZSByZWFz b25hYmxlIGFuZCBzdXN0YWluYWJsZSB0byBmaXggdGhlIHByb2JsZW0gKGkuZS4sIHRoZSBsYWNr IG9mIGEgcHJvdG9jb2wgZmllbGQgaW4gdGhlIE1QTFMgaGVhZGVyKSBieSB0aGUgTVBMUyBoZWFk ZXIgaXRzZWxmPw0KDQoNCg0KV2hvIHNheXMgaXQgaXMgYSAqcHJvYmxlbSo/IFRoZXJloa9zIG5v IKGwZml4aW5nobEgbmVlZGVkLg0KDQpCeSB0aGUgd2F5LCBzaW5jZSBpdCdzIGNsYWltZWQgdGhh dCB0aGUgTlNIIGlzIHRyYW5zcG9ydC1pbmRlcGVuZGFudCwgaXQgbWVhbnMgdGhlIE5TSCBzaG91 bGQgYmUgYWJsZSB0byBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMuIEhvd2V2ZXIsIGl0IHNlZW1z IHRoYXQgdGhlIGZpcnN0IG5pYmJsZSBpc3N1ZSBoYXMgbm90IGJlIGNvbnNpZGVyZWQgaW4gdGhl IGN1cnJlbnQgTlNIIGRyYWZ0LiBBcyBhIHJlc3VsdCwgd2hlbiBlbmNhcHN1bGF0aW5nIE5TSCBv dmVyIE1QTFMsIHRoZSBOU0ggbWF5IGJlIG1pcy1pbnRlcnByZXRlZCBhcyBJUCBoZWFkZXIuDQoN Cg0KDQoNClRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWFzc2l2ZSBjb25mdXNpb24gb24gdGhpcyBw YXJhZ3JhcGgsIG9uIGEgbnVtYmVyIG9mIGxldmVscy4gRmlyc3QsIE5TSCBpcyBub3QgobBjbGFp bWVkIHRvIGJlobEgdHJhbnNwb3J0LWluZGVwZW5kZW50LiBJdCBpcyBieSBjaGFydGVyIGFuZCBi eSBkZXNpZ24uIFNlY29uZCwgdGhlIE5TSCBkcmFmdCBkb2VzIG5vdCBldmVuIGluY2x1ZGUgdGhl IHRlcm0gobBNUExTobEsIGJlY2F1c2UgaXQgZG9lcyBub3QgZGVmaW5lIHRyYW5zcG9ydHMuIFRo ZSBTRkMgRW5jYXBzdWxhdGlvbiBjYW4gYmUgdXNlZCBpbiBhIHRyYW5zcG9ydC1hZ25vc3RpYyB3 YXkuDQoNCk9uZSBtb3JlIGNvbW1lbnQgYmVsb3cuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogQklFUiBbYmll ci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIFRv bnkgUHJ6eWdpZW5kYSBbdG9ueXNpZXRmQGdtYWlsLmNvbTxtYWlsdG86dG9ueXNpZXRmQGdtYWls LmNvbT5dDQq3osvNyrG85DogMjAxNsTqNNTCNcjVIDIyOjM2DQrK1bz+yMs6IGJpZXJAaWV0Zi5v cmc8bWFpbHRvOmJpZXJAaWV0Zi5vcmc+DQrW98ziOiBbQmllcl0gY29tbWVudHMgb24gZHJhZnQt d2FuZy1iaWVyLWV0aGVybmV0LTAxDQoNCmFmdGVyIHJlYWRpbmcNCg0KYSkgZmlyc3QgbmliYmxl OiByZWZlciB0byBNUExTIGVuY2FwcyBhcyAidGhlIHNhbWUgdmFsdWUiIHRvIGtlZXAgaW4gc3lu Yw0KDQpPbmUgY29tbWVudCByZWdhcmRpbmcgdGhlIKGwRmlyc3QgbmliYmxlobEgdGV4dCBhdCBk cmFmdC1pZXRmLWJpZXItbXBscy1lbmNhcHN1bGF0aW9uLTAzDQoNClNpbmNlIHRoZSBmdW5jdGlv biBvZiB0aGUgZmlyc3QgbmliYmxlIGlzIHRvIHByZXZlbnQgYWxpYXNpbmcgd2l0aCBhbiBJUCBw YWNrZXQsIGluIG9yZGVyIGZvciBSRkMgNDkyOCB0byBzcGVjaWZ5IHZhbHVlcyBvZiAweDAgYW5k IDB4MSBmb3IgdGhlIEZpcnN0IE5pYmJsZSwgaXQgaGFkIHRvIKGwUmVzZXJ2ZaGxIElQIHByb3Rv Y29sIHZlcnNpb25zIG9mIDAgYW5kIDEsIHJlZmVyZW5jaW5nIHRoYXQgUkZDIChzZWUgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5Mjgjc2VjdGlvbi01KS4NCg0KSXMgdGhlIGludGVu dCB0byByZS1hc3NpZ24gSVB2NSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Zl cnNpb24tbnVtYmVycy8gPw0KDQpOb3RlIHRoYXQgUkZDIDQ5Mjggc2F5cyChsFJFUVVJUkVEobEg YXQ6DQoNCiAgIEl0IGlzIFJFUVVJUkVELCBob3dldmVyLCB0aGF0IGFwcGxpY2F0aW9ucyBkZXBl bmQgdXBvbiBpbi1vcmRlcg0KICAgcGFja2V0IGRlbGl2ZXJ5IHJlc3RyaWN0IHRoZSBmaXJzdCBu aWJibGUgdmFsdWVzIHRvIDB4MCBhbmQgMHgxLg0KDQpUaGFua3MsDQoNCqGqIENhcmxvcy4NCg0K DQpiKSByZWZlciB0byBhbGwgb3RoZXIgcG9zc2libGUgZmllbGRzIHRvIE1QTFMgZW5jYXBzIHRv IGtlZXAgaW4gc3luYyB3aGVuIGRlc2NyaWJpbmcgaW5zdGVhZCBvZiByZXBlYXRpbmcNCmMpIHlv dSBuZWVkIHRvIGRlc2NyaWJlIHdoaWNoIGtpbmQgb2YgZXRoZXIgTUFDcyBhcmUgYWxsb3dlZCwg ZXNwZWNpYWxseSBvbiBicm9hZGNhc3QgbWVkaWEsIGkuZS4gaXMgaXQgYWx3YXlzIHAycCBvciBj YW4geW91IHRha2UgYWR2YW50YWdlIG9mIHRoZSBicm9hZGNhc3QgPw0KZCkgRmlndXJlIDQ6IHVz ZSB0aGUgYXJjaGl0ZWN0dXJlL01QTFMgZW5jb2RpbmcgZm9yIHRoZSBsZW5ndGgsIGRvbid0IGlu dmVudCBhIG5ldyBvbmUNCmUpIHdobyB3aWxsIG9idGFpbiBhIG5ldyBldGhlciB0eXBlIGZyb20g SUVFRT8gQXMgZmFyIEkgdW5kZXJzdGFuZCwgbm90IGEgdHJpdmlhbCBwcm9jZXNzIGFsYmVpdCB3 ZSBoYXZlIHNldmVyYWwgbGlhaXNvbnMgd2l0aCBJRUVFDQoNCi0tDQpXZaGvdmUgaGVhcmQgdGhh dCBhIG1pbGxpb24gbW9ua2V5cyBhdCBhIG1pbGxpb24ga2V5Ym9hcmRzIGNvdWxkIHByb2R1Y2Ug dGhlIGNvbXBsZXRlIHdvcmtzIG9mIFNoYWtlc3BlYXJlOyBub3csIHRoYW5rcyB0byB0aGUgSW50 ZXJuZXQsIHdlIGtub3cgdGhhdCBpcyBub3QgdHJ1ZS4NCqGqUm9iZXJ0IFdpbGVuc2t5DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5n IGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg0K --_000_D32DB7253F57Bcpignataciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <3242BE28202B6448860133AA216FD753@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greg,

My point, sorry if I was not clear, was that there is no such a thing as a = =A1=AEfirst nibble registry=A1=AF.

Instead, RFC 4928, Section 5, at https://tools.ietf.org/html/rfc4928#section-5, says:

   IANA has marked the val= ue 0x1 in the IP protocol version number space
   as "Reserved"= and placed a reference to this document to both values
   0x0 and 0x1.


The IANA text in 4928 is additionally followed by a disclaimer:

   Note that this document= does not in any way change the policies
   regarding the allocatio= n of version numbers, including the possible
   use of the reserved num= bers for some future purpose.

Further, RFC 4385 does not specify the =A1=AEfirst nibble=A1=AF as a field.= Instead, it depicts the actual binary values for the different CW formats.= In other words, it takes the values from the IP protocol version number an= d not as a new CW Field.

Thanks,

=A1=AA Carlos.

PS: Sasha, quick typo, s/1119/1190/;

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Friday, April 8, 2016 at 7:28= PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.= com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>, "bier@ietf.org"= <bier@ietf.org>, "Dr. Tony= Przygienda" <tonysietf@gmail.com>, &q= uot;mpls@ietf.org" <mpls@ietf.org>, Xiaohu Xu <xuxiaohu@huawei.com>, Carlos Pignataro <cpignata@cisco.com>
Subject: Re: [mpls] The first nibbl= e issue associated with MPLS encapsulation

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder = if there is the registry for the first nibble. We, Tony and I, had discusse= d the way the first nibble space managed. If there already is the registry,= could you please point me to it.
Regards, Greg

On Apr 8, 2016 2:31 PM, "Alexander Vainshte= in" <Alexander.= Vainshtein@ecitele.com> wrote:
Carlos and all,
Just for the reference, IANA has defined version 5 (0101) has assigned to S=
T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181=
9, but the IANA=20
assignment still holds.

Is there, just in case, any relationship between BIER and ST?
Thumb typed on my cellphone
Regards,
Sasha

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <=
xuxiaohu@huawei.com>
CC: mpls@ietf.org, <=
a href=3D"mailto:bier@ietf.org" target=3D"_blank">bier@ietf.org, sfc@ietf.org, "Dr. Ton=
y Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati=
on
Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

As for the first nibble iss= ue, will it violate the layering principle of network protocol stacks if th= e first nibble of any new encapsulation header (which could be an MPLS payl= oad) is used as the "MPLS payload type" field?

Reading draft-wang-bier-ethernet-01, Section 3, the =A1=B0first n= ibble=A1=B1 is _not_ used as an =A1=B0MPLS payload type=A1=B1. Instead, the= text describes an anti-aliasing mechanism, much like RFC 4928. 

The relevant text is:
     First nibble: The first 4 bits of the header are s= et to 0101; this
   ensures that the BIER header will not be confused with an= IP header
   or with the header of a pseudowire packet.

Which says =A1=B0=A1=AD will not be confused with =A1=AD"

wouldn't it  be more r= easonable and sustainable to fix the problem (i.e., the lack of a= protocol field in the MPLS header) by the MPLS header itself?

 


Who says it is a *problem*? There=A1=AFs no =A1=B0fixing=A1=B1 needed.=

By the way, since it's clai= med that the NSH is transport-independant, it means the NSH should be able = to be transported over MPLS. However, it seems that the first nibble issue = has not be considered in the current NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be m= is-interpreted as IP header.

 



There seems to be some massive confusion on this paragraph, on a numbe= r of levels. First, NSH is not =A1=B0claimed to be=A1=B1 transport-independ= ent. It is by charter and by design. Second, the NSH draft does not even in= clude the term =A1=B0MPLS=A1=B1, because it does not define transports. The SFC Encapsulation can be used in a transport-agnost= ic way.

One more comment below.

Best regards,
Xiaohu

 

=B7=A2=BC= =FE=C8=CB: BIER [bier-bounces@ietf.org] =B4=FA=B1=ED Tony Przygie= nda [tonysietf@gma= il.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA4=D4=C25=C8=D5= 22:36
=CA=D5=BC=FE=C8=CB: bier@ietf.org
=D6=F7=CC=E2: [Bier] comments on draft-wang-bier-e= thernet-01

after reading 

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync 

One comment regarding the =A1=B0First nibble=A1=B1 text at draft-= ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an = IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the F= irst Nibble, it had to =A1=B0Reserve=A1=B1 IP protocol versions of 0 and 1,= referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at http://www.iana.org/assign= ments/version-numbers/ ?

Note that RFC 4928 says =A1=B0REQUIRED=A1=B1 at:

   It is REQUIRED, however, that applications depend upon in= -order
   packet delivery restrict the first nibble values to 0x0 a= nd 0x1.

Thanks,

=A1=AA Carlos.


b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating 
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don't = invent a new one 
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE 

-- 
We=A1= =AFve heard that a million monkeys at a million keyboards could produce the= complete works of Shakespeare; now, thanks to the Internet, we know that i= s not true.
= =A1=AARobert Wilensky
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/lis= tinfo/mpls


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

 --_000_D32DB7253F57Bcpignataciscocom_-- From nobody Fri Apr 8 16:05:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98A712D529; Fri, 8 Apr 2016 16:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B37xZErWW8a7; Fri, 8 Apr 2016 16:05:52 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A79112D0E1; Fri, 8 Apr 2016 16:05:52 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id d68so151617701ywe.1; Fri, 08 Apr 2016 16:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fsZNJKiA0lO0GEWzjNEjsbc5MqkiJCPPc9PvgOB60qQ=; b=ohn+JkbYMpr7NlfudKEVqxMGl0d4ygJvVFY+FilSI1E6W9etLXNYH0Nel0CP/q43H0 yZy/VXf9L2SCQ7/oQGHzJeizfv30qFK+iKDOqKcjxKGfLNl39esVnXVVidKJnUoHihf2 6BbqdStYgLm5fwZSRNeoPW11DHZgF90MxqExewOhOL46cuHBVGkMgEoIU6NJormJIS+2 vYLZr3z1pY5LvxXeOJKd77ukcH5jZEAPcR+4MXMUE8mzyc84e5R/jhX+rndsuow2LJgE CvzIsJt2zX5ftbmkpHVSyMqCG9FR+F6g2JoV3Jm8Yszs4r60+jP2S/Lg43Fgou3oyy7z SGOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fsZNJKiA0lO0GEWzjNEjsbc5MqkiJCPPc9PvgOB60qQ=; b=i75+oaNrOBmuRB6u+oiwbm/XOitpHF2YI7BQoqkjRnYBzO4YVhiE95K7ec4YeQFBK2 BiGdLflKykJOy7VGACnM/85CnoUsRorbnDsoR6xKqRbjvesRLAdSArXa5g5dSau9gf1a 4A+7hfBY0OnWvxFtxLGmB4BEzCL69pZeOtt42NNnVQHlcGnwuxKlJhQ9OhxPRiaS/uDC jJNYmqgCBzSvP/EkQ7Q/sYfoAPMcLLmoe9axrW9wZYBoV5mjTiE9wb0iLJ6n4gv6Zr7Z RPKmcZLVaxBrYk2oKA/EIOECod71yb966ftyQzpboAhmbOgxxmEMgF7QmhIisuJTtzVm tIHA== X-Gm-Message-State: AD7BkJIl62grfIxr7YxqmS/jcKT/XrdETY1Mb7cMW5o95EUPOr20lmbg5rpg4dx5EnzQTN4oMUbipIackKXkIw== MIME-Version: 1.0 X-Received: by 10.13.220.197 with SMTP id f188mr5650849ywe.172.1460156751807; Fri, 08 Apr 2016 16:05:51 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 16:05:51 -0700 (PDT) Received: by 10.37.215.143 with HTTP; Fri, 8 Apr 2016 16:05:51 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> Date: Fri, 8 Apr 2016 16:05:51 -0700 Message-ID: From: Greg Mirsky To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=94eb2c07bc90820b460530013ca7 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , sfc@ietf.org, "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 23:05:56 -0000 --94eb2c07bc90820b460530013ca7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, thank you for the clarification. Should we think about establishing the registry than? Regards, Greg On Apr 8, 2016 5:38 PM, "Carlos Pignataro (cpignata)" wrote: > Greg, > > My point, sorry if I was not clear, was that there is no such a thing as = a > =E2=80=98first nibble registry=E2=80=99. > > Instead, RFC 4928, Section 5, at > https://tools.ietf.org/html/rfc4928#section-5, says: > > IANA has marked the value 0x1 in the IP protocol version number space > as "Reserved" and placed a reference to this document to both values > 0x0 and 0x1. > > And that is reflected as > http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#ver= sion-numbers-1 > > > The IANA text in 4928 is additionally followed by a disclaimer: > > Note that this document does not in any way change the policies > regarding the allocation of version numbers, including the possible > use of the reserved numbers for some future purpose. > > Further, RFC 4385 does not specify the =E2=80=98first nibble=E2=80=99 as = a field. Instead, > it depicts the actual binary values for the different CW formats. In othe= r > words, it takes the values from the IP protocol version number and not as= a > new CW Field. > > Thanks, > > =E2=80=94 Carlos. > > PS: Sasha, quick typo, s/1119/1190/; > > From: Greg Mirsky > Date: Friday, April 8, 2016 at 7:28 PM > To: Alexander Vainshtein > Cc: "sfc@ietf.org" , "bier@ietf.org" , "Dr. > Tony Przygienda" , "mpls@ietf.org" , > Xiaohu Xu , Carlos Pignataro > Subject: Re: [mpls] The first nibble issue associated with MPLS > encapsulation > > Hi Sasha, > thank you for pointing to existing IANA allocation, though stale. I wonde= r > if there is the registry for the first nibble. We, Tony and I, had > discussed the way the first nibble space managed. If there already is the > registry, could you please point me to it. > Regards, Greg > On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" < > Alexander.Vainshtein@ecitele.com> wrote: > >> Carlos and all, >> Just for the reference, IANA has defined version 5 (0101) has assigned t= o ST protocol and refers to RFC 1119. The latter has been obsoleted by RFC = 1819, but the IANA >> assignment still holds. >> >> Is there, just in case, any relationship between BIER and ST? >> Thumb typed on my cellphone >> Regards, >> Sasha >> >> -------- Original Message -------- >> From: "Carlos Pignataro (cpignata)" >> Date: Fri, April 08, 2016 9:25 PM +0300 >> To: Xiaohu Xu >> CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda" >> Subject: Re: [mpls] The first nibble issue associated with MPLS encapsul= ation >> >> >> Xiaohu, Tony, >> >> Please see inline. >> >> On Apr 7, 2016, at 2:39 PM, Xuxiaohu wrote: >> >> As for the first nibble issue, will it violate the layering principle of >> network protocol stacks if the first nibble of any new encapsulation hea= der >> (which could be an MPLS payload) is used as the "MPLS payload type" fiel= d? >> >> >> Reading draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirst nibbl= e=E2=80=9D is >> _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. Instead, the text = describes an >> anti-aliasing mechanism, much like RFC 4928. >> >> The relevant text is: >> First nibble: The first 4 bits of the header are set to 0101; this >> ensures that the BIER header will not be confused with an IP header >> or with the header of a pseudowire packet. >> >> Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6" >> >> wouldn't it be more reasonable and sustainable to fix the problem (i.e.= , >> the lack of a protocol field in the MPLS header) by the MPLS header itse= lf? >> >> >> >> >> Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80=9D = needed. >> >> By the way, since it's claimed that the NSH is transport-independant, it >> means the NSH should be able to be transported over MPLS. However, it se= ems >> that the first nibble issue has not be considered in the current NSH dra= ft. >> As a result, when encapsulating NSH over MPLS, the NSH may be >> mis-interpreted as IP header. >> >> >> >> >> There seems to be some massive confusion on this paragraph, on a number >> of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-i= ndependent. It is >> by charter and by design. Second, the NSH draft does not even include th= e >> term =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The = SFC Encapsulation >> can be used in a transport-agnostic way. >> >> One more comment below. >> >> Best regards, >> Xiaohu >> >> >> ------------------------------ >> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* BIER [bier-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Tony Przygienda [ >> tonysietf@gmail.com] >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B44=E6=9C=885=E6=97= =A5 22:36 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* bier@ietf.org >> *=E4=B8=BB=E9=A2=98:* [Bier] comments on draft-wang-bier-ethernet-01 >> >> after reading >> >> a) first nibble: refer to MPLS encaps as "the same value" to keep in syn= c >> >> >> One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text >> at draft-ietf-bier-mpls-encapsulation-03 >> >> Since the function of the first nibble is to prevent aliasing with an IP >> packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the >> First Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions o= f 0 and 1, >> referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5)= . >> >> Is the intent to re-assign IPv5 at >> http://www.iana.org/assignments/version-numbers/ ? >> >> Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at: >> >> It is REQUIRED, however, that applications depend upon in-order >> packet delivery restrict the first nibble values to 0x0 and 0x1. >> >> Thanks, >> >> =E2=80=94 Carlos. >> >> >> b) refer to all other possible fields to MPLS encaps to keep in sync whe= n >> describing instead of repeating >> c) you need to describe which kind of ether MACs are allowed, especially >> on broadcast media, i.e. is it always p2p or can you take advantage of t= he >> broadcast ? >> d) Figure 4: use the architecture/MPLS encoding for the length, don't >> invent a new one >> e) who will obtain a new ether type from IEEE? As far I understand, not = a >> trivial process albeit we have several liaisons with IEEE >> >> -- >> *We=E2=80=99ve heard that a million monkeys at a million keyboards could= produce >> the complete works of Shakespeare; now, thanks to the Internet, we know >> that is not true.* >> =E2=80=94Robert Wilensky >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> --94eb2c07bc90820b460530013ca7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Carlos,
thank you for the clarification. Should we think about establishing the reg= istry than?
Regards, Greg

On Apr 8, 2016 5:38 PM, "Carlos Pignataro (= cpignata)" <cpignata@cisco.co= m> wrote:
Greg,

My point, sorry if I was not clear, was that there is no such a thing as a = =E2=80=98first nibble registry=E2=80=99.

Instead, RFC 4928, Section 5, at https://tools.ietf.org/html/rfc4928#section-5, says:

=C2=A0 =C2=A0IANA has marked the val= ue 0x1 in the IP protocol version number space
=C2=A0 =C2=A0as "Reserved"= and placed a reference to this document to both values
=C2=A0 =C2=A00x0 and 0x1.


The IANA text in 4928 is additionally followed by a disclaimer:

=C2=A0 =C2=A0Note that this document= does not in any way change the policies
=C2=A0 =C2=A0regarding the allocatio= n of version numbers, including the possible
=C2=A0 =C2=A0use of the reserved num= bers for some future purpose.

Further, RFC 4385 does not specify the =E2=80=98first nibble=E2=80=99 as a = field. Instead, it depicts the actual binary values for the different CW fo= rmats. In other words, it takes the values from the IP protocol version num= ber and not as a new CW Field.

Thanks,

=E2=80=94 Carlos.

PS: Sasha, quick typo, s/1119/1190/;

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Friday, April 8, 2016 at 7:28= PM
To: Alexander Vainshtein <Alexander.V= ainshtein@ecitele.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "Dr. Tony Pr= zygienda" <tonysietf@gma= il.com>, "mp= ls@ietf.org" <mpls@ietf.org>, Xiaohu Xu <xuxiaohu@huawei.com>, Carlos Pignataro <cpignata@cisco= .com>
Subject: Re: [mpls] The first nibbl= e issue associated with MPLS encapsulation

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder = if there is the registry for the first nibble. We, Tony and I, had discusse= d the way the first nibble space managed. If there already is the registry,= could you please point me to it.
Regards, Greg

On Apr 8, 2016 2:31 PM, "Alexander Vainshte= in" <Alexander.Vainshtein@ecitele.com> wrote:
Carlos and all,
Just for the reference, IANA has defined version 5 (0101) has assigned to S=
T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181=
9, but the IANA=20
assignment still holds.

Is there, just in case, any relationship between BIER and ST?
Thumb typed on my cellphone
Regards,
Sasha

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <=
xuxiaohu@huawei.com>
CC: mpls@ietf.org, <=
a href=3D"mailto:bier@ietf.org" target=3D"_blank">bier@ietf.org, sfc@ietf.org, "Dr. Ton=
y Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati=
on
Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

As for the first nibble iss= ue, will it violate the layering principle of network protocol stacks if th= e first nibble of any new encapsulation header (which could be an MPLS payl= oad)=C2=A0is used as the "MPLS payload type" field?

Reading=C2=A0draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirs= t nibble=E2=80=9D is _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. = Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.= =C2=A0

The relevant text is:
=C2=A0 =C2=A0 =C2=A0First nibble: The first 4 bits of the header are s= et to 0101; this
=C2=A0 =C2=A0ensures that the BIER header will not be confused with an= IP header
=C2=A0 =C2=A0or with the header of a pseudowire packet.

Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6"= ;

wouldn't it=C2=A0 be mo= re reasonable and sustainable=C2=A0to fix the=C2=A0problem (i.e., the lack = of a protocol field in the MPLS header) by the MPLS header itself?

=C2=A0


Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80= =9D needed.

By the way, since it's = claimed that the NSH is transport-independant, it means the NSH should be a= ble to be transported over MPLS. However, it seems that the first nibble is= sue has not be considered=C2=A0in the current NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be m= is-interpreted as IP header.

=C2=A0



There seems to be some massive confusion on this paragraph, on a numbe= r of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-in= dependent. It is by charter and by design. Second, the NSH draft does not e= ven include the term =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The SFC Encapsulation can be used in a transport-agnost= ic way.

One more comment below.

Best regards,
Xiaohu

=C2=A0

=E5=8F=91= =E4=BB=B6=E4=BA=BA:=C2=A0BIER [bier-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Tony Przygienda [tonysietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:=C2=A02016=E5=B9= =B44=E6=9C=885=E6=97=A5 22:36
=E6=94=B6=E4=BB=B6=E4=BA=BA:=C2=A0bier@ietf.org
=E4=B8=BB=E9=A2=98:=C2=A0[Bier] comments on draft-wang-= bier-ethernet-01

after reading=C2=A0

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync=C2=A0

One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text at=C2=A0= draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an = IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the F= irst Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions of 0 = and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at=C2=A0http://www.iana.org/assign= ments/version-numbers/=C2=A0?

Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at:

=C2=A0 =C2=A0It is REQUIRED, however, that applications depend upon in= -order
=C2=A0 =C2=A0packet delivery restrict the first nibble values to 0x0 a= nd 0x1.

Thanks,

=E2=80=94 Carlos.


b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating=C2=A0
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don= 9;t invent a new one=C2=A0
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE=C2=A0

--=C2=A0
We=E2= =80=99ve heard that a million monkeys at a million keyboards could produce = the complete works of Shakespeare; now, thanks to the Internet, we know tha= t is not true.
= =E2=80=94Robert Wilensky
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/lis= tinfo/mpls


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
--94eb2c07bc90820b460530013ca7-- From nobody Fri Apr 8 17:37:38 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EBF12D51A; Fri, 8 Apr 2016 17:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M366FEqMTbGe; Fri, 8 Apr 2016 17:37:33 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 B6B2012D0D3; Fri, 8 Apr 2016 17:37:32 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id i84so147062238ywc.2; Fri, 08 Apr 2016 17:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RBgywSpGwniNNMvCbr1dMjIGNSmf9xAUy9sQAzwaaZI=; b=TczCvw2nA5MwKkRR1Ywn2YH0Nh+a6DvvjtjBaZdiOFIhn07sulAQPsqRy34VmcyD2P 0MZQJcwKKd+MzOyToaYXqcgYia8I+mtk85z1/1/d6tuR4hhH7tTWMcN7AuLgiDsht4y9 1Z5itD427KinalnS3OfLA2JjbRMeLXu5fKXQi1UztQKdcaWwR+g7gpfdjMkmWpxEvz6d 53wVfrKyIArK2epFeVSaK+KZHy0ArO1OKdK91jo8d1oep00ofIhqoq4hRvC9ekykJvMm 2kp9h0e/hoY8w+0qVlXc8ZVjpaIwlmK+SxmPw4iRqLeHiwtG8wlXQN9chW6bCGVgVzpa gCdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RBgywSpGwniNNMvCbr1dMjIGNSmf9xAUy9sQAzwaaZI=; b=YRXHtJZVZ29mXUCgd+fJvOyhkCi9ZB3DpvsemreOGpvztXuxwEbS8uDM5nDIxYTvYZ w9ikvgRzfCqjZj0ds/hsmcBYRYrI35OYngmVXSewBfP5+HVYg82syILGJLzjnZCBhSE3 eFKpajMSCIQJSMphuWnpeCYPts3rjBGnS4P6iIgx/6SP7UjGgA4S6FWUzayux4zDb6Ss FgcsnejajFzNCtj/D2qY1OVFHK0zDpftcfzH0/stCSiTDLBTeIfPN/Ai0URYmGADvcNU GKJeHeVPDjHDtfTqqtLy8ezV0Y0cko2eadmnlYHUOi1ialWyGf6RBYlUrG//rp0HDrrg z5RQ== X-Gm-Message-State: AD7BkJIitaegNfb/cifOzvaGnOnGtrHAG6J+I6cjZkBVP1rZWr3IbSpKCeq881230tfT/PDh8op+hBcRiWzEmQ== MIME-Version: 1.0 X-Received: by 10.129.120.23 with SMTP id t23mr6573759ywc.45.1460162251894; Fri, 08 Apr 2016 17:37:31 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Fri, 8 Apr 2016 17:37:31 -0700 (PDT) In-Reply-To: References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> Date: Sat, 9 Apr 2016 06:07:31 +0530 Message-ID: From: Manav Bhatia To: Greg Mirsky Content-Type: multipart/alternative; boundary=94eb2c0b038c56bdfd0530028470 Archived-At: Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org, "rtg-bfd-chairs@ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 00:37:36 -0000 --94eb2c0b038c56bdfd0530028470 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, the update could be in addition of either broadcast or link local multicast > or both with appropriate normative language. But I would not agree that > these wouldn't work. > Double negatives make it very hard to parse a sentence. Anyway, why would you NOT agree that this WOULDNT work? I am telling you that link local multicasts and unicasts are dealt with differently in the data plane, so the data path being up for the former may not necessarily mean that its up for the latter as well. So tell me WHY you think this argument isnt valid? I was the L3 data plane architect in my former company for one of the product lines and i am telling you that in my box, which is very very widely deployed, your scheme will NOT work since i punt all link local packets to the CPU differently. In fact, in some cases even the TX path is different. So sure, u-BFD may very well claim that the link is up, but its possible that there may be no IP connectivity. Cheers, Manav Regards, Greg > On Apr 8, 2016 12:34 PM, "Manav Bhatia" wrote: > >> Hi Greg, >> >> Not sure i understand how it can "update RFC 7130". Is that by using a >> link local mcast IP instead of a Unicast IP? >> >> We know that, that wouldnt work. >> >> Cheers, Manav >> >> On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky < >> gregory.mirsky@ericsson.com> wrote: >> >>> Hi Reshad, >>> >>> thank you for your comments. Indeed, RFC 7130 is restricted and thus >>> hardly applicable to MC-LAG case. We realize that if this proposal is >>> adopted it not only enhance applicability on u-BFD but will update RFC = 7130. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> *From:* Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>> *Sent:* Friday, April 08, 2016 8:51 AM >>> *To:* Manav Bhatia; Gregory Mirsky >>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; >>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; >>> rtg-bfd-chairs@ietf.org >>> >>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> I agree with Manav, and nothing in RFC7130 seems to preclude using >>> different unicast IP address as destination on different member links. >>> >>> >>> >>> Regards, >>> >>> Reshad (as individual contributor). >>> >>> >>> >>> *From: *Rtg-bfd on behalf of Manav Bhatia < >>> manavbhatia@gmail.com> >>> *Date: *Friday, April 8, 2016 at 11:04 AM >>> *To: *Gregory Mirsky >>> *Cc: *"draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" < >>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org>, "mpls@ietf.org" < >>> mpls@ietf.org>, "mpls-chairs@ietf.org" , "Alia >>> Atlas (akatlas@gmail.com)" , "rtg-bfd@ietf.org" < >>> rtg-bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" >>> *Subject: *Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> Hi Greg, >>> >>> >>> >>> Why cant different micro-BFD packets use the IP address of the MC-LAG >>> end points? Ones going to router 1 will all carry the same unicast IP >>> address. The ones going towards the other router will all carry some ot= her >>> IP address, which would be configured along with the MC-LAG configs. >>> >>> >>> >>> In fact i would argue that the u-bfd packets going to different routers >>> must use different IP addresses so that you can actually verify the dat= a >>> plane liveliness. Whats the point in sending a contrived IP address if = the >>> path that it takes is different from the other regular packets? >>> >>> >>> >>> Cheers, Manav >>> >>> >>> >>> On Fri, Apr 8, 2016 at 6:09 PM, Gregory Mirsky < >>> gregory.mirsky@ericsson.com> wrote: >>> >>> Hi Manav, >>> >>> thank you for sharing insight view of discussions around RFC 7130, >>> extremely helpful. >>> >>> We believe, and Jeff is co-author of RFC 7130 too, that MC-LAG presents >>> different case and the compromise that you=E2=80=99ve pointed too is ju= stified. We >>> will add more details on the potential differences between unicast and >>> multicast fast paths in the next update. >>> >>> We are open to the discussion and always welcome comments and >>> alternative proposals. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] >>> *Sent:* Thursday, April 07, 2016 7:39 PM >>> *To:* Mach Chen >>> *Cc:* Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; >>> draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.or= g; >>> mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com) >>> *Subject:* Re: Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> >>> >>> I believe it had to do with multicast datapath (especially link local) >>> being different from the unicast datapath in most routers. Using link l= ocal >>> multicast IP addresses may not necessarily guarantee Unicast IP >>> reachability. >>> >>> >>> >>> When writing 7130 we spent quite a bit of time ensuring that we dont >>> carve out a special data path for the micro-BFD packets. Using link loc= al >>> would have made it a lot simpler. >>> >>> >>> >>> And this is where i think the current proposal is flawed -- they use >>> link local multicast to ensure IP unicast reachability which is incorre= ct. >>> >>> >>> >>> Cheers, Manav >>> >>> >>> >>> On Thu, Apr 7, 2016 at 11:16 PM, Mach Chen wrote= : >>> >>> Hi Greg and all, >>> >>> >>> >>> I just have quick review on the drafts. If my understanding is correct, >>> the idea is to use multicast destination address other than unicast add= ress >>> when sending BFD packets over LAG links. And actually this idea has be= en >>> proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00 (th= e >>> predecessor of RFC 7130). And at that time, the co-authors of RFC 7130 = did >>> discuss the idea of using multicast destination address, but for some >>> reason I forget now(I may need to reiterate the discussions on the >>> archive), the idea was abandoned, although I still think multicast >>> destination address is a smart idea. >>> >>> >>> >>> Best regards, >>> >>> Mach >>> ------------------------------ >>> >>> *From:* Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky = [ >>> gregory.mirsky@ericsson.com] >>> *Sent:* Tuesday, April 05, 2016 6:16 >>> *To:* rtg-bfd@ietf.org; mpls@ietf.org >>> *Cc:* draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; >>> rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas ( >>> akatlas@gmail.com) >>> *Subject:* Two new drafts on (micro-)BFD over MC-LAG interfaces >>> >>> Dear All, >>> >>> two new drafts, related to RFC 7130, were published before the meeting: >>> >>> =C2=B7 BFD on MC-LAG interfaces in IP network >>> >>> >>> =C2=B7 BFD on MC-LAG interfaces in IP/MPLS network >>> >>> >>> >>> >>> Greatly appreciate your reviews, comments, questions and suggestions. >>> >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> --94eb2c0b038c56bdfd0530028470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

the update= could be in addition of either broadcast or link local multicast or both w= ith appropriate normative language. But I would not agree that these wouldn= 't work.


Double negatives make= it very hard to parse a sentence.

Anyway, why wou= ld you NOT agree that this WOULDNT work?

I am tell= ing you that link local multicasts and unicasts are dealt with differently = in the data plane, so the data path being up for the former may not necessa= rily mean that its up for the latter as well. So tell me WHY you think this= argument isnt valid? I was the L3 data plane architect in my former compan= y for one of the product lines and i am telling you that in my box, which i= s very very widely deployed, your scheme will NOT work since i punt all lin= k local packets to the CPU differently. In fact, in some cases even the TX = path is different. So sure, u-BFD may very well claim that the link is up, = but its possible that there may be no IP connectivity.

=
Cheers, Manav

Regards, Greg

On Apr 8, 2016 12:34 PM, = "Manav Bhatia" <manavbhatia@gmail.com> wrote:
<= /div>
Hi Greg,

Not sure i understand how it can "= ;update RFC 7130". Is that by using a link local mcast IP instead of a= Unicast IP?

We know that, that wouldnt work.

Cheers, Manav
On Fri, Apr 8, 2016 at 9:44 PM, Gregory Mirsky = <gregory.mirsky@ericsson.com> wrote:

Hi Reshad,<= /span>

thank you for your commen= ts. Indeed, RFC 7130 is restricted and thus hardly applicable to MC-LAG cas= e. We realize that if this proposal is adopted it not only enhance applicability on u-BFD but will update RFC 7130.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Greg

=C2=A0

From: Reshad R= ahman (rrahman) [mailto:rrahman@cisco.com]
Sent: Friday, April 08, 2016 8:51 AM
To: Manav Bhatia; Gregory Mirsky
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; <= a href=3D"mailto:mpls@ietf.org" target=3D"_blank">mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatl= as@gmail.com); rt= g-bfd@ietf.org; rtg-bfd-chairs@ietf.org


Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0

I agree with Manav, and not= hing in RFC7130 seems to preclude using different unicast IP address as des= tination on different member links.

=C2=A0=

Regards,

Reshad (as individual contr= ibutor).

=C2=A0=

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on beha= lf of Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, April 8, 2016 at 11:04 AM
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org<= /a>" <draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org= >, "mpls@ietf.or= g" <mpls@ietf.org&g= t;, "mpls-ch= airs@ietf.org" <mpls-chairs@ietf.org>, "Alia Atlas (akatlas@gmail.com)" <akatlas@gmail.com&= gt;, "rtg-bfd@ietf.o= rg" <rtg-= bfd@ietf.org>, "rtg-bfd-chairs@ietf.org" <rtg-bfd-chairs@ietf.org>
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces=

=C2=A0=

Hi Greg,

=C2=A0=

Why cant different micro-BF= D packets use the IP address of the MC-LAG end points? Ones going to router= 1 will all carry the same unicast IP address. The ones going towards the other router will all carry some other IP address, which= would be configured along with the MC-LAG configs.

=C2=A0=

In fact i would argue that = the u-bfd packets going to different routers must use different IP addresse= s so that you can actually verify the data plane liveliness. Whats the point in sending a contrived IP address if the path that it take= s is different from the other regular packets?

=C2=A0=

Cheers, Manav=

=C2=A0=

On Fri, Apr 8, 2016 at 6:09= PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

thank you for sharing ins= ight view of discussions around RFC 7130, extremely helpful.

We believe, and Jeff is c= o-author of RFC 7130 too, that MC-LAG presents different case and the compr= omise that you=E2=80=99ve pointed too is justified. We will add more details on = the potential differences between unicast and multicast fast paths in the n= ext update.

We are open to the discus= sion and always welcome comments and alternative proposals.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bhatia [mailto:= manavbhatia@gmail.com]
Sent: Thursday, April 07, 2016 7:39 PM
To: Mach Chen
Cc: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

I believe it had to do w= ith multicast datapath (especially link local) being different from the uni= cast datapath in most routers. Using link local multicast IP addresses may not necessarily guarantee Unicast IP reachability.=C2=A0<= u>

=C2=A0

When writing 7130 we spe= nt quite a bit of time ensuring that we dont carve out a special data path = for the micro-BFD packets. Using link local would have made it a lot simpler.

=C2=A0

And this is where i thin= k the current proposal is flawed -- they use link local multicast to ensure= IP unicast reachability which is incorrect.

=C2=A0

Cheers, Manav<= /u>

=C2=A0

On Thu, Apr 7, 2016 at 1= 1:16 PM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Greg and all,=

=C2=A0=

I just have quick review on the drafts. If my un= derstanding is correct, the idea is to use multicast destination address ot= her than unicast address when=C2=A0=C2=A0sending BFD packets over LAG links. And actually this idea has been proposed in https://tools.ietf.org/html/draft-chen-bfd-interface-00=C2=A0(the prede= cessor of RFC 7130). And at=C2=A0that time, the co-authors of RFC 7130 did = discuss=C2=A0the idea of using multicast destination address, but for some = reason I forget now(I may need to reiterate the discussions on the archive), the idea was abandoned, although I still thin= k multicast destination address is a smart idea.

=C2=A0=

Best regards,=

Mach=C2=A0

From: Rtg-bfd [rtg-bfd-bounces@ietf.org] on behalf of Gregory Mirsky [gregory.mirsky@ericsson.com]
Sent: Tuesday, April 05, 2016 6:16
To: rtg-bfd@ie= tf.org; mpls@ietf.org
Cc: draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd-chairs@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com)
Subject: Two new drafts on (micro-)BFD over MC-LAG interfaces=

Dear All,<= /span>

two new drafts, related = to RFC 7130, were published before the meeting:

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfaces= in IP network

=C2=B7=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BFD on MC-LAG interfac= es in IP/MPLS network

=C2=A0

Greatly appreciate your = reviews, comments, questions and suggestions.

=C2=A0

Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0

=C2=A0=



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


--94eb2c0b038c56bdfd0530028470-- From nobody Fri Apr 8 17:54:14 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6571212D0C7 for ; Fri, 8 Apr 2016 17:54:13 -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 oc-K7-Q3d3QC for ; Fri, 8 Apr 2016 17:54:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C30812D0C0 for ; Fri, 8 Apr 2016 17:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5470; q=dns/txt; s=iport; t=1460163251; x=1461372851; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fWWs9UslSlakgzddSPPgDsq9WOJBfl10l4s0aAmuCrE=; b=dQGAiT2Dk4wAZ8Qj5U6TvhX9yt6vB0JqxfPgPmiG5qAMLLXHhl9Gb6vp uF4VsZ1kYyICyl+yHJ8pHrkd507Obbk46F0QznB/het2K9DyyVoGeA5GM MopPCSpaPBHX/prUtOwhtZzIdRByllvlGuel4446/t4tN9KWu6BrP1R5D A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLCABCUghX/51dJa1cgzdTfQanc5JaA?= =?us-ascii?q?Q2BcyGFbAIcgRQ4FAEBAQEBAQFlJ4RBAQEBAwEjET4MBwYBCBEDAQIDAiYCBDA?= =?us-ascii?q?VCAoEARKIHwgOrmWRZwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEfIUkgXWCVoc/K?= =?us-ascii?q?4IrBZgEAYV2iBWPDY8kAR4BAUKCBBmBSmwBiDp+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="89855070" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2016 00:54:10 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u390sA7F005851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Apr 2016 00:54:10 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 19:54:09 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 19:54:09 -0500 From: "Rajiv Asati (rajiva)" To: Eric Gray , "mpls@ietf.org" Thread-Topic: [mpls] YANG Data Model for MPLS LDP and mLDP Thread-Index: AQHRkfpSY9I+d44DRkmey74svOJp4A== Date: Sat, 9 Apr 2016 00:54:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.255.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] YANG Data Model for MPLS LDP and mLDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 00:54:14 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGZvciBwb2ludGluZyBvdXQgdGhpcyBleGNlcHRpb24uIFRoaXMg Y2VydGFpbmx5IGlzIHdvcnRoIGEgYml0IG9mIGRpc2N1c3Npb24gKGV2ZW4gdGhvdWdoIHdlIG1h eSB3ZWxsIGJlIHNwbGl0dGluZyBoYWlyKS4gDQoNCkl0IG1pZ2h0IGJlIHJlYXNvbmFibGUgdG8g c2F5IHRoYXQgdGhlIOKAnHBlZXJpbmfigJ0gcmVsYXRpb25zaGlwIGRvZXMgTk9UIHN1cnZpdmUg ZHVyaW5nIGdyYWNlZnVsIHJlc3RhcnQsIGV2ZW4gdGhvdWdoIGxhYmVsIGJpbmRpbmdzIGRvbuKA mXQgZ2V0IGRlbGV0ZWQgdXB0byB0aGUgdGhlIGdyYWNlIHBlcmlvZC4gVGhlIHJlYXNvbiBpcyB0 aGF0IGFmdGVyIHRoZSBzZXNzaW9uIGlzIGNsb3NlZCwgbmVpdGhlciBMU1JzIGNvdWxkIHNlbmQg YW55IG1lc3NhZ2VzIChLZWVwQWxpdmUsIEFkZHJlc3MvV2l0aGRyYXcsIE5vdGlmaWNhdGlvbiwg TGFiZWwgTWFwcGluZy9SZXF1ZXN0L1dpdGhkcmF3L0Fib3J0L1JlbGVhc2UgZXRjLikgYXMgZXhw ZWN0ZWQvcmVxdWlyZWQgZHVyaW5nIHRoZSDigJxwZWVyaW5n4oCdIHJlbGF0aW9uc2hpcC4NCg0K V2l0aCB0aGF0IGluIG1pbmQsIHRoZSBiZWxvdyBkZWZpbml0aW9uIHNlZW1zIHJlYXNvbmFibHkg YWNjdXJhdGUgZnJvbSBtb2RlbGluZyBwb2ludCBvZiB2aWV3Og0KDQovLw0KUGVlcjogQW4gTERQ IHNlc3Npb24gd2hpY2ggaGFzIHN1Y2Nlc3NmdWxseSBwcm9ncmVzc2VkIGJleW9uZCBpdHMgaW5p dGlhbGl6YXRpb24NCnBoYXNlIGFuZCBpcyByZWFkeSBmb3IgYmluZGluZyBleGNoYW5nZS4NCi8v DQoNCg0KSGF2aW5nIHNhaWQgdGhlIGFib3ZlLCBpdCBkb2VzIE5PVCBodXJ0IHRvIGFkZCBhIG5v dGUgcmlnaHQgYmVsb3cgdGhlIGRlZmluaXRpb24uIFNvbWV0aGluZyBsaWtlOiBEdXJpbmcgR3Jh Y2VmdWwgUmVzdGFydCB7UkZDMzQ3OCksIExTUnMgbXVzdCBob2xkIG9uIHRvIHRoZSBsYWJlbCBi aW5kaW5ncyB1cHRvIHRoZSBncmFjZSBwZXJpb2QgZXZlbiBhZnRlciB0aGUg4oCcc2Vzc2lvbuKA nSBpcyBkZWxldGVkLg0KDQpUaG91Z2h0cz8gDQoNCg0KDQoNCg0KPiBTcGVjaWZpY2FsbHksIHdo aWxlIHRoZSBkZWZpbml0aW9ucyBzaG93biBhcmUgY2xvc2VseSByZWxhdGVkIHRvIHRoZSBkZWZp bml0aW9ucyBvcmlnaW5hbGx5IHVzZWQgaW4gUkZDIDUwMzYgKGFuZA0KPiBSRkMgMzAzNiBiZWZv cmUgdGhhdCksDQogDQoNCkkgYWdyZWUuIEhvd2V2ZXIsIHRoZSBwb2ludCB3YXMgdGhhdCByZmM1 MDM2IGxvb3NlbHkgdXNlZCB0aGVzZSDigJxuZWlnaGJvcnPigJ0gYW5kIOKAnHBlZXJzIiBhbmQg bWl4ZWQgdGhlaXIgdXNhZ2UuIEluY2x1ZGluZyA0IGV4YW1wbGVzIGJlbG93ICh3aGVyZSAxc3Qg dHdvIHNob3VsZCBoYXZlIHVzZWQg4oCccGVlcnPigJ0gaW5zdGVhZCBvZiDigJxuZWlnaGJvcnPi gJ0sIGFuZCBsYXN0IDIgc2hvdWxkIGhhdmUgdXNlIOKAnG5laWdoYm9yc+KAnSBpbnN0ZWFkIG9m IOKAnHBlZXJz4oCdKTo6DQogDQoNCjIuNi4xLjEuICBJbmRlcGVuZGVudCBMYWJlbCBEaXN0cmli dXRpb24gQ29udHJvbA0KLi4NCg0KV2hlbiB1c2luZyBpbmRlcGVuZGVudCBMU1AgY29udHJvbCwg ZWFjaCBMU1IgbWF5IGFkdmVydGlzZSBsYWJlbA0KICAgbWFwcGluZ3MgdG8gaXRzIG5laWdoYm9y cyBhdCBhbnkgdGltZSBpdCBkZXNpcmVzLiAgRm9yIGV4YW1wbGUsIHdoZW4NCi8vDQoyLjYuMi4g IExhYmVsIFJldGVudGlvbiBNb2RlDQouLg0KDQogICBiaW5kaW5nIGZvciBhIEZFQyBsZWFybmVk IGZyb20gYSBuZWlnaGJvciB0aGF0IGlzIG5vdCBpdHMgbmV4dCBob3ANCiAgIGZvciB0aGUgRkVD Lg0KLy8NCg0KDQoyLjIuMi4gIExEUCBJZGVudGlmaWVycw0KLi4NCg0KICAgQSBzaXR1YXRpb24g d2hlcmUgYW4gTFNSIHdvdWxkIG5lZWQgdG8gYWR2ZXJ0aXNlIG1vcmUgdGhhbiBvbmUgbGFiZWwN CiAgIHNwYWNlIHRvIGEgcGVlciANCi8vDQoNCjIuMi4xLiAgTGFiZWwgU3BhY2VzDQouLg0KDQog ICAgICAgICBOb3RlIHRoYXQgdGhlIHVzZSBvZiBhIHBlciBpbnRlcmZhY2UgbGFiZWwgc3BhY2Ug b25seSBtYWtlcw0KICAgICAgICAgc2Vuc2Ugd2hlbiB0aGUgTERQIHBlZXJzIGFyZSAiZGlyZWN0 bHkgY29ubmVjdGVkIiBvdmVyIGFuIGludGVyZmFjZSwNCi8vDQoNCg0KDQoNCi0tIA0KQ2hlZXJz LA0KUmFqaXYgQXNhdGkNCkRpc3Rpbmd1aXNoZWQgRW5naW5lZXIsIENpc2NvDQoNCg0KDQoNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBFcmljIEdyYXkgPGVyaWMuZ3JheUBlcmljc3Nvbi5jb20+ DQpEYXRlOiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiBhdCA5OjE1IEFNDQpUbzogIm1wbHNAaWV0 Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDogW21wbHNdIFlBTkcgRGF0YSBNb2RlbCBm b3IgTVBMUyBMRFAgYW5kIG1MRFANCg0KPkZvbGtzLA0KPg0KPg0KPlR1ZXNkYXkgZXZlbmluZywg YXQgdGhlIGpvaW50IFRFQVMvTVBMUy9QQ0UgbWVldGluZywgUmFqaXYgcHJlc2VudGVkIHRoZSB3 b3JrIGhlIGFuZCBoaXMgY28tYXV0aG9ycyBoYWQgZG9uZSBvbiBhIGRyYWZ0IHJlbGF0ZWQgdG8g TVBMUyBMRFAgYW5kIG1MRFAuICANCj4NCj4NCj5UaGUgZHJhZnQgaXMgYXQ6IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhemEtbXBscy1sZHAtbWxkcC15YW5nICA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmF6YS1tcGxzLWxkcC1tbGRwLXlh bmclQzIlQTA+IChvcg0KPiBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmF6 YS1tcGxzLWxkcC1tbGRwLXlhbmcpLg0KPg0KPg0KPlRoZSBzbGlkZXMgY2FuIGJlIGZvdW5kIGF0 OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlkZXMvc2xpZGVzLTk1LXRl YXMtMTQucHB0eCANCj4NCj4NCj5BZnRlcndhcmRzLCBzZXZlcmFsIHBlb3BsZSBkaXNjdXNzZWQg dGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBzb21ldGhpbmcgbm90LXF1aXRlIHJpZ2h0IGFib3V0IHRo ZSBkZWZpbml0aW9uIG9mICJwZWVyIiB0aGV5IHdvdWxkIGJlIHVzaW5nIGluIHRoZWlyIG1vZGVs cy4NCj4NCj4NCj5TcGVjaWZpY2FsbHksIHdoaWxlIHRoZSBkZWZpbml0aW9ucyBzaG93biBhcmUg Y2xvc2VseSByZWxhdGVkIHRvIHRoZSBkZWZpbml0aW9ucyBvcmlnaW5hbGx5IHVzZWQgaW4gUkZD IDUwMzYgKGFuZCBSRkMgMzAzNiBiZWZvcmUgdGhhdCksIHRoZXkgZG8gbm90IHF1aXRlIGZpdCB3 aGVuIGNvbnNpZGVyaW5nIExEUCBncmFjZWZ1bCByZXN0YXJ0IChSRkMgMzQ3OCkgLSBiZWNhdXNl IHRoZSBwZWVyIHJlbGF0aW9uc2hpcCBzdXJ2aXZlcyB0aGUNCj4gc2Vzc2lvbiByZWxhdGlvbnNo aXAgd2hlbiB1c2luZyBncmFjZWZ1bCByZXN0YXJ0IC0gaS5lLiAtIHRoZSBsYWJlbHMgZGlzdHJp YnV0ZWQgYnkgYSBwZWVyIHJlbWFpbiB2YWxpZCBmb3Igc29tZSB0aW1lIGFmdGVyIHRoZSBzZXNz aW9uIGVuZHMuIEluIGZhY3QsIHdpdGggTERQIGdyYWNlZnVsIHJlc3RhcnQsIHRoZSBpbnRlbnRp b24gaXMgdGhhdCB0aGUgbGFiZWxzIHByZXZpb3VzbHkgZGlzdHJpYnV0ZWQgYnkgdGhlIHBlZXIg d291bGQgcmVtYWluIHZhbGlkIHVudGlsIGV4cGxpY2l0bHkgd2l0aGRyYXduIGluIHRoZSBuZXh0 IChvciBhIHN1YnNlcXVlbnQpIHNlc3Npb24uDQo+DQo+DQo+QWZ0ZXIgc29tZSBkaXNjdXNzaW9u LCBib3RoIGFmdGVyIHRoZSBtZWV0aW5nIGFuZCBlYXJsaWVyIHRvZGF5LCBpdCBzZWVtcyBsaWtl bHkgdGhpcyBtYXkgYmUgb25seSBvbmUgZXhhbXBsZSBvZiBhIGNhc2Ugd2hlcmUgdGhlIGRyYWZ0 IG1heSBub3QgYWRlcXVhdGVseSBhZGRyZXNzIHRoZSBpbXBsaWNhdGlvbnMgb2YgTERQIGdyYWNl ZnVsIHJlc3RhcnQuDQo+DQo+DQo+LS0NCj5FcmljIEdyYXkNCj4NCj4NCj5TZW50IGZyb20gbXkg aVBhZA0K From nobody Fri Apr 8 21:16:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270312D62B; Fri, 8 Apr 2016 21:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 qGCQZwLGqU1W; Fri, 8 Apr 2016 21:16:26 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE8112D5B8; Fri, 8 Apr 2016 21:16:25 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-f4-57087bc4440c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AB.6D.30335.4CB78075; Sat, 9 Apr 2016 05:49:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Sat, 9 Apr 2016 00:16:24 -0400 From: Gregory Mirsky To: Manav Bhatia , Greg Mirsky Thread-Topic: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4P//39qAgAAYVICAAF4BgIAACP5Q Date: Sat, 9 Apr 2016 04:16:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyuXRPrO6Rao5wg6/fTSwObDrIaPFt2lNW i8uT2tgt1l0+xWZxa+lKVotrK1rZLT7/2cbowO4x5fdGVo+ds+6yeyxZ8pPJ48vlz2wBLFFc NimpOZllqUX6dglcGT27L7AVNC1nrri8+jVLA2PDHOYuRk4OCQETiVvvzzFC2GISF+6tZ+ti 5OIQEjjKKLHuyDkWCGcZo8THz20sIFVsAkYSLzb2sHcxcnCICPhKLDiqDlLDLDCVSeLyylWs IDXCAh4StxdMALNFBDwlNr86ywpRnyexb309SJhFQEXi+JEDbCA2L9CY7i2HoHatYpX49G0J E0iCUyBQ4uPzp2BzGIGu+35qDVicWUBc4taT+UwQVwtILNlzHuobUYmXj/+xQthKEh9/z2eH qM+XWHGlkRFimaDEyZlPWCYwis5CMmoWkrJZSMpmAZ3NLKApsX6XPkSJosSU7ofsELaGROuc uezI4gsY2VcxcpQWF+TkphsZbGIExucxCTbdHYz3p3seYhTgYFTi4VVI4ggXYk0sK67MPcQo wcGsJMK7oAIoxJuSWFmVWpQfX1Sak1p8iFGag0VJnLcx+F+YkEB6YklqdmpqQWoRTJaJg1Oq gVFwa83Z5Y9sFum1zp72a7dNP9vuvJfNRskZ/Rve9eh+6viWZMiqNHl78zWxMq4vHGpHco+c qrruq8sokvluYxFv3FWrz0tsPzZNV9Ld/XinrNK8w7JZS987s9lMt6rwsIiIMzR4pOX2KICD mf9gfcTRFkt77uWKesoSz9g2safx5ZzczXPjlRJLcUaioRZzUXEiAC1P3PfLAgAA Archived-At: Cc: "Reshad Rahman \(rrahman\)" , "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "rtg-bfd@ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 04:16:29 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp0aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNl cyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRyYWZ0cyB0byBh ZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24gaW4gb3JkZXIg dG8gdHJpZ2dlciBMQUNQIGNvbnZlcmdlbmNlIGFuZCwgc3Vic2VxdWVudGx5LCBzd2l0Y2hvdmVy IHdpdGhpbiB0aGUgUmVkdW5kYW5jeSBHcm91cCBpbiBBY3RpdmUtU3RhbmRieSBjYXNlLiBIZW5j ZSBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBMMyBhZGRyZXNzZXMgYXJlIHF1aXRlIGRpc3Rh bnQgZnJvbSBMMiBmYXN0IHBhdGggYW5kIHByb2Nlc3NpbmcgdXN1YWxseSB0YWtlbiBieSBDQ00g ZnJhbWVzLiBPZiBjb3Vyc2UsIG9uZSBjYW4gdXNlIENGTSBwZXIgTEFHIENvbnN0aXR1ZW50IExp bmssIGFuZCBJIGhhdmUgaW1wbGVtZW50ZWQgdGhhdCBhbmQgaXQgaW50ZXJvcGVyYXRlcyB3aXRo IGFub3RoZXIgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgdmVuZG9yLCBidXQgb3BlcmF0b3JzIHBy ZWZlciBlYXNlIG9mIEJGRCBwcm92aXNpb25pbmcuIFRodXMgSeKAmXZlIHRvIHByb3ZpZGUgdGhl bSB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhhdCBpbiBzb21l IGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMgZnVuY3Rpb25h bCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0LCBlbmdpbmUu IEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29udGludWluZyBh cmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHByb2Nlc3NpbmcgaXMgZnJv bSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tIEwyIHBhdGguIEF0IHRoZSBl bmQsIGFzIEkgdGhpbmssIGl0IGlzIHVwIHRvIG9wZXJhdG9ycyB0byBkZWNpZGUgd2hldGhlciB0 aGV5IGFyZSBjb21mb3J0YWJsZSB3aXRoIHRoaXMgbWVjaGFuaXNtIG9yIHdvdWxkIHJlcXVpcmUg ZGVmZWN0IGRldGVjdGlvbiBhdCBMMi4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFtt YWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAx NiA1OjM4IFBNDQpUbzogR3JlZyBNaXJza3kNCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsg ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmRA aWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBydGctYmZkLWNo YWlyc0BpZXRmLm9yZzsgR3JlZ29yeSBNaXJza3kNClN1YmplY3Q6IFJlOiBbbXBsc10gVHdvIG5l dyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcw0KDQpIaSBHcmVn LA0KDQoNCnRoZSB1cGRhdGUgY291bGQgYmUgaW4gYWRkaXRpb24gb2YgZWl0aGVyIGJyb2FkY2Fz dCBvciBsaW5rIGxvY2FsIG11bHRpY2FzdCBvciBib3RoIHdpdGggYXBwcm9wcmlhdGUgbm9ybWF0 aXZlIGxhbmd1YWdlLiBCdXQgSSB3b3VsZCBub3QgYWdyZWUgdGhhdCB0aGVzZSB3b3VsZG4ndCB3 b3JrLg0KDQpEb3VibGUgbmVnYXRpdmVzIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHBhcnNlIGEgc2Vu dGVuY2UuDQoNCkFueXdheSwgd2h5IHdvdWxkIHlvdSBOT1QgYWdyZWUgdGhhdCB0aGlzIFdPVUxE TlQgd29yaz8NCg0KSSBhbSB0ZWxsaW5nIHlvdSB0aGF0IGxpbmsgbG9jYWwgbXVsdGljYXN0cyBh bmQgdW5pY2FzdHMgYXJlIGRlYWx0IHdpdGggZGlmZmVyZW50bHkgaW4gdGhlIGRhdGEgcGxhbmUs IHNvIHRoZSBkYXRhIHBhdGggYmVpbmcgdXAgZm9yIHRoZSBmb3JtZXIgbWF5IG5vdCBuZWNlc3Nh cmlseSBtZWFuIHRoYXQgaXRzIHVwIGZvciB0aGUgbGF0dGVyIGFzIHdlbGwuIFNvIHRlbGwgbWUg V0hZIHlvdSB0aGluayB0aGlzIGFyZ3VtZW50IGlzbnQgdmFsaWQ/IEkgd2FzIHRoZSBMMyBkYXRh IHBsYW5lIGFyY2hpdGVjdCBpbiBteSBmb3JtZXIgY29tcGFueSBmb3Igb25lIG9mIHRoZSBwcm9k dWN0IGxpbmVzIGFuZCBpIGFtIHRlbGxpbmcgeW91IHRoYXQgaW4gbXkgYm94LCB3aGljaCBpcyB2 ZXJ5IHZlcnkgd2lkZWx5IGRlcGxveWVkLCB5b3VyIHNjaGVtZSB3aWxsIE5PVCB3b3JrIHNpbmNl IGkgcHVudCBhbGwgbGluayBsb2NhbCBwYWNrZXRzIHRvIHRoZSBDUFUgZGlmZmVyZW50bHkuIElu IGZhY3QsIGluIHNvbWUgY2FzZXMgZXZlbiB0aGUgVFggcGF0aCBpcyBkaWZmZXJlbnQuIFNvIHN1 cmUsIHUtQkZEIG1heSB2ZXJ5IHdlbGwgY2xhaW0gdGhhdCB0aGUgbGluayBpcyB1cCwgYnV0IGl0 cyBwb3NzaWJsZSB0aGF0IHRoZXJlIG1heSBiZSBubyBJUCBjb25uZWN0aXZpdHkuDQoNCkNoZWVy cywgTWFuYXYNCg0KDQpSZWdhcmRzLCBHcmVnDQpPbiBBcHIgOCwgMjAxNiAxMjozNCBQTSwgIk1h bmF2IEJoYXRpYSIgPG1hbmF2YmhhdGlhQGdtYWlsLmNvbTxtYWlsdG86bWFuYXZiaGF0aWFAZ21h aWwuY29tPj4gd3JvdGU6DQpIaSBHcmVnLA0KDQpOb3Qgc3VyZSBpIHVuZGVyc3RhbmQgaG93IGl0 IGNhbiAidXBkYXRlIFJGQyA3MTMwIi4gSXMgdGhhdCBieSB1c2luZyBhIGxpbmsgbG9jYWwgbWNh c3QgSVAgaW5zdGVhZCBvZiBhIFVuaWNhc3QgSVA/DQoNCldlIGtub3cgdGhhdCwgdGhhdCB3b3Vs ZG50IHdvcmsuDQoNCkNoZWVycywgTWFuYXYNCg0KT24gRnJpLCBBcHIgOCwgMjAxNiBhdCA5OjQ0 IFBNLCBHcmVnb3J5IE1pcnNreSA8Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPG1haWx0bzpn cmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIFJlc2hhZCwNCnRoYW5rIHlv dSBmb3IgeW91ciBjb21tZW50cy4gSW5kZWVkLCBSRkMgNzEzMCBpcyByZXN0cmljdGVkIGFuZCB0 aHVzIGhhcmRseSBhcHBsaWNhYmxlIHRvIE1DLUxBRyBjYXNlLiBXZSByZWFsaXplIHRoYXQgaWYg dGhpcyBwcm9wb3NhbCBpcyBhZG9wdGVkIGl0IG5vdCBvbmx5IGVuaGFuY2UgYXBwbGljYWJpbGl0 eSBvbiB1LUJGRCBidXQgd2lsbCB1cGRhdGUgUkZDIDcxMzAuDQoNClJlZ2FyZHMsDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogUmVzaGFkIFJhaG1hbiAocnJh aG1hbikgW21haWx0bzpycmFobWFuQGNpc2NvLmNvbTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+ XQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA4OjUxIEFNDQpUbzogTWFuYXYgQmhhdGlh OyBHcmVnb3J5IE1pcnNreQ0KQ2M6IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29s cy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChh a2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+KTsgcnRnLWJmZEBpZXRm Lm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1h aWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCg0KSSBhZ3JlZSB3aXRo IE1hbmF2LCBhbmQgbm90aGluZyBpbiBSRkM3MTMwIHNlZW1zIHRvIHByZWNsdWRlIHVzaW5nIGRp ZmZlcmVudCB1bmljYXN0IElQIGFkZHJlc3MgYXMgZGVzdGluYXRpb24gb24gZGlmZmVyZW50IG1l bWJlciBsaW5rcy4NCg0KUmVnYXJkcywNClJlc2hhZCAoYXMgaW5kaXZpZHVhbCBjb250cmlidXRv cikuDQoNCkZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRn LWJmZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1hbmF2IEJoYXRpYSA8bWFuYXZi aGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+Pg0KRGF0ZTogRnJp ZGF5LCBBcHJpbCA4LCAyMDE2IGF0IDExOjA0IEFNDQpUbzogR3JlZ29yeSBNaXJza3kgPGdyZWdv cnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29t Pj4NCkNjOiAiZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPiIg PGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZz4+LCAibXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPj4sICJtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0 Zi5vcmc+IiA8bXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3Jn Pj4sICJBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5j b20+KSIgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+LCAicnRn LWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4iIDxydGctYmZkQGlldGYub3Jn PG1haWx0bzpydGctYmZkQGlldGYub3JnPj4sICJydGctYmZkLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+IiA8cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8bWFp bHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBUd28gbmV3IGRyYWZ0 cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkhpIEdyZWcsDQoNCldo eSBjYW50IGRpZmZlcmVudCBtaWNyby1CRkQgcGFja2V0cyB1c2UgdGhlIElQIGFkZHJlc3Mgb2Yg dGhlIE1DLUxBRyBlbmQgcG9pbnRzPyBPbmVzIGdvaW5nIHRvIHJvdXRlciAxIHdpbGwgYWxsIGNh cnJ5IHRoZSBzYW1lIHVuaWNhc3QgSVAgYWRkcmVzcy4gVGhlIG9uZXMgZ29pbmcgdG93YXJkcyB0 aGUgb3RoZXIgcm91dGVyIHdpbGwgYWxsIGNhcnJ5IHNvbWUgb3RoZXIgSVAgYWRkcmVzcywgd2hp Y2ggd291bGQgYmUgY29uZmlndXJlZCBhbG9uZyB3aXRoIHRoZSBNQy1MQUcgY29uZmlncy4NCg0K SW4gZmFjdCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcgdG8gZGlm ZmVyZW50IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3NlcyBzbyB0aGF0IHlv dSBjYW4gYWN0dWFsbHkgdmVyaWZ5IHRoZSBkYXRhIHBsYW5lIGxpdmVsaW5lc3MuIFdoYXRzIHRo ZSBwb2ludCBpbiBzZW5kaW5nIGEgY29udHJpdmVkIElQIGFkZHJlc3MgaWYgdGhlIHBhdGggdGhh dCBpdCB0YWtlcyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb3RoZXIgcmVndWxhciBwYWNrZXRzPw0K DQpDaGVlcnMsIE1hbmF2DQoNCk9uIEZyaSwgQXByIDgsIDIwMTYgYXQgNjowOSBQTSwgR3JlZ29y eSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBNYW5hdiwNCnRoYW5rIHlvdSBmb3Igc2hhcmlu ZyBpbnNpZ2h0IHZpZXcgb2YgZGlzY3Vzc2lvbnMgYXJvdW5kIFJGQyA3MTMwLCBleHRyZW1lbHkg aGVscGZ1bC4NCldlIGJlbGlldmUsIGFuZCBKZWZmIGlzIGNvLWF1dGhvciBvZiBSRkMgNzEzMCB0 b28sIHRoYXQgTUMtTEFHIHByZXNlbnRzIGRpZmZlcmVudCBjYXNlIGFuZCB0aGUgY29tcHJvbWlz ZSB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ugd2lsbCBhZGQgbW9y ZSBkZXRhaWxzIG9uIHRoZSBwb3RlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgZmFzdCBwYXRocyBpbiB0aGUgbmV4dCB1cGRhdGUuDQpXZSBhcmUgb3BlbiB0 byB0aGUgZGlzY3Vzc2lvbiBhbmQgYWx3YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0 aXZlIHByb3Bvc2Fscy4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb20+XQ0KU2VudDog VGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDc6MzkgUE0NClRvOiBNYWNoIENoZW4NCkNjOiBHcmVn b3J5IE1pcnNreTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz47IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBkcmFmdC10YW5taXItcnRnd2ctYmZk LW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1t Yy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc+OyBydGctYmZkLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBs cy1jaGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86 YWthdGxhc0BnbWFpbC5jb20+KQ0KU3ViamVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNy by0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCg0KSSBiZWxpZXZlIGl0IGhhZCB0byBkbyB3 aXRoIG11bHRpY2FzdCBkYXRhcGF0aCAoZXNwZWNpYWxseSBsaW5rIGxvY2FsKSBiZWluZyBkaWZm ZXJlbnQgZnJvbSB0aGUgdW5pY2FzdCBkYXRhcGF0aCBpbiBtb3N0IHJvdXRlcnMuIFVzaW5nIGxp bmsgbG9jYWwgbXVsdGljYXN0IElQIGFkZHJlc3NlcyBtYXkgbm90IG5lY2Vzc2FyaWx5IGd1YXJh bnRlZSBVbmljYXN0IElQIHJlYWNoYWJpbGl0eS4NCg0KV2hlbiB3cml0aW5nIDcxMzAgd2Ugc3Bl bnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0IGEg c3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGluayBs b2NhbCB3b3VsZCBoYXZlIG1hZGUgaXQgYSBsb3Qgc2ltcGxlci4NCg0KQW5kIHRoaXMgaXMgd2hl cmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0gdGhleSB1c2UgbGlu ayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hhYmlsaXR5IHdoaWNo IGlzIGluY29ycmVjdC4NCg0KQ2hlZXJzLCBNYW5hdg0KDQpPbiBUaHUsIEFwciA3LCAyMDE2IGF0 IDExOjE2IFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNo ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSBHcmVnIGFuZCBhbGwsDQoNCg0KDQpJIGp1c3Qg aGF2ZSBxdWljayByZXZpZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBj b3JyZWN0LCB0aGUgaWRlYSBpcyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mg b3RoZXIgdGhhbiB1bmljYXN0IGFkZHJlc3Mgd2hlbiAgc2VuZGluZyBCRkQgcGFja2V0cyBvdmVy IExBRyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlLTAwICh0 aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcxMzApLiBBbmQgYXQgdGhhdCB0aW1lLCB0aGUgY28tYXV0 aG9ycyBvZiBSRkMgNzEzMCBkaWQgZGlzY3VzcyB0aGUgaWRlYSBvZiB1c2luZyBtdWx0aWNhc3Qg ZGVzdGluYXRpb24gYWRkcmVzcywgYnV0IGZvciBzb21lIHJlYXNvbiBJIGZvcmdldCBub3coSSBt YXkgbmVlZCB0byByZWl0ZXJhdGUgdGhlIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhl IGlkZWEgd2FzIGFiYW5kb25lZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVz dGluYXRpb24gYWRkcmVzcyBpcyBhIHNtYXJ0IGlkZWEuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoN Ck1hY2gNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJ0Zy1iZmQg W3J0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3Jn Pl0gb24gYmVoYWxmIG9mIEdyZWdvcnkgTWlyc2t5IFtncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5j b208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBB cHJpbCAwNSwgMjAxNiA2OjE2DQpUbzogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpDYzogZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRh bm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZC1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPjsgbXBscy1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnPjsgQWxpYSBBdGxhcyAoYWthdGxhc0Bn bWFpbC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPikNClN1YmplY3Q6IFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXMNCkRlYXIgQWxsLA0KdHdv IG5ldyBkcmFmdHMsIHJlbGF0ZWQgdG8gUkZDIDcxMzAsIHdlcmUgcHVibGlzaGVkIGJlZm9yZSB0 aGUgbWVldGluZzoNCg0KwrcgICAgICAgICBCRkQgb24gTUMtTEFHIGludGVyZmFjZXMgaW4gSVAg bmV0d29yazxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXAtMDA+DQoNCsK3ICAgICAgICAgQkZEIG9uIE1DLUxBRyBpbnRlcmZhY2VzIGlu IElQL01QTFMgbmV0d29yazxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFubWly LXJ0Z3dnLWJmZC1tYy1sYWctbXBscy0wMD4NCg0KR3JlYXRseSBhcHByZWNpYXRlIHlvdXIgcmV2 aWV3cywgY29tbWVudHMsIHF1ZXN0aW9ucyBhbmQgc3VnZ2VzdGlvbnMuDQoNClJlZ2FyZHMsDQog ICAgICAgIEdyZWcNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoN Cg== --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj50aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlcyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRy YWZ0cyB0byBhZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24g aW4gb3JkZXINCiB0byB0cmlnZ2VyIExBQ1AgY29udmVyZ2VuY2UgYW5kLCBzdWJzZXF1ZW50bHks IHN3aXRjaG92ZXIgd2l0aGluIHRoZSBSZWR1bmRhbmN5IEdyb3VwIGluIEFjdGl2ZS1TdGFuZGJ5 IGNhc2UuIEhlbmNlIGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0IEwzIGFkZHJlc3NlcyBhcmUg cXVpdGUgZGlzdGFudCBmcm9tIEwyIGZhc3QgcGF0aCBhbmQgcHJvY2Vzc2luZyB1c3VhbGx5IHRh a2VuIGJ5IENDTSBmcmFtZXMuIE9mIGNvdXJzZSwgb25lIGNhbiB1c2UNCiBDRk0gcGVyIExBRyBD b25zdGl0dWVudCBMaW5rLCBhbmQgSSBoYXZlIGltcGxlbWVudGVkIHRoYXQgYW5kIGl0IGludGVy b3BlcmF0ZXMgd2l0aCBhbm90aGVyIGltcGxlbWVudGF0aW9uIGJ5IG90aGVyIHZlbmRvciwgYnV0 IG9wZXJhdG9ycyBwcmVmZXIgZWFzZSBvZiBCRkQgcHJvdmlzaW9uaW5nLiBUaHVzIEnigJl2ZSB0 byBwcm92aWRlIHRoZW0gd2l0aCBhYmlsaXR5IHRvIG1vbml0b3IgTUMtTEFHIGFuZCBleHBsYWlu IHRoYXQgaW4gc29tZSBjYXNlcw0KIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4g TDIgaXMgZnVuY3Rpb25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVs dGljYXN0LCBlbmdpbmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUg aW4gY29udGludWluZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHBy b2Nlc3NpbmcgaXMgZnJvbSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tDQog TDIgcGF0aC4gQXQgdGhlIGVuZCwgYXMgSSB0aGluaywgaXQgaXMgdXAgdG8gb3BlcmF0b3JzIHRv IGRlY2lkZSB3aGV0aGVyIHRoZXkgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhpcyBtZWNoYW5pc20g b3Igd291bGQgcmVxdWlyZSBkZWZlY3QgZGV0ZWN0aW9uIGF0IEwyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEgW21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNPGJy Pg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxicj4NCjxiPkNjOjwvYj4gUmVzaGFkIFJhaG1hbiAo cnJhaG1hbik7IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3Jn OyBydGctYmZkQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsg cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc7IEdyZWdvcnkgTWlyc2t5PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbbXBsc10gVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdyZWcs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwPnRoZSB1cGRh dGUgY291bGQgYmUgaW4gYWRkaXRpb24gb2YgZWl0aGVyIGJyb2FkY2FzdCBvciBsaW5rIGxvY2Fs IG11bHRpY2FzdCBvciBib3RoIHdpdGggYXBwcm9wcmlhdGUgbm9ybWF0aXZlIGxhbmd1YWdlLiBC dXQgSSB3b3VsZCBub3QgYWdyZWUgdGhhdCB0aGVzZSB3b3VsZG4ndCB3b3JrLg0KPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb3Vi bGUgbmVnYXRpdmVzIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHBhcnNlIGEgc2VudGVuY2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueXdheSwg d2h5IHdvdWxkIHlvdSBOT1QgYWdyZWUgdGhhdCB0aGlzIFdPVUxETlQgd29yaz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSB0ZWxsaW5n IHlvdSB0aGF0IGxpbmsgbG9jYWwgbXVsdGljYXN0cyBhbmQgdW5pY2FzdHMgYXJlIGRlYWx0IHdp dGggZGlmZmVyZW50bHkgaW4gdGhlIGRhdGEgcGxhbmUsIHNvIHRoZSBkYXRhIHBhdGggYmVpbmcg dXAgZm9yIHRoZSBmb3JtZXIgbWF5IG5vdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgaXRzIHVwIGZv ciB0aGUgbGF0dGVyIGFzIHdlbGwuIFNvIHRlbGwgbWUgV0hZIHlvdSB0aGluayB0aGlzIGFyZ3Vt ZW50DQogaXNudCB2YWxpZD8gSSB3YXMgdGhlIEwzIGRhdGEgcGxhbmUgYXJjaGl0ZWN0IGluIG15 IGZvcm1lciBjb21wYW55IGZvciBvbmUgb2YgdGhlIHByb2R1Y3QgbGluZXMgYW5kIGkgYW0gdGVs bGluZyB5b3UgdGhhdCBpbiBteSBib3gsIHdoaWNoIGlzIHZlcnkgdmVyeSB3aWRlbHkgZGVwbG95 ZWQsIHlvdXIgc2NoZW1lIHdpbGwgTk9UIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2Fs IHBhY2tldHMgdG8gdGhlIENQVSBkaWZmZXJlbnRseS4gSW4NCiBmYWN0LCBpbiBzb21lIGNhc2Vz IGV2ZW4gdGhlIFRYIHBhdGggaXMgZGlmZmVyZW50LiBTbyBzdXJlLCB1LUJGRCBtYXkgdmVyeSB3 ZWxsIGNsYWltIHRoYXQgdGhlIGxpbmsgaXMgdXAsIGJ1dCBpdHMgcG9zc2libGUgdGhhdCB0aGVy ZSBtYXkgYmUgbm8gSVAgY29ubmVjdGl2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwPlJlZ2FyZHMsIEdyZWcgPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgOCwgMjAxNiAx MjozNCBQTSwgJnF1b3Q7TWFuYXYgQmhhdGlhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFuYXZiaGF0aWFAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdyZWcsPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qgc3VyZSBpIHVu ZGVyc3RhbmQgaG93IGl0IGNhbiAmcXVvdDt1cGRhdGUgUkZDIDcxMzAmcXVvdDsuIElzIHRoYXQg YnkgdXNpbmcgYSBsaW5rIGxvY2FsIG1jYXN0IElQIGluc3RlYWQgb2YgYSBVbmljYXN0IElQPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBr bm93IHRoYXQsIHRoYXQgd291bGRudCB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgOCwgMjAxNiBh dCA5OjQ0IFBNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSBSZXNoYWQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhhbmsgeW91IGZv ciB5b3VyIGNvbW1lbnRzLiBJbmRlZWQsIFJGQyA3MTMwIGlzIHJlc3RyaWN0ZWQgYW5kIHRodXMg aGFyZGx5IGFwcGxpY2FibGUgdG8gTUMtTEFHDQogY2FzZS4gV2UgcmVhbGl6ZSB0aGF0IGlmIHRo aXMgcHJvcG9zYWwgaXMgYWRvcHRlZCBpdCBub3Qgb25seSBlbmhhbmNlIGFwcGxpY2FiaWxpdHkg b24gdS1CRkQgYnV0IHdpbGwgdXBkYXRlIFJGQyA3MTMwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzt0ZXh0LWluZGVudDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSZXNoYWQgUmFobWFuIChycmFobWFu KSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpycmFobWFuQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJyYWhtYW5AY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFw cmlsIDA4LCAyMDE2IDg6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hbmF2IEJoYXRpYTsgR3JlZ29y eSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRn d2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1w bHMtY2hhaXJzQGlldGYub3JnPC9hPjsgQWxpYSBBdGxhcyAoPGEgaHJlZj0ibWFpbHRvOmFrYXRs YXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+KTsNCjxh IGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgYWdyZWUgd2l0aCBNYW5hdiwgYW5kIG5v dGhpbmcgaW4gUkZDNzEzMCBzZWVtcyB0byBwcmVjbHVkZSB1c2luZyBkaWZmZXJlbnQgdW5pY2Fz dCBJUCBhZGRyZXNzIGFzDQogZGVzdGluYXRpb24gb24gZGlmZmVyZW50IG1lbWJlciBsaW5rcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5S ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZXNo YWQgKGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJ0Zy1iZmQgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWFuYXYgQmhhdGlhICZs dDs8YSBocmVmPSJtYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWFuYXZiaGF0aWFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBB cHJpbCA4LCAyMDE2IGF0IDExOjA0IEFNPGJyPg0KPGI+VG86IDwvYj5HcmVnb3J5IE1pcnNreSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBA dG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC10YW5taXItcnRnd2ctYmZkLW1j LWxhZy1pcEB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFm dC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPiZn dDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tcGxzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJz QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OywNCiAmcXVv dDtBbGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+Jmd0OywNCiAm cXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpydGctYmZkLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1iZmQtY2hhaXJz QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFR3byBuZXcgZHJhZnRz IG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgR3JlZywNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPldoeSBjYW50IGRpZmZlcmVudCBtaWNyby1CRkQgcGFja2V0 cyB1c2UgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIE1DLUxBRyBlbmQgcG9pbnRzPyBPbmVzIGdvaW5n IHRvIHJvdXRlcg0KIDEgd2lsbCBhbGwgY2FycnkgdGhlIHNhbWUgdW5pY2FzdCBJUCBhZGRyZXNz LiBUaGUgb25lcyBnb2luZyB0b3dhcmRzIHRoZSBvdGhlciByb3V0ZXIgd2lsbCBhbGwgY2Fycnkg c29tZSBvdGhlciBJUCBhZGRyZXNzLCB3aGljaCB3b3VsZCBiZSBjb25maWd1cmVkIGFsb25nIHdp dGggdGhlIE1DLUxBRyBjb25maWdzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SW4gZmFjdCBpIHdvdWxkIGFyZ3VlIHRoYXQgdGhlIHUtYmZkIHBhY2tldHMgZ29pbmcg dG8gZGlmZmVyZW50IHJvdXRlcnMgbXVzdCB1c2UgZGlmZmVyZW50IElQIGFkZHJlc3Nlcw0KIHNv IHRoYXQgeW91IGNhbiBhY3R1YWxseSB2ZXJpZnkgdGhlIGRhdGEgcGxhbmUgbGl2ZWxpbmVzcy4g V2hhdHMgdGhlIHBvaW50IGluIHNlbmRpbmcgYSBjb250cml2ZWQgSVAgYWRkcmVzcyBpZiB0aGUg cGF0aCB0aGF0IGl0IHRha2VzIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlciByZWd1bGFyIHBh Y2tldHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsIE1h bmF2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PbiBGcmksIEFwciA4 LCAyMDE2IGF0IDY6MDkgUE0sIEdyZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3Jl Z29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ29yeS5taXJza3lA ZXJpY3Nzb24uY29tPC9hPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPnRoYW5rIHlvdSBmb3Igc2hhcmluZyBpbnNpZ2h0IHZpZXcgb2YgZGlzY3Vzc2lvbnMgYXJv dW5kIFJGQyA3MTMwLCBleHRyZW1lbHkgaGVscGZ1bC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XZSBiZWxpZXZlLCBhbmQgSmVmZiBpcyBjby1hdXRob3Igb2YgUkZDIDcxMzAgdG9v LCB0aGF0IE1DLUxBRyBwcmVzZW50cyBkaWZmZXJlbnQgY2FzZSBhbmQgdGhlIGNvbXByb21pc2UN CiB0aGF0IHlvdeKAmXZlIHBvaW50ZWQgdG9vIGlzIGp1c3RpZmllZC4gV2Ugd2lsbCBhZGQgbW9y ZSBkZXRhaWxzIG9uIHRoZSBwb3RlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB1bmljYXN0IGFu ZCBtdWx0aWNhc3QgZmFzdCBwYXRocyBpbiB0aGUgbmV4dCB1cGRhdGUuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XZSBhcmUgb3BlbiB0byB0aGUgZGlzY3Vzc2lvbiBhbmQgYWx3 YXlzIHdlbGNvbWUgY29tbWVudHMgYW5kIGFsdGVybmF0aXZlIHByb3Bvc2Fscy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IE1hbmF2DQogQmhhdGlhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmF2YmhhdGlhQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmF2YmhhdGlhQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDA3LCAyMDE2IDc6MzkgUE08YnI+DQo8Yj5Ubzo8 L2I+IE1hY2ggQ2hlbjxicj4NCjxiPkNjOjwvYj4gR3JlZ29yeSBNaXJza3k7IDxhIGhyZWY9Im1h aWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJmZEBpZXRmLm9yZzwv YT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1s YWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1ydGd3 Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1i ZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGctYmZkLWNoYWlyc0BpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBBbGlhIEF0bGFzICg8YSBocmVmPSJt YWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNv bTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8t KUJGRCBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGJlbGlldmUgaXQgaGFkIHRvIGRvIHdpdGgg bXVsdGljYXN0IGRhdGFwYXRoIChlc3BlY2lhbGx5IGxpbmsgbG9jYWwpIGJlaW5nIGRpZmZlcmVu dCBmcm9tIHRoZSB1bmljYXN0IGRhdGFwYXRoIGluIG1vc3Qgcm91dGVycy4gVXNpbmcgbGluayBs b2NhbCBtdWx0aWNhc3QNCiBJUCBhZGRyZXNzZXMgbWF5IG5vdCBuZWNlc3NhcmlseSBndWFyYW50 ZWUgVW5pY2FzdCBJUCByZWFjaGFiaWxpdHkuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2hlbiB3cml0aW5nIDcxMzAgd2Ug c3BlbnQgcXVpdGUgYSBiaXQgb2YgdGltZSBlbnN1cmluZyB0aGF0IHdlIGRvbnQgY2FydmUgb3V0 IGEgc3BlY2lhbCBkYXRhIHBhdGggZm9yIHRoZSBtaWNyby1CRkQgcGFja2V0cy4gVXNpbmcgbGlu ayBsb2NhbCB3b3VsZCBoYXZlDQogbWFkZSBpdCBhIGxvdCBzaW1wbGVyLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QW5k IHRoaXMgaXMgd2hlcmUgaSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBmbGF3ZWQgLS0g dGhleSB1c2UgbGluayBsb2NhbCBtdWx0aWNhc3QgdG8gZW5zdXJlIElQIHVuaWNhc3QgcmVhY2hh YmlsaXR5IHdoaWNoIGlzIGluY29ycmVjdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNoZWVycywgTWFuYXY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPk9uIFRodSwgQXByIDcsIDIwMTYgYXQgMTE6MTYgUE0sIE1hY2ggQ2hlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFjaC5jaGVu QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBHcmVn IGFuZCBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGp1c3QgaGF2ZSBxdWljayByZXZp ZXcgb24gdGhlIGRyYWZ0cy4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgaWRl YSBpcyB0byB1c2UgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3Mgb3RoZXIgdGhhbiB1bmlj YXN0IGFkZHJlc3Mgd2hlbiZuYnNwOyZuYnNwO3NlbmRpbmcgQkZEIHBhY2tldHMgb3Zlcg0KIExB RyBsaW5rcy4gQW5kIGFjdHVhbGx5IHRoaXMgaWRlYSBoYXMgYmVlbiBwcm9wb3NlZCBpbiA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNl LTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Y2hlbi1iZmQtaW50ZXJmYWNlLTAwPC9hPiZuYnNwOyh0aGUgcHJlZGVjZXNzb3Igb2YgUkZDIDcx MzApLiBBbmQgYXQmbmJzcDt0aGF0IHRpbWUsIHRoZSBjby1hdXRob3JzIG9mIFJGQyA3MTMwIGRp ZCBkaXNjdXNzJm5ic3A7dGhlIGlkZWEgb2YgdXNpbmcgbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFk ZHJlc3MsIGJ1dCBmb3Igc29tZSByZWFzb24gSSBmb3JnZXQgbm93KEkgbWF5IG5lZWQgdG8gcmVp dGVyYXRlIHRoZQ0KIGRpc2N1c3Npb25zIG9uIHRoZSBhcmNoaXZlKSwgdGhlIGlkZWEgd2FzIGFi YW5kb25lZCwgYWx0aG91Z2ggSSBzdGlsbCB0aGluayBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRk cmVzcyBpcyBhIHNtYXJ0IGlkZWEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2Fy ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPk1hY2gmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ IFJ0Zy1iZmQgWzxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KIG9uIGJlaGFsZiBvZiBH cmVnb3J5IE1pcnNreSBbPGEgaHJlZj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT5dPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDA1LCAyMDE2IDY6MTY8YnI+DQo8Yj5Ubzo8L2I+ IDxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnLWJm ZEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpydGctYmZkLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxz LWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBscy1jaGFpcnNAaWV0Zi5vcmc8 L2E+OyBBbGlhIEF0bGFzICg8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFR3 byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGVhciBBbGwsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPnR3byBuZXcgZHJhZnRzLCByZWxhdGVkIHRvIFJGQyA3MTMwLCB3ZXJlIHB1 Ymxpc2hlZCBiZWZvcmUgdGhlIG1lZXRpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj7Ctzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAtMDAiIHRhcmdldD0iX2JsYW5rIj5CRkQgb24gTUMt TEFHIGludGVyZmFjZXMgaW4gSVAgbmV0d29yazwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPsK3PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9ibGFuayI+QkZE IG9uIE1DLUxBRyBpbnRlcmZhY2VzIGluIElQL01QTFMgbmV0d29yazwvYT48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIHJldmlld3Ms IGNvbW1lbnRzLCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A40D56eusaamb103erics_-- From nobody Fri Apr 8 21:43:40 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AE112D736; Fri, 8 Apr 2016 21:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPHslMZLQ6iu; Fri, 8 Apr 2016 21:43:34 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9534212D732; Fri, 8 Apr 2016 21:43:34 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q128so153813117iof.3; Fri, 08 Apr 2016 21:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U1RZmcIyOJF98alsdMYhMT3PZLzoA+seFYmkiMvrBL0=; b=jqZ8s8dW01YrmPcLpcaKQsQcu/cvt6NuD85LuDylys+SqZhs/6FhjSM6NKEy41wa0N BXI0pTyWjB76xOgOi7nBG18XQcUp3pi1Ga3wZhbBbBhuIELnxA3gQlbuSnq6i/d6hUfq wbEZzbLcdldlzaty55AJM7AADpA3eji41IiKJvHmq8QWzMIxsuddFlPOYabXlbn3S4Yc TuSxCCxZEYTTpwtCVFlm5eT6C377gYGoD6jPe6YB1dcBji2gvugdCttdnIV1OON/Xn8M H/uuPSfYD/42uM0E5N5vnrLjmDtyRBCxLinQHIaR4qIOlgcVQDLdodnDEQB1fbkiAEyX tU3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U1RZmcIyOJF98alsdMYhMT3PZLzoA+seFYmkiMvrBL0=; b=LLDwPthl9hAdrEUcL3JCVdLK6eXiPxM3B0lpYdQj8roVhLnAnQtCLvmtaZBfqPD9o5 sN1Ij5SVMsVHQf3lpiFYG6Xcnma/SmNypHvOKuvdZOdlM5w+F5peNK3FsFRmnwjBEDx9 o6ve626AfFdF9/SPlihvLlO9HO0+nxOwfkSva4YR2xC2PUY3UBChO38swiqyLgZ8BFLr q0HEc0+Q9BFS81Fs+/8ipW5UV1R+OeLE4R9le3e9jwbLNVHf4Yum8go5nzFqecxN8Alq S3A+4MXrsPviydrdEyfP6uP+muVxxDXO/LzP85xMZOhD7W1UWrT6nIIzJdoVpglq0CkZ fh4A== X-Gm-Message-State: AD7BkJJf6iLfd1oRD5Z0Q1ZXDv6gUQ6DjluSrsJ2Vij+xT7siZG0ec28ZkQoBEJ2EAoFvJahs3Xw9UHO7n4Gnw== X-Received: by 10.107.132.78 with SMTP id g75mr13312367iod.50.1460177013821; Fri, 08 Apr 2016 21:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.198.198 with HTTP; Fri, 8 Apr 2016 21:42:54 -0700 (PDT) In-Reply-To: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> From: Tony Przygienda Date: Fri, 8 Apr 2016 21:42:54 -0700 Message-ID: To: Greg Mirsky Content-Type: multipart/alternative; boundary=001a113fb6b237d75b053005f4bd Archived-At: Cc: "bier@ietf.org" , "sfc@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 04:43:38 -0000 --001a113fb6b237d75b053005f4bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, thanks, enlightening input. That leads kind of back towards BIER with the question whether we are comfortable with it being ECMP'ed by DPI by mistake or whether we actually consider it desirable that it is ECMP'ed. BIER has its own ECMP section and is otherwise basically a hop-by-hop technology but the question still hold in case we have IP ECMP between two nodes (now, whether that's of practical relevance today or will be of relevance I leave over to the list to discuss). Then there is of course the consideration what happens if BIER is carried over tunnels, amongst them MPLS. Overall, looks like the only safe choice if we do NOT want it to be ECMP'ed unintentionally is to follow 4925 sec. 5, otherwise to pick up something that is not 4/6 to prevent firewall DPI and other tricks. --- tony On Fri, Apr 8, 2016 at 4:05 PM, Greg Mirsky wrote: > Hi Carlos, > thank you for the clarification. Should we think about establishing the > registry than? > Regards, Greg > On Apr 8, 2016 5:38 PM, "Carlos Pignataro (cpignata)" > wrote: > >> Greg, >> >> My point, sorry if I was not clear, was that there is no such a thing as >> a =E2=80=98first nibble registry=E2=80=99. >> >> Instead, RFC 4928, Section 5, at >> https://tools.ietf.org/html/rfc4928#section-5, says: >> >> IANA has marked the value 0x1 in the IP protocol version number space >> as "Reserved" and placed a reference to this document to both values >> 0x0 and 0x1. >> >> And that is reflected as >> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#ve= rsion-numbers-1 >> >> >> The IANA text in 4928 is additionally followed by a disclaimer: >> >> Note that this document does not in any way change the policies >> regarding the allocation of version numbers, including the possible >> use of the reserved numbers for some future purpose. >> >> Further, RFC 4385 does not specify the =E2=80=98first nibble=E2=80=99 as= a field. >> Instead, it depicts the actual binary values for the different CW format= s. >> In other words, it takes the values from the IP protocol version number = and >> not as a new CW Field. >> >> Thanks, >> >> =E2=80=94 Carlos. >> >> PS: Sasha, quick typo, s/1119/1190/; >> >> From: Greg Mirsky >> Date: Friday, April 8, 2016 at 7:28 PM >> To: Alexander Vainshtein >> Cc: "sfc@ietf.org" , "bier@ietf.org" , "Dr. >> Tony Przygienda" , "mpls@ietf.org" , >> Xiaohu Xu , Carlos Pignataro >> Subject: Re: [mpls] The first nibble issue associated with MPLS >> encapsulation >> >> Hi Sasha, >> thank you for pointing to existing IANA allocation, though stale. I >> wonder if there is the registry for the first nibble. We, Tony and I, ha= d >> discussed the way the first nibble space managed. If there already is th= e >> registry, could you please point me to it. >> Regards, Greg >> On Apr 8, 2016 2:31 PM, "Alexander Vainshtein" < >> Alexander.Vainshtein@ecitele.com> wrote: >> >>> Carlos and all, >>> Just for the reference, IANA has defined version 5 (0101) has assigned = to ST protocol and refers to RFC 1119. The latter has been obsoleted by RFC= 1819, but the IANA >>> assignment still holds. >>> >>> Is there, just in case, any relationship between BIER and ST? >>> Thumb typed on my cellphone >>> Regards, >>> Sasha >>> >>> -------- Original Message -------- >>> From: "Carlos Pignataro (cpignata)" >>> Date: Fri, April 08, 2016 9:25 PM +0300 >>> To: Xiaohu Xu >>> CC: mpls@ietf.org, bier@ietf.org, sfc@ietf.org, "Dr. Tony Przygienda" <= tonysietf@gmail.com> >>> Subject: Re: [mpls] The first nibble issue associated with MPLS encapsu= lation >>> >>> >>> Xiaohu, Tony, >>> >>> Please see inline. >>> >>> On Apr 7, 2016, at 2:39 PM, Xuxiaohu wrote: >>> >>> As for the first nibble issue, will it violate the layering principle o= f >>> network protocol stacks if the first nibble of any new encapsulation he= ader >>> (which could be an MPLS payload) is used as the "MPLS payload type" fie= ld? >>> >>> >>> Reading draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirst nibb= le=E2=80=9D is >>> _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. Instead, the text= describes an >>> anti-aliasing mechanism, much like RFC 4928. >>> >>> The relevant text is: >>> First nibble: The first 4 bits of the header are set to 0101; this >>> ensures that the BIER header will not be confused with an IP header >>> or with the header of a pseudowire packet. >>> >>> Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6" >>> >>> wouldn't it be more reasonable and sustainable to fix the problem >>> (i.e., the lack of a protocol field in the MPLS header) by the MPLS hea= der >>> itself? >>> >>> >>> >>> >>> Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80=9D= needed. >>> >>> By the way, since it's claimed that the NSH is transport-independant, i= t >>> means the NSH should be able to be transported over MPLS. However, it s= eems >>> that the first nibble issue has not be considered in the current NSH dr= aft. >>> As a result, when encapsulating NSH over MPLS, the NSH may be >>> mis-interpreted as IP header. >>> >>> >>> >>> >>> There seems to be some massive confusion on this paragraph, on a number >>> of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-= independent. It is >>> by charter and by design. Second, the NSH draft does not even include t= he >>> term =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The= SFC Encapsulation >>> can be used in a transport-agnostic way. >>> >>> One more comment below. >>> >>> Best regards, >>> Xiaohu >>> >>> >>> ------------------------------ >>> *=E5=8F=91=E4=BB=B6=E4=BA=BA:* BIER [bier-bounces@ietf.org] =E4=BB=A3= =E8=A1=A8 Tony Przygienda [ >>> tonysietf@gmail.com] >>> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2016=E5=B9=B44=E6=9C=885=E6=97= =A5 22:36 >>> *=E6=94=B6=E4=BB=B6=E4=BA=BA:* bier@ietf.org >>> *=E4=B8=BB=E9=A2=98:* [Bier] comments on draft-wang-bier-ethernet-01 >>> >>> after reading >>> >>> a) first nibble: refer to MPLS encaps as "the same value" to keep in >>> sync >>> >>> >>> One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text >>> at draft-ietf-bier-mpls-encapsulation-03 >>> >>> Since the function of the first nibble is to prevent aliasing with an I= P >>> packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the >>> First Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions = of 0 and 1, >>> referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5 >>> ). >>> >>> Is the intent to re-assign IPv5 at >>> http://www.iana.org/assignments/version-numbers/ ? >>> >>> Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at: >>> >>> It is REQUIRED, however, that applications depend upon in-order >>> packet delivery restrict the first nibble values to 0x0 and 0x1. >>> >>> Thanks, >>> >>> =E2=80=94 Carlos. >>> >>> >>> b) refer to all other possible fields to MPLS encaps to keep in sync >>> when describing instead of repeating >>> c) you need to describe which kind of ether MACs are allowed, especiall= y >>> on broadcast media, i.e. is it always p2p or can you take advantage of = the >>> broadcast ? >>> d) Figure 4: use the architecture/MPLS encoding for the length, don't >>> invent a new one >>> e) who will obtain a new ether type from IEEE? As far I understand, not >>> a trivial process albeit we have several liaisons with IEEE >>> >>> -- >>> *We=E2=80=99ve heard that a million monkeys at a million keyboards coul= d produce >>> the complete works of Shakespeare; now, thanks to the Internet, we know >>> that is not true.* >>> =E2=80=94Robert Wilensky >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> --=20 *We=E2=80=99ve heard that a million monkeys at a million keyboards could pr= oduce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.* =E2=80=94Robert Wilensky --001a113fb6b237d75b053005f4bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos, thanks, enlightening input. That leads kind of bac= k towards BIER with the question whether we are comfortable with it being = =C2=A0ECMP'ed by DPI by mistake or whether we actually consider it desi= rable that it is ECMP'ed. BIER has its own ECMP section and is otherwis= e basically a hop-by-hop technology but the question still hold in case we = have IP ECMP between two nodes (now, whether that's of practical releva= nce today or will be of relevance I leave over to the list to discuss). The= n there is of course the consideration what happens if BIER is carried over= tunnels, amongst them MPLS.=C2=A0

Overall, looks like t= he only safe choice if we do NOT want it to be ECMP'ed unintentionally = is to follow 4925 sec. 5, otherwise to pick up something that is not 4/6 to= prevent firewall DPI and other tricks.=C2=A0

--- to= ny =C2=A0

On Fri, Apr 8, 2016 at 4:05 PM, Greg Mirsky <= ;gregimirsky@gma= il.com> wrote:

Hi Carlos,
thank you for the clarification. Should we think about establishing the reg= istry than?
Regards, Greg

On Apr 8, 2016 5:38 PM, "Carlos Pignataro (= cpignata)" <cpignata@cisco.com> wrote:
Greg,

My point, sorry if I was not clear, was that there is no such a thing as a = =E2=80=98first nibble registry=E2=80=99.

Instead, RFC 4928, Section 5, at https://tools.ietf.org/html/rfc4928#section-5, says:

=C2=A0 =C2=A0IANA has marked the val= ue 0x1 in the IP protocol version number space
=C2=A0 =C2=A0as "Reserved"= and placed a reference to this document to both values
=C2=A0 =C2=A00x0 and 0x1.


The IANA text in 4928 is additionally followed by a disclaimer:

=C2=A0 =C2=A0Note that this document= does not in any way change the policies
=C2=A0 =C2=A0regarding the allocatio= n of version numbers, including the possible
=C2=A0 =C2=A0use of the reserved num= bers for some future purpose.

Further, RFC 4385 does not specify the =E2=80=98first nibble=E2=80=99 as a = field. Instead, it depicts the actual binary values for the different CW fo= rmats. In other words, it takes the values from the IP protocol version num= ber and not as a new CW Field.

Thanks,

=E2=80=94 Carlos.

PS: Sasha, quick typo, s/1119/1190/;

From: Greg Mirsky <gregimirsky@gmail.com>=
Date: Friday, April 8, 2016 at 7:28= PM
To: Alexander Vainshtein <Alexander.V= ainshtein@ecitele.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "Dr. Tony Pr= zygienda" <tonysietf@gma= il.com>, "mp= ls@ietf.org" <mpls@ietf.org>, Xiaohu Xu <xuxiaohu@huawei.com>, Carlos Pignataro <cpignata@cisco= .com>
Subject: Re: [mpls] The first nibbl= e issue associated with MPLS encapsulation

Hi Sasha,
thank you for pointing to existing IANA allocation, though stale. I wonder = if there is the registry for the first nibble. We, Tony and I, had discusse= d the way the first nibble space managed. If there already is the registry,= could you please point me to it.
Regards, Greg

On Apr 8, 2016 2:31 PM, "Alexander Vainshte= in" <Alexander.Vainshtein@ecitele.com> wrote:
Carlos and all,
Just for the reference, IANA has defined version 5 (0101) has assigned to S=
T protocol and refers to RFC 1119. The latter has been obsoleted by RFC 181=
9, but the IANA=20
assignment still holds.

Is there, just in case, any relationship between BIER and ST?
Thumb typed on my cellphone
Regards,
Sasha

-------- Original Message --------
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Date: Fri, April 08, 2016 9:25 PM +0300
To: Xiaohu Xu <=
xuxiaohu@huawei.com>
CC: mpls@ietf.org, <=
a href=3D"mailto:bier@ietf.org" target=3D"_blank">bier@ietf.org, sfc@ietf.org, "Dr. Ton=
y Przygienda" <tonysietf@gmail.com>
Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulati=
on
Xiaohu, Tony,

Please see inline.

On Apr 7, 2016, at 2:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:

As for the first nibble iss= ue, will it violate the layering principle of network protocol stacks if th= e first nibble of any new encapsulation header (which could be an MPLS payl= oad)=C2=A0is used as the "MPLS payload type" field?

Reading=C2=A0draft-wang-bier-ethernet-01, Section 3, the =E2=80=9Cfirs= t nibble=E2=80=9D is _not_ used as an =E2=80=9CMPLS payload type=E2=80=9D. = Instead, the text describes an anti-aliasing mechanism, much like RFC 4928.= =C2=A0

The relevant text is:
=C2=A0 =C2=A0 =C2=A0First nibble: The first 4 bits of the header are s= et to 0101; this
=C2=A0 =C2=A0ensures that the BIER header will not be confused with an= IP header
=C2=A0 =C2=A0or with the header of a pseudowire packet.

Which says =E2=80=9C=E2=80=A6 will not be confused with =E2=80=A6"= ;

wouldn't it=C2=A0 be mo= re reasonable and sustainable=C2=A0to fix the=C2=A0problem (i.e., the lack = of a protocol field in the MPLS header) by the MPLS header itself?

=C2=A0


Who says it is a *problem*? There=E2=80=99s no =E2=80=9Cfixing=E2=80= =9D needed.

By the way, since it's = claimed that the NSH is transport-independant, it means the NSH should be a= ble to be transported over MPLS. However, it seems that the first nibble is= sue has not be considered=C2=A0in the current NSH draft. As a result, when encapsulating NSH over MPLS, the NSH may be m= is-interpreted as IP header.

=C2=A0



There seems to be some massive confusion on this paragraph, on a numbe= r of levels. First, NSH is not =E2=80=9Cclaimed to be=E2=80=9D transport-in= dependent. It is by charter and by design. Second, the NSH draft does not e= ven include the term =E2=80=9CMPLS=E2=80=9D, because it does not define transports. The SFC Encapsulation can be used in a transport-agnost= ic way.

One more comment below.

Best regards,
Xiaohu

=C2=A0

=E5=8F=91= =E4=BB=B6=E4=BA=BA:=C2=A0BIER [bier-bounces@ietf.org] =E4=BB=A3=E8=A1= =A8 Tony Przygienda [tonysietf@gmail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:=C2=A02016=E5=B9= =B44=E6=9C=885=E6=97=A5 22:36
=E6=94=B6=E4=BB=B6=E4=BA=BA:=C2=A0bier@ietf.org
=E4=B8=BB=E9=A2=98:=C2=A0[Bier] comments on draft-wang-= bier-ethernet-01

after reading=C2=A0

a) first nibble: refer to MPLS encaps as "the same value" to= keep in sync=C2=A0

One comment regarding the =E2=80=9CFirst nibble=E2=80=9D text at=C2=A0= draft-ietf-bier-mpls-encapsulation-03

Since the function of the first nibble is to prevent aliasing with an = IP packet, in order for RFC 4928 to specify values of 0x0 and 0x1 for the F= irst Nibble, it had to =E2=80=9CReserve=E2=80=9D IP protocol versions of 0 = and 1, referencing that RFC (see https://tools.ietf.org/html/rfc4928#section-5).

Is the intent to re-assign IPv5 at=C2=A0http://www.iana.org/assign= ments/version-numbers/=C2=A0?

Note that RFC 4928 says =E2=80=9CREQUIRED=E2=80=9D at:

=C2=A0 =C2=A0It is REQUIRED, however, that applications depend upon in= -order
=C2=A0 =C2=A0packet delivery restrict the first nibble values to 0x0 a= nd 0x1.

Thanks,

=E2=80=94 Carlos.


b) refer to all other possible fields to MPLS encaps to keep in sync w= hen describing instead of repeating=C2=A0
c) you need to describe which kind of ether MACs are allowed, especial= ly on broadcast media, i.e. is it always p2p or can you take advantage of t= he broadcast ?
d) Figure 4: use the architecture/MPLS encoding for the length, don= 9;t invent a new one=C2=A0
e) who will obtain a new ether type from IEEE? As far I understand, no= t a trivial process albeit we have several liaisons with IEEE=C2=A0

--=C2=A0
We=E2= =80=99ve heard that a million monkeys at a million keyboards could produce = the complete works of Shakespeare; now, thanks to the Internet, we know tha= t is not true.
= =E2=80=94Robert Wilensky
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/lis= tinfo/mpls


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



--
=
We=E2=80=99ve heard= that a million monkeys at a million keyboards could produce the complete w= orks of Shakespeare; now, thanks to the Internet, we know that is not true.=
=E2=80=94Robert Wilensky
--001a113fb6b237d75b053005f4bd-- From nobody Sat Apr 9 02:08:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875712D158; Sat, 9 Apr 2016 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNXkhRvEo2Dp; Sat, 9 Apr 2016 02:08:21 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 6660412D13B; Sat, 9 Apr 2016 02:08:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id o66so68779002ywc.3; Sat, 09 Apr 2016 02:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=aXEodagEAT415mNdSGV5iOy2Jo+FoN6VWbtqUUpmnC95up7x9xYrNkxjHPwVGPY/Tl h18Gp0aHnDoBvHNlGPXq7YXYFLmU/1mTyFq8xhrZTf8A/il+KmFeVDcceUAI3DgEtQRK wXB3MZ2IKNHQIDUdkE4gUv8DQ36AuIennHpkQwQQxiOdoXjRG7sMF6lQ9BZcLlg0XHY2 DURRj0aZoF3fOUzYoslwNfrhTYm5aPDvoReyDwht+USLhEDcQP3moc2U/YXd6rQlva/a Q043hgscylUnk9kjgqMdIaKlwTJthmA6rdn9/rS0IWy1tpUFtZSwOkxaxJP4l1+9TWFg fbpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PXAMq23NHFZylcScxzEupxlGW+FRWogTJxheaijnOEw=; b=j2SOZ9fED86dHuCZenzsCUrPtAjDINQ+JURYVklQRoJcZMB9jBRvpyYqlaxdAfRlW7 bcifu2tW85wZZ6FUq/oCo2kvdn5jhkPw5q4d0yxfmNhazhGGI1klnrVrLAzm3WQ5fn0J DQOkHXkrQgOlBNa9Q9kL+M9lY2Gw1SMct6EGBNPNsE2b9H3N5zswmhfU0ZJtit5XNq60 qaFmdsZtEHINL/14yuCCPjf9MbFfzoMc2/ISiU+fod5CtsS03lrdE8UxAvJ/tKXblLIR rghRjJCJUbIzEZ8UQxN4RuApVWXdddOpyVcpz/ebnC7BkcDQCaR39+LOzjOm9gmE+UbG N1kg== X-Gm-Message-State: AD7BkJLjqAMNu46oUPnJoUQESGp/v9UuIuFfDAPNXT+gYxL6sDhfcwvFVeq/BuXOaRFymV+3VR9rYzirHZhiUQ== MIME-Version: 1.0 X-Received: by 10.129.70.70 with SMTP id t67mr6357220ywa.6.1460192900595; Sat, 09 Apr 2016 02:08:20 -0700 (PDT) Received: by 10.13.216.3 with HTTP; Sat, 9 Apr 2016 02:08:20 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> Date: Sat, 9 Apr 2016 14:38:20 +0530 Message-ID: From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a114d71ce24c89b053009a715 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 09:08:23 -0000 --001a114d71ce24c89b053009a715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, There is a difference, a big one. When you use CFM or some other L2 OAM protocol, you dont make any claims about L3 connectivity. However, when you start using BFD it implicitly means that youre talking about L3 connectivity. So, its going to be bizarre debugging complex topologies where BFD sessions never flap and yet MPLS LSPs randomly time out (because there is this one MC-LAG thats dropping packets -- and in the worst case, only sporadically and intermittently drops IP packets) It will NOT produce false negatives (as you claim) but rather introduce false positives, which is more dangerous. The MC-LAG will be up, while it would be dropping all or few IP packets. I have no objections if operators and the community think that this is something that they can live with. I am personally having an out-of-body experience just discussing this! :-) Cheers, Manav On Sat, Apr 9, 2016 at 9:46 AM, Gregory Mirsky wrote: > Hi Manav, > > the use case for the BFD over MC-LAG interfaces that I consider the most > important for this drafts to address is to enable sub-second defect > detection in order to trigger LACP convergence and, subsequently, > switchover within the Redundancy Group in Active-Standby case. Hence both > unicast and multicast L3 addresses are quite distant from L2 fast path an= d > processing usually taken by CCM frames. Of course, one can use CFM per LA= G > Constituent Link, and I have implemented that and it interoperates with > another implementation by other vendor, but operators prefer ease of BFD > provisioning. Thus I=E2=80=99ve to provide them with ability to monitor M= C-LAG and > explain that in some cases it may produce false negative when L2 is > functional and the problem is in L3, unicast or multicast, engine. As you > can see, there=E2=80=99s not much value in continuing argument how much d= ifferent > L3 multicast processing is from L3 unicast as both are different from L2 > path. At the end, as I think, it is up to operators to decide whether the= y > are comfortable with this mechanism or would require defect detection at = L2. > > > > Regards, > > Greg > > > > *From:* Manav Bhatia [mailto:manavbhatia@gmail.com] > *Sent:* Friday, April 08, 2016 5:38 PM > *To:* Greg Mirsky > *Cc:* Reshad Rahman (rrahman); > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; rtg-bfd@ietf.org; > mpls-chairs@ietf.org; mpls@ietf.org; rtg-bfd-chairs@ietf.org; Gregory > Mirsky > *Subject:* Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interface= s > > > > Hi Greg, > > > > the update could be in addition of either broadcast or link local > multicast or both with appropriate normative language. But I would not > agree that these wouldn't work. > > > > Double negatives make it very hard to parse a sentence. > > > > Anyway, why would you NOT agree that this WOULDNT work? > > > > I am telling you that link local multicasts and unicasts are dealt with > differently in the data plane, so the data path being up for the former m= ay > not necessarily mean that its up for the latter as well. So tell me WHY y= ou > think this argument isnt valid? I was the L3 data plane architect in my > former company for one of the product lines and i am telling you that in = my > box, which is very very widely deployed, your scheme will NOT work since = i > punt all link local packets to the CPU differently. In fact, in some case= s > even the TX path is different. So sure, u-BFD may very well claim that th= e > link is up, but its possible that there may be no IP connectivity. > > > > Cheers, Manav > > > --001a114d71ce24c89b053009a715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

There is a difference, a big o= ne.=C2=A0

When you use CFM or some other L2 OAM pr= otocol, you dont make any claims about L3 connectivity. However, when you s= tart using BFD it implicitly means that youre talking about L3 connectivity= . So, its going to be bizarre debugging complex topologies where BFD sessio= ns never flap and yet MPLS LSPs randomly time out (because there is this on= e MC-LAG thats dropping packets -- and in the worst case, only sporadically= and intermittently drops IP packets)

It will NOT = produce false negatives (as you claim) but rather introduce false positives= , which is more dangerous. The MC-LAG will be up, while it would be droppin= g all or few IP packets.

I have no objections if o= perators and the community think that this is something that they can live = with. I am personally having an out-of-body experience just discussing this= ! :-)

Cheers, Manav

On Sat, Apr 9, 2016 at 9:46 AM, G= regory Mirsky <gregory.mirsky@ericsson.com> wrote:=

Hi Manav,

the use case for the BFD = over MC-LAG interfaces that I consider the most important for this drafts t= o address is to enable sub-second defect detection in order to trigger LACP convergence and, subsequently, switchover within the Redun= dancy Group in Active-Standby case. Hence both unicast and multicast L3 add= resses are quite distant from L2 fast path and processing usually taken by = CCM frames. Of course, one can use CFM per LAG Constituent Link, and I have implemented that and it interoper= ates with another implementation by other vendor, but operators prefer ease= of BFD provisioning. Thus I=E2=80=99ve to provide them with ability to mon= itor MC-LAG and explain that in some cases it may produce false negative when L2 is functional and the problem is in = L3, unicast or multicast, engine. As you can see, there=E2=80=99s not much = value in continuing argument how much different L3 multicast processing is = from L3 unicast as both are different from L2 path. At the end, as I think, it is up to operators to decide whether t= hey are comfortable with this mechanism or would require defect detection a= t L2.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Manav Bh= atia [mailto:man= avbhatia@gmail.com]
Sent: Friday, April 08, 2016 5:38 PM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag= -ip@tools.ietf.org; rtg-bfd@ietf.org; mpls-chairs@ietf.org; mpls@ietf.org; rtg-bfd-chairs@ietf.org; Gregory Mirsky
Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interf= aces

=C2=A0

Hi Greg,

=C2=A0

the update could be in addition of either broadcast or link local multic= ast or both with appropriate normative language. But I would not agree that= these wouldn't work.

=C2=A0

Double negatives make it very hard to parse a senten= ce.

=C2=A0

Anyway, why would you NOT agree that this WOULDNT wo= rk?

=C2=A0

I am telling you that link local multicasts and unic= asts are dealt with differently in the data plane, so the data path being u= p for the former may not necessarily mean that its up for the latter as wel= l. So tell me WHY you think this argument isnt valid? I was the L3 data plane architect in my former company for one= of the product lines and i am telling you that in my box, which is very ve= ry widely deployed, your scheme will NOT work since i punt all link local p= ackets to the CPU differently. In fact, in some cases even the TX path is different. So sure, u-BFD may very= well claim that the link is up, but its possible that there may be no IP c= onnectivity.

=C2=A0

Cheers, Manav

=C2=A0

--001a114d71ce24c89b053009a715-- From nobody Sat Apr 9 06:33:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1773212D6C7 for ; Sat, 9 Apr 2016 06:33:51 -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 VsnwdWcyxUIW for ; Sat, 9 Apr 2016 06:33:49 -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 C571F12D689 for ; Sat, 9 Apr 2016 06:33:48 -0700 (PDT) Received: from [10.10.2.96] (unknown [190.111.246.165]) (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 155001802AA8; Sat, 9 Apr 2016 15:33:45 +0200 (CEST) To: "Rajiv Asati (rajiva)" , Eric Gray , "mpls@ietf.org" References: From: Loa Andersson Message-ID: <570904B2.6020708@pi.nu> Date: Sat, 9 Apr 2016 21:33:38 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] YANG Data Model for MPLS LDP and mLDP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 13:33:51 -0000 Carlos and Eric, On 2016-04-09 08:54, Rajiv Asati (rajiva) wrote: > Hi Eric, > > Thanks for pointing out this exception. This certainly is worth a bit of discussion (even though we may well be splitting hair). > > It might be reasonable to say that the “peering” relationship does NOT survive during graceful restart, even though label bindings don’t get deleted upto the the grace period. The reason is that after the session is closed, neither LSRs could send any messages (KeepAlive, Address/Withdraw, Notification, Label Mapping/Request/Withdraw/Abort/Release etc.) as expected/required during the “peering” relationship. > > With that in mind, the below definition seems reasonably accurate from modeling point of view: > > // > Peer: An LDP session which has successfully progressed beyond its initialization > phase and is ready for binding exchange. > // I'm not entirely comfortable with this definition, the approach is right, but a few words need to be changed. How about: LDP Peers: A pair of LSRs that has established an LDP session between themselves. The session has successfully progressed beyond its initialization phase and the LSRs are exchanging label bindings or are ready to to so. As for Eric's comment, I think that for modeling purposes we could invent something like a "parked LSP session". /Loa > > > Having said the above, it does NOT hurt to add a note right below the definition. Something like: During Graceful Restart {RFC3478), LSRs must hold on to the label bindings upto the grace period even after the “session” is deleted. > > Thoughts? > > > > > >> Specifically, while the definitions shown are closely related to the definitions originally used in RFC 5036 (and >> RFC 3036 before that), > > > I agree. However, the point was that rfc5036 loosely used these “neighbors” and “peers" and mixed their usage. Including 4 examples below (where 1st two should have used “peers” instead of “neighbors”, and last 2 should have use “neighbors” instead of “peers”):: > > > 2.6.1.1. Independent Label Distribution Control > .. > > When using independent LSP control, each LSR may advertise label > mappings to its neighbors at any time it desires. For example, when > // > 2.6.2. Label Retention Mode > .. > > binding for a FEC learned from a neighbor that is not its next hop > for the FEC. > // > > > 2.2.2. LDP Identifiers > .. > > A situation where an LSR would need to advertise more than one label > space to a peer > // > > 2.2.1. Label Spaces > .. > > Note that the use of a per interface label space only makes > sense when the LDP peers are "directly connected" over an interface, > // > > > > From nobody Sat Apr 9 14:21:24 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD6812D192; Sat, 9 Apr 2016 14:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZqwsjDo39lm; Sat, 9 Apr 2016 14:21:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9845F12D18D; Sat, 9 Apr 2016 14:21:21 -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=Acw20Sa4cWTXVxTJwCfeHuQ09x94AAXInYkZjsSZWf4=; b=S37FzQsw/yEviBMFAL+3I1UKXJgby4bRmw0gRGqu1hQYLVuGhxU5tMYMukqYx6YyddVYIBFpVQmbITzSTBuz+a0zu9K/5haIRrEGIwlTuPXXR2vEbW+8yJ0Lm14cr+S+JZ3vhZ9mvTeFHlrbMBGIyrh2ogWgU1vJL5eJFo1qpK8= Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sat, 9 Apr 2016 21:21:20 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0447.029; Sat, 9 Apr 2016 21:21:20 +0000 From: Chris Bowers To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AQHRkX87DMMCVm+vgEGiM0AIoPPP4Z+CKFVA Date: Sat, 9 Apr 2016 21:21:20 +0000 Message-ID: References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu> In-Reply-To: <57078417.3070700@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.13] x-ms-office365-filtering-correlation-id: 386eb284-2cca-405c-cf4a-08d360bce534 x-microsoft-exchange-diagnostics: 1; BY2PR05MB614; 5:rKEetYxtWLrTc1/XB0u0kwsn2yQDyotniVcjqNG/sz+d857psMgVaimojwxyfLkoJ85DrhYkbps3qVyq2lBkQnN11epKpQJGW/HqcYMVNr+XfnHCjJDU2mUstztZHab0yVlumC5p+akJgt92iAfheQ==; 24:3/fnJWzoKDtZOAkl2UX4JHlx3Iht3kwJPBw+bFrm+WJC50iOu5J7u0zPj0D1/xLQ5VJBh+gn1OWrcq62ikJeVXIszQ4WA4QeLt93Zm/qp4I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB614; 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)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB614; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB614; x-forefront-prvs: 0907F58A24 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377424004)(24454002)(377454003)(3280700002)(2906002)(106116001)(66066001)(74316001)(9686002)(230783001)(5004730100002)(50986999)(11100500001)(5008740100001)(3660700001)(2501003)(122556002)(92566002)(6116002)(3846002)(586003)(164054004)(102836003)(87936001)(107886002)(5003600100002)(33656002)(1220700001)(77096005)(19580395003)(81166005)(19580405001)(10400500002)(15975445007)(86362001)(2201001)(5002640100001)(2900100001)(54356999)(76176999)(76576001)(99286002)(5001770100001)(1096002)(189998001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB614; H:BY2PR05MB614.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: 09 Apr 2016 21:21:20.2121 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB614 Archived-At: Subject: Re: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 21:21:23 -0000 I am not aware of any other IPR. Thanks, Chris -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, April 08, 2016 7:13 AM To: mpls@ietf.org; draft-ietf-mpls-app-aware-tldp@ietf.org; mpls-chairs@iet= f.org Subject: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp WG, Sorry I had a cut and paste error in the two first paragraphs of this mail,= it should have read: The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready for working group last call. We will do an IPR poll prior to the start of wglc. I apologize for the mistake! /Loa On 2016-04-08 03:04, Loa Andersson wrote: > Working Group, > > The authors of draft-ietf-mpls-app-aware-tldp has told us that the=20 > document is ready to be considered for working adoption. > > The document been through MPLS-RT review. We will do an IPR poll prior=20 > to the start of the adoption poll. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There is one IPR disclosure filed directly against this document. > > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. *The response needs to be sent to the MPLS wg mailing=20 > list.* The document will not advance to the next stage until a=20 > response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that has not yet been disclosed in conformance with IETF rules= . > > > /Loa > mpls wg co-chair _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Apr 9 15:32:55 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6075A12D18D; Sat, 9 Apr 2016 15:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HYIyqg2V90Uv; Sat, 9 Apr 2016 15:32:52 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C7112D175; Sat, 9 Apr 2016 15:32:51 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-d2-57097cb47ba4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.49.30335.4BC79075; Sun, 10 Apr 2016 00:05:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sat, 9 Apr 2016 18:32:49 -0400 From: Gregory Mirsky To: Manav Bhatia Thread-Topic: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAGbkoAAB59e4P//39qAgAAYVICAAF4BgIAACP5QgACFuwD//2O6MA== Date: Sat, 9 Apr 2016 22:32:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A4146E@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40798@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40D56@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyuXSPt+6WGs5wg9+HtS0ObDrIaPFt2lNW i8uT2tgt1l0+xWZxa+lKVotrK1rZLT7/2cbowO4x5fdGVo+ds+6yeyxZ8pPJ48vlz2wBLFFc NimpOZllqUX6dglcGQd+NDEW/NvNWLHz6VymBsaG7YxdjBwcEgImEv2z5LoYOYFMMYkL99az dTFycQgJHGWU+L/7HzOEs4xRYvbyn4wgVWwCRhIvNvawg9giAhoSre8PgBUxC+xiknh24zML SEJYwEPi9oIJrBBFnhKbX52Fsuskdv3rYQKxWQRUJFZfP8sMYvMK+ErMu3+VFWLbVjaJfQcv gxVxCgRK9F9bCNbMCHTf91NrwOLMAuISt57MZ4K4W0BiyZ7zzBC2qMTLx/9YIWwliY+/57ND 1OdLfLt3kR1imaDEyZlPWCYwis5CMmoWkrJZSMpmAUOJWUBTYv0ufYgSRYkp3Q/ZIWyg/+fM ZUcWX8DIvoqRo7S4ICc33chgEyMwQo9JsOnuYLw/3fMQowAHoxIPb0I1Z7gQa2JZcWXuIUYJ DmYlEd5IkBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHexuB/YUIC6YklqdmpqQWpRTBZJg5OqQZG ib27rFYbRvmI7n7afYPp65HwCQb5i/f9sXG4WSL7ojdgnZytmP4j5ovXCpgn+R163hkgvlKc +eLCA0fj5yQezs0RXPPnLYtP1oazE1XZt+lIPcj5+Lj0qfNmrxUz8qffKi8OXHNO4Grat+q3 r2N+Zn1N0JCQW3bXePred5VHip9pxRi9i2h+p8RSnJFoqMVcVJwIAOs/pCHMAgAA Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2016 22:32:54 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQpJ4oCZbSBnbGFkIHRoYXQgd2XigJlyZSBjb252ZXJnaW5nIOKAkyB0aGUgZmlu YWwgZGVjaXNpb24gd291bGQgY29tZSBmcm9tIG91ciBjdXN0b21lcnMsIHRoZSBvcGVyYXRvcnMu DQpJIGhvcGUgd2XigJlsbCBoYXZlIHRoZWlyIGNvbW1lbnRzLg0KSW4gdGhlIG1lYW50aW1lLCBJ IGludml0ZSB5b3UgYW5kIG90aGVyIGV4cGVydHMgdG8gcmV2aWV3IHRoZSBzZWNvbmQgZHJhZnQg dGhhdCBsb29rcyBpbnRvIHRoZSBzYW1lIHNjZW5hcmlvIGJ1dCBvdmVyIHRoZSBJUC9NUExTIG5l dHdvcmsuIEl0IG1heSBiZSBsZXNzIGNvbnRyb3ZlcnNpYWwgYXMgbmVpdGhlciBtdWx0aWNhc3Qs IG5vciBicm9hZGNhc3QgYWRkcmVzc2VzIG5lZWQgdG8gYmUgdXNlZCBhcyB0aGUgZGVzdGluYXRp b24gSVAgYWRkcmVzcy4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYgQmhhdGlhIFttYWlsdG86bWFu YXZiaGF0aWFAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDA5LCAyMDE2IDI6MDgg QU0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IEdyZWcgTWlyc2t5OyBSZXNoYWQgUmFobWFuIChy cmFobWFuKTsgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc7 IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMt TEFHIGludGVyZmFjZXMNCg0KSGkgR3JlZywNCg0KVGhlcmUgaXMgYSBkaWZmZXJlbmNlLCBhIGJp ZyBvbmUuDQoNCldoZW4geW91IHVzZSBDRk0gb3Igc29tZSBvdGhlciBMMiBPQU0gcHJvdG9jb2ws IHlvdSBkb250IG1ha2UgYW55IGNsYWltcyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIEhvd2V2ZXIs IHdoZW4geW91IHN0YXJ0IHVzaW5nIEJGRCBpdCBpbXBsaWNpdGx5IG1lYW5zIHRoYXQgeW91cmUg dGFsa2luZyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIFNvLCBpdHMgZ29pbmcgdG8gYmUgYml6YXJy ZSBkZWJ1Z2dpbmcgY29tcGxleCB0b3BvbG9naWVzIHdoZXJlIEJGRCBzZXNzaW9ucyBuZXZlciBm bGFwIGFuZCB5ZXQgTVBMUyBMU1BzIHJhbmRvbWx5IHRpbWUgb3V0IChiZWNhdXNlIHRoZXJlIGlz IHRoaXMgb25lIE1DLUxBRyB0aGF0cyBkcm9wcGluZyBwYWNrZXRzIC0tIGFuZCBpbiB0aGUgd29y c3QgY2FzZSwgb25seSBzcG9yYWRpY2FsbHkgYW5kIGludGVybWl0dGVudGx5IGRyb3BzIElQIHBh Y2tldHMpDQoNCkl0IHdpbGwgTk9UIHByb2R1Y2UgZmFsc2UgbmVnYXRpdmVzIChhcyB5b3UgY2xh aW0pIGJ1dCByYXRoZXIgaW50cm9kdWNlIGZhbHNlIHBvc2l0aXZlcywgd2hpY2ggaXMgbW9yZSBk YW5nZXJvdXMuIFRoZSBNQy1MQUcgd2lsbCBiZSB1cCwgd2hpbGUgaXQgd291bGQgYmUgZHJvcHBp bmcgYWxsIG9yIGZldyBJUCBwYWNrZXRzLg0KDQpJIGhhdmUgbm8gb2JqZWN0aW9ucyBpZiBvcGVy YXRvcnMgYW5kIHRoZSBjb21tdW5pdHkgdGhpbmsgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0 IHRoZXkgY2FuIGxpdmUgd2l0aC4gSSBhbSBwZXJzb25hbGx5IGhhdmluZyBhbiBvdXQtb2YtYm9k eSBleHBlcmllbmNlIGp1c3QgZGlzY3Vzc2luZyB0aGlzISA6LSkNCg0KQ2hlZXJzLCBNYW5hdg0K DQpPbiBTYXQsIEFwciA5LCAyMDE2IGF0IDk6NDYgQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+ IHdyb3RlOg0KSGkgTWFuYXYsDQp0aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcg aW50ZXJmYWNlcyB0aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRy YWZ0cyB0byBhZGRyZXNzIGlzIHRvIGVuYWJsZSBzdWItc2Vjb25kIGRlZmVjdCBkZXRlY3Rpb24g aW4gb3JkZXIgdG8gdHJpZ2dlciBMQUNQIGNvbnZlcmdlbmNlIGFuZCwgc3Vic2VxdWVudGx5LCBz d2l0Y2hvdmVyIHdpdGhpbiB0aGUgUmVkdW5kYW5jeSBHcm91cCBpbiBBY3RpdmUtU3RhbmRieSBj YXNlLiBIZW5jZSBib3RoIHVuaWNhc3QgYW5kIG11bHRpY2FzdCBMMyBhZGRyZXNzZXMgYXJlIHF1 aXRlIGRpc3RhbnQgZnJvbSBMMiBmYXN0IHBhdGggYW5kIHByb2Nlc3NpbmcgdXN1YWxseSB0YWtl biBieSBDQ00gZnJhbWVzLiBPZiBjb3Vyc2UsIG9uZSBjYW4gdXNlIENGTSBwZXIgTEFHIENvbnN0 aXR1ZW50IExpbmssIGFuZCBJIGhhdmUgaW1wbGVtZW50ZWQgdGhhdCBhbmQgaXQgaW50ZXJvcGVy YXRlcyB3aXRoIGFub3RoZXIgaW1wbGVtZW50YXRpb24gYnkgb3RoZXIgdmVuZG9yLCBidXQgb3Bl cmF0b3JzIHByZWZlciBlYXNlIG9mIEJGRCBwcm92aXNpb25pbmcuIFRodXMgSeKAmXZlIHRvIHBy b3ZpZGUgdGhlbSB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhh dCBpbiBzb21lIGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMg ZnVuY3Rpb25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0 LCBlbmdpbmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29u dGludWluZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0IHByb2Nlc3Np bmcgaXMgZnJvbSBMMyB1bmljYXN0IGFzIGJvdGggYXJlIGRpZmZlcmVudCBmcm9tIEwyIHBhdGgu IEF0IHRoZSBlbmQsIGFzIEkgdGhpbmssIGl0IGlzIHVwIHRvIG9wZXJhdG9ycyB0byBkZWNpZGUg d2hldGhlciB0aGV5IGFyZSBjb21mb3J0YWJsZSB3aXRoIHRoaXMgbWVjaGFuaXNtIG9yIHdvdWxk IHJlcXVpcmUgZGVmZWN0IGRldGVjdGlvbiBhdCBMMi4NCg0KICAgICAgICAgICAgICAgIFJlZ2Fy ZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogTWFuYXYg QmhhdGlhIFttYWlsdG86bWFuYXZiaGF0aWFAZ21haWwuY29tPG1haWx0bzptYW5hdmJoYXRpYUBn bWFpbC5jb20+XQ0KU2VudDogRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNDQpUbzogR3Jl ZyBNaXJza3kNCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsgZHJhZnQtdGFubWlyLXJ0Z3dn LWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXRhbm1pci1ydGd3Zy1i ZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPjsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRn LWJmZEBpZXRmLm9yZz47IG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0Bp ZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBydGctYmZkLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc+OyBHcmVnb3J5IE1p cnNreQ0KU3ViamVjdDogUmU6IFttcGxzXSBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBv dmVyIE1DLUxBRyBpbnRlcmZhY2VzDQoNCkhpIEdyZWcsDQoNCg0KdGhlIHVwZGF0ZSBjb3VsZCBi ZSBpbiBhZGRpdGlvbiBvZiBlaXRoZXIgYnJvYWRjYXN0IG9yIGxpbmsgbG9jYWwgbXVsdGljYXN0 IG9yIGJvdGggd2l0aCBhcHByb3ByaWF0ZSBub3JtYXRpdmUgbGFuZ3VhZ2UuIEJ1dCBJIHdvdWxk IG5vdCBhZ3JlZSB0aGF0IHRoZXNlIHdvdWxkbid0IHdvcmsuDQoNCkRvdWJsZSBuZWdhdGl2ZXMg bWFrZSBpdCB2ZXJ5IGhhcmQgdG8gcGFyc2UgYSBzZW50ZW5jZS4NCg0KQW55d2F5LCB3aHkgd291 bGQgeW91IE5PVCBhZ3JlZSB0aGF0IHRoaXMgV09VTEROVCB3b3JrPw0KDQpJIGFtIHRlbGxpbmcg eW91IHRoYXQgbGluayBsb2NhbCBtdWx0aWNhc3RzIGFuZCB1bmljYXN0cyBhcmUgZGVhbHQgd2l0 aCBkaWZmZXJlbnRseSBpbiB0aGUgZGF0YSBwbGFuZSwgc28gdGhlIGRhdGEgcGF0aCBiZWluZyB1 cCBmb3IgdGhlIGZvcm1lciBtYXkgbm90IG5lY2Vzc2FyaWx5IG1lYW4gdGhhdCBpdHMgdXAgZm9y IHRoZSBsYXR0ZXIgYXMgd2VsbC4gU28gdGVsbCBtZSBXSFkgeW91IHRoaW5rIHRoaXMgYXJndW1l bnQgaXNudCB2YWxpZD8gSSB3YXMgdGhlIEwzIGRhdGEgcGxhbmUgYXJjaGl0ZWN0IGluIG15IGZv cm1lciBjb21wYW55IGZvciBvbmUgb2YgdGhlIHByb2R1Y3QgbGluZXMgYW5kIGkgYW0gdGVsbGlu ZyB5b3UgdGhhdCBpbiBteSBib3gsIHdoaWNoIGlzIHZlcnkgdmVyeSB3aWRlbHkgZGVwbG95ZWQs IHlvdXIgc2NoZW1lIHdpbGwgTk9UIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2FsIHBh Y2tldHMgdG8gdGhlIENQVSBkaWZmZXJlbnRseS4gSW4gZmFjdCwgaW4gc29tZSBjYXNlcyBldmVu IHRoZSBUWCBwYXRoIGlzIGRpZmZlcmVudC4gU28gc3VyZSwgdS1CRkQgbWF5IHZlcnkgd2VsbCBj bGFpbSB0aGF0IHRoZSBsaW5rIGlzIHVwLCBidXQgaXRzIHBvc3NpYmxlIHRoYXQgdGhlcmUgbWF5 IGJlIG5vIElQIGNvbm5lY3Rpdml0eS4NCg0KQ2hlZXJzLCBNYW5hdg0KDQo= --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPknigJltIGdsYWQgdGhhdCB3ZeKAmXJlIGNvbnZlcmdpbmcg4oCTIHRoZSBmaW5hbCBkZWNp c2lvbiB3b3VsZCBjb21lIGZyb20gb3VyIGN1c3RvbWVycywgdGhlIG9wZXJhdG9ycy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3BlIHdl4oCZbGwgaGF2ZSB0aGVpciBjb21tZW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIG1lYW50aW1lLCBJIGludml0 ZSB5b3UgYW5kIG90aGVyIGV4cGVydHMgdG8gcmV2aWV3IHRoZSBzZWNvbmQgZHJhZnQgdGhhdCBs b29rcyBpbnRvIHRoZSBzYW1lIHNjZW5hcmlvIGJ1dCBvdmVyIHRoZSBJUC9NUExTIG5ldHdvcmsu IEl0IG1heSBiZSBsZXNzIGNvbnRyb3ZlcnNpYWwNCiBhcyBuZWl0aGVyIG11bHRpY2FzdCwgbm9y IGJyb2FkY2FzdCBhZGRyZXNzZXMgbmVlZCB0byBiZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBJ UCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVn PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5hdiBCaGF0aWEg W21haWx0bzptYW5hdmJoYXRpYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJk YXksIEFwcmlsIDA5LCAyMDE2IDI6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IEdyZWdvcnkgTWlyc2t5 PGJyPg0KPGI+Q2M6PC9iPiBHcmVnIE1pcnNreTsgUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IGRy YWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnOyBydGctYmZkQGll dGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMt TEFHIGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBH cmVnLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUg aXMgYSBkaWZmZXJlbmNlLCBhIGJpZyBvbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4geW91IHVzZSBDRk0gb3Igc29tZSBv dGhlciBMMiBPQU0gcHJvdG9jb2wsIHlvdSBkb250IG1ha2UgYW55IGNsYWltcyBhYm91dCBMMyBj b25uZWN0aXZpdHkuIEhvd2V2ZXIsIHdoZW4geW91IHN0YXJ0IHVzaW5nIEJGRCBpdCBpbXBsaWNp dGx5IG1lYW5zIHRoYXQgeW91cmUgdGFsa2luZyBhYm91dCBMMyBjb25uZWN0aXZpdHkuIFNvLCBp dHMgZ29pbmcgdG8gYmUgYml6YXJyZSBkZWJ1Z2dpbmcgY29tcGxleA0KIHRvcG9sb2dpZXMgd2hl cmUgQkZEIHNlc3Npb25zIG5ldmVyIGZsYXAgYW5kIHlldCBNUExTIExTUHMgcmFuZG9tbHkgdGlt ZSBvdXQgKGJlY2F1c2UgdGhlcmUgaXMgdGhpcyBvbmUgTUMtTEFHIHRoYXRzIGRyb3BwaW5nIHBh Y2tldHMgLS0gYW5kIGluIHRoZSB3b3JzdCBjYXNlLCBvbmx5IHNwb3JhZGljYWxseSBhbmQgaW50 ZXJtaXR0ZW50bHkgZHJvcHMgSVAgcGFja2V0cyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd2lsbCBOT1QgcHJvZHVjZSBmYWxzZSBuZWdh dGl2ZXMgKGFzIHlvdSBjbGFpbSkgYnV0IHJhdGhlciBpbnRyb2R1Y2UgZmFsc2UgcG9zaXRpdmVz LCB3aGljaCBpcyBtb3JlIGRhbmdlcm91cy4gVGhlIE1DLUxBRyB3aWxsIGJlIHVwLCB3aGlsZSBp dCB3b3VsZCBiZSBkcm9wcGluZyBhbGwgb3IgZmV3IElQIHBhY2tldHMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBubyBvYmplY3Rp b25zIGlmIG9wZXJhdG9ycyBhbmQgdGhlIGNvbW11bml0eSB0aGluayB0aGF0IHRoaXMgaXMgc29t ZXRoaW5nIHRoYXQgdGhleSBjYW4gbGl2ZSB3aXRoLiBJIGFtIHBlcnNvbmFsbHkgaGF2aW5nIGFu IG91dC1vZi1ib2R5IGV4cGVyaWVuY2UganVzdCBkaXNjdXNzaW5nIHRoaXMhIDotKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1h bmF2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gU2F0LCBBcHIgOSwgMjAxNiBhdCA5OjQ2IEFNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNYW5hdiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj50aGUgdXNlIGNhc2UgZm9yIHRoZSBCRkQgb3ZlciBNQy1MQUcgaW50ZXJmYWNlcyB0 aGF0IEkgY29uc2lkZXIgdGhlIG1vc3QgaW1wb3J0YW50IGZvciB0aGlzIGRyYWZ0cw0KIHRvIGFk ZHJlc3MgaXMgdG8gZW5hYmxlIHN1Yi1zZWNvbmQgZGVmZWN0IGRldGVjdGlvbiBpbiBvcmRlciB0 byB0cmlnZ2VyIExBQ1AgY29udmVyZ2VuY2UgYW5kLCBzdWJzZXF1ZW50bHksIHN3aXRjaG92ZXIg d2l0aGluIHRoZSBSZWR1bmRhbmN5IEdyb3VwIGluIEFjdGl2ZS1TdGFuZGJ5IGNhc2UuIEhlbmNl IGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0IEwzIGFkZHJlc3NlcyBhcmUgcXVpdGUgZGlzdGFu dCBmcm9tIEwyIGZhc3QgcGF0aCBhbmQNCiBwcm9jZXNzaW5nIHVzdWFsbHkgdGFrZW4gYnkgQ0NN IGZyYW1lcy4gT2YgY291cnNlLCBvbmUgY2FuIHVzZSBDRk0gcGVyIExBRyBDb25zdGl0dWVudCBM aW5rLCBhbmQgSSBoYXZlIGltcGxlbWVudGVkIHRoYXQgYW5kIGl0IGludGVyb3BlcmF0ZXMgd2l0 aCBhbm90aGVyIGltcGxlbWVudGF0aW9uIGJ5IG90aGVyIHZlbmRvciwgYnV0IG9wZXJhdG9ycyBw cmVmZXIgZWFzZSBvZiBCRkQgcHJvdmlzaW9uaW5nLiBUaHVzIEnigJl2ZSB0byBwcm92aWRlIHRo ZW0NCiB3aXRoIGFiaWxpdHkgdG8gbW9uaXRvciBNQy1MQUcgYW5kIGV4cGxhaW4gdGhhdCBpbiBz b21lIGNhc2VzIGl0IG1heSBwcm9kdWNlIGZhbHNlIG5lZ2F0aXZlIHdoZW4gTDIgaXMgZnVuY3Rp b25hbCBhbmQgdGhlIHByb2JsZW0gaXMgaW4gTDMsIHVuaWNhc3Qgb3IgbXVsdGljYXN0LCBlbmdp bmUuIEFzIHlvdSBjYW4gc2VlLCB0aGVyZeKAmXMgbm90IG11Y2ggdmFsdWUgaW4gY29udGludWlu ZyBhcmd1bWVudCBob3cgbXVjaCBkaWZmZXJlbnQgTDMgbXVsdGljYXN0DQogcHJvY2Vzc2luZyBp cyBmcm9tIEwzIHVuaWNhc3QgYXMgYm90aCBhcmUgZGlmZmVyZW50IGZyb20gTDIgcGF0aC4gQXQg dGhlIGVuZCwgYXMgSSB0aGluaywgaXQgaXMgdXAgdG8gb3BlcmF0b3JzIHRvIGRlY2lkZSB3aGV0 aGVyIHRoZXkgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhpcyBtZWNoYW5pc20gb3Igd291bGQgcmVx dWlyZSBkZWZlY3QgZGV0ZWN0aW9uIGF0IEwyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTWFuYXYgQmhhdGlhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmF2 YmhhdGlhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hbmF2YmhhdGlhQGdtYWlsLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBcHJpbCAwOCwgMjAxNiA1OjM4IFBNPGJy Pg0KPGI+VG86PC9iPiBHcmVnIE1pcnNreTxicj4NCjxiPkNjOjwvYj4gUmVzaGFkIFJhaG1hbiAo cnJhaG1hbik7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5taXItcnRnd2ctYmZkLW1jLWxhZy1p cEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtdGFubWlyLXJ0Z3dnLWJm ZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJz QGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBH cmVnb3J5IE1pcnNreTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIFR3byBuZXcgZHJh ZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVyZmFjZXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBHcmVnLDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cD50aGUgdXBkYXRlIGNvdWxkIGJlIGluIGFkZGl0aW9uIG9m IGVpdGhlciBicm9hZGNhc3Qgb3IgbGluayBsb2NhbCBtdWx0aWNhc3Qgb3IgYm90aCB3aXRoIGFw cHJvcHJpYXRlIG5vcm1hdGl2ZSBsYW5ndWFnZS4gQnV0IEkgd291bGQgbm90IGFncmVlIHRoYXQg dGhlc2Ugd291bGRuJ3Qgd29yay4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvdWJsZSBuZWdhdGl2ZXMgbWFrZSBpdCB2 ZXJ5IGhhcmQgdG8gcGFyc2UgYSBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFueXdheSwgd2h5IHdvdWxkIHlvdSBOT1Qg YWdyZWUgdGhhdCB0aGlzIFdPVUxETlQgd29yaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gdGVsbGluZyB5b3UgdGhhdCBsaW5r IGxvY2FsIG11bHRpY2FzdHMgYW5kIHVuaWNhc3RzIGFyZSBkZWFsdCB3aXRoIGRpZmZlcmVudGx5 IGluIHRoZSBkYXRhIHBsYW5lLCBzbyB0aGUgZGF0YSBwYXRoIGJlaW5nIHVwIGZvciB0aGUgZm9y bWVyIG1heSBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IGl0cw0KIHVwIGZvciB0aGUgbGF0dGVy IGFzIHdlbGwuIFNvIHRlbGwgbWUgV0hZIHlvdSB0aGluayB0aGlzIGFyZ3VtZW50IGlzbnQgdmFs aWQ/IEkgd2FzIHRoZSBMMyBkYXRhIHBsYW5lIGFyY2hpdGVjdCBpbiBteSBmb3JtZXIgY29tcGFu eSBmb3Igb25lIG9mIHRoZSBwcm9kdWN0IGxpbmVzIGFuZCBpIGFtIHRlbGxpbmcgeW91IHRoYXQg aW4gbXkgYm94LCB3aGljaCBpcyB2ZXJ5IHZlcnkgd2lkZWx5IGRlcGxveWVkLCB5b3VyIHNjaGVt ZSB3aWxsIE5PVA0KIHdvcmsgc2luY2UgaSBwdW50IGFsbCBsaW5rIGxvY2FsIHBhY2tldHMgdG8g dGhlIENQVSBkaWZmZXJlbnRseS4gSW4gZmFjdCwgaW4gc29tZSBjYXNlcyBldmVuIHRoZSBUWCBw YXRoIGlzIGRpZmZlcmVudC4gU28gc3VyZSwgdS1CRkQgbWF5IHZlcnkgd2VsbCBjbGFpbSB0aGF0 IHRoZSBsaW5rIGlzIHVwLCBidXQgaXRzIHBvc3NpYmxlIHRoYXQgdGhlcmUgbWF5IGJlIG5vIElQ IGNvbm5lY3Rpdml0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkNoZWVycywgTWFuYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_7347100B5761DC41A166AC17F22DF11221A4146Eeusaamb103erics_-- From nobody Sun Apr 10 05:14:20 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4644912B03D; Sun, 10 Apr 2016 05:14:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160410121417.10212.6655.idtracker@ietfa.amsl.com> Date: Sun, 10 Apr 2016 05:14:17 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 12:14:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Authors : Kireeti Kompella Carlos Pignataro Nagendra Kumar Sam Aldrin Mach(Guoyi) Chen Filename : draft-ietf-mpls-rfc4379bis-02.txt Pages : 53 Date : 2016-04-10 Abstract: This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. This document obsoletes RFCs 4379 and 6829. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc4379bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 10 06:46:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7779E12D5AD; Sun, 10 Apr 2016 06:46:48 -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 LcPFXCJ9dSXL; Sun, 10 Apr 2016 06:46:47 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4210312D5AE; Sun, 10 Apr 2016 06:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=941; q=dns/txt; s=iport; t=1460296007; x=1461505607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TEmYboNSsTxrsIrAYivz0XRkrchAtIQH9XnJayVb7lE=; b=kFOs2I7JS33NHoj2+CvGzlNj0K4EKudrd7k3idEXRHlKShWZz/LNNNVC ej/Mp9mt9tc3uO4r6mbL++pRDIjsfA5vgj76PVZ08YAIuxOsw7agtVsJV v3jpC3xPY9/zFnxQy58mRwETd/z+yHc1I9afXmCpgpH6t77Xafyn1hMjD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgAaWApX/5ldJa1cgzeBUAaud4lJg?= =?us-ascii?q?g8BDYFzhg0CgSE4FAEBAQEBAQFlJ4RCAQEEOj8QAgEINhAhESUCBAENBYgSAxK?= =?us-ascii?q?2OQ2FHwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLgkGHVAEEkxmEOjEBjBaBd?= =?us-ascii?q?YFnjSaGH4Erh1sBHgEBQoIygTVsiS1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="89856013" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2016 13:46:46 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3ADkkEW013110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Apr 2016 13:46:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 10 Apr 2016 08:46:45 -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; Sun, 10 Apr 2016 08:46:45 -0500 From: "Alvaro Retana (aretana)" To: Stewart Bryant , The IESG Thread-Topic: Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) Thread-Index: AQHRkOChUIDXC97tPUm+npeu/kPy1J+DXpQA Date: Sun, 10 Apr 2016 13:46:45 +0000 Message-ID: References: <20160105031027.29211.97181.idtracker@ietfa.amsl.com> <570679AF.2030101@gmail.com> In-Reply-To: <570679AF.2030101@gmail.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.82.180.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-ietf-mpls-rfc6374-udp-return-path@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 13:46:48 -0000 Thanks Stewart, that updated text looks good to me. Alvaro. On 4/7/16, 12:15 PM, "Stewart Bryant" wrote: >> >> >> >>* As far as I can tell, there is no restriction for having both a Return >>Address object and the URO in the same query, right? If so, and if the >>intent is *not* to update RFC6374, then it seems (from the text in >>RFC6374) that the URO would never be used (if a Return Address object is >>also present). > >I have added the following text which should resolve any ambiguity: > >To prevent any ambiguity as to which address the Responder needs to >reply to, an MPLS-PLDM message containing a URO MUST NOT include an >RFC6374 Return Address TLV (TLV 1). Additionally, the method of >constructing the return address from the Source Address TLV (TLV 130) >described in Section 3.5.2 of RFC6374 MUST NOT be used to construct to >an Query message that contains a URO. From nobody Sun Apr 10 09:10:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13C212B036; Sun, 10 Apr 2016 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pd2trkrJrLX; Sun, 10 Apr 2016 09:10:03 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5094B12B035; Sun, 10 Apr 2016 09:10:03 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-8c-570a7ab3d8c7 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2B.87.22441.3BA7A075; Sun, 10 Apr 2016 18:09:23 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Sun, 10 Apr 2016 12:10:02 -0400 From: Uma Chunduri To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AQHRkQBp48DdLzVYIUG3HEzyZpHyEZ+AH2mAgANFCeA= Date: Sun, 10 Apr 2016 16:10:01 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580117DE@eusaamb105.ericsson.se> References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu> In-Reply-To: <57078417.3070700@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiO7mKq5wg5ffdCyaN89gtvg3dw6z xbrLp9gsbi1dyerA4rFkyU8mj1nT29gCmKK4bFJSczLLUov07RK4Mhaevsda8JC/4tarhUwN jFt4uhg5OCQETCR+nNbrYuQEMsUkLtxbz9bFyMUhJHCUUeL54i0sEM5yRonfiw6zg1SxCehJ fJz6kx0kISJwglGiZ/ZTFpCEsICXxOneT2C2iIC3xPvpvYwQtpXEpTPrWEFsFgFVia7uC2Bx XgFfifc7XjCD2EICthJNCzeyg1zECVTze3ssSJgR6KLvp9YwgdjMAuISt57MZ4K4VEBiyZ7z zBC2qMTLx/9YIWwliY+/57ND1OtILNj9iQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk7CwkLbOQ tMxC0rKAkWUVI0dpcUFObrqR4SZGYIQck2Bz3MG4t9fzEKMAB6MSD29CNWe4EGtiWXFl7iFG CQ5mJRHeL4lc4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5vSP/hQkJpCeWpGanphakFsFkmTg4 pRoY4+8/4Zv37M7F5CDHUhbxh1LP+Dk/7Hj09kTRlOjja3vDGDZbO8bLizz0ODbn3K8TokqT uPYsXbJqw7mfJW2r824pWpmYNzcruy5inFHXUh3Y51mbdLSRd98PuerpXaW8bMm8c9yEuLTq BHMXaVoGZK6SPd9psbV53/ytkfqygpyTyp+wPv2rxFKckWioxVxUnAgAQL4jkYwCAAA= Archived-At: Subject: Re: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 16:10:05 -0000 Hi Loa, I don't have any IPR on this draft and also I don't know any other IPR than= which was already disclosed on this draft. -- Uma C. -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Friday, April 08, 2016 3:13 AM To: mpls@ietf.org; draft-ietf-mpls-app-aware-tldp@ietf.org; mpls-chairs@iet= f.org Subject: Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp WG, Sorry I had a cut and paste error in the two first paragraphs of this mail,= it should have read: The authors of draft-ietf-mpls-app-aware-tldp has told us that the document is ready for working group last call. We will do an IPR poll prior to the start of wglc. I apologize for the mistake! /Loa On 2016-04-08 03:04, Loa Andersson wrote: > Working Group, > > The authors of draft-ietf-mpls-app-aware-tldp has told us that the=20 > document is ready to be considered for working adoption. > > The document been through MPLS-RT review. We will do an IPR poll prior=20 > to the start of the adoption poll. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? > > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > There is one IPR disclosure filed directly against this document. > > If you are listed as a document author or contributor please respond=20 > to this email regardless of whether or not you are aware of any=20 > relevant IPR. *The response needs to be sent to the MPLS wg mailing=20 > list.* The document will not advance to the next stage until a=20 > response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author=20 > or contributor, then please explicitly respond only if you are aware=20 > of any IPR that has not yet been disclosed in conformance with IETF rules= . > > > /Loa > mpls wg co-chair From nobody Mon Apr 11 05:45:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A63A12D1D2; Mon, 11 Apr 2016 05:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 vFiHPpIoAD0v; Mon, 11 Apr 2016 05:45:07 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0131.outbound.protection.outlook.com [104.47.2.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9216112EDF3; Mon, 11 Apr 2016 05:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BqWWij5NkOViBc6lr5Vpb6RLY3ykmzRFEKa7uikncR0=; b=SESnpIQqYGYhwCxeM1Q+8wg5/C6u7pUxIYpEbfj1ZGKRNoO9om/FC67227k86Uj605ieSB3C5i1BRYeoUAZFe1Vigv6zUUer9R+rAyMZ+yrFHCbbvcV2Ffw+y69oYOMwYjfKekfC7OBUr81gZ0LhFgdK7hOwyfuINQ8wvCvr09M= Received: from AM3PR03MB0775.eurprd03.prod.outlook.com (2a01:111:e400:8848::11) by AM3PR03MB0776.eurprd03.prod.outlook.com (2a01:111:e400:8848::12) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 12:45:03 +0000 Received: from AM3PR03MB0775.eurprd03.prod.outlook.com ([fe80::bd20:7adf:a75f:a656]) by AM3PR03MB0775.eurprd03.prod.outlook.com ([fe80::bd20:7adf:a75f:a656%18]) with mapi id 15.01.0453.029; Mon, 11 Apr 2016 12:45:03 +0000 From: Alexander Vainshtein To: Greg Mirsky Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A///PiXuAADFYgIAAAwEAgAAHioCAA/oHsA== Date: Mon, 11 Apr 2016 12:45:02 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 577dfd5e-db9e-4e05-04d4-08d362071a13 x-microsoft-exchange-diagnostics: 1; AM3PR03MB0776; 5:O7B6Alj63/+flhxc+yVurfVCZQSxkAbWUw99rj+vGHx3WvJilwaqLlbzSQsjerZMFAqQvRoeF8FDS0lGi3fdvJ1D3DTrIRMl6d9b69BbYlShe8JwErCjTJ8X9O8qYBl5iOR0dBhuIcVdYyPtu++CkQ==; 24:uvfc7XtnwFf3+lnq2RCGzSlto5i/Y1pdOBb82gSO588005CvfDoO1vcg618c6h7TyfG+zjIuKyQoVTGyqaJWYr8hUjD9DTzLIVC4D/pPZBM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB0776; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM3PR03MB0776; BCL:0; PCL:0; RULEID:; SRVR:AM3PR03MB0776; x-forefront-prvs: 09090B6B69 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(252514010)(13464003)(24454002)(52034003)(5002640100001)(2900100001)(2950100001)(74316001)(19609705001)(87936001)(5250100002)(19580395003)(164054004)(110136002)(15975445007)(9686002)(189998001)(5008740100001)(5004730100002)(76576001)(66066001)(586003)(11100500001)(1220700001)(1096002)(6116002)(3846002)(102836003)(790700001)(93886004)(92566002)(16236675004)(19617315012)(345774005)(19580405001)(50986999)(54356999)(33656002)(5003600100002)(86362001)(106116001)(3660700001)(19625215002)(4326007)(76176999)(3280700002)(19300405004)(81166005)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR03MB0776; H:AM3PR03MB0775.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR03MB0775C55E5AD3247F373007139D940AM3PR03MB0775eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 12:45:02.8150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR03MB0776 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:45:11 -0000 --_000_AM3PR03MB0775C55E5AD3247F373007139D940AM3PR03MB0775eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywgYW5kIGFsbCwNCkZyb20gbXkgZXhwZXJpZW5jZSAoZnJvbSB0aGUgZGF5cyBsb25nIHBh c3TimLopLCB0aGUgSUVURiBoYXMgYmVlbiBhbHdheXMgdHJlYXRpbmcgdGhlIGZpcnN0IG5pYmJs ZSBqdXN0IGFmdGVyIHRoZSBib3R0b20gb2YgdGhlIGxhYmVsIHN0YWNrIGFzIGJlaW5nIG1hbmFn ZWQgdmlhIHRoZSBJUCBWZXJzaW9uIE51bWJlcnMgcmVnaXN0cnk8aHR0cDovL3d3dy5pYW5hLm9y Zy9hc3NpZ25tZW50cy92ZXJzaW9uLW51bWJlcnMvdmVyc2lvbi1udW1iZXJzLnhodG1sPiDigJMg YW5kIHRoaXMgYmVjYXVzZSwgYXMgcGVyIFJGQyAzMDMyPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMzMDMyPiwg4oCcdGhlIG5ldHdvcmsgIGxheWVyIHBhY2tldCBpbW1lZGlhdGVseSBm b2xsb3dzIHRoZSBsYWJlbCBzdGFjayBlbnRyeSB3aGljaCBoYXMgdGhlICBTIGJpdCBzZXTigJ0u DQoNClJGQyA0Mzg1PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzQzODUvP2lu Y2x1ZGVfdGV4dD0xPiBoYXMgcmV1c2VkIHRoZSB2YWx1ZXMgdGhhdCBoYXZlIGJlZW4gZGVmaW5l ZCBhcyDigJxSZXNlcnZlZOKAnSBpbiB0aGlzIHJlZ2lzdHJ5Lg0KQnV0LCBBRkFJSywgYXR0ZW1w dHMgdG8gcmV1c2Ugc29tZSBzdGFsZSB2YWx1ZXMgKGUuZy4sIFBJUDxodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMTYyMT4pIGhhdmUgYmVlbiByZWplY3RlZCBvdXQtb2YtaGFuZC4NCg0K TXkgMmMsDQpTYXNoYQ0KDQpPZmZpY2U6ICs5NzItMzkyNjYzMDINCkNlbGw6ICAgICAgKzk3Mi01 NDkyNjYzMDINCkVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tDQoNCkZy b206IEdyZWcgTWlyc2t5IFttYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tXQ0KU2VudDogU2F0 dXJkYXksIEFwcmlsIDA5LCAyMDE2IDI6MDYgQU0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkNCkNjOiBzZmNAaWV0Zi5vcmc7IEFsZXhhbmRlciBWYWluc2h0ZWluOyBiaWVyQGlldGYu b3JnOyBEci4gVG9ueSBQcnp5Z2llbmRhOyBYaWFvaHUgWHU7IG1wbHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbXBsc10gVGhlIGZpcnN0IG5pYmJsZSBpc3N1ZSBhc3NvY2lhdGVkIHdpdGggTVBM UyBlbmNhcHN1bGF0aW9uDQoNCg0KSGkgQ2FybG9zLA0KdGhhbmsgeW91IGZvciB0aGUgY2xhcmlm aWNhdGlvbi4gU2hvdWxkIHdlIHRoaW5rIGFib3V0IGVzdGFibGlzaGluZyB0aGUgcmVnaXN0cnkg dGhhbj8NClJlZ2FyZHMsIEdyZWcNCk9uIEFwciA4LCAyMDE2IDU6MzggUE0sICJDYXJsb3MgUGln bmF0YXJvIChjcGlnbmF0YSkiIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbT4+IHdyb3RlOg0KR3JlZywNCg0KTXkgcG9pbnQsIHNvcnJ5IGlmIEkgd2FzIG5vdCBj bGVhciwgd2FzIHRoYXQgdGhlcmUgaXMgbm8gc3VjaCBhIHRoaW5nIGFzIGEg4oCYZmlyc3Qgbmli YmxlIHJlZ2lzdHJ54oCZLg0KDQpJbnN0ZWFkLCBSRkMgNDkyOCwgU2VjdGlvbiA1LCBhdCBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDkyOCNzZWN0aW9uLTUsIHNheXM6DQoNCiAgIElB TkEgaGFzIG1hcmtlZCB0aGUgdmFsdWUgMHgxIGluIHRoZSBJUCBwcm90b2NvbCB2ZXJzaW9uIG51 bWJlciBzcGFjZQ0KICAgYXMgIlJlc2VydmVkIiBhbmQgcGxhY2VkIGEgcmVmZXJlbmNlIHRvIHRo aXMgZG9jdW1lbnQgdG8gYm90aCB2YWx1ZXMNCiAgIDB4MCBhbmQgMHgxLg0KDQpBbmQgdGhhdCBp cyByZWZsZWN0ZWQgYXMgaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy92ZXJzaW9uLW51 bWJlcnMvdmVyc2lvbi1udW1iZXJzLnhodG1sI3ZlcnNpb24tbnVtYmVycy0xDQoNClRoZSBJQU5B IHRleHQgaW4gNDkyOCBpcyBhZGRpdGlvbmFsbHkgZm9sbG93ZWQgYnkgYSBkaXNjbGFpbWVyOg0K DQogICBOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbiBhbnkgd2F5IGNoYW5nZSB0 aGUgcG9saWNpZXMNCiAgIHJlZ2FyZGluZyB0aGUgYWxsb2NhdGlvbiBvZiB2ZXJzaW9uIG51bWJl cnMsIGluY2x1ZGluZyB0aGUgcG9zc2libGUNCiAgIHVzZSBvZiB0aGUgcmVzZXJ2ZWQgbnVtYmVy cyBmb3Igc29tZSBmdXR1cmUgcHVycG9zZS4NCg0KRnVydGhlciwgUkZDIDQzODUgZG9lcyBub3Qg c3BlY2lmeSB0aGUg4oCYZmlyc3QgbmliYmxl4oCZIGFzIGEgZmllbGQuIEluc3RlYWQsIGl0IGRl cGljdHMgdGhlIGFjdHVhbCBiaW5hcnkgdmFsdWVzIGZvciB0aGUgZGlmZmVyZW50IENXIGZvcm1h dHMuIEluIG90aGVyIHdvcmRzLCBpdCB0YWtlcyB0aGUgdmFsdWVzIGZyb20gdGhlIElQIHByb3Rv Y29sIHZlcnNpb24gbnVtYmVyIGFuZCBub3QgYXMgYSBuZXcgQ1cgRmllbGQuDQoNClRoYW5rcywN Cg0K4oCUIENhcmxvcy4NCg0KUFM6IFNhc2hhLCBxdWljayB0eXBvLCBzLzExMTkvMTE5MC87DQoN CkZyb206IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDgsIDIwMTYgYXQgNzoyOCBQTQ0K VG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNv bTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+Pg0KQ2M6ICJzZmNAaWV0 Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm Lm9yZz4+LCAiYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4iIDxiaWVyQGlldGYu b3JnPG1haWx0bzpiaWVyQGlldGYub3JnPj4sICJEci4gVG9ueSBQcnp5Z2llbmRhIiA8dG9ueXNp ZXRmQGdtYWlsLmNvbTxtYWlsdG86dG9ueXNpZXRmQGdtYWlsLmNvbT4+LCAibXBsc0BpZXRmLm9y ZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYu b3JnPj4sIFhpYW9odSBYdSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVh d2VpLmNvbT4+LCBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNw aWduYXRhQGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBSZTogW21wbHNdIFRoZSBmaXJzdCBuaWJibGUg aXNzdWUgYXNzb2NpYXRlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbg0KDQoNCkhpIFNhc2hhLA0K dGhhbmsgeW91IGZvciBwb2ludGluZyB0byBleGlzdGluZyBJQU5BIGFsbG9jYXRpb24sIHRob3Vn aCBzdGFsZS4gSSB3b25kZXIgaWYgdGhlcmUgaXMgdGhlIHJlZ2lzdHJ5IGZvciB0aGUgZmlyc3Qg bmliYmxlLiBXZSwgVG9ueSBhbmQgSSwgaGFkIGRpc2N1c3NlZCB0aGUgd2F5IHRoZSBmaXJzdCBu aWJibGUgc3BhY2UgbWFuYWdlZC4gSWYgdGhlcmUgYWxyZWFkeSBpcyB0aGUgcmVnaXN0cnksIGNv dWxkIHlvdSBwbGVhc2UgcG9pbnQgbWUgdG8gaXQuDQpSZWdhcmRzLCBHcmVnDQpPbiBBcHIgOCwg MjAxNiAyOjMxIFBNLCAiQWxleGFuZGVyIFZhaW5zaHRlaW4iIDxBbGV4YW5kZXIuVmFpbnNodGVp bkBlY2l0ZWxlLmNvbTxtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20+PiB3 cm90ZToNCg0KQ2FybG9zIGFuZCBhbGwsDQoNCkp1c3QgZm9yIHRoZSByZWZlcmVuY2UsIElBTkEg aGFzIGRlZmluZWQgdmVyc2lvbiA1ICgwMTAxKSBoYXMgYXNzaWduZWQgdG8gU1QgcHJvdG9jb2wg YW5kIHJlZmVycyB0byBSRkMgMTExOS4gVGhlIGxhdHRlciBoYXMgYmVlbiBvYnNvbGV0ZWQgYnkg UkZDIDE4MTksIGJ1dCB0aGUgSUFOQQ0KDQphc3NpZ25tZW50IHN0aWxsIGhvbGRzLg0KDQoNCg0K SXMgdGhlcmUsIGp1c3QgaW4gY2FzZSwgYW55IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIEJJRVIgYW5k IFNUPw0KDQpUaHVtYiB0eXBlZCBvbiBteSBjZWxscGhvbmUNCg0KUmVnYXJkcywNCg0KU2FzaGEN Cg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCg0KRnJvbTogIkNhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSIgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25h dGFAY2lzY28uY29tPj4NCg0KRGF0ZTogRnJpLCBBcHJpbCAwOCwgMjAxNiA5OjI1IFBNICswMzAw DQoNClRvOiBYaWFvaHUgWHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1 YXdlaS5jb20+Pg0KDQpDQzogbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4sIGJp ZXJAaWV0Zi5vcmc8bWFpbHRvOmJpZXJAaWV0Zi5vcmc+LCBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNm Y0BpZXRmLm9yZz4sICJEci4gVG9ueSBQcnp5Z2llbmRhIiA8dG9ueXNpZXRmQGdtYWlsLmNvbTxt YWlsdG86dG9ueXNpZXRmQGdtYWlsLmNvbT4+DQoNClN1YmplY3Q6IFJlOiBbbXBsc10gVGhlIGZp cnN0IG5pYmJsZSBpc3N1ZSBhc3NvY2lhdGVkIHdpdGggTVBMUyBlbmNhcHN1bGF0aW9uDQoNCg0K WGlhb2h1LCBUb255LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KT24gQXByIDcsIDIwMTYsIGF0 IDI6MzkgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tPj4gd3JvdGU6DQoNCkFzIGZvciB0aGUgZmlyc3QgbmliYmxlIGlzc3VlLCB3aWxs IGl0IHZpb2xhdGUgdGhlIGxheWVyaW5nIHByaW5jaXBsZSBvZiBuZXR3b3JrIHByb3RvY29sIHN0 YWNrcyBpZiB0aGUgZmlyc3QgbmliYmxlIG9mIGFueSBuZXcgZW5jYXBzdWxhdGlvbiBoZWFkZXIg KHdoaWNoIGNvdWxkIGJlIGFuIE1QTFMgcGF5bG9hZCkgaXMgdXNlZCBhcyB0aGUgIk1QTFMgcGF5 bG9hZCB0eXBlIiBmaWVsZD8NCg0KUmVhZGluZyBkcmFmdC13YW5nLWJpZXItZXRoZXJuZXQtMDEs IFNlY3Rpb24gMywgdGhlIOKAnGZpcnN0IG5pYmJsZeKAnSBpcyBfbm90XyB1c2VkIGFzIGFuIOKA nE1QTFMgcGF5bG9hZCB0eXBl4oCdLiBJbnN0ZWFkLCB0aGUgdGV4dCBkZXNjcmliZXMgYW4gYW50 aS1hbGlhc2luZyBtZWNoYW5pc20sIG11Y2ggbGlrZSBSRkMgNDkyOC4NCg0KVGhlIHJlbGV2YW50 IHRleHQgaXM6DQogICAgIEZpcnN0IG5pYmJsZTogVGhlIGZpcnN0IDQgYml0cyBvZiB0aGUgaGVh ZGVyIGFyZSBzZXQgdG8gMDEwMTsgdGhpcw0KICAgZW5zdXJlcyB0aGF0IHRoZSBCSUVSIGhlYWRl ciB3aWxsIG5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIElQIGhlYWRlcg0KICAgb3Igd2l0aCB0aGUg aGVhZGVyIG9mIGEgcHNldWRvd2lyZSBwYWNrZXQuDQoNCldoaWNoIHNheXMg4oCc4oCmIHdpbGwg bm90IGJlIGNvbmZ1c2VkIHdpdGgg4oCmIg0KDQoNCndvdWxkbid0IGl0ICBiZSBtb3JlIHJlYXNv bmFibGUgYW5kIHN1c3RhaW5hYmxlIHRvIGZpeCB0aGUgcHJvYmxlbSAoaS5lLiwgdGhlIGxhY2sg b2YgYSBwcm90b2NvbCBmaWVsZCBpbiB0aGUgTVBMUyBoZWFkZXIpIGJ5IHRoZSBNUExTIGhlYWRl ciBpdHNlbGY/DQoNCg0KDQpXaG8gc2F5cyBpdCBpcyBhICpwcm9ibGVtKj8gVGhlcmXigJlzIG5v IOKAnGZpeGluZ+KAnSBuZWVkZWQuDQoNCkJ5IHRoZSB3YXksIHNpbmNlIGl0J3MgY2xhaW1lZCB0 aGF0IHRoZSBOU0ggaXMgdHJhbnNwb3J0LWluZGVwZW5kYW50LCBpdCBtZWFucyB0aGUgTlNIIHNo b3VsZCBiZSBhYmxlIHRvIGJlIHRyYW5zcG9ydGVkIG92ZXIgTVBMUy4gSG93ZXZlciwgaXQgc2Vl bXMgdGhhdCB0aGUgZmlyc3QgbmliYmxlIGlzc3VlIGhhcyBub3QgYmUgY29uc2lkZXJlZCBpbiB0 aGUgY3VycmVudCBOU0ggZHJhZnQuIEFzIGEgcmVzdWx0LCB3aGVuIGVuY2Fwc3VsYXRpbmcgTlNI IG92ZXIgTVBMUywgdGhlIE5TSCBtYXkgYmUgbWlzLWludGVycHJldGVkIGFzIElQIGhlYWRlci4N Cg0KDQoNCg0KVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBtYXNzaXZlIGNvbmZ1c2lvbiBvbiB0aGlz IHBhcmFncmFwaCwgb24gYSBudW1iZXIgb2YgbGV2ZWxzLiBGaXJzdCwgTlNIIGlzIG5vdCDigJxj bGFpbWVkIHRvIGJl4oCdIHRyYW5zcG9ydC1pbmRlcGVuZGVudC4gSXQgaXMgYnkgY2hhcnRlciBh bmQgYnkgZGVzaWduLiBTZWNvbmQsIHRoZSBOU0ggZHJhZnQgZG9lcyBub3QgZXZlbiBpbmNsdWRl IHRoZSB0ZXJtIOKAnE1QTFPigJ0sIGJlY2F1c2UgaXQgZG9lcyBub3QgZGVmaW5lIHRyYW5zcG9y dHMuIFRoZSBTRkMgRW5jYXBzdWxhdGlvbiBjYW4gYmUgdXNlZCBpbiBhIHRyYW5zcG9ydC1hZ25v c3RpYyB3YXkuDQoNCk9uZSBtb3JlIGNvbW1lbnQgYmVsb3cuDQoNCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6 OiBCSUVSIFtiaWVyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9y Zz5dIOS7o+ihqCBUb255IFByenlnaWVuZGEgW3RvbnlzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRv bnlzaWV0ZkBnbWFpbC5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0NOaciDXml6UgMjI6MzYN CuaUtuS7tuS6ujogYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4NCuS4u+mimDog W0JpZXJdIGNvbW1lbnRzIG9uIGRyYWZ0LXdhbmctYmllci1ldGhlcm5ldC0wMQ0KYWZ0ZXIgcmVh ZGluZw0KDQphKSBmaXJzdCBuaWJibGU6IHJlZmVyIHRvIE1QTFMgZW5jYXBzIGFzICJ0aGUgc2Ft ZSB2YWx1ZSIgdG8ga2VlcCBpbiBzeW5jDQoNCk9uZSBjb21tZW50IHJlZ2FyZGluZyB0aGUg4oCc Rmlyc3QgbmliYmxl4oCdIHRleHQgYXQgZHJhZnQtaWV0Zi1iaWVyLW1wbHMtZW5jYXBzdWxhdGlv bi0wMw0KDQpTaW5jZSB0aGUgZnVuY3Rpb24gb2YgdGhlIGZpcnN0IG5pYmJsZSBpcyB0byBwcmV2 ZW50IGFsaWFzaW5nIHdpdGggYW4gSVAgcGFja2V0LCBpbiBvcmRlciBmb3IgUkZDIDQ5MjggdG8g c3BlY2lmeSB2YWx1ZXMgb2YgMHgwIGFuZCAweDEgZm9yIHRoZSBGaXJzdCBOaWJibGUsIGl0IGhh ZCB0byDigJxSZXNlcnZl4oCdIElQIHByb3RvY29sIHZlcnNpb25zIG9mIDAgYW5kIDEsIHJlZmVy ZW5jaW5nIHRoYXQgUkZDIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5Mjgj c2VjdGlvbi01KS4NCg0KSXMgdGhlIGludGVudCB0byByZS1hc3NpZ24gSVB2NSBhdCBodHRwOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3ZlcnNpb24tbnVtYmVycy8gPw0KDQpOb3RlIHRoYXQg UkZDIDQ5Mjggc2F5cyDigJxSRVFVSVJFROKAnSBhdDoNCg0KICAgSXQgaXMgUkVRVUlSRUQsIGhv d2V2ZXIsIHRoYXQgYXBwbGljYXRpb25zIGRlcGVuZCB1cG9uIGluLW9yZGVyDQogICBwYWNrZXQg ZGVsaXZlcnkgcmVzdHJpY3QgdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZXMgdG8gMHgwIGFuZCAweDEu DQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KDQoNCmIpIHJlZmVyIHRvIGFsbCBvdGhlciBw b3NzaWJsZSBmaWVsZHMgdG8gTVBMUyBlbmNhcHMgdG8ga2VlcCBpbiBzeW5jIHdoZW4gZGVzY3Jp YmluZyBpbnN0ZWFkIG9mIHJlcGVhdGluZw0KYykgeW91IG5lZWQgdG8gZGVzY3JpYmUgd2hpY2gg a2luZCBvZiBldGhlciBNQUNzIGFyZSBhbGxvd2VkLCBlc3BlY2lhbGx5IG9uIGJyb2FkY2FzdCBt ZWRpYSwgaS5lLiBpcyBpdCBhbHdheXMgcDJwIG9yIGNhbiB5b3UgdGFrZSBhZHZhbnRhZ2Ugb2Yg dGhlIGJyb2FkY2FzdCA/DQpkKSBGaWd1cmUgNDogdXNlIHRoZSBhcmNoaXRlY3R1cmUvTVBMUyBl bmNvZGluZyBmb3IgdGhlIGxlbmd0aCwgZG9uJ3QgaW52ZW50IGEgbmV3IG9uZQ0KZSkgd2hvIHdp bGwgb2J0YWluIGEgbmV3IGV0aGVyIHR5cGUgZnJvbSBJRUVFPyBBcyBmYXIgSSB1bmRlcnN0YW5k LCBub3QgYSB0cml2aWFsIHByb2Nlc3MgYWxiZWl0IHdlIGhhdmUgc2V2ZXJhbCBsaWFpc29ucyB3 aXRoIElFRUUNCg0KLS0NCldl4oCZdmUgaGVhcmQgdGhhdCBhIG1pbGxpb24gbW9ua2V5cyBhdCBh IG1pbGxpb24ga2V5Ym9hcmRzIGNvdWxkIHByb2R1Y2UgdGhlIGNvbXBsZXRlIHdvcmtzIG9mIFNo YWtlc3BlYXJlOyBub3csIHRoYW5rcyB0byB0aGUgSW50ZXJuZXQsIHdlIGtub3cgdGhhdCBpcyBu b3QgdHJ1ZS4NCuKAlFJvYmVydCBXaWxlbnNreQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1wbHMgbWFpbGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_AM3PR03MB0775C55E5AD3247F373007139D940AM3PR03MB0775eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA TWluZ0xpVSI7DQoJcGFub3NlLTE6MiAyIDUgOSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBaGFyb25pOw0KCXBhbm9zZS0xOjIgMSA4 IDMgMiAxIDQgMyAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 Okdlb3JnaWE7DQoJcGFub3NlLTE6MiA0IDUgMiA1IDQgNSAyIDMgMzt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOiMx RjQ5N0Q7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25l Ow0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdyZWcs IGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZyb20gbXkgZXhwZXJpZW5j ZSAoZnJvbSB0aGUgZGF5cyBsb25nIHBhc3Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiksDQogdGhlIElFVEYgaGFzIGJl ZW4gYWx3YXlzIHRyZWF0aW5nIHRoZSBmaXJzdCBuaWJibGUganVzdCBhZnRlciB0aGUgYm90dG9t IG9mIHRoZSBsYWJlbCBzdGFjayBhcyBiZWluZyBtYW5hZ2VkIHZpYSB0aGUNCjxhIGhyZWY9Imh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdmVyc2lvbi1udW1iZXJzL3ZlcnNpb24tbnVt YmVycy54aHRtbCI+SVAgVmVyc2lvbiBOdW1iZXJzIHJlZ2lzdHJ5PC9hPiDigJMgYW5kIHRoaXMg YmVjYXVzZSwgYXMgcGVyDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj MzAzMiI+UkZDIDMwMzI8L2E+LCDigJw8L3NwYW4+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMwMDcwQzAiPnRoZSBuZXR3b3JrICZuYnNwO2xheWVyIHBhY2tldCBpbW1lZGlh dGVseSBmb2xsb3dzIHRoZSBsYWJlbCBzdGFjayBlbnRyeSB3aGljaCBoYXMgdGhlICZuYnNwO1Mg Yml0IHNldDwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPuKAnS4NCiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL3JmYzQzODUvP2luY2x1ZGVfdGV4dD0xIj5SRkMgNDM4NTwvYT4gaGFzIHJl dXNlZCB0aGUgdmFsdWVzIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgYXMg4oCcUmVzZXJ2ZWTigJ0g aW4gdGhpcyByZWdpc3RyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0LCBBRkFJ SywgYXR0ZW1wdHMgdG8gcmV1c2Ugc29tZSBzdGFsZSB2YWx1ZXMgKGUuZy4sDQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMTYyMSI+UElQPC9hPikgaGF2ZSBiZWVuIHJl amVjdGVkIG91dC1vZi1oYW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgMmMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNhc2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PZmZpY2U6ICYjNDM7OTcyLTM5MjY2MzAyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FbWFp bDombmJzcDsmbmJzcDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEdyZWcgTWlyc2t5IFttYWlsdG86Z3Jl Z2ltaXJza3lAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAw OSwgMjAxNiAyOjA2IEFNPGJyPg0KPGI+VG86PC9iPiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSk8YnI+DQo8Yj5DYzo8L2I+IHNmY0BpZXRmLm9yZzsgQWxleGFuZGVyIFZhaW5zaHRlaW47IGJp ZXJAaWV0Zi5vcmc7IERyLiBUb255IFByenlnaWVuZGE7IFhpYW9odSBYdTsgbXBsc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIFRoZSBmaXJzdCBuaWJibGUgaXNzdWUg YXNzb2NpYXRlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgQ2FybG9z LCA8YnI+DQp0aGFuayB5b3UgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBTaG91bGQgd2UgdGhpbmsg YWJvdXQgZXN0YWJsaXNoaW5nIHRoZSByZWdpc3RyeSB0aGFuPw0KPGJyPg0KUmVnYXJkcywgR3Jl ZyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBcHIgOCwg MjAxNiA1OjM4IFBNLCAmcXVvdDtDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iPmNwaWduYXRhQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkdyZWcsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk15IHBvaW50LCBzb3JyeSBpZiBJIHdh cyBub3QgY2xlYXIsIHdhcyB0aGF0IHRoZXJlIGlzIG5vIHN1Y2ggYSB0aGluZyBhcyBhIOKAmGZp cnN0IG5pYmJsZSByZWdpc3RyeeKAmS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SW5zdGVhZCwgUkZDIDQ5MjgsIFNlY3Rpb24gNSwgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTI4I3NlY3Rpb24tNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0OTI4I3NlY3Rpb24tNTwvYT4sIHNheXM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO0lBTkEgaGFzIG1hcmtlZCB0aGUgdmFsdWUg MHgxIGluIHRoZSBJUCBwcm90b2NvbCB2ZXJzaW9uIG51bWJlciBzcGFjZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyAmbmJzcDthcyAmcXVvdDtSZXNlcnZlZCZxdW90OyBhbmQgcGxhY2VkIGEgcmVmZXJl bmNlIHRvIHRoaXMgZG9jdW1lbnQgdG8gYm90aCB2YWx1ZXM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsg Jm5ic3A7MHgwIGFuZCAweDEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+QW5kIHRoYXQgaXMgcmVmbGVjdGVkIGFzJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy92ZXJzaW9uLW51bWJlcnMvdmVyc2lvbi1udW1iZXJzLnhodG1s I3ZlcnNpb24tbnVtYmVycy0xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy92ZXJzaW9uLW51bWJlcnMvdmVyc2lvbi1udW1iZXJzLnhodG1sI3ZlcnNpb24t bnVtYmVycy0xPC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGUgSUFOQSB0ZXh0IGluIDQ5MjggaXMgYWRkaXRpb25hbGx5IGZvbGxvd2VkIGJ5IGEgZGlzY2xh aW1lcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7Tm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQg ZG9lcyBub3QgaW4gYW55IHdheSBjaGFuZ2UgdGhlIHBvbGljaWVzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7ICZuYnNwO3JlZ2FyZGluZyB0aGUgYWxsb2NhdGlvbiBvZiB2ZXJzaW9uIG51bWJlcnMsIGlu Y2x1ZGluZyB0aGUgcG9zc2libGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7dXNlIG9mIHRo ZSByZXNlcnZlZCBudW1iZXJzIGZvciBzb21lIGZ1dHVyZSBwdXJwb3NlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZ1cnRoZXIsIFJGQyA0Mzg1 IGRvZXMgbm90IHNwZWNpZnkgdGhlIOKAmGZpcnN0IG5pYmJsZeKAmSBhcyBhIGZpZWxkLiBJbnN0 ZWFkLCBpdCBkZXBpY3RzIHRoZSBhY3R1YWwgYmluYXJ5IHZhbHVlcyBmb3IgdGhlIGRpZmZlcmVu dCBDVyBmb3JtYXRzLiBJbiBvdGhlciB3b3JkcywgaXQNCiB0YWtlcyB0aGUgdmFsdWVzIGZyb20g dGhlIElQIHByb3RvY29sIHZlcnNpb24gbnVtYmVyIGFuZCBub3QgYXMgYSBuZXcgQ1cgRmllbGQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+UFM6IFNhc2hhLCBxdWljayB0eXBvLCBzLzExMTkvMTE5MC87PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5H cmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgQXByaWwgOCwgMjAxNiBhdCA3OjI4IFBNPGJyPg0KPGI+VG86IDwvYj5BbGV4 YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWlu QGVjaXRlbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNmY0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNAaWV0Zi5vcmc8L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5iaWVyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5iaWVyQGlldGYub3JnPC9hPiZndDssDQogJnF1b3Q7RHIuIFRv bnkgUHJ6eWdpZW5kYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlzaWV0ZkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj50b255c2lldGZAZ21haWwuY29tPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBsc0BpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7LCBYaWFvaHUgWHUgJmx0OzxhIGhyZWY9Im1haWx0 bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4aWFvaHVAaHVhd2VpLmNv bTwvYT4mZ3Q7LA0KIENhcmxvcyBQaWduYXRhcm8gJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0 YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW21wbHNdIFRoZSBmaXJzdCBuaWJibGUgaXNzdWUgYXNz b2NpYXRlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ SGkgU2FzaGEsDQo8YnI+DQp0aGFuayB5b3UgZm9yIHBvaW50aW5nIHRvIGV4aXN0aW5nIElBTkEg YWxsb2NhdGlvbiwgdGhvdWdoIHN0YWxlLiBJIHdvbmRlciBpZiB0aGVyZSBpcyB0aGUgcmVnaXN0 cnkgZm9yIHRoZSBmaXJzdCBuaWJibGUuIFdlLCBUb255IGFuZCBJLCBoYWQgZGlzY3Vzc2VkIHRo ZSB3YXkgdGhlIGZpcnN0IG5pYmJsZSBzcGFjZSBtYW5hZ2VkLiBJZiB0aGVyZSBhbHJlYWR5IGlz IHRoZSByZWdpc3RyeSwgY291bGQgeW91IHBsZWFzZSBwb2ludCBtZSB0byBpdC4NCjxicj4NClJl Z2FyZHMsIEdyZWcgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T24gQXByIDgs IDIwMTYgMjozMSBQTSwgJnF1b3Q7QWxleGFuZGVyIFZhaW5zaHRlaW4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DYXJs b3MgYW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5KdXN0IGZvciB0aGUgcmVmZXJlbmNlLCBJQU5BIGhhcyBkZWZpbmVkIHZlcnNpb24g NSAoMDEwMSkgaGFzIGFzc2lnbmVkIHRvIFNUIHByb3RvY29sIGFuZCByZWZlcnMgdG8gUkZDIDEx MTkuIFRoZSBsYXR0ZXIgaGFzIGJlZW4gb2Jzb2xldGVkIGJ5IFJGQyAxODE5LCBidXQgdGhlIElB TkEgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ YXNzaWdubWVudCBzdGlsbCBob2xkcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JcyB0aGVyZSwganVzdCBpbiBjYXNlLCBhbnkgcmVsYXRp b25zaGlwIGJldHdlZW4gQklFUiBhbmQgU1Q/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGh1bWIgdHlwZWQgb24gbXkgY2VsbHBob25lPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TYXNo YTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOiAmcXVvdDtDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRhdGU6IEZyaSwgQXBy aWwgMDgsIDIwMTYgOToyNSBQTSAmIzQzOzAzMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UbzogWGlhb2h1IFh1ICZsdDs8YSBocmVmPSJtYWls dG86eHV4aWFvaHVAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh1eGlhb2h1QGh1YXdlaS5j b208L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkNDOiA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHNAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmJpZXJAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPiwgJnF1b3Q7RHIuIFRvbnkgUHJ6eWdp ZW5kYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlzaWV0ZkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50b255c2lldGZAZ21haWwuY29tPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TdWJqZWN0OiBSZTogW21wbHNdIFRo ZSBmaXJzdCBuaWJibGUgaXNzdWUgYXNzb2NpYXRlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WGlhb2h1LCBUb255LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5PbiBBcHIgNywgMjAxNiwgYXQgMjozOSBQTSwgWHV4aWFvaHUgJmx0 OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+eHV4 aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+QXMgZm9yIHRoZSBmaXJzdCBuaWJibGUgaXNzdWUsIHdpbGwgaXQgdmlvbGF0ZSB0 aGUgbGF5ZXJpbmcgcHJpbmNpcGxlIG9mIG5ldHdvcmsgcHJvdG9jb2wgc3RhY2tzIGlmIHRoZSBm aXJzdCBuaWJibGUgb2YgYW55IG5ldyBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggY291bGQN CiBiZSBhbiBNUExTIHBheWxvYWQpJm5ic3A7aXMgdXNlZCBhcyB0aGUgJnF1b3Q7TVBMUyBwYXls b2FkIHR5cGUmcXVvdDsgZmllbGQ/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVhZGluZyZuYnNwO2RyYWZ0LXdhbmct Ymllci1ldGhlcm5ldC0wMSwgU2VjdGlvbiAzLCB0aGUg4oCcZmlyc3QgbmliYmxl4oCdIGlzIF9u b3RfIHVzZWQgYXMgYW4g4oCcTVBMUyBwYXlsb2FkIHR5cGXigJ0uIEluc3RlYWQsIHRoZSB0ZXh0 IGRlc2NyaWJlcyBhbiBhbnRpLWFsaWFzaW5nIG1lY2hhbmlzbSwNCiBtdWNoIGxpa2UgUkZDIDQ5 MjguJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSByZWxldmFu dCB0ZXh0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7Rmlyc3QgbmliYmxlOiBUaGUgZmlyc3QgNCBiaXRzIG9m IHRoZSBoZWFkZXIgYXJlIHNldCB0byAwMTAxOyB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ZW5zdXJlcyB0aGF0IHRoZSBCSUVSIGhl YWRlciB3aWxsIG5vdCBiZSBjb25mdXNlZCB3aXRoIGFuIElQIGhlYWRlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO29yIHdpdGggdGhlIGhl YWRlciBvZiBhIHBzZXVkb3dpcmUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5XaGljaCBzYXlzIOKAnOKApiB3aWxsIG5vdCBiZSBjb25mdXNlZCB3aXRoIOKApiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj53b3Vs ZG4ndCBpdCZuYnNwOyBiZSBtb3JlIHJlYXNvbmFibGUgYW5kIHN1c3RhaW5hYmxlJm5ic3A7dG8g Zml4IHRoZSZuYnNwO3Byb2JsZW0gKGkuZS4sIHRoZSBsYWNrIG9mIGEgcHJvdG9jb2wgZmllbGQg aW4gdGhlIE1QTFMgaGVhZGVyKSBieSB0aGUgTVBMUyBoZWFkZXIgaXRzZWxmPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2hvIHNheXMgaXQgaXMg YSAqcHJvYmxlbSo/IFRoZXJl4oCZcyBubyDigJxmaXhpbmfigJ0gbmVlZGVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CeSB0aGUgd2F5LCBzaW5j ZSBpdCdzIGNsYWltZWQgdGhhdCB0aGUgTlNIIGlzIHRyYW5zcG9ydC1pbmRlcGVuZGFudCwgaXQg bWVhbnMgdGhlIE5TSCBzaG91bGQgYmUgYWJsZSB0byBiZSB0cmFuc3BvcnRlZCBvdmVyIE1QTFMu IEhvd2V2ZXIsIGl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0DQogbmliYmxlIGlzc3VlIGhhcyBub3Qg YmUgY29uc2lkZXJlZCZuYnNwO2luIHRoZSBjdXJyZW50IE5TSCBkcmFmdC4gQXMgYSByZXN1bHQs IHdoZW4gZW5jYXBzdWxhdGluZyBOU0ggb3ZlciBNUExTLCB0aGUgTlNIIG1heSBiZSBtaXMtaW50 ZXJwcmV0ZWQgYXMgSVAgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWFzc2l2ZSBj b25mdXNpb24gb24gdGhpcyBwYXJhZ3JhcGgsIG9uIGEgbnVtYmVyIG9mIGxldmVscy4gRmlyc3Qs IE5TSCBpcyBub3Qg4oCcY2xhaW1lZCB0byBiZeKAnSB0cmFuc3BvcnQtaW5kZXBlbmRlbnQuIEl0 IGlzIGJ5IGNoYXJ0ZXIgYW5kDQogYnkgZGVzaWduLiBTZWNvbmQsIHRoZSBOU0ggZHJhZnQgZG9l cyBub3QgZXZlbiBpbmNsdWRlIHRoZSB0ZXJtIOKAnE1QTFPigJ0sIGJlY2F1c2UgaXQgZG9lcyBu b3QgZGVmaW5lIHRyYW5zcG9ydHMuIFRoZSBTRkMgRW5jYXBzdWxhdGlvbiBjYW4gYmUgdXNlZCBp biBhIHRyYW5zcG9ydC1hZ25vc3RpYyB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk9uZSBtb3JlIGNvbW1lbnQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIx MDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVU7Y29sb3I6YmxhY2siPuWPkeS7tuS6ujwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtCSUVS DQogWzxhIGhyZWY9Im1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5iaWVyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+ 5Luj6KGoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gVG9u eSBQcnp5Z2llbmRhIFs8YSBocmVmPSJtYWlsdG86dG9ueXNpZXRmQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnRvbnlzaWV0ZkBnbWFpbC5jb208L2E+XTxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmJsYWNrIj7l j5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7MjAxNjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuW5tDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+NDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6Ymxh Y2siPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+NTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBH b3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+DQogMjI6MzY8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJs YWNrIj7mlLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5iaWVyQGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuS4 uzwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 TWluZ0xpVTtjb2xvcjpibGFjayI+6aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwO1tCaWVyXQ0KIGNvbW1lbnRzIG9uIGRyYWZ0LXdhbmctYmll ci1ldGhlcm5ldC0wMTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmFmdGVyIHJlYWRpbmcmbmJzcDsgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5hKSBmaXJzdCBuaWJi bGU6IHJlZmVyIHRvIE1QTFMgZW5jYXBzIGFzICZxdW90O3RoZSBzYW1lIHZhbHVlJnF1b3Q7IHRv IGtlZXAgaW4gc3luYyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+T25lIGNvbW1lbnQgcmVnYXJk aW5nIHRoZSDigJxGaXJzdCBuaWJibGXigJ0gdGV4dCBhdCZuYnNwO2RyYWZ0LWlldGYtYmllci1t cGxzLWVuY2Fwc3VsYXRpb24tMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ U2luY2UgdGhlIGZ1bmN0aW9uIG9mIHRoZSBmaXJzdCBuaWJibGUgaXMgdG8gcHJldmVudCBhbGlh c2luZyB3aXRoIGFuIElQIHBhY2tldCwgaW4gb3JkZXIgZm9yIFJGQyA0OTI4IHRvIHNwZWNpZnkg dmFsdWVzIG9mIDB4MCBhbmQgMHgxIGZvciB0aGUgRmlyc3QgTmliYmxlLA0KIGl0IGhhZCB0byDi gJxSZXNlcnZl4oCdIElQIHByb3RvY29sIHZlcnNpb25zIG9mIDAgYW5kIDEsIHJlZmVyZW5jaW5n IHRoYXQgUkZDIChzZWUgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5 Mjgjc2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNDkyOCNzZWN0aW9uLTU8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SXMgdGhlIGludGVudCB0byByZS1hc3NpZ24gSVB2NSBhdCZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdmVyc2lvbi1udW1iZXJzLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdmVyc2lvbi1udW1iZXJzLzwv YT4mbmJzcDs/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5vdGUgdGhhdCBS RkMgNDkyOCBzYXlzIOKAnFJFUVVJUkVE4oCdIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO0l0IGlzIFJFUVVJUkVELCBob3dldmVyLCB0 aGF0IGFwcGxpY2F0aW9ucyBkZXBlbmQgdXBvbiBpbi1vcmRlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwO3BhY2tldCBkZWxpdmVyeSByZXN0 cmljdCB0aGUgZmlyc3QgbmliYmxlIHZhbHVlcyB0byAweDAgYW5kIDB4MS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5iKSByZWZlciB0byBhbGwgb3RoZXIgcG9zc2libGUgZmllbGRzIHRvIE1Q TFMgZW5jYXBzIHRvIGtlZXAgaW4gc3luYyB3aGVuIGRlc2NyaWJpbmcgaW5zdGVhZCBvZiByZXBl YXRpbmcmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmMpIHlvdSBuZWVkIHRvIGRl c2NyaWJlIHdoaWNoIGtpbmQgb2YgZXRoZXIgTUFDcyBhcmUgYWxsb3dlZCwgZXNwZWNpYWxseSBv biBicm9hZGNhc3QgbWVkaWEsIGkuZS4gaXMgaXQgYWx3YXlzIHAycCBvciBjYW4geW91IHRha2Ug YWR2YW50YWdlIG9mIHRoZSBicm9hZGNhc3QgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ ZCkgRmlndXJlIDQ6IHVzZSB0aGUgYXJjaGl0ZWN0dXJlL01QTFMgZW5jb2RpbmcgZm9yIHRoZSBs ZW5ndGgsIGRvbid0IGludmVudCBhIG5ldyBvbmUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPmUpIHdobyB3aWxsIG9idGFpbiBhIG5ldyBldGhlciB0eXBlIGZyb20gSUVFRT8gQXMg ZmFyIEkgdW5kZXJzdGFuZCwgbm90IGEgdHJpdmlhbCBwcm9jZXNzIGFsYmVpdCB3ZSBoYXZlIHNl dmVyYWwgbGlhaXNvbnMgd2l0aCBJRUVFJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi0tJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XZeKAmXZlIGhlYXJkIHRoYXQgYSBt aWxsaW9uIG1vbmtleXMgYXQgYSBtaWxsaW9uIGtleWJvYXJkcyBjb3VsZCBwcm9kdWNlIHRoZSBj b21wbGV0ZSB3b3JrcyBvZiBTaGFrZXNwZWFyZTsgbm93LCB0aGFua3MgdG8gdGhlIEludGVybmV0 LCB3ZSBrbm93IHRoYXQgaXMgbm90IHRydWUuPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPuKAlFJv YmVydCBXaWxlbnNreTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOm1wbHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5t cGxzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM3PR03MB0775C55E5AD3247F373007139D940AM3PR03MB0775eurp_-- From nobody Mon Apr 11 07:19:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079ED12EF24; Mon, 11 Apr 2016 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-BDLOyOkpeP; Mon, 11 Apr 2016 07:19:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F1C12EF2A; Mon, 11 Apr 2016 07:19:41 -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=okqA7OYMtzouzsTDX+LC+D11PRbhuPLbWRBXK7uhG1g=; b=SxT+kv0UI604V4FcKFkgiq7wF11EVhS9PHd12q5BF8eMIO9wFL8uC+F8zbiNbpRefmPjKFl/Zd9IeqsUmQW7HhoZEbNZFdIMeUvscKn720uQLR2v4MqqqapPiCPd2jYoRdZZjPLOc8bPFJOLCn49id5OZs1vQ5gRwcz7BAYS4q4= 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.153] (66.129.241.12) by CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 14:19:22 +0000 To: Alexander Vainshtein , Greg Mirsky References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> From: Eric C Rosen Message-ID: <570BB266.8090608@juniper.net> Date: Mon, 11 Apr 2016 10:19:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BLUPR14CA0043.namprd14.prod.outlook.com (10.163.209.139) To CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) X-MS-Office365-Filtering-Correlation-Id: 38680cc9-7b0d-4abc-34c9-08d36214481b X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 2:Or9tlYpN3u2SzFupnnFWjH6ifcVWOOxSWJPRIot5K47HQVBsdw3DzvjlWiH7SSpmS+GhNNZXdXrgJqChotzZZfTx+t9cXV7rK1ib9wj2dOtp2NAdTpiomsf8aq583Em2FFF/mBmKmVXgmPI99SVN3+IlJK8ldJ4lcjd03U4E/rbrQRAny6mENpTXIlng094L; 3:BEdiTsqLhFydPLVs0W2DNF/RAUdO+eZPE+MbV/0D2iFK/YEsvr1/ijYWAmC+CO2BtLzgCdnHmqv/Sfbb25kHQKvnk1vxrNcXUIvggIAhugN++885KpqRs/quHob8zXML X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB794; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 25:BW6Pmn2CPxV/4f5ORgWeJrVxk2+7pGq6E9ts8bSCR6cz9ZLmRbnN/T70dL+7f6c6gnAdfUifKmRXaYWy9Jdv/paFAtO4o5wnW+MvyW5xNHkXNfMIVHW5CjM1gdi4sxkqFLM31VENxmeLpB0J40eVOaS1DQqRHREiz7z9gcFFX0V5jmqq2whqQ7/EQghQzT9jm6JkP5XvSOXN5fJ6OFMwXAmwFXFtBnNWtOXyunERztdja9ytqYYz8giJBGPZr+R4Wo4ZvQO620tMkpbW2XBstNjhcyXfzeEefU+NrA0zM/yHvI6Sm7734SiTcScETUWIgLQ9UI4Jgb0OSLfOsG8Oy1LCBjeVbQZUEeS4n74CI7POxNoemPfgoxICe8Dlxa/PSYYCXrivPbgKzKiCpEaNRMlBMmC9CZODCARxMB7Lgzwt3+DcL8njD3ug1yJO97bLsRyFtyw4RrOTJltxBwttkih75Mh3nIloLZhmLMXrGcpFHWrUET0mKfpL7YFUs1B+sJuE596kQRn5decAn1IHZt8y3XvCQgtf8HM60RpCxfFwtaEV7By62RNomCdzsQ7Esp2qVxZujAp4A+TOPjhp4xQNz5KD/f/cWzhBMdk3aVgreYMfEz5Jr/2m5+K6N6dMAfpH4mtv0rkBFVoeMoF18kLh2p+3qfPdDkK6rx86xp6gHxaK0Q3/TH93UbTK63F7 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 20:Xio8BDmi+PhGZgcGWmiYcVf0oxhdyNv4Mbk7685xcT2jztnpccSNcAZgNGEFFkRjv9P9WXGnBa7Ax0Vo1t0FE1IY/HqHKn1R/J9Wpl6eCDfClAl/PCnZ9igMpVPA5utHuq825jD25Gz6hiwHsviyhcJcBso7LYxqINQv12xRtkBsaaJf2dStMrXTDN37gnXZFdjRoGl87ZcklAT+aXFVh48IMYlkzDwFbrM/yhmxaiRqS4iWpaCKQjc/7O6HK9nrUf6UyJ9UEXdN+lEugCyEBezsyyPjUOV5QFbDQLfUrVCaCic8ZHWcHF0Ijvt4mxKELJXnExt4iI7uOxbXjXtMwgazgLwIwA94S5xpVHjGylFx9a/eGhaFObkwxnZbqsCIqNMpGGZV4FieDUk0YmEVNBUkLh57TovN+9eNBEsJXLaZVHvp/Ohe2TdLpHJFjJOur+t98bRdfSDYZx4yvL8rl+3WaUQH+UfTAmR/EC41zS0DLntO8wO4CAFNvcPX9QOM; 4:71Z5eH8MuRNqD0wRKJ6alUD/BaRh2GtMLlU840Rr4ZYHBLrjMi0t5+oD7qse6hHAZPqsosYCbibmvLl0rsEEucUQHCHkeXc1EHlOeBQv8q28tcuc37Yxvlfki/ejGkq0/ehaSfXnSL/uS6YjLQAokue1hB/RAonJhoJNjr1tjvjMwZrTYyr7tGiMmDjp1IbuR4O/94bBYmPEs9BkN+IO+JrxXtHWQCmjDBjvI7rjEk+RlgKLKxHHhCE7DR0n64JYekeAzU68pYeteQWi8qLvlErc/KXyOYASGCiWvMfg/kARWSTNrmXDMj6nIR2xUZcFQo7UbZd+MgIy7fBmLRX5AUQQS4zsTRDohVhwZU50uGGoVMWEdLeFK/1MpwnFI0hcVWGxoi+x0WZz0fgg8Urnow== 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)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB794; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB794; X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(23676002)(4326007)(33656002)(50466002)(65956001)(65806001)(66066001)(64126003)(1096002)(586003)(3846002)(6116002)(42186005)(47776003)(5004730100002)(80316001)(2906002)(93886004)(92566002)(5008740100001)(4001350100001)(83506001)(230700001)(2950100001)(81166005)(77096005)(36756003)(189998001)(50986999)(86362001)(76176999)(65816999)(54356999)(87266999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB794; H:[172.29.33.153]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjA1TUI3OTQ7MjM6YzdLUEZDb1pjSHRTTHlhRlNSWTdzeDE0K2h3?= =?utf-8?B?N25KME5TdmhtYjJVQlNyYnUxSld2eTZkL2FScjFDbHJ1c2VVb0dJNzdDaDlo?= =?utf-8?B?K1FKOGVodFhWVVNEd2xHRlA1eUxWTGtNWXJKSXh4ODhrcmt5U3BkdjRUYjN4?= =?utf-8?B?K2k1K0tZVmRseHhOK2wvU2ZwcXJKblZ4bEdlRVQ0Mit6VWhXR0RxUnV2cjJi?= =?utf-8?B?SENjVnBmaW1KRldrV2cyUTE5QW5XWGIvOFBhRlhaOVpHNW44RE5ZQ0hPY3NI?= =?utf-8?B?NmtnMEY5Sml5ODFEdzBSTXduMklXY1FmUEx5dHZ2emNZTHpjYXZjMDIrbUo0?= =?utf-8?B?TkREZjVYVHNnVjlmeE1GNUJvWTR5c0lweFdPdjhEK1YwWnRSMG5ENGNwWTZ3?= =?utf-8?B?dmMrcytaRFFTU3dRcThnb1AvenJoRjU1ZURtaEdKVUVrZk1Tb0F1OEFGL241?= =?utf-8?B?UW11Wk9FR1NUcFZ3aVVJdnY4SkcrQ1paTzMrY3pBeEc2QnlxS0ZSVWNhWVpX?= =?utf-8?B?UitGU1gvVml2dmN3SnE3OGdUcGxWdmhxUjIvZWNuekxoaGhMc0ZZaVdiT016?= =?utf-8?B?SmlZZ0JXODhHM0hsRWRqVElUczJldXpzUDRTMlZtQThhSk1MbzlOZVZMVjFG?= =?utf-8?B?STBEcDNFZ1J4ZFVCeHhZVjgrL29xWFVPOEN2YmcyVUcyKzR5dHFoYWhEWEtw?= =?utf-8?B?alRQcjFFRVFwKzViQkp2V3hkSnJmN1NVNmdtNnJjUVJ3T2VDSUVKM2lobGUz?= =?utf-8?B?Zm1za0VkMnltMkRwZmdsTkZaK0dTMElIU3dzblV5QTRLR2k4Y2dZelhwZCtE?= =?utf-8?B?V3NHcVJCMWMwVmFjamE0RVpQTEQ2dEdNSVlzclk5QkNydlJ1WldOSS9HNGI4?= =?utf-8?B?SG40Ky8zeTVod3FwU0l4SkFObWF5Y2pONGdJR09NOGZsZklndzd3Wk51ZEtR?= =?utf-8?B?a2dtK1BFa0dQeHIxV2pTWHNkZTlTdFhYR3Y1aGhJMEVEdlAzc2FLVThMMkNP?= =?utf-8?B?cEE2WkZLSVlIT3dvTWc2cnQyZ01QMG5JTU9FR1ZlNmFvbU1YK2Q5cFhGU2pz?= =?utf-8?B?b0o2TzJPZW1iREY0M21wL01tOHN4Nnp0cldQdWlBcGRIWmJPN2RteFgrQnRR?= =?utf-8?B?THBrZEc2c0l4ai9kNmgwczNkbmN4eVVndjRLSm1wMzNyWDFKNy9CTjgvSTNS?= =?utf-8?B?Ty9aTjRWVmZoL25BY3E4Nkw4bTRSS3g3Qml3azhzdVIzaFVvTXJXNjNCVWpT?= =?utf-8?B?WTgra1pZeWFRZ2x6bllURnR2aWJDbWJKYkU2Sk11a082RXR2cHcxdGVOYTM3?= =?utf-8?Q?CdL9tLHavYWg+O7TD1SxDTYbbDep534=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 5:VrAJjOTcwBG4FSwBwgJsPyadCPZBZDmwBl5QU1j0AzwYPojKwb3GJspHA5jCyTQwsYKZ1digkk6UZ4vx8q1HMBvSEXSwTXlWIaceF40fYQK/OKP7ciXHf3fyg/Jj5BEAY15FpDxsfOukWpZImdUbzQ==; 24:gntWe3iCTB31al97lhdjXFIXTFERnsN9KzpgfL7o/SlF+h5FqxAjZk+JK9UyR+bP75Yx9X0K3Z7Uhbwjob1LXRY6vVH1RUGRcFHvr56g2wc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 14:19:22.7201 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB794 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 14:19:43 -0000 (Removed sfc from the cc-list, this seems out of scope for that WG.) In designing the BIER header, the BIER WG is free to mandate any value it chooses in the first nibble. These values do not come from a "first nibble" registry. It seems prudent to put a value like 5 for the following reasons: - If a BIER packet is being parsed by an off-line tool, this is a good hint (though just a hint) that the packet is actually a BIER packet; - If a BIER packet is traveling through an MPLS tunnel, and it traverses a node that does its MPLS load splitting by guessing at the type of the payload, then this is a good hint that the MPLS payload is not IPv4, IPv6, or PW. This strategy does incur a risk. Suppose IPv5 gets designed, implemented, and deployed, and folks start to deploy hardware that does MPLS load balancing by inspecting the IPv5 headers of the MPLS payloads. If a BIER packet is traversing an MPLS tunnel, inappropriate load splitting may occur if the hardware thinks the payload is IPv5 rather than BIER. This particular risk doesn't seem very significant to me. Thus I don't think there's anything here that needs fixing. From nobody Mon Apr 11 10:19:20 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872DC12F1EB; Mon, 11 Apr 2016 10:19:16 -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 XhAyYEaGanGJ; Mon, 11 Apr 2016 10:19:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77F6712F1EA; Mon, 11 Apr 2016 10:19:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4AE8B1E83B; Mon, 11 Apr 2016 13:23:32 -0400 (EDT) Date: Mon, 11 Apr 2016 13:23:32 -0400 From: Jeffrey Haas To: Greg Mirsky Message-ID: <20160411172332.GA22064@pfrc.org> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:19:16 -0000 Greg, This is more of a general comment on discussions from the development from RFC 7130 than any specific comment on your draft. On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > yes, link local multicast may be used in MC-LAG scenario. The draft states > that it MAY be used while the broadcast has SHOULD normative. But we are > all open to the discussion. During our discussions across multiple vendors, including some hardware vendors, it was determined that attempts to exercise the layer 3 mechanisms would vary significantly across implementations depending on how packets were encapsulated. Multicast in particular provided some problematic issues for us beyond the initial bootstrapping phase of LAG for BFD wherein we might not have ARP completed. My recommendation is to proceed with your drafts with similar caution. Try to stay as true to pure IP as possible to best insure the L3 data paths are exercised across implementations from various vendors. -- Jeff (speaking as an individual contributor) From nobody Mon Apr 11 11:51:10 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB19812D815; Mon, 11 Apr 2016 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpVjUjDujyew; Mon, 11 Apr 2016 11:51:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7B212E2C4; Mon, 11 Apr 2016 11:51:06 -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=k3L2eQ2m1uyFhRipxdnTyo4g4CCDnO99oA8YuEU23JM=; b=Waja2R5ihUUFBpYVXHkhL8h1Z5chR61vsZx0LDizUrVELLvHgBRr5EQRPNkU9ovcxar7bO9K10MOa7lBfZlnjptpvClu7vylqMtKhcsr7MthWw36e37kYVhL8pBsHJZpcSRjrCTXvJ9neXnsz89U5gt1lLmkmaLjWVg0XxupAlM= 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.153] (66.129.241.12) by BLUPR05MB787.namprd05.prod.outlook.com (10.141.209.146) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 18:50:47 +0000 To: Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> From: Eric C Rosen Message-ID: <570BF204.6050301@juniper.net> Date: Mon, 11 Apr 2016 14:50:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR12CA0010.namprd12.prod.outlook.com (10.160.137.20) To BLUPR05MB787.namprd05.prod.outlook.com (10.141.209.146) X-MS-Office365-Filtering-Correlation-Id: 4e4b20d1-a84f-48b1-d612-08d3623a3299 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 2:dPwsddEmD2C6CghbHbM/dX1qTrrNNMyj17j1827NZh/L26kh++cA78WoFxhkoZW7gLnKMz/tSDLc9aCzUQfp8xbM6F4dX++2Pr+Gt0d6QD4lPUXXYqW9AHbIq1HGN7DNXq6I8qGe6MDhfUPpYo94WFY+tkKTvIQ3WaWu/P2f1m8vaH7JvNnHADvpYH9xpOSj; 3:iGCOnw4M1cp7epouTPuBRDRXPc9jE6Gub4oF8ue0b05xZb9z/XSCrjw+DiSa5nt+LKxarEtlffbSCB50ca2kY+//mFfJaiksuhwaNY3sCU1GZwsLLtiFExnb2rNNflaY; 25:vAaho+YcdvhQd8zjWYlK1Q22URniYA06yoB3DW/uHEpYAp7wEEv0UhrAl0XuHOf6eXQqU++VqmarenUsulLlnsO/dr2BAg78FWOY0Efx/Hxti/pgdnIeYEOTlZUd27+JY0OWPp6+1D95B8hwovpppSovIPYwe7Zg5KNeAVProv4dLrmcApK/K1qi5lUhzIWuDRcPtRlOv3FaF3urvRqJam1qBn0ewCzPWhPyhb3pInJfjM6XwUzBu8iOD00gdXu9g6ZYWPTtjveL+HlSIFlYtaWXOQ4G1wpaQ/5OrswyDnzZQguzamSh6Hthcfr90XtIgrLitVYP3fQXMo472aCwWw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB787; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 20:4mX4XK6uggJ7g/01ccvc1EokAGKakGbLAFAclGxqcjI9Rd8rWmbK6FCMsnGk83jneX+AxVc8DghKtyslxq5ml628+ctky01oENy+HX6BE4lD1pf/ZfBthMp9UvWSd2TdMxzFbOFWZbsbFhDtu80GwnVDekcrkXEZU2+x1XoyCkS1mdWTt2UlHlNQ71S/7/IbPe2z8MbcdcynCVdgGquNQU35wliI+TctUIwnu9kYvmazQ2mx/WTEPlA1AqFrxEgXC1+cW9P5Xpqa+CChdiypa3cm56p/yqrT/CcgRvTaafU84QePAMA3UAWjzlmbU3xLaVxOyH3UxTum4m3UcT6j1Wc5DmkGNX6EtAWYmX7HYLOmVoZGGSdxER0IMQxyVUN2xUTLhwTK98vQPS88g3dECvVFn28YKnMXYjRzv6fdqr0TqSj8yryVA2V/LIkhksfnRvquOlfyREPYLZAxys3sKT5e9SvWQ7RYqHhBDKVQFLD2s+sL5Ki2J2R+P5RwBjSE; 4:1jbGutPmT+jj4J7hzGD87OV7TYkefWhTD7vEjrifIRhLbVUEsfSlXMVsLpxarcma+lqnQjaFghOeCUOYHFapGURu9bjsXG2ptNeomLynP5VU0BO9ozbG3kzCPSrQgw7UoGDNdpP9f0+8bIWZbi897DZ+5O4nNPQaUjTtuKrntdTse0C5lpfvVnZS234q/6L8BAV0HOta60HSv3ruY0Iitdw0ymKEe6O8X6xD8ceoR7CnzMUp2EJegnNLQfwltfJ8+ziotc/+9HF4R/2vsSkAWUwJJehtjqp0kfBTonBmpV4RMRfPkZ0Ji8yhi3jeBvQTyhBaBuaIfv3+KM6JXuWaTZpQVqZxNs/9D86Vr4coqCdc8RUvkxzlBK17BrQRRpry75h9GD7R0NZkUxqtJBdE+g== 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)(10201501046)(3002001)(6055026); SRVR:BLUPR05MB787; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB787; X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(586003)(1096002)(81166005)(80316001)(36756003)(2501003)(230783001)(33656002)(4001350100001)(6116002)(59896002)(2906002)(5001770100001)(83506001)(42186005)(230700001)(47776003)(3846002)(65816999)(50986999)(86362001)(87266999)(54356999)(76176999)(5004730100002)(23676002)(2950100001)(50466002)(92566002)(4326007)(77096005)(189998001)(66066001)(5008740100001)(65956001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB787; H:[172.29.33.153]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUI3ODc7MjM6YVNnTnEzU203ZXNVZVV1NWE4NWxXWDVlSyto?= =?utf-8?B?WWxMTW92aDdFS1NxaTl3TlBwL0JXeHhSTVgwYm4zT3FxNHlVdmdPRi93Qm9k?= =?utf-8?B?clZ3bklsTHR3MEFXd3ZvU2xSR3NDMmtpUEZjM05jRER1elBnVUJicFFzS1JI?= =?utf-8?B?cjF5d0VVVkFGUjN2QTlWVkcvUk9NV2pCa0J5Q1htaEVuRkVNWWNCMkJZS0Uw?= =?utf-8?B?RTZROFY2azhCVFNYek9sTmxPeHRpb1VGNmNrVWRpRjc1STdaKzV1Y2ttZEJv?= =?utf-8?B?VFhPTVNqakpmSFByRmdiRWJkWFJoTzNzNDdZOHFmaVhHQ2NCZGhLNzBsdVpo?= =?utf-8?B?QU9MekFyeDZYWWJqd1pvK3hNUXozMmt3RElabWpjNFpGaWV3OUhIaVNKQUpH?= =?utf-8?B?Tlhkd0ZMcm5YdjR4ZUh0d1pjaitHV1BaQUN6eWV5cm5zNHRtSlVuNDkvUkdn?= =?utf-8?B?d0pTOEFvTjRGeERqMENoT2E5OEtoeVZDY1ArTFdKVExuUW5MNmVMR3NwYUh3?= =?utf-8?B?bXNHRnArWGZIUGhHYTZzU09IbzFYbjdYdkZtbUlOZ3YxM29HNjFFSFloRTM3?= =?utf-8?B?bFR1Ny9pMlROcXhTZ0x1UHBrM1h6QlhJYks4WXlVZ2ZHZWlMZ1dxNU9RWXFa?= =?utf-8?B?Q2dBaHM0YmVCbFNaRlFaSXlZTzZYWmRwRUhTcVVDYlpOQXBRdlJvcGZKOER6?= =?utf-8?B?WHc4S2tlaStRcUZDTU5Gd2wyZ0ROeU1rbGFPeE1wdDFYMlJQUURaWE1FTXZF?= =?utf-8?B?VVc4TnVXTDJXc3MxTXp6U05Uc2ZxU0gvRHhyQXB0Ukk2QWY4aERBdXJodmJW?= =?utf-8?B?c3dibE5BWUdKMVhqS1Y4Zi9TTGdaNEtkYjJRSWt5MWtjUWU4UXFITGk5Z3B4?= =?utf-8?B?ZzdzTnY2ZVhIbTNSU3VwZmQ5ZldUUHVzYnBDNHVLY2FBWm9TMWJwWGdtVHVO?= =?utf-8?B?ckNJRFVxNFVhSmtnbUVqMlpHVDFwMGQ4MkFOK3F4SGhvRkhGdVQ3cWgyWWlm?= =?utf-8?B?NE9KQ1NuTGsrNWF5bFJWRUR1RVQ1dHhpS1BrRUdSVm5XWlJmOXJlaHVJeFd1?= =?utf-8?B?SC9ndExXYmlnYm1YVnpUNXhQNkNUQ01nYmd3Nk9uenVvNGlkL2FTbjJUVE5J?= =?utf-8?B?MXdVUm1vR1lSV2sycUdVU1pIUi8yRE5URmlob2Q1RTByRWFkZ205OTFKZlBo?= =?utf-8?B?UVlzZ0JPaTQzakVCVjFlNWIzbFliWVU5WjUxd1VkdTdCU1ZyYnBmTmRadzIr?= =?utf-8?B?eWtVRFIyVzZ4SU1aTWxydFN2ZXlLZHZzVWgvMVFBdWx3TWExOGVvNithNmZI?= =?utf-8?B?SVFJcHcydnhIaWVXRndFZXdJRmxzb0p5ZVVxcnI4SWxBZ3g4S01kUHVCWEtD?= =?utf-8?B?UXJsWXg0RTB6S3NqTGN1aEFsNmt5UGxqcUVjQ251Ymw3Z3FWT2tuemNFRXB4?= =?utf-8?Q?a7sJI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 5:WvHoAdOnx4YxKmsaRXTjpv6CmQqBhDdb/kaLyVj9tbk+NkRPWDTx5bEHAaeLR3mpgGFrbuPXx69shHtqwsOU/ZAOP+O/LhpCypG6wOvn+yt+yrIfKX1FDPgERt1gzPKxptke/saneGUvN/kxphoTIg==; 24:WHvSJg0KK5yRXcQmTUK+L0vW0u/kLtVtBmtdqpRWecVDKsjRHvqDe5AxmieM3zQTpUwj2XW7bb+yBSsviLzvFmsffMeMYZ2zFzig3eTkUAc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 18:50:47.7345 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB787 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 18:51:10 -0000 On 4/7/2016 6:39 PM, Xuxiaohu wrote: > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label of L is desired to forward that MPLS packet towards node N via an IP-based tunnel. In this case, the node N is the remote peer for that FEC. Yes, in this case, the tunnel's receive endpoint can be regarded as a remote label distribution peer of the tunnel's transmit endpoint. However, in the above case I don't think it is obvious that you want to IP-tunnel the packet to N. You might just want to tunnel it around the non-MPLS node. In that case, the tunnel's receive endpoint can still be regarded as a remote label distribution peer of the transmit endpoint, but the receive endpoint is not N. From nobody Mon Apr 11 11:58:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C146012F314; Mon, 11 Apr 2016 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6-XaXSVQXxJ; Mon, 11 Apr 2016 11:58:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B86312F312; Mon, 11 Apr 2016 11:58:39 -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=jeqy2oOgQyL5AWuKIzRtTorYS+pEJkJOZR6/Vdzo45k=; b=Tkpf4V5UUk2RS9cCnqSn2o5CTQCt2hoAS4j7lF8+o398IyOrbNvzneo06GhrYzATzEJZNDLF5fjwy8cs91p8MW2MYr47wrWp2warU9xzBa+Jj/p8Wl9DeJS3nTeTszkF2NmjlXVCTobpx0/LjjUXllw9S/QswLcq7HqddFBZqFk= 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.153] (66.129.241.12) by BY2PR05MB790.namprd05.prod.outlook.com (10.141.225.20) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 18:58:36 +0000 To: Uma Chunduri , Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> From: Eric C Rosen Message-ID: <570BF3D8.5080601@juniper.net> Date: Mon, 11 Apr 2016 14:58:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR12CA0051.namprd12.prod.outlook.com (10.163.230.19) To BY2PR05MB790.namprd05.prod.outlook.com (10.141.225.20) X-MS-Office365-Filtering-Correlation-Id: 909d53a4-4826-4ade-ff33-08d3623b4a4d X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 2:wy6vc9HMAZJOSK4VZauJS6MKXi/1f+i4yfEAr50DyNoEWRB9JjOLLvhZ0Ubbu9fXOnf5hhEr6RedC/HNldn39f8DvEy00IRgH95rA9Ar0B6pO+Qo+PYyr6uEKvY3DxT9cbNz+6ji1Xlz2eA/9ZA1+K6Pz3yJoBdwbZGDEcvN/HWgOt4OWpqCaB3LAK2HRyy0; 3:k1yL2tdSkjrjjoTyi6+W4fo+ta5CNRIAXKOpXsDPZQtZDTXnF0LPlUgqAQVYES5Xas1EBHfMwTu5JeyMcGOc7nZvYdb8R3CWd5Q23v+IfmvUJnDHSfMfiK4jCZBTBwxu; 25:EKPVsFnajiola3dxGClXfE3InMkvAFVs82eIJPZ27JExSAhNHy+dnepADchcrUT5fAi9SlpA5JF329NRvphNKVqLVtd7ABwjbBF3s2Psi12LurG2jQWVkGdjdF8UOm0J0a/6d0cnFMwlZrS0H8K5PmzEZ/Db/0ytd5nkDv5oVt/7WXrPu0hPovHOpoYbov4/DNRdXwZ97cFGT8zQNdoTBYd5vnRrtS+DGXMkEzZuPIFQ1nFWOXjxq44L3Q+rGPNrvnQhKqhUyg6wzeNaJj5xq9O+pdGZyCmDntUPShRDaBqiESVLJzacAo3ziAPBDfCsuIWMl/Qx6cgCO7lRpgjceg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB790; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 20:cVpMZ9DCOdpFuX1KbeFrYDtBYYEtCHQnDZWvXzR3Y5crvKgtJ62hSl+HhqGSro/l7qzwEPqlc3NBGFKyFkmMIX7rQ+JOXmr8GMmcjOWPY19kdL3NAEzljJeSi+4v6oeafV7xcXo4ZGpHgmJsdg3f2VeOoopgBXSktZE+3D1viijctxpYy7cUZzPnbPsLDM3TBLi9hpxpvmPpRs20aamovpiyZiJGn24sR1Xl4lzv8gXg2CA0sShylv5KaxHHutJK7t4L4PKM+eE4iFRpo83k0P8Tvz8A4uibNaf0VOiCKc5F4f18mJVIZlWFwJbPs129j/UklZrXzTZXpLIpuKHDPsXqz7ghG+6+7lc02ziT1tzAy0tP05JfJWxTsrTOMJFQwpsTJF147Grsbi2U+1HBFiQ9Xda7J44XSdTMUjmc/M52rFr5DkcyOYQiUmBQQ57WaubpHeRrYLX6s3Br14/bNJyU3UIbDtzYkDYGKQfFGSg2bgnvAEmkNWS70rxRJl2t; 4:BCnWcV2BUB++gckJTMnXYV6YW+dqTAncaFJSctg+nwN5P5xg1WZJKMlZyrlTb/FeXeGbLPR6g5v08ASwxy8golOgfnMgqTwaNsqCAMcqTCG72kTYxKz18l/jc+U5udo9myua2Q0nvctjIhB5K24bmHivKkIJ/9iU8WmvO42nescHxS6+puP5MVIRL48ZXCtGhq8RDlDsx/d7gbMSQ3Jgz4Vq0628P0huAdh1r9gRJbZ0XBzi8hwi0GRkK7uiprJ18o6Qe26OMyqISl6LAnt/HCj90Z0cZ8QasuOyTD2OH0JuyH/Zs9ACBKWwuXc6R3osJtYweR6RXStTcX0PYqf+N1Zf3xEhrk7ikvXbUMI4JPJ3xaTSpC1vJQXr/fRwHcTjfSLEkUhW61lNPl9SXhXciA== 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)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB790; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB790; X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(87266999)(54356999)(50986999)(65816999)(50466002)(76176999)(92566002)(189998001)(230700001)(81166005)(4326007)(5004730100002)(2906002)(33656002)(42186005)(80316001)(5001770100001)(586003)(5008740100001)(36756003)(6116002)(3846002)(2501003)(1096002)(2950100001)(77096005)(66066001)(230783001)(59896002)(65956001)(93886004)(86362001)(23676002)(47776003)(83506001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB790; H:[172.29.33.153]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI3OTA7MjM6WjJzdzVDVWkrVnFrK1dHMTJ0OFAvaHRDVUxM?= =?utf-8?B?YTU0Y1RNVGRXYStKVTJFK0xjNEkvT0QyU1BveEY1ODFtMUVLVmNSdzloY1lu?= =?utf-8?B?S0RRR3VEeE4zZmJSQVJENldvN2lEMU1ETjJMV3FIMkUzNFNXYTJZYS9RaWlH?= =?utf-8?B?czFJUlZQa2h3UzJ5N0t2ZTVwUXJFMFBReTFWVHBvQmI0Qzg4WXZSR1JKMVpz?= =?utf-8?B?YmkvYmtrRUZ0bEdQVGdTNW1MSXJ4aTlPSXNtU1VlVXAyZ2NLK096b21GR1Vo?= =?utf-8?B?VTlrWUt2V3htVDVMd2dKMEIvSFVKRFJKdHpUenI4VGY4Z2J6c2lEUWVHWkdV?= =?utf-8?B?Witrc0JxeWdJaVFhb21ab0R1cTE3SC9JQ3I4TE5yRFN6cDVjczdOaFZsZ3NI?= =?utf-8?B?MzBxYnUxS0ZFeFppRHY0c3BLQlZiY29DV2NXbENKQzZuY2xrSkVMNDBrNGNj?= =?utf-8?B?cmFMZ2dEaGhPaWFONUJ4V081eVdacUZzbGdDdDlYaUd5RUt4amNpaFBXOEFX?= =?utf-8?B?UmFkYVZNcDRQYzBpN3BYdmd0L3UxREVmaG1YZCtKZUVnYlJoWk50cm4yTXl5?= =?utf-8?B?K25EckNrQ3lYSVozOGFLMHYyOXVNV2xwbVR5NXVMNTFrWGhSalQvVDY4YmJY?= =?utf-8?B?Tk5CeVFwYWRoR3RKWmpuNHlLUXZCZm5vS2Zlc01iOWR2MUh1a3VyU0ZjUkFN?= =?utf-8?B?b0NTclYrSU03cENZVjZxc2JtQ0p5Q0o5NzBKb0M0Tk5nZjhaWlVkaklOSE11?= =?utf-8?B?OW5BOGhhcWpUWC8xSlgxVUxFei9yWjNLYVNqNzdSUFFEdzZIZmtDaDQyM0ZO?= =?utf-8?B?eUVKTzQybkxBSzdnMy9iUnp4K1lSQXFLczQ0b01qUlZEQnRUT0EwSzljRUVq?= =?utf-8?B?WmRpZWVLeGRjR1AybDMwVVEweTdER0E5Q3hIaS96RThWdEtwdTJRSEhxM0lM?= =?utf-8?B?TXFQTnRNcjJzSUIxRXVtWkk2MDlCTkM4bG92ZUlxOG80UnJqc3k2emJMeDBk?= =?utf-8?B?U2kveTBLREZEbGNaRExEMzN5ZElTQjA3VmhSV3RoM1JKOW9ZVGh5RGEzSkFI?= =?utf-8?B?QVNDTWkvOHdtNzZWTElCc2VGQVlLakpRS0JaVjNVTTFjalFRZ0FObFJQakhL?= =?utf-8?B?TmlFYTlHZmtEcHB5aW5SVHZhMjJ6WnVHaGYzQXRvNWVQU21KMDF5S0RTR0tv?= =?utf-8?B?NDY2L1J0WUNzRFFwSDV3c0kxL0NkcUFRNlJoS3lxWDJIcHdvaHNnSUFBWUlY?= =?utf-8?B?Q3p0cVpzL2ZpdTNtT294QmFVNCsxRW5iNllOTG41RzFFUnE1UkNqSWxiUm8y?= =?utf-8?B?bzJpZ0ZIcHVFeHBwNSthdmxnMVg0SytXdXp5aGZTbnR3d290VkVkdG5BS2Fs?= =?utf-8?B?R3RtVStKTVRmTE1BNzMrb1VHWnFieGl2RjczU2c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 5:WDyvFCMz4e9xlSoYjT6VYe2Sdr7IXHRi/EZk6F1ig98jI2IdWn10iydBe0gPAObpb451XaHAhSmBMClUTXRDUijUNVgoyHfEh6QMiQwwgfrMDfg5VNo1yY6CK1M9QIxoEaREbYSUfL2zvj7wp3WI0Q==; 24:rTALhHbezrVE0WFZazsQGTvbjQwuLoKNXnbEcLWXlvAy4z6av7diSzzrgyn1W29mtuB9uNU2yRGOgngWHJn+yPja8wSUN3C+RaOcmjfwbUY= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 18:58:36.9683 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB790 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 18:58:41 -0000 >> [Eric] It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't. > [Uma] May be true with non-SR and traditional MPLS. > But with SR I am working with one customer where MPLS (as SR data plane) is brought into their pure IGP-IP domain. > With static PW labels (inner label) currently pure soft GRE encap is being used (for transport) but SR is being planned from EPG to cell site routers eventually. > Planning slow upgrade for some of the MBH nodes with SR-MPLS data plane. In this case its quite possible to use (in future) non-shortest path SR label stack. > > Interesting. But I'm not sure which of two scenarios you are describing: 1. There is always an MPLS path from ingress to egress, but the shortest path may not consist entirely of MPLS-capable nodes. 2. There isn't always an MPLS path from ingress to egress. So if the ingress creates an MPLS packet, some intermediate node may need to re-encapsulate the packet in IP, in order to get the packet delivered to the egress node. Or is the scenario different from either of these two? From nobody Mon Apr 11 14:45:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB3412F36D; Mon, 11 Apr 2016 14:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 6cTQ-APoWn7o; Mon, 11 Apr 2016 14:45:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484A212F2F1; Mon, 11 Apr 2016 14:45:11 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-d3-570c14704bac Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 7B.C5.30335.0741C075; Mon, 11 Apr 2016 23:17:36 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 17:45:09 -0400 From: Uma Chunduri To: Eric C Rosen , Xuxiaohu , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ9/Rn2wgAYinAD//+k4MA== Date: Mon, 11 Apr 2016 21:45:08 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580216EE@eusaamb105.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> <570BF3D8.5080601@juniper.net> In-Reply-To: <570BF3D8.5080601@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonQbdAhCfc4PhaOYt1Gz4wW9xaupLV 4viF34wWW8+vYnRg8Wg58pbVY8mSn0we15uusgcwR3HZpKTmZJalFunbJXBlfDiylbGgSaRi z4FXLA2MB4S7GDk5JARMJD4smscCYYtJXLi3nq2LkYtDSOAoo8TKt7OYIJzljBJr3j5kAqli E9CT+Dj1JzuILSKQIzG57xZQBwcHs4CyxKm7MiBhYYE0iTkzjrFAlKRL3L7/kQ3CdpL4dfsF I0g5i4CqxM5JIiBhXgFfieu3NrJCrWKSeHb0AtgqTgFtiatf37OC2IxAx30/tQYsziwgLnHr yXwmiKMFJJbsOc8MYYtKvHz8jxXCVpTY1z+dHeI0TYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmM YrOQTJ2F0DELSccsJB0LGFlWMXKUFhfk5KYbGWxiBMbPMQk23R2M96d7HmIU4GBU4uFVYOUO F2JNLCuuzD3EKMHBrCTCWynJEy7Em5JYWZValB9fVJqTWnyIUZqDRUmctzH4X5iQQHpiSWp2 ampBahFMlomDU6qB0cWvf8e0GzaHVAPuhodttXuYwZu1KJh7TeHPskyZ/w4Rv5b7a2tJt/32 5ayoWfHmroivqL24d9n1aafmymk9sNpx9Un6Fvl7+1LDO2YfKmHuc5xgc/FZ9P+jqh/beb6d yttU/Vv7QtantRsDY/TSNHdf+bv+jOUqaUMXh8J7duyLcyInBT4IV2Ipzkg01GIuKk4EAKQk o3GbAgAA Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 21:45:13 -0000 SW4tbGluZSBbVW1hXToNCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBFcmljIEMgUm9zZW4gW21haWx0bzplcm9zZW5AanVuaXBlci5uZXRdIA0KU2Vu dDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMTo1OSBBTQ0KVG86IFVtYSBDaHVuZHVyaTsgWHV4 aWFvaHU7IHNwcmluZ0BpZXRmLm9yZw0KQ2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb bXBsc10gQ2xhcmlmaWNhdGlvbiBvbiB0aGUgbW90aXZhdGlvbiBvZiBkcmFmdC14dS1zcHJpbmct aXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDUNCg0KDQo+PiBbRXJpY10gSXQgd291bGQgYmUg c29tZXdoYXQgdW51c3VhbCB0byBoYXZlIGFuIElHUCBkb21haW4gaW4gd2hpY2ggc29tZSBub2Rl cyBzdXBwb3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQo+IFtVbWFdIE1heSBiZSB0cnVlIHdpdGgg bm9uLVNSIGFuZCB0cmFkaXRpb25hbCAgTVBMUy4NCj4gQnV0IHdpdGggU1IgSSBhbSB3b3JraW5n IHdpdGggb25lIGN1c3RvbWVyIHdoZXJlIE1QTFMgKGFzIFNSIGRhdGEgcGxhbmUpIGlzIGJyb3Vn aHQgaW50byB0aGVpciBwdXJlIElHUC1JUCBkb21haW4uDQo+IFdpdGggc3RhdGljIFBXIGxhYmVs cyAoaW5uZXIgbGFiZWwpICBjdXJyZW50bHkgcHVyZSBzb2Z0IEdSRSBlbmNhcCBpcyBiZWluZyB1 c2VkIChmb3IgdHJhbnNwb3J0KSAgYnV0IFNSIGlzIGJlaW5nIHBsYW5uZWQgZnJvbSBFUEcgdG8g Y2VsbCBzaXRlIHJvdXRlcnMgZXZlbnR1YWxseS4NCj4gUGxhbm5pbmcgc2xvdyB1cGdyYWRlIGZv ciBzb21lIG9mIHRoZSBNQkggbm9kZXMgd2l0aCBTUi1NUExTIGRhdGEgcGxhbmUuICBJbiB0aGlz IGNhc2UgaXRzIHF1aXRlIHBvc3NpYmxlIHRvIHVzZSAoaW4gZnV0dXJlKSBub24tc2hvcnRlc3Qg cGF0aCBTUiBsYWJlbCBzdGFjay4NCj4NCj4NCkludGVyZXN0aW5nLiAgQnV0IEknbSBub3Qgc3Vy ZSB3aGljaCBvZiB0d28gc2NlbmFyaW9zIHlvdSBhcmUgZGVzY3JpYmluZzoNCg0KMS4gVGhlcmUg aXMgYWx3YXlzIGFuIE1QTFMgcGF0aCBmcm9tIGluZ3Jlc3MgdG8gZWdyZXNzLCBidXQgdGhlIHNo b3J0ZXN0IHBhdGggbWF5IG5vdCBjb25zaXN0IGVudGlyZWx5IG9mIE1QTFMtY2FwYWJsZSBub2Rl cy4NCg0KMi4gVGhlcmUgaXNuJ3QgYWx3YXlzIGFuIE1QTFMgcGF0aCBmcm9tIGluZ3Jlc3MgdG8g ZWdyZXNzLiAgU28gaWYgdGhlIGluZ3Jlc3MgY3JlYXRlcyBhbiBNUExTIHBhY2tldCwgc29tZSBp bnRlcm1lZGlhdGUgbm9kZSBtYXkgbmVlZCB0byByZS1lbmNhcHN1bGF0ZSB0aGUgcGFja2V0ICBp biBJUCwgaW4gb3JkZXIgdG8gZ2V0IHRoZSBwYWNrZXQgZGVsaXZlcmVkIHRvIHRoZSBlZ3Jlc3Mg bm9kZS4NCg0KT3IgaXMgdGhlIHNjZW5hcmlvIGRpZmZlcmVudCBmcm9tIGVpdGhlciBvZiB0aGVz ZSB0d28/DQoNCltVbWFdOiBJIHdhcyBkZXNjcmliaW5nIG1vcmUgb2YgIzIuIEhvd2V2ZXIgIzEg aXMgb25lIG9mIHRoZSBjYXNlcy4gDQogICAgICAgICAgICAgIEluICMyIGFzIHRoZSBzaG9ydGVz dCBwYXRoIG5laWdoYm9yIGRvZXNuJ3Qgc3VwcG9ydCBTUiAoYW5kIG5vIG91dGdvaW5nIExEUC9S U1ZQIGxhYmVsKSBhbmQgaXQgcmVjb2duaXplcyB0aGUgc2FtZSwgaXQgZW5jYXBzdWxhdGVzIGlu IElQIG9yIA0KICAgICAgICAgICAgICBhcyBwZXIgdGhlICBlZ3Jlc3Mgbm9kZSBOJ3MgdHVubmVs IGRlLWNhcHN1bGF0aW9uIGNhcGFiaWxpdGllcy4gDQogICAgICAgICAgICAgIFRoZXJlIGlzIG5v IGFkZGl0aW9uYWwgY29tcHV0YXRpb24gcmVxdWlyZWQgaGVyZSBhbmQgIGl0cyBzdGlsbCBzaG9y dGVzdCBwYXRoIHRvd2FyZHMgZWdyZXNzIGJ1dCBub3QgbGFiZWxlZC4gDQoNCg== From nobody Mon Apr 11 14:46:37 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17012D16B; Mon, 11 Apr 2016 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js95Av0SKn6b; Mon, 11 Apr 2016 14:46:33 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FB312B033; Mon, 11 Apr 2016 14:46:33 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-e1-570c1b10a345 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.4A.22441.01B1C075; Mon, 11 Apr 2016 23:45:53 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 17:46:31 -0400 From: Uma Chunduri To: Eric C Rosen , Xuxiaohu , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ+FZusA///mJkA= Date: Mon, 11 Apr 2016 21:46:31 +0000 Message-ID: <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <570BF204.6050301@juniper.net> In-Reply-To: <570BF204.6050301@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonSldQmifc4PJ5Lot1Gz4wW9xaupLV 4viF34wWW8+vYnRg8Wg58pbVY8mSn0we15uusgcwR3HZpKTmZJalFunbJXBlLHvzhbWgV6Bi 35ILbA2Mx3m6GDk5JARMJOY/2sICYYtJXLi3nq2LkYtDSOAoo8TJiw+gnOWMEufXNLCDVLEJ 6El8nPoTzBYRyJGY3HcLqIiDg1lAWeLUXRmQsLBAmsScGcdYIErSJW7f/8gGYVtJPH/TzAhi swioSnzvf8gEYvMK+EpMfrmTCWLXY0aJ22/ugiU4BbQl1m35C2YzAl33/dQaMJtZQFzi1pP5 TBBXC0gs2XOeGcIWlXj5+B8rhK0osa9/OjtEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEax WUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbmIERtExCTbHHYx7ez0PMQpwMCrx8CqwcocL sSaWFVfmHmKU4GBWEuGtlOQJF+JNSaysSi3Kjy8qzUktPsQozcGiJM7rHfkvTEggPbEkNTs1 tSC1CCbLxMEp1cBYzrKgW/dPUEuP+BptM/ODNlXb2T81T2bIZdbUXLPn7oWIJxIT4jxnbi5c vCRWNtPn6t+D19PubHRRTMp7X7IoPOPE3TPtk4/E/HwcuETrPIujwmaXb2/W7TFWWhtf3sa2 4s4h/mc72uJ3nzombeD85evP+uwnBzbejWx2vJSXlR7P6fb82bz1SizFGYmGWsxFxYkAOKnP 0p4CAAA= Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 21:46:36 -0000 Hi Eric, Quick response In-line [Uma]: -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Monday, April 11, 2016 11:51 AM To: Xuxiaohu; spring@ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-isla= nds-connection-over-ip-05 On 4/7/2016 6:39 PM, Xuxiaohu wrote: > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix o= f node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LS= R receiving the above MPLS packet with top label of L is desired to forward= that MPLS packet towards node N via an IP-based tunnel. In this case, the = node N is the remote peer for that FEC. Yes, in this case, the tunnel's receive endpoint can be regarded as a remot= e label distribution peer of the tunnel's transmit endpoint. However, in the above case I don't think it is obvious that you want to IP-= tunnel the packet to N. =20 You might just want to tunnel it around the=20 non-MPLS node. In that case, the tunnel's receive endpoint can still=20 be regarded as a remote label distribution peer of the transmit endpoint, b= ut the receive endpoint is not N. [Uma]: Sure, this can be done; if at all if there is a shortest path node = towards N (supporting MPLS/SR) and if we can tunnel to that node yes, packe= t can be delivered to N eventually. However, this involves (additional computation/adjustment) c= omputation by all the boarder nodes to deliver it to the shortest SR node t= owards N. In that case, actually I would have expected operator to put= that additional node Label as the top label instead of N. If the former ha= s to happen operator has to=20 exercise how this should happen through a knob ..(apart from= the additional work on the boarder node). =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Apr 11 17:19:10 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688E612F558; Mon, 11 Apr 2016 17:19:09 -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 7cLnZsB3-SxR; Mon, 11 Apr 2016 17:19:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245D912F542; Mon, 11 Apr 2016 17:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3939; q=dns/txt; s=iport; t=1460420344; x=1461629944; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JFjG4kU9+w9VEpdD8+CfcftwNlAMqEQ23V0nWObETaU=; b=lzuzikXsMmfWtf2FDj4HeCY+Yd7oFKxKUfGR1k4yPzXrdaVBWStQY80/ MqAeG8TIAFU7mKB5DY8yWhJ3EepM/VUZavX+kOjXHgfSzEj2N/ZjAXSzp 9t7hMuctdMGCnc3ZataHGKTOxeqMsSGl1IZQbEdPGhcTqhQ2QGadr4IN3 U=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAgChPQxX/5pdJa1dgzeBUAa4ToIPD?= =?us-ascii?q?oFyhg0CgTA4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IEQi?= =?us-ascii?q?td5IiAQEBAQEBAQEBAQEBAQEBAQEBAQEOCIYhgXUIgk6HPyuCKwWYBAGDI4Fmi?= =?us-ascii?q?QKPDY8lAR4BQ4IEGYFKbIkHfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,471,1454976000"; d="asc'?scan'208";a="260139644" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2016 00:19:03 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3C0J2cX002826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 00:19:03 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 20:19:01 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 20:19:01 -0400 From: "Carlos Pignataro (cpignata)" To: Eric C Rosen Thread-Topic: [sfc] [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4A///PiXuAAHRmgP//0LOAgAA52ICABAmLAIAAGlYAgACnj4A= Date: Tue, 12 Apr 2016 00:19:01 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> In-Reply-To: <570BB266.8090608@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.101.176] Content-Type: multipart/signed; boundary="Apple-Mail=_0CE6BADB-12FF-46DB-920E-1F70601B7917"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "bier@ietf.org" , "mpls@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 00:19:09 -0000 --Apple-Mail=_0CE6BADB-12FF-46DB-920E-1F70601B7917 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 11, 2016, at 10:19 AM, Eric C Rosen wrote: >=20 > (Removed sfc from the cc-list, this seems out of scope for that WG.) >=20 > In designing the BIER header, the BIER WG is free to mandate any value = it chooses in the first nibble. These values do not come from a "first = nibble" registry. >=20 I absolutely agree with this, in particular the comment about a = registry. However... > It seems prudent to put a value like 5 for the following reasons: =E2=80=A6 the value (significance, merit) of such value (magnitude, = number) seems, as described below, minimally incremental. >=20 > - If a BIER packet is being parsed by an off-line tool, this is a good = hint (though just a hint) that the packet is actually a BIER packet; >=20 The format of a BIER packet have enough constrained or self-defining = fields, that an off-line parsing tool like Wireshark can apply enough = heuristics to figure it out, without the 0x5. > - If a BIER packet is traveling through an MPLS tunnel, and it = traverses a node that does its MPLS load splitting by guessing at the = type of the payload, then this is a good hint that the MPLS payload is = not IPv4, IPv6, or PW. >=20 I understand why a mid-point LSR might want to not alias the MPLS = payload with IPv4 or IPv6, to prevent mis-hashing in the LB. Why would a = node be interested in knowing the payload is not a PW? What would it do = differently? [It is interesting that the hint is, as described, to nudge = a node that the packet is *not* something, instead of the packet *is* = BIER.] > This strategy does incur a risk. Suppose IPv5 gets designed, = implemented, and deployed, and folks start to deploy hardware that does = MPLS load balancing by inspecting the IPv5 headers of the MPLS payloads. = If a BIER packet is traversing an MPLS tunnel, inappropriate load = splitting may occur if the hardware thinks the payload is IPv5 rather = than BIER. >=20 > This particular risk doesn't seem very significant to me. >=20 I agree that risk is quite insignificant (null in practice). The real = risk I believe is if some other application over MPLS uses 0x5 in the = first nibble, because they do not want to be confused with IP either, = and they do not like 0x0 or 0x1. > Thus I don't think there's anything here that needs fixing. >=20 >=20 Frankly do not have strong opinions either way. I do believe, however, = that the rational for using 0x5 as the first nibble is underspecified = (or at least under-documented). Thanks, =E2=80=94 Carlos. --Apple-Mail=_0CE6BADB-12FF-46DB-920E-1F70601B7917 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXDD70AAoJEIXgpQGOZny9GakP/2+/aFDxk+rPp+C8clVd0TbS bUqMZCmjlRJVCCLj9EAQzEkcj15PX/VmhlSik+UnQZkiUQ2E0jMFANWWtchokYrw YjPlCoFcxtP8lM+bgS4Qx/bYRg7uzyv0zI76axdBVTycPlAj5XRjKynLbhko8HOP 2RWWW5+YQcRssVV8SRKcKlsK85OKev6avZLO0l5aa84DSePllBmgqKNY4zZwI4ZP KMr9+vjgvdFvjdNNOdPrWHkLNcvkuVCm41oHq2eyyIB2Tj037MOwLVDSO4Nvwezj TQuXeH82VFaqXjKmnRHvM3wysqssoEraiBkuNRcwsg6zU7jw1/BVZK0UKVDOdO+2 69CP63EsbeaaLWXSUBdzl8TY/n+0bjYi44isSOPIZG82NDRwA+J1gawRM9NQLMfT zOI2cffjKhX8Z0ZgxVQ88DSpiI4QLtAI1Lxq7aQ75L0wiJQHSptrksR2nQwcLkiS t03nnZ/AADOhfIFrCtUYiKLSH4BXROSdYTjB7FWmMizAFhwXUqnQAvXw9cPEwuF4 ZV/rck5sZ/qkw+Eai7+/vJ28YD0t93JTQ6VCPxIkaKZxOedhm9XLrpzK3eJ+ybXg /lbo4Vu4E/xsndgcOBnuoH/RZMdsJGGs+Ed5+OevoFRd4y+fT/WjJIaOs2R2kr3J 9NPC0HB/FDPatxnICGSm =WrOs -----END PGP SIGNATURE----- --Apple-Mail=_0CE6BADB-12FF-46DB-920E-1F70601B7917-- From nobody Mon Apr 11 17:23:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3912D734; Mon, 11 Apr 2016 17:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 P377ktsvJxiy; Mon, 11 Apr 2016 17:23:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E4F12D748; Mon, 11 Apr 2016 17:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11884; q=dns/txt; s=iport; t=1460420586; x=1461630186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0N3D5npgpPjjS2Sk0b53JGAMw/sz/zcnpq/344krXLE=; b=VkDejO+pkJJD+ts3zSW6Z1603UjhAnL5GwaCsW2FXvWbxo/nJCe1hfTt LOc4ER0giT/48utJ3wDcDLg4rEjRFzTV7jl64M02tyPa1AEGZCKhyp5Je APyP9kKjpFLsADlhh53MeZq8Kzg2EA7CgDwnFvpejcw2hIFds9EKaxvkr 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnBQB/PwxX/4oNJK1dgmtMgVAGtWqFA?= =?us-ascii?q?YFyhg0CgTA5EwEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IEQi?= =?us-ascii?q?tdZIlAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF1CIJOhz8rgisFmAQBgyOBZ?= =?us-ascii?q?okCjw2PJQEiAj6CMoE1bIkHfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,471,1454976000"; d="asc'?scan'208,217";a="260310481" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 00:23:02 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3C0N2Fm030948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 00:23:02 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 20:23:01 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 20:23:01 -0400 From: "Carlos Pignataro (cpignata)" To: Xuxiaohu Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR5txOXaaHM/6UCWJNsvqUTm05+Fw8EA Date: Tue, 12 Apr 2016 00:23:01 +0000 Message-ID: <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.101.176] Content-Type: multipart/signed; boundary="Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 00:23:07 -0000 --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4 Content-Type: multipart/alternative; boundary="Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056" --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2016, at 6:39 PM, Xuxiaohu wrote: >=20 > On 4/6/2016 11:37 AM, Xuxiaohu wrote: >> The situation in MPLS-SR is a little bit complex since the outgoing = label for a given /32 or /128 prefix FEC could be learnt either from the = IGP next-hop of that FEC or the originator of that FEC due to the IGP = flooding property. In the former case, the IGP next-hop for a given FEC = is taken as the next-hop of the received MPLS packet belonging to that = FEC; in the latter case, the originator of that FEC is taken as the = next-hop of the MPLS packet belonging to that FEC ... the latter case = belongs to the "remote label distribution peer" case as defined in = RFC3031 >=20 > I don't believe this is correct. In SR, the fact that label L was > advertised by node N does not imply that a packet with L at the top of > the stack needs to be tunneled to N. In the typical case, the packet >=20 > [Xiaohu] The FEC associated the above label L is the /32 or 128/ = prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS = node, the LSR receiving the above MPLS packet with top label of L is = desired to forward that MPLS packet towards node N via an IP-based = tunnel. In this case, the node N is the remote peer for that FEC. >=20 Is this really a =E2=80=9Cremote label distribution peer=E2=80=9D? Or a = local one by way of the forwarding adjacency of an IP Tunnel as a = logical MPLS-enabled interface (towards N or bypassing the old router)? Thanks, =E2=80=94 Carlos. > Best regards, > Xiaohu --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 7, 2016, at 6:39 PM, Xuxiaohu <xuxiaohu@huawei.com>= wrote:

On 4/6/2016 11:37 AM, Xuxiaohu wrote:
The situation in MPLS-SR is = a little bit complex since the outgoing label for a given /32 or /128 = prefix FEC could be learnt either from the IGP next-hop of that FEC or = the originator of that FEC due to the IGP flooding property. In the = former case, the IGP next-hop for a given FEC is taken as the next-hop = of the received MPLS packet belonging to that FEC; in the latter case, = the originator of that FEC is taken as the next-hop of the MPLS packet = belonging to that FEC ... the latter case belongs to the "remote label = distribution peer" case as defined in RFC3031

I don't believe this is correct.  In SR, = the fact that label L was
advertised by node N does not imply that = a packet with L at the top of
the stack needs to be tunneled to N. =  In the typical case, the packet

[Xiaohu] The FEC associated the above label L is = the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC = is a non-MPLS node, the LSR receiving the above MPLS packet with top = label of L is desired to forward that MPLS packet towards node N via an = IP-based tunnel. In this case, the node N is the remote peer for that = FEC.


Is this really a =E2=80=9Cremote label = distribution peer=E2=80=9D? Or a local one by way of the forwarding = adjacency of an IP Tunnel as a logical MPLS-enabled interface (towards N = or bypassing the old router)?

Thanks,

=E2=80=94= Carlos.

Best regards,
Xiaohu

= --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056-- --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXDD/kAAoJEIXgpQGOZny93gAP/3Aw0ayjP2ljsafeSXLpFo1g CCyV4KCsrl6h4R3qt2igLqQ+1yOwjsGxmoHdJRaQ6BOxbEPtQ/yanR0dIxObXFjd gdsXjo5l1DaIJCFSsCHjJzoBfF8vwj4zlGudIO604z3e1EGR/7CAtbURcj5R5EA5 mjfNlrzSqLeyRiBEbjEXfCqJ7vb4tpIl2BvJmxUuo0pdPdLF4gENiUhfbjP4+HxF kki3iL0ud1ceZ6wcMdDqGz8END1GSK2nIMXCdVLEslobi6g9c2yUcj4K2JXDzHg8 B3So9a0kIj8aAbZ7SKnYnNo6dq8XN1ttNoRVUAmg6KPXGlN6VK9DtsTZcEXseRpv pGomhZ8sUPmMgTWWY0ThciLqk27Pi23WdTaNHlOK8MgEtyhDqP8yZk6HIHtoTEra 6HqnWpyKVXZOoudAyEVeyQmdbmiaoRqk004pUGqY6tUmvV8zCPMhR5cz6AyUB6Fa U4fz0ucAqBHV/bPMNCgA2Gv28z00YIB6Mk3TKb5qSlIM2aF+G+aqkrSXxD5lozFP 2l9J//PIS6CGOd1YKouWt3qSwB19IM3MlsRdm+smeuRzPcpmVsYtwcc51QdfEYHh 6HeAWDlXyZ1kQwEUVsush4SHlAnhzx2U9Xq7a48bTiQ+BpdiR9eVs04wH3IvsSAv DpGR5xH+SZ2Dhd8TRA6o =fhXG -----END PGP SIGNATURE----- --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4-- From nobody Tue Apr 12 03:08:04 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EA812E55E; Tue, 12 Apr 2016 03:08:02 -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 iPDzcOMQ2Bhh; Tue, 12 Apr 2016 03:08:01 -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 F17A812E500; Tue, 12 Apr 2016 03:08:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE85678; Tue, 12 Apr 2016 10:07:57 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 11:07:57 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 18:07:51 +0800 From: Xuxiaohu To: Uma Chunduri , Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT6ABYY/AIAAMR2AgAFUO4A= Date: Tue, 12 Apr 2016 10:07:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53933F@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <570BF204.6050301@juniper.net> <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A020202.570CC8FE.015F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bd99262ea2d76e94853e1e05ac2cff1 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 10:08:02 -0000 > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Tuesday, April 12, 2016 5:47 AM > To: Eric C Rosen; Xuxiaohu; spring@ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > Hi Eric, >=20 > Quick response In-line [Uma]: >=20 > -- > Uma C. >=20 >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Monday, April 11, 2016 11:51 AM > To: Xuxiaohu; spring@ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > On 4/7/2016 6:39 PM, Xuxiaohu wrote: > > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix= of node > N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR > receiving the above MPLS packet with top label of L is desired to forward= that > MPLS packet towards node N via an IP-based tunnel. In this case, the node= N is > the remote peer for that FEC. >=20 > Yes, in this case, the tunnel's receive endpoint can be regarded as a rem= ote label > distribution peer of the tunnel's transmit endpoint. >=20 > However, in the above case I don't think it is obvious that you want to I= P-tunnel > the packet to N. > You might just want to tunnel it around the > non-MPLS node. In that case, the tunnel's receive endpoint can still > be regarded as a remote label distribution peer of the transmit endpoint,= but the > receive endpoint is not N. >=20 > [Uma]: Sure, this can be done; if at all if there is a shortest path nod= e towards > N (supporting MPLS/SR) and if we can tunnel to that node yes, packet can = be > delivered to N eventually. > However, this involves (additional computation/adjustment) > computation by all the boarder nodes to deliver it to the shortest SR nod= e > towards N. > In that case, actually I would have expected operator to p= ut > that additional node Label as the top label instead of N. If the former h= as to > happen operator has to > exercise how this should happen through a knob ..(apart fr= om > the additional work on the boarder node). Agree with Uma. There is no need to introduce any complexity to the SPF alg= orithm by taking N as the remote peer. Best regards, Xiaohu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 12 03:15:10 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8512EA4E; Tue, 12 Apr 2016 03:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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 xMiY48S0daIn; Tue, 12 Apr 2016 03:15:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1C612EAB6; Tue, 12 Apr 2016 03:05:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLX93296; Tue, 12 Apr 2016 10:05:23 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 11:05:14 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 18:05:08 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT6ABeMWgIABJ9Ug Date: Tue, 12 Apr 2016 10:05:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932F@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> In-Reply-To: <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.570CC863.01BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e2ba583e0e62352372d91647ccbbba9 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 10:15:09 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDg6MjMgQU0NClRvOiBYdXhp YW9odQ0KQ2M6IEVyaWMgQyBSb3Nlbjsgc3ByaW5nQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRpb24gb2YgZHJh ZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCg0KT24gQXByIDcs IDIwMTYsIGF0IDY6MzkgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCk9uIDQvNi8yMDE2IDExOjM3IEFNLCBYdXhp YW9odSB3cm90ZToNCg0KVGhlIHNpdHVhdGlvbiBpbiBNUExTLVNSIGlzIGEgbGl0dGxlIGJpdCBj b21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgYSBnaXZlbiAvMzIgb3IgLzEyOCBw cmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIgZnJvbSB0aGUgSUdQIG5leHQtaG9wIG9m IHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9yIG9mIHRoYXQgRkVDIGR1ZSB0byB0aGUgSUdQIGZs b29kaW5nIHByb3BlcnR5LiBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBJR1AgbmV4dC1ob3AgZm9y IGEgZ2l2ZW4gRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0LWhvcCBvZiB0aGUgcmVjZWl2ZWQgTVBM UyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBv cmlnaW5hdG9yIG9mIHRoYXQgRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0LWhvcCBvZiB0aGUgTVBM UyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDIC4uLiB0aGUgbGF0dGVyIGNhc2UgYmVsb25n cyB0byB0aGUgInJlbW90ZSBsYWJlbCBkaXN0cmlidXRpb24gcGVlciIgY2FzZSBhcyBkZWZpbmVk IGluIFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgY29ycmVjdC4gIEluIFNSLCB0 aGUgZmFjdCB0aGF0IGxhYmVsIEwgd2FzDQphZHZlcnRpc2VkIGJ5IG5vZGUgTiBkb2VzIG5vdCBp bXBseSB0aGF0IGEgcGFja2V0IHdpdGggTCBhdCB0aGUgdG9wIG9mDQp0aGUgc3RhY2sgbmVlZHMg dG8gYmUgdHVubmVsZWQgdG8gTi4gIEluIHRoZSB0eXBpY2FsIGNhc2UsIHRoZSBwYWNrZXQNCg0K W1hpYW9odV0gVGhlIEZFQyBhc3NvY2lhdGVkIHRoZSBhYm92ZSBsYWJlbCBMIGlzIHRoZSAvMzIg b3IgMTI4LyBwcmVmaXggb2Ygbm9kZSBOLiBXaGVuIHRoZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0 aGF0IEZFQyBpcyBhIG5vbi1NUExTIG5vZGUsIHRoZSBMU1IgcmVjZWl2aW5nIHRoZSBhYm92ZSBN UExTIHBhY2tldCB3aXRoIHRvcCBsYWJlbCBvZiBMIGlzIGRlc2lyZWQgdG8gZm9yd2FyZCB0aGF0 IE1QTFMgcGFja2V0IHRvd2FyZHMgbm9kZSBOIHZpYSBhbiBJUC1iYXNlZCB0dW5uZWwuIEluIHRo aXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0aGUgcmVtb3RlIHBlZXIgZm9yIHRoYXQgRkVDLg0KDQoN CklzIHRoaXMgcmVhbGx5IGEg4oCccmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVy4oCdPyBP ciBhIGxvY2FsIG9uZSBieSB3YXkgb2YgdGhlIGZvcndhcmRpbmcgYWRqYWNlbmN5IG9mIGFuIElQ IFR1bm5lbCBhcyBhIGxvZ2ljYWwgTVBMUy1lbmFibGVkIGludGVyZmFjZSAodG93YXJkcyBOIG9y IGJ5cGFzc2luZyB0aGUgb2xkIHJvdXRlcik/DQoNCltYaWFvaHVdIHdoYXTigJlzIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIGFib3ZlIHR3bz8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoN ClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDg6MjMgQU08YnI+DQo8Yj5U bzo8L2I+IFh1eGlhb2h1PGJyPg0KPGI+Q2M6PC9iPiBFcmljIEMgUm9zZW47IHNwcmluZ0BpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIENsYXJp ZmljYXRpb24gb24gdGhlIG1vdGl2YXRpb24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29u bmVjdGlvbi1vdmVyLWlwLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBcHIgNywgMjAxNiwgYXQgNjozOSBQTSwgWHV4 aWFvaHUgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIj54dXhpYW9odUBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiA0LzYvMjAxNiAxMTozNyBBTSwgWHV4aWFvaHUg d3JvdGU6PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHNpdHVhdGlvbiBpbiBNUExTLVNSIGlz IGEgbGl0dGxlIGJpdCBjb21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgYSBnaXZl biAvMzIgb3IgLzEyOCBwcmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIgZnJvbSB0aGUg SUdQIG5leHQtaG9wIG9mDQogdGhhdCBGRUMgb3IgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMg ZHVlIHRvIHRoZSBJR1AgZmxvb2RpbmcgcHJvcGVydHkuIEluIHRoZSBmb3JtZXIgY2FzZSwgdGhl IElHUCBuZXh0LWhvcCBmb3IgYSBnaXZlbiBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9m IHRoZSByZWNlaXZlZCBNUExTIHBhY2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUM7IGluIHRoZSBs YXR0ZXIgY2FzZSwgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMgaXMgdGFrZW4NCiBhcyB0aGUg bmV4dC1ob3Agb2YgdGhlIE1QTFMgcGFja2V0IGJlbG9uZ2luZyB0byB0aGF0IEZFQyAuLi4gdGhl IGxhdHRlciBjYXNlIGJlbG9uZ3MgdG8gdGhlICZxdW90O3JlbW90ZSBsYWJlbCBkaXN0cmlidXRp b24gcGVlciZxdW90OyBjYXNlIGFzIGRlZmluZWQgaW4gUkZDMzAzMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQpJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBjb3JyZWN0LiAmbmJz cDtJbiBTUiwgdGhlIGZhY3QgdGhhdCBsYWJlbCBMIHdhczxicj4NCmFkdmVydGlzZWQgYnkgbm9k ZSBOIGRvZXMgbm90IGltcGx5IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2Y8YnI+ DQp0aGUgc3RhY2sgbmVlZHMgdG8gYmUgdHVubmVsZWQgdG8gTi4gJm5ic3A7SW4gdGhlIHR5cGlj YWwgY2FzZSwgdGhlIHBhY2tldDxicj4NCjxicj4NCltYaWFvaHVdIFRoZSBGRUMgYXNzb2NpYXRl ZCB0aGUgYWJvdmUgbGFiZWwgTCBpcyB0aGUgLzMyIG9yIDEyOC8gcHJlZml4IG9mIG5vZGUgTi4g V2hlbiB0aGUgSUdQIG5leHQtaG9wIHRvd2FyZHMgdGhhdCBGRUMgaXMgYSBub24tTVBMUyBub2Rl LCB0aGUgTFNSIHJlY2VpdmluZyB0aGUgYWJvdmUgTVBMUyBwYWNrZXQgd2l0aCB0b3AgbGFiZWwg b2YgTCBpcyBkZXNpcmVkIHRvIGZvcndhcmQgdGhhdCBNUExTIHBhY2tldCB0b3dhcmRzIG5vZGUg TiB2aWENCiBhbiBJUC1iYXNlZCB0dW5uZWwuIEluIHRoaXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0 aGUgcmVtb3RlIHBlZXIgZm9yIHRoYXQgRkVDLjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JcyB0aGlzIHJlYWxseSBhIOKAnHJlbW90ZSBs YWJlbCBkaXN0cmlidXRpb24gcGVlcuKAnT8gT3IgYSBsb2NhbCBvbmUgYnkgd2F5IG9mIHRoZSBm b3J3YXJkaW5nIGFkamFjZW5jeSBvZiBhbiBJUCBUdW5uZWwgYXMgYSBsb2dpY2FsIE1QTFMtZW5h YmxlZCBpbnRlcmZhY2UgKHRvd2FyZHMgTiBvciBieXBhc3NpbmcgdGhlIG9sZCByb3V0ZXIpPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSB3aGF04oCZcyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhYm92ZSB0d28/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_-- From nobody Tue Apr 12 06:44:00 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1973D12E372; Tue, 12 Apr 2016 06:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 GVlID08un2T4; Tue, 12 Apr 2016 06:43:58 -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 1B4B212E2EA; Tue, 12 Apr 2016 06:43:58 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 04C721802C3D; Tue, 12 Apr 2016 15:43:54 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" Message-ID: <570CFB90.8020706@pi.nu> Date: Tue, 12 Apr 2016 21:43:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:43:59 -0000 Working Group, The authors of draft-ietf-mpls-spring-entropy-label has told us that the document is ready to be considered for working group last call. We will do an IPR poll prior to the start of the wg last call. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- label? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosures filed directly against this document. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair -- 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 12 06:51:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A6312DBAB; Tue, 12 Apr 2016 06:51:48 -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 LxO9gLhVYshr; Tue, 12 Apr 2016 06:51:47 -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 095E612D541; Tue, 12 Apr 2016 06:51:47 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id F2F5A5B473EBA; Tue, 12 Apr 2016 13:51:41 +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 u3CDpjj4002634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2016 13:51:45 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u3CDpi1P015116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Apr 2016 15:51:44 +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; Tue, 12 Apr 2016 15:51:44 +0200 From: "Henderickx, Wim (Nokia - BE)" To: EXT Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRlMFl+Y4T8+SxW0SCVuhvdnDUoZ+GbCMA Date: Tue, 12 Apr 2016 13:51:43 +0000 Message-ID: <40DD1A73-B0EA-435C-B7E5-1933DFF4213E@alcatel-lucent.com> References: <570CFB90.8020706@pi.nu> In-Reply-To: <570CFB90.8020706@pi.nu> 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: text/plain; charset="utf-8" Content-ID: <7C4DCF7B81CD1F4D8A7FC2F5D18665C9@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 13:51:49 -0000 SSBhbSBub3QgYXdhcmUgb2YgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdA0KDQoNCg0KDQpPbiAx Mi8wNC8xNiAxNjo0MywgIm1wbHMgb24gYmVoYWxmIG9mIEVYVCBMb2EgQW5kZXJzc29uIiA8bXBs cy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsb2FAcGkubnU+IHdyb3RlOg0KDQo+V29y a2luZyBHcm91cCwNCj4NCj5UaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVu dHJvcHktbGFiZWwgaGFzIHRvbGQgdXMgdGhhdA0KPnRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBi ZSBjb25zaWRlcmVkIGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCj4NCj5XZSB3aWxsIGRv IGFuIElQUiBwb2xsIHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgd2cgbGFzdCBjYWxsLg0KPg0K PlRoaXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsLg0KPg0KPkFyZSB5b3UgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LQ0KPmxh YmVsPw0KPg0KPklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQo+KHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUz NzggZm9yIG1vcmUgZGV0YWlscykuDQo+DQo+VGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBm aWxlZCBkaXJlY3RseSBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+DQo+SWYgeW91IGFyZSBsaXN0 ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8N Cj50aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBv ZiBhbnkgcmVsZXZhbnQNCj5JUFIuICpUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0 aGUgTVBMUyB3ZyBtYWlsaW5nIGxpc3QuKiBUaGUNCj5kb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNl IHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4NCj5yZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4NCj5JZiB5b3UgYXJlIG9uIHRoZSBN UExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KPmNv bnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJl IGF3YXJlIG9mIGFueQ0KPklQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNv bmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCj4NCj4NCj4vTG9hDQo+bXBscyB3ZyBjby1jaGFp cg0KPi0tIA0KPg0KPg0KPkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQo+U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAg ICAgICAgICAgICAgICBsb2FAcGkubnUNCj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50 KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1wbHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Tue Apr 12 08:13:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A112EF22; Tue, 12 Apr 2016 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uHsVBQ9tWegw; Tue, 12 Apr 2016 08:13:38 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A585512EF1F; Tue, 12 Apr 2016 08:13:37 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p188so25936166oih.2; Tue, 12 Apr 2016 08:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fSYZAs5PiBtWvoW4vKgN4AXd2I1UYXceUWhjZnKMSAg=; b=UHddwiuZX2PtZNyyIBH86P32Xso+e+k6EkT0QrD7DcoTWxS7xvmgXfCpOeg6UYZ7EN XHFLG487X3jPlhhqlYFp0zORkjAzcYxnzcyGIl3gDMY5odz/Fylqp1diwWqo1JUNu4eI wHY3x4IT7ZU+P4UwLPIud/J0eetuixqUVFSbb6hjwwJs5oaFvtwr+bsB+zykQjed9p9H mo7bfByKKTHX1V1znn/6xPRsXdroqpnVJ2dWq69JX0dORAlEHcjMhiuLAlEi5fSHKOuS pi5+sRCAFow1JtQQ8gXxAq/oiVa+ZrRc+bQy25Wz18JtUQDNy1HThDgBqNsnrtRznD2U qoTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fSYZAs5PiBtWvoW4vKgN4AXd2I1UYXceUWhjZnKMSAg=; b=Vk13VM7eJxLb+6qju/RInsWZnWpi0OUKQR9eyhdlyGL1eCJ7HzCYlA0AxpBbFnBaUk 54raZufen8/Gg/ADTTxFmpzfGwxb9LRndTF2Y5VJqRRT9ZehZHPaI8NgYpCKGs+WK0sW iFbso+Jndp/up7P9esna7bcZP8noZ8br2LT3weCI43wWCS1jMKOvShnprnf1RlT0DU/4 FCDdyupKIFopM1tFIMR2QMNNM7sarNmDlxBKCqpVCTAq3au1rsEzCD1KbTt2aUXjhCxJ 7l3rRoPSIte7z7UI91dhGxf9B3HqDGZg3oJYKaMZb7CsM877Y7hBhPr0Q9SYWWBqTULi iX7A== X-Gm-Message-State: AOPr4FWf7x44JyO/VL0cTyAlvNYKWzstf5KsSKGyFJeUi6HOUMJxKvyXxMh3pUNZ8i+MQLE/Y73W1r+JXGnV+w== X-Received: by 10.157.36.3 with SMTP id p3mr1889185ota.62.1460474016983; Tue, 12 Apr 2016 08:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.175.4 with HTTP; Tue, 12 Apr 2016 08:13:07 -0700 (PDT) In-Reply-To: <40DD1A73-B0EA-435C-B7E5-1933DFF4213E@alcatel-lucent.com> References: <570CFB90.8020706@pi.nu> <40DD1A73-B0EA-435C-B7E5-1933DFF4213E@alcatel-lucent.com> From: Sri Date: Tue, 12 Apr 2016 08:13:07 -0700 Message-ID: To: "Henderickx, Wim (Nokia - BE)" Content-Type: multipart/alternative; boundary=001a1147b38efc75fa05304b1ae9 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 15:13:40 -0000 --001a1147b38efc75fa05304b1ae9 Content-Type: text/plain; charset=UTF-8 Hi Loa, I am not aware of IPR that applies to this draft. Sri On Tue, Apr 12, 2016 at 6:51 AM, Henderickx, Wim (Nokia - BE) < wim.henderickx@nokia.com> wrote: > I am not aware of IPR related to this draft > > > > > On 12/04/16 16:43, "mpls on behalf of EXT Loa Andersson" < > mpls-bounces@ietf.org on behalf of loa@pi.nu> wrote: > > >Working Group, > > > >The authors of draft-ietf-mpls-spring-entropy-label has told us that > >the document is ready to be considered for working group last call. > > > >We will do an IPR poll prior to the start of the wg last call. > > > >This mail starts the IPR poll. > > > >Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- > >label? > > > >If so, has this IPR been disclosed in compliance with IETF IPR rules > >(see RFCs 3979, 4879, 3669 and 5378 for more details). > > > >There are no IPR disclosures filed directly against this document. > > > >If you are listed as a document author or contributor please respond to > >this email regardless of whether or not you are aware of any relevant > >IPR. *The response needs to be sent to the MPLS wg mailing list.* The > >document will not advance to the next stage until a response has been > >received from each author and contributor. > > > >If you are on the MPLS WG email list but 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. > > > > > >/Loa > >mpls wg co-chair > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > --001a1147b38efc75fa05304b1ae9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

I am not aware of IPR that appl= ies to this draft.

Sri

On Tue, Apr 12, 2016 at 6:51 AM, = Henderickx, Wim (Nokia - BE) <wim.henderickx@nokia.com> wrote:
I am not aware of IPR related t= o this draft




On 12/04/16 16:43, "mpls on behalf of EXT Loa Andersson" <mpls-bounces@ietf.org on behalf of= loa@pi.nu> wrote:

>Working Group,
>
>The authors of draft-ietf-mpls-spring-entropy-label has told us that >the document is ready to be considered for working group last call.
>
>We will do an IPR poll prior to the start of the wg last call.
>
>This mail starts the IPR poll.
>
>Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy= -
>label?
>
>If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>There are no IPR disclosures filed directly against this document.
>
>If you are listed as a document author or contributor please respond to=
>this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor.
>
>If you are on the MPLS WG email list but are not listed as an author or=
>contributor, then please explicitly respond only if you are aware of an= y
>IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>/Loa
>mpls wg co-chair
>--
>
>
>Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
>Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
>Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64<= br> >
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

--001a1147b38efc75fa05304b1ae9-- From nobody Tue Apr 12 09:50:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914BA12E35B; Tue, 12 Apr 2016 09:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL1c5JQIYvtW; Tue, 12 Apr 2016 09:50:12 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B8212D5F8; Tue, 12 Apr 2016 09:50:11 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-da-570d271a63c3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 6B.99.03614.A172D075; Tue, 12 Apr 2016 18:49:31 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 12:50:10 -0400 From: Jeff Tantsura To: Sri Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRlMFnf+IwF2HjnEKYtIcTpcvsOZ+Gnm+AgAAWvoD//9gPcQ== Date: Tue, 12 Apr 2016 16:50:09 +0000 Message-ID: <3E32C408-A593-4AEB-B20C-6394BF5FFE57@ericsson.com> References: <570CFB90.8020706@pi.nu> <40DD1A73-B0EA-435C-B7E5-1933DFF4213E@alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E32C408A5934AEBB20C6394BF5FFE57ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPiK60Om+4wccDjBbnzp1itFh3+RSb xa2lK1kt7i86xmgx6fcmFgdWj52z7rJ7LFnyk8nj7q1LTB5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mr4sfoVe8E9k4pnb1tZGxhP6HQxcnJICJhIfGrdxgphi0lcuLeerYuRi0NI4CijxMYXHSwQ znJGiXWtSxlBqtgEDCT+fzvOAmKLCChKLJ/3EKyIWaCBSeL6vGXsIAlhAReJs6sXMXUxcgAV uUocXpMPUe8ksXb5BrBtLAKqEhv6zoPZvAL2Eif37maHWLaUUWLF/r3MIAlOgUCJd80tYMsY gc77fmoNE4jNLCAucevJfCaIswUkluw5zwxhi0q8fPyPFaImWeLtpaeMEAsEJU7OfMIygVFk FpL2WUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYOUqLC3Jy040MNzECY+6Y BJvjDsa9vZ6HGAU4GJV4eBeE8YQLsSaWFVfmHmKU4GBWEuFtVuYNF+JNSaysSi3Kjy8qzUkt PsQozcGiJM7rHfkvTEggPbEkNTs1tSC1CCbLxMEp1cBY/0k4YD/n5o/fJDad2nGma3L1q8m3 7ubFNpWw9F1dMENLTKipjvXy/oDLBa3N7wqzfrX/4lNcmvRhhcjZxWon3KSSL6Q//fJrsU5W ypTdS770Bhvs4ZW7MbHY7suDDc0Lp73dPGu1vd7uu63HlV6+dVGQ3/eBI/eMuPI3qTUCNz/N cTOJYrt8TYmlOCPRUIu5qDgRAIM9vpC1AgAA Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 16:50:14 -0000 --_000_3E32C408A5934AEBB20C6394BF5FFE57ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Loa, Not aware of any IPR related to this draft. Regards, Jeff On Apr 12, 2016, at 8:13 AM, Sri > wrote: Hi Loa, I am not aware of IPR that applies to this draft. Sri On Tue, Apr 12, 2016 at 6:51 AM, Henderickx, Wim (Nokia - BE) > wrote: I am not aware of IPR related to this draft On 12/04/16 16:43, "mpls on behalf of EXT Loa Andersson" on behalf of loa@pi.nu= > wrote: >Working Group, > >The authors of draft-ietf-mpls-spring-entropy-label has told us that >the document is ready to be considered for working group last call. > >We will do an IPR poll prior to the start of the wg last call. > >This mail starts the IPR poll. > >Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- >label? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >There are no IPR disclosures filed directly against this document. > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor. > >If you are on the MPLS WG email list but 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. > > >/Loa >mpls wg co-chair >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_3E32C408A5934AEBB20C6394BF5FFE57ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Loa, 

Not aware of any IPR related to this draft.<= br>
Regards,
Jeff

On Apr 12, 2016, at 8:13 AM, Sri <sriganeshkini@gmail.com> wrote:

Hi Loa,

I am not aware of IPR that applies to this draft.

Sri

On Tue, Apr 12, 2016 at 6:51 AM, Henderickx, Wim= (Nokia - BE) <wim.henderickx@nokia.com> wrote:
I am not aware of IPR related to this draft




On 12/04/16 16:43, "mpls on behalf of EXT Loa Andersson" <mpls-bounces@ietf.org on behalf of loa@pi.nu> wrote:

>Working Group,
>
>The authors of draft-ietf-mpls-spring-entropy-label has told us that >the document is ready to be considered for working group last call.
>
>We will do an IPR poll prior to the start of the wg last call.
>
>This mail starts the IPR poll.
>
>Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy= -
>label?
>
>If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>There are no IPR disclosures filed directly against this document.
>
>If you are listed as a document author or contributor please respond to=
>this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >document will not advance to the next stage until a response has been >received from each author and contributor.
>
>If you are on the MPLS WG email list but are not listed as an author or=
>contributor, then please explicitly respond only if you are aware of an= y
>IPR that has not yet been disclosed in conformance with IETF rules.
>
>
>/Loa
>mpls wg co-chair
>--
>
>
>Loa Andersson                &n= bsp;       email: loa@mail01.huawei.com
>Senior MPLS Expert              &nbs= p;           loa@pi.n= u
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ie= tf.org/mailman/listinfo/mpls
--_000_3E32C408A5934AEBB20C6394BF5FFE57ericssoncom_-- From nobody Tue Apr 12 10:52:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C100B12DB87; Tue, 12 Apr 2016 10:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 nKBfjeIszdNY; Tue, 12 Apr 2016 10:52:38 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 688CF12DAF5; Tue, 12 Apr 2016 10:52:37 -0700 (PDT) Received: from [199.87.120.129] (helo=latte) by cappuccino.rob.sh with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1aq2U4-00060f-2F; Tue, 12 Apr 2016 18:52:16 +0100 Date: Tue, 12 Apr 2016 11:52:34 -0600 From: Rob Shakir To: "=?utf-8?Q?mpls=40ietf.org?=" , Loa Andersson Message-ID: In-Reply-To: <570CFB90.8020706@pi.nu> References: <570CFB90.8020706@pi.nu> X-Mailer: Airmail Beta (353) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="570d35e2_4bc2a796_22c" Archived-At: Cc: "=?utf-8?Q?draft-ietf-mpls-spring-entropy-label=40tools.ietf.org?=" , "=?utf-8?Q?mpls-chairs=40ietf.org?=" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 17:52:41 -0000 --570d35e2_4bc2a796_22c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12 April, 2016 at 7:44:20 AM, Loa Andersson (loa@pi.nu) wrote: Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- label? I am not aware of any IPR which applies to this draft. r. --570d35e2_4bc2a796_22c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Jeff,

thank you for adding more details to the discussi= ons before RFC 7130. We have submitted another draft that proposes to use M= PLS encapsulation of BFD control packets over MC-LAG interfaces. Would grea= tly appreciate reviews, questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls.

 

        &= nbsp;       Regards,

        &= nbsp;           &nbs= p;           Greg

 

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.or= g; mpls@ietf.org; mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg= -bfd@ietf.org; rtg-bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

 

Greg,

 

This is more of a general comment on discussions = from the development from RFC 7130 than any specific comment on your draft.=  

 

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mi= rsky wrote:

> yes, link local multicast may be used in MC-= LAG scenario. The draft

> states that it MAY be used while the broadca= st has SHOULD normative.

> But we are all open to the discussion.<= /o:p>

 

During our discussions across multiple vendors, i= ncluding some hardware vendors, it was determined that attempts to exercise= the layer 3 mechanisms would vary significantly across implementations dep= ending on how packets were encapsulated.  Multicast in particular provided some problematic issues for us beyond the= initial bootstrapping phase of LAG for BFD wherein we might not have ARP c= ompleted. 

 

My recommendation is to proceed with your drafts = with similar caution.  Try to stay as true to pure IP as possible to b= est insure the L3 data paths are exercised across implementations from vari= ous vendors.

 

-- Jeff (speaking as an individual contributor)

--_000_7347100B5761DC41A166AC17F22DF11221A43F14eusaamb103erics_-- From nobody Tue Apr 12 18:31:00 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34AB12D53D; Tue, 12 Apr 2016 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_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 4YgRUQ5J_ymi; Tue, 12 Apr 2016 18:30:43 -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 8221B12D6E6; Tue, 12 Apr 2016 18:30:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLY72075; Wed, 13 Apr 2016 01:30:39 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 02:30:38 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 13 Apr 2016 09:30:27 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRkPR7Ow6l9wh8WUKpFJXl+MwAqJ+AqQ4AgAZ6g/A= Date: Wed, 13 Apr 2016 01:30:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539531@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539531NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.570DA140.00C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ab026e93858a75662410608323ce5cf6 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "sfc@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 01:30:45 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539531NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAwOSwgMjAxNiAyOjI1IEFNDQpUbzogWHV4 aWFvaHUNCkNjOiBEci4gVG9ueSBQcnp5Z2llbmRhOyBiaWVyQGlldGYub3JnOyBtcGxzQGlldGYu b3JnOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gVGhlIGZpcnN0IG5pYmJsZSBp c3N1ZSBhc3NvY2lhdGVkIHdpdGggTVBMUyBlbmNhcHN1bGF0aW9uDQoNClhpYW9odSwgVG9ueSwN Cg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIEFwciA3LCAyMDE2LCBhdCAyOjM5IFBNLCBYdXhp YW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+IHdy b3RlOg0KDQpBcyBmb3IgdGhlIGZpcnN0IG5pYmJsZSBpc3N1ZSwgd2lsbCBpdCB2aW9sYXRlIHRo ZSBsYXllcmluZyBwcmluY2lwbGUgb2YgbmV0d29yayBwcm90b2NvbCBzdGFja3MgaWYgdGhlIGZp cnN0IG5pYmJsZSBvZiBhbnkgbmV3IGVuY2Fwc3VsYXRpb24gaGVhZGVyICh3aGljaCBjb3VsZCBi ZSBhbiBNUExTIHBheWxvYWQpIGlzIHVzZWQgYXMgdGhlICJNUExTIHBheWxvYWQgdHlwZSIgZmll bGQ/DQoNClJlYWRpbmcgZHJhZnQtd2FuZy1iaWVyLWV0aGVybmV0LTAxLCBTZWN0aW9uIDMsIHRo ZSDigJxmaXJzdCBuaWJibGXigJ0gaXMgX25vdF8gdXNlZCBhcyBhbiDigJxNUExTIHBheWxvYWQg dHlwZeKAnS4gSW5zdGVhZCwgdGhlIHRleHQgZGVzY3JpYmVzIGFuIGFudGktYWxpYXNpbmcgbWVj aGFuaXNtLCBtdWNoIGxpa2UgUkZDIDQ5MjguDQoNClRoZSByZWxldmFudCB0ZXh0IGlzOg0KICAg ICBGaXJzdCBuaWJibGU6IFRoZSBmaXJzdCA0IGJpdHMgb2YgdGhlIGhlYWRlciBhcmUgc2V0IHRv IDAxMDE7IHRoaXMNCiAgIGVuc3VyZXMgdGhhdCB0aGUgQklFUiBoZWFkZXIgd2lsbCBub3QgYmUg Y29uZnVzZWQgd2l0aCBhbiBJUCBoZWFkZXINCiAgIG9yIHdpdGggdGhlIGhlYWRlciBvZiBhIHBz ZXVkb3dpcmUgcGFja2V0Lg0KDQpXaGljaCBzYXlzIOKAnOKApiB3aWxsIG5vdCBiZSBjb25mdXNl ZCB3aXRoIOKApiINCg0KDQp3b3VsZG4ndCBpdCAgYmUgbW9yZSByZWFzb25hYmxlIGFuZCBzdXN0 YWluYWJsZSB0byBmaXggdGhlIHByb2JsZW0gKGkuZS4sIHRoZSBsYWNrIG9mIGEgcHJvdG9jb2wg ZmllbGQgaW4gdGhlIE1QTFMgaGVhZGVyKSBieSB0aGUgTVBMUyBoZWFkZXIgaXRzZWxmPw0KDQoN CldobyBzYXlzIGl0IGlzIGEgKnByb2JsZW0qPyBUaGVyZeKAmXMgbm8g4oCcZml4aW5n4oCdIG5l ZWRlZC4NCg0KQnkgdGhlIHdheSwgc2luY2UgaXQncyBjbGFpbWVkIHRoYXQgdGhlIE5TSCBpcyB0 cmFuc3BvcnQtaW5kZXBlbmRhbnQsIGl0IG1lYW5zIHRoZSBOU0ggc2hvdWxkIGJlIGFibGUgdG8g YmUgdHJhbnNwb3J0ZWQgb3ZlciBNUExTLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZSBmaXJz dCBuaWJibGUgaXNzdWUgaGFzIG5vdCBiZSBjb25zaWRlcmVkIGluIHRoZSBjdXJyZW50IE5TSCBk cmFmdC4gQXMgYSByZXN1bHQsIHdoZW4gZW5jYXBzdWxhdGluZyBOU0ggb3ZlciBNUExTLCB0aGUg TlNIIG1heSBiZSBtaXMtaW50ZXJwcmV0ZWQgYXMgSVAgaGVhZGVyLg0KDQoNCg0KVGhlcmUgc2Vl bXMgdG8gYmUgc29tZSBtYXNzaXZlIGNvbmZ1c2lvbiBvbiB0aGlzIHBhcmFncmFwaCwgb24gYSBu dW1iZXIgb2YgbGV2ZWxzLiBGaXJzdCwgTlNIIGlzIG5vdCDigJxjbGFpbWVkIHRvIGJl4oCdIHRy YW5zcG9ydC1pbmRlcGVuZGVudC4gSXQgaXMgYnkgY2hhcnRlciBhbmQgYnkgZGVzaWduLiBTZWNv bmQsIHRoZSBOU0ggZHJhZnQgZG9lcyBub3QgZXZlbiBpbmNsdWRlIHRoZSB0ZXJtIOKAnE1QTFPi gJ0sIGJlY2F1c2UgaXQgZG9lcyBub3QgZGVmaW5lIHRyYW5zcG9ydHMuIFRoZSBTRkMgRW5jYXBz dWxhdGlvbiBjYW4gYmUgdXNlZCBpbiBhIHRyYW5zcG9ydC1hZ25vc3RpYyB3YXkuDQoNCg0KW1hp YW9odV0gVGhlIGZvbGxvd2luZyB0ZXh0IGlzIHF1b3RlZCBmcm9tIHRoZSBOU0ggZHJhZnQ6DQoN Cg0KDQrigJwgIDYuICBUcmFuc3BvcnQgQWdub3N0aWM6IE5TSCBpcyB0cmFuc3BvcnQgaW5kZXBl bmRlbnQgYW5kIGlzIGNhcnJpZWQNCg0KICAgICAgIGluIGFuIG92ZXJsYXksIG92ZXIgZXhpc3Rp bmcgdW5kZXJsYXlzLiAgSWYgYW4gZXhpc3Rpbmcgb3ZlcmxheQ0KDQogICAgICAgdG9wb2xvZ3kg cHJvdmlkZXMgdGhlIHJlcXVpcmVkIHNlcnZpY2UgcGF0aCBjb25uZWN0aXZpdHksIHRoYXQNCg0K ICAgICAgIGV4aXN0aW5nIG92ZXJsYXkgbWF5IGJlIHVzZWQu4oCdDQoNCg0KDQpCZXN0IHJlZ2Fy ZHMsDQoNClhpYW9odQ0KDQoNCg0KDQoNCuKAnQ0KDQpPbmUgbW9yZSBjb21tZW50IGJlbG93Lg0K DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0K5Y+R5Lu25Lq6OiBCSUVSIFtiaWVyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXIt Ym91bmNlc0BpZXRmLm9yZz5dIOS7o+ihqCBUb255IFByenlnaWVuZGEgW3RvbnlzaWV0ZkBnbWFp bC5jb208bWFpbHRvOnRvbnlzaWV0ZkBnbWFpbC5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAyMDE25bm0 NOaciDXml6UgMjI6MzYNCuaUtuS7tuS6ujogYmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRm Lm9yZz4NCuS4u+mimDogW0JpZXJdIGNvbW1lbnRzIG9uIGRyYWZ0LXdhbmctYmllci1ldGhlcm5l dC0wMQ0KYWZ0ZXIgcmVhZGluZw0KDQphKSBmaXJzdCBuaWJibGU6IHJlZmVyIHRvIE1QTFMgZW5j YXBzIGFzICJ0aGUgc2FtZSB2YWx1ZSIgdG8ga2VlcCBpbiBzeW5jDQoNCk9uZSBjb21tZW50IHJl Z2FyZGluZyB0aGUg4oCcRmlyc3QgbmliYmxl4oCdIHRleHQgYXQgZHJhZnQtaWV0Zi1iaWVyLW1w bHMtZW5jYXBzdWxhdGlvbi0wMw0KDQpTaW5jZSB0aGUgZnVuY3Rpb24gb2YgdGhlIGZpcnN0IG5p YmJsZSBpcyB0byBwcmV2ZW50IGFsaWFzaW5nIHdpdGggYW4gSVAgcGFja2V0LCBpbiBvcmRlciBm b3IgUkZDIDQ5MjggdG8gc3BlY2lmeSB2YWx1ZXMgb2YgMHgwIGFuZCAweDEgZm9yIHRoZSBGaXJz dCBOaWJibGUsIGl0IGhhZCB0byDigJxSZXNlcnZl4oCdIElQIHByb3RvY29sIHZlcnNpb25zIG9m IDAgYW5kIDEsIHJlZmVyZW5jaW5nIHRoYXQgUkZDIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzQ5Mjgjc2VjdGlvbi01KS4NCg0KSXMgdGhlIGludGVudCB0byByZS1hc3NpZ24g SVB2NSBhdCBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3ZlcnNpb24tbnVtYmVycy8g Pw0KDQpOb3RlIHRoYXQgUkZDIDQ5Mjggc2F5cyDigJxSRVFVSVJFROKAnSBhdDoNCg0KICAgSXQg aXMgUkVRVUlSRUQsIGhvd2V2ZXIsIHRoYXQgYXBwbGljYXRpb25zIGRlcGVuZCB1cG9uIGluLW9y ZGVyDQogICBwYWNrZXQgZGVsaXZlcnkgcmVzdHJpY3QgdGhlIGZpcnN0IG5pYmJsZSB2YWx1ZXMg dG8gMHgwIGFuZCAweDEuDQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KDQoNCmIpIHJlZmVy IHRvIGFsbCBvdGhlciBwb3NzaWJsZSBmaWVsZHMgdG8gTVBMUyBlbmNhcHMgdG8ga2VlcCBpbiBz eW5jIHdoZW4gZGVzY3JpYmluZyBpbnN0ZWFkIG9mIHJlcGVhdGluZw0KYykgeW91IG5lZWQgdG8g ZGVzY3JpYmUgd2hpY2gga2luZCBvZiBldGhlciBNQUNzIGFyZSBhbGxvd2VkLCBlc3BlY2lhbGx5 IG9uIGJyb2FkY2FzdCBtZWRpYSwgaS5lLiBpcyBpdCBhbHdheXMgcDJwIG9yIGNhbiB5b3UgdGFr ZSBhZHZhbnRhZ2Ugb2YgdGhlIGJyb2FkY2FzdCA/DQpkKSBGaWd1cmUgNDogdXNlIHRoZSBhcmNo aXRlY3R1cmUvTVBMUyBlbmNvZGluZyBmb3IgdGhlIGxlbmd0aCwgZG9uJ3QgaW52ZW50IGEgbmV3 IG9uZQ0KZSkgd2hvIHdpbGwgb2J0YWluIGEgbmV3IGV0aGVyIHR5cGUgZnJvbSBJRUVFPyBBcyBm YXIgSSB1bmRlcnN0YW5kLCBub3QgYSB0cml2aWFsIHByb2Nlc3MgYWxiZWl0IHdlIGhhdmUgc2V2 ZXJhbCBsaWFpc29ucyB3aXRoIElFRUUNCg0KLS0NCldl4oCZdmUgaGVhcmQgdGhhdCBhIG1pbGxp b24gbW9ua2V5cyBhdCBhIG1pbGxpb24ga2V5Ym9hcmRzIGNvdWxkIHByb2R1Y2UgdGhlIGNvbXBs ZXRlIHdvcmtzIG9mIFNoYWtlc3BlYXJlOyBub3csIHRoYW5rcyB0byB0aGUgSW50ZXJuZXQsIHdl IGtub3cgdGhhdCBpcyBub3QgdHJ1ZS4NCuKAlVJvYmVydCBXaWxlbnNreQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBsaXN0DQpt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539531NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9z ZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2VvcmdpYTsNCglwYW5vc2UtMToy IDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk65a6L5L2TO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnm s6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglm b250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE 6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgQXByaWwgMDksIDIwMTYgMjoyNSBBTTxicj4NCjxiPlRvOjwvYj4gWHV4aWFv aHU8YnI+DQo8Yj5DYzo8L2I+IERyLiBUb255IFByenlnaWVuZGE7IGJpZXJAaWV0Zi5vcmc7IG1w bHNAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNd IFRoZSBmaXJzdCBuaWJibGUgaXNzdWUgYXNzb2NpYXRlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlhpYW9odSwgVG9ueSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugc2VlIGlubGluZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gQXByIDcsIDIwMTYsIGF0 IDI6MzkgUE0sIFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNv bSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QXMgZm9y IHRoZSBmaXJzdCBuaWJibGUgaXNzdWUsIHdpbGwgaXQgdmlvbGF0ZSB0aGUgbGF5ZXJpbmcgcHJp bmNpcGxlIG9mIG5ldHdvcmsgcHJvdG9jb2wgc3RhY2tzIGlmIHRoZSBmaXJzdCBuaWJibGUgb2Yg YW55IG5ldyBlbmNhcHN1bGF0aW9uIGhlYWRlciAod2hpY2ggY291bGQNCiBiZSBhbiBNUExTIHBh eWxvYWQpJm5ic3A7aXMgdXNlZCBhcyB0aGUgJnF1b3Q7TVBMUyBwYXlsb2FkIHR5cGUmcXVvdDsg ZmllbGQ/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlYWRpbmcmbmJzcDtkcmFmdC13YW5nLWJp ZXItZXRoZXJuZXQtMDEsIFNlY3Rpb24gMywgdGhlIOKAnGZpcnN0IG5pYmJsZeKAnSBpcyBfbm90 XyB1c2VkIGFzIGFuIOKAnE1QTFMgcGF5bG9hZCB0eXBl4oCdLiBJbnN0ZWFkLCB0aGUgdGV4dCBk ZXNjcmliZXMgYW4gYW50aS1hbGlhc2luZyBtZWNoYW5pc20sIG11Y2ggbGlrZSBSRkMgNDkyOC4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo ZSByZWxldmFudCB0ZXh0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwOyAmbmJzcDtGaXJzdCBuaWJibGU6IFRoZSBmaXJzdCA0IGJpdHMgb2YgdGhlIGhlYWRlciBh cmUgc2V0IHRvIDAxMDE7IHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2Vu c3VyZXMgdGhhdCB0aGUgQklFUiBoZWFkZXIgd2lsbCBub3QgYmUgY29uZnVzZWQgd2l0aCBhbiBJ UCBoZWFkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO29yIHdpdGggdGhlIGhl YWRlciBvZiBhIHBzZXVkb3dpcmUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+V2hpY2ggc2F5cyDigJzigKYgd2lsbCBub3QgYmUgY29uZnVz ZWQgd2l0aCDigKYmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+d291bGRuJ3QgaXQm bmJzcDsgYmUgbW9yZSByZWFzb25hYmxlIGFuZCBzdXN0YWluYWJsZSZuYnNwO3RvIGZpeCB0aGUm bmJzcDtwcm9ibGVtIChpLmUuLCB0aGUgbGFjayBvZiBhIHByb3RvY29sIGZpZWxkIGluIHRoZSBN UExTIGhlYWRlcikgYnkgdGhlIE1QTFMgaGVhZGVyIGl0c2VsZj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldobyBzYXlzIGl0IGlzIGEgKnByb2JsZW0qPyBUaGVy ZeKAmXMgbm8g4oCcZml4aW5n4oCdIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QnkgdGhlIHdheSwgc2luY2UgaXQncyBjbGFpbWVkIHRoYXQgdGhlIE5TSCBpcyB0cmFuc3Bv cnQtaW5kZXBlbmRhbnQsIGl0IG1lYW5zIHRoZSBOU0ggc2hvdWxkIGJlIGFibGUgdG8gYmUgdHJh bnNwb3J0ZWQgb3ZlciBNUExTLiBIb3dldmVyLCBpdCBzZWVtcyB0aGF0IHRoZQ0KIGZpcnN0IG5p YmJsZSBpc3N1ZSBoYXMgbm90IGJlIGNvbnNpZGVyZWQmbmJzcDtpbiB0aGUgY3VycmVudCBOU0gg ZHJhZnQuIEFzIGEgcmVzdWx0LCB3aGVuIGVuY2Fwc3VsYXRpbmcgTlNIIG92ZXIgTVBMUywgdGhl IE5TSCBtYXkgYmUgbWlzLWludGVycHJldGVkIGFzIElQIGhlYWRlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgc2VlbXMgdG8gYmUgc29t ZSBtYXNzaXZlIGNvbmZ1c2lvbiBvbiB0aGlzIHBhcmFncmFwaCwgb24gYSBudW1iZXIgb2YgbGV2 ZWxzLiBGaXJzdCwgTlNIIGlzIG5vdCDigJxjbGFpbWVkIHRvIGJl4oCdIHRyYW5zcG9ydC1pbmRl cGVuZGVudC4gSXQgaXMgYnkgY2hhcnRlciBhbmQgYnkgZGVzaWduLiBTZWNvbmQsIHRoZSBOU0gg ZHJhZnQgZG9lcyBub3QgZXZlbiBpbmNsdWRlIHRoZQ0KIHRlcm0g4oCcTVBMU+KAnSwgYmVjYXVz ZSBpdCBkb2VzIG5vdCBkZWZpbmUgdHJhbnNwb3J0cy4gVGhlIFNGQyBFbmNhcHN1bGF0aW9uIGNh biBiZSB1c2VkIGluIGEgdHJhbnNwb3J0LWFnbm9zdGljIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSBUaGUgZm9sbG93aW5n IHRleHQgaXMgcXVvdGVkIGZyb20gdGhlIE5TSCBkcmFmdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgNi4m bmJzcDsgVHJhbnNwb3J0IEFnbm9zdGljOiBOU0ggaXMgdHJhbnNwb3J0IGluZGVwZW5kZW50IGFu ZCBpcyBjYXJyaWVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIGFuIG92ZXJsYXksIG92 ZXIgZXhpc3RpbmcgdW5kZXJsYXlzLiZuYnNwOyBJZiBhbiBleGlzdGluZyBvdmVybGF5PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvcG9sb2d5IHByb3ZpZGVzIHRoZSByZXF1aXJlZCBzZXJ2 aWNlIHBhdGggY29ubmVjdGl2aXR5LCB0aGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4 aXN0aW5nIG92ZXJsYXkgbWF5IGJlIHVzZWQu4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxNi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgbW9yZSBjb21tZW50IGJlbG93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+WGlhb2h1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwRjEwMDc0NCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QklF Ug0KIFs8YSBocmVmPSJtYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnIj5iaWVyLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuS7o+ih qDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUb255IFBy enlnaWVuZGEgWzxhIGhyZWY9Im1haWx0bzp0b255c2lldGZAZ21haWwuY29tIj50b255c2lldGZA Z21haWwuY29tPC9hPl08YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPuWPkemAgeaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij46PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yMDE2PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij40PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij41PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7ml6U8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAyMjozNjxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5pS25Lu25Lq6PC9zcGFuPjwvYj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpiaWVyQGlldGYub3JnIj5iaWVy QGlldGYub3JnPC9hPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCaWVyXQ0KIGNvbW1l bnRzIG9uIGRyYWZ0LXdhbmctYmllci1ldGhlcm5ldC0wMTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hZnRlciBy ZWFkaW5nJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+YSkgZmlyc3QgbmliYmxlOiByZWZlciB0byBNUExTIGVuY2FwcyBhcyAm cXVvdDt0aGUgc2FtZSB2YWx1ZSZxdW90OyB0byBrZWVwIGluIHN5bmMmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgY29tbWVudCByZWdhcmRpbmcgdGhlIOKAnEZpcnN0 IG5pYmJsZeKAnSB0ZXh0IGF0Jm5ic3A7ZHJhZnQtaWV0Zi1iaWVyLW1wbHMtZW5jYXBzdWxhdGlv bi0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2lu Y2UgdGhlIGZ1bmN0aW9uIG9mIHRoZSBmaXJzdCBuaWJibGUgaXMgdG8gcHJldmVudCBhbGlhc2lu ZyB3aXRoIGFuIElQIHBhY2tldCwgaW4gb3JkZXIgZm9yIFJGQyA0OTI4IHRvIHNwZWNpZnkgdmFs dWVzIG9mIDB4MCBhbmQgMHgxIGZvciB0aGUgRmlyc3QgTmliYmxlLCBpdCBoYWQgdG8g4oCcUmVz ZXJ2ZeKAnSBJUCBwcm90b2NvbCB2ZXJzaW9ucyBvZiAwIGFuZCAxLCByZWZlcmVuY2luZw0KIHRo YXQgUkZDIChzZWUgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ5Mjgj c2VjdGlvbi01Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDkyOCNzZWN0aW9uLTU8 L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklz IHRoZSBpbnRlbnQgdG8gcmUtYXNzaWduIElQdjUgYXQmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3ZlcnNpb24tbnVtYmVycy8iPmh0dHA6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvdmVyc2lvbi1udW1iZXJzLzwvYT4mbmJzcDs/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlIHRoYXQgUkZDIDQ5Mjggc2F5 cyDigJxSRVFVSVJFROKAnSBhdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7SXQgaXMgUkVRVUlSRUQsIGhvd2V2ZXIs IHRoYXQgYXBwbGljYXRpb25zIGRlcGVuZCB1cG9uIGluLW9yZGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyAmbmJzcDtwYWNrZXQgZGVsaXZlcnkgcmVzdHJpY3QgdGhlIGZpcnN0IG5pYmJs ZSB2YWx1ZXMgdG8gMHgwIGFuZCAweDEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj7igJQgQ2FybG9zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5iKSByZWZlciB0byBhbGwgb3RoZXIg cG9zc2libGUgZmllbGRzIHRvIE1QTFMgZW5jYXBzIHRvIGtlZXAgaW4gc3luYyB3aGVuIGRlc2Ny aWJpbmcgaW5zdGVhZCBvZiByZXBlYXRpbmcmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+YykgeW91IG5lZWQgdG8gZGVzY3JpYmUgd2hpY2gga2luZCBvZiBldGhlciBNQUNzIGFy ZSBhbGxvd2VkLCBlc3BlY2lhbGx5IG9uIGJyb2FkY2FzdCBtZWRpYSwgaS5lLiBpcyBpdCBhbHdh eXMgcDJwIG9yIGNhbiB5b3UgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGJyb2FkY2FzdCA/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmQpIEZpZ3VyZSA0OiB1c2UgdGhlIGFyY2hpdGVjdHVy ZS9NUExTIGVuY29kaW5nIGZvciB0aGUgbGVuZ3RoLCBkb24ndCBpbnZlbnQgYSBuZXcgb25lJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmUpIHdobyB3aWxsIG9idGFpbiBhIG5l dyBldGhlciB0eXBlIGZyb20gSUVFRT8gQXMgZmFyIEkgdW5kZXJzdGFuZCwgbm90IGEgdHJpdmlh bCBwcm9jZXNzIGFsYmVpdCB3ZSBoYXZlIHNldmVyYWwgbGlhaXNvbnMgd2l0aCBJRUVFJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4tLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XZeKA mXZlIGhlYXJkIHRoYXQgYSBtaWxsaW9uIG1vbmtleXMgYXQgYSBtaWxsaW9uIGtleWJvYXJkcyBj b3VsZCBwcm9kdWNlIHRoZSBjb21wbGV0ZSB3b3JrcyBvZiBTaGFrZXNwZWFyZTsgbm93LCB0aGFu a3MgdG8gdGhlIEludGVybmV0LCB3ZSBrbm93IHRoYXQgaXMgbm90IHRydWUuPC9zcGFuPjwvaT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij7igJVSb2JlcnQgV2lsZW5za3k8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxp bmcgbGlzdDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOm1w bHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1wbHNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539531NKGEML515MBXchi_-- From nobody Tue Apr 12 19:27:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7315C12D7A6; Tue, 12 Apr 2016 19:27:09 -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 jlql1dQXpHDT; Tue, 12 Apr 2016 19:27:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6400712D787; Tue, 12 Apr 2016 19:27:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLY75157; Wed, 13 Apr 2016 02:27:04 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 03:27:03 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 13 Apr 2016 10:26:56 +0800 From: Xuxiaohu To: Joel Halpern Direct Thread-Topic: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt Thread-Index: AQHRivfgoOh5TUt/KkmiZB4K1T/tUZ+HM4ag//98hgCAAIcBwP//f7YAgACID4A= Date: Wed, 13 Apr 2016 02:26:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539638@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53955F@NKGEML515-MBX.china.huawei.com> <570DA48A.9010507@joelhalpern.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539582@NKGEML515-MBX.china.huawei.com> <570DAA2C.10800@joelhalpern.com> In-Reply-To: <570DAA2C.10800@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.570DAE78.00FC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7f390b4846863f306fe54fcbe9ebbbe3 Archived-At: Cc: "mpls@ietf.org" , "sfc@ietf.org" Subject: Re: [mpls] [sfc] WG last call for draft-ietf-sfc-nsh-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 02:27:09 -0000 Hi Joel, Please see https://tools.ietf.org/html/rfc4928#page-4. Although it's a BCP = RFC, it'd better to obey it, IMO. No? Best regards, Xiaohu > -----Original Message----- > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > Sent: Wednesday, April 13, 2016 10:09 AM > To: Xuxiaohu > Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt >=20 > Is there a standards track RFC that requires this? >=20 > I know it is a good practice. It may even be a good idea for us as a des= ign point, > as I do want MPLS to be a usable transport for NSH. >=20 > But as far as I can tell, there is no standards track RFC that requires t= his. >=20 > Yours, > Joel >=20 > On 4/12/16 9:53 PM, Xuxiaohu wrote: > > Joel, > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Wednesday, April 13, 2016 9:45 AM > >> To: Xuxiaohu; Thomas Narten; sfc@ietf.org > >> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >> > >> Xu, > >> I do not believe that there is an MPLS specification that > >> requires that all content other than IP must have a first nibble of 0 = or 1. > > > > When encapsulating NSH over MPLS directly, the first nibble of the NSH = must > not be 4 or 6. > > > >> There are specifications where it is discussed as desirable. > >> > >> It is in fact pretty trivial for us to change the format so that the > >> first three bits are 0, but it burns several valuable flag bits. It > >> is an SFC working group decision, > > > > That's the reason why I raised the first nibble question. > > > > Best regards, > > Xiaohu > > > >> not, as far as I can tell, a violation of the MPLS specification. > >> > >> Yours, > >> Joel > >> > >> On 4/12/16 9:41 PM, Xuxiaohu wrote: > >>> Hi Thomas, > >>> > >>> It said in the NSH draft: > >>> > >>> "6. Transport Agnostic: NSH is transport independent and is carr= ied > >>> in an overlay, over existing underlays. If an existing over= lay > >>> topology provides the required service path connectivity, th= at > >>> existing overlay may be used." > >>> > >>> That means the NSH should be able to be transported over MPLS. > >>> However, > >> according to the current NSH format definition, it's not safe to > >> carry the NSH over MPLS due to the first nibble issue. Therefore, I > >> believe this issue needs to be addressed before publication. > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>>> -----Original Message----- > >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > >>>> Sent: Thursday, March 31, 2016 10:48 AM > >>>> To: sfc@ietf.org > >>>> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt > >>>> > >>>> Dear WG: > >>>> > >>>> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt > >>>> (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/). > >>>> > >>>> The editors of the NSH document have indicated that they have > >>>> addressed all known comments and that there are no open issues with > >>>> the current version of the document. > >>>> > >>>> Substantive comments to the list please, editorial comments can go > >>>> directly to the document editors. > >>>> > >>>> We'll also get a brief update from the editors at next week's > >>>> meeting. If there are any remaining issues with the document, > >>>> raising them before the meeting would be especially helpful. > >>>> > >>>> For the chairs, > >>>> Thomas > >>>> > >>>> _______________________________________________ > >>>> sfc mailing list > >>>> sfc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sfc > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Wed Apr 13 04:32:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:00 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:32 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] draft-rosen-mpls-rfc3107bis-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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:38 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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 04:57:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E2C12DDC3; Wed, 13 Apr 2016 04:57:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 LkhVkl9oLf6R; Wed, 13 Apr 2016 04:57:29 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06A812DADF; Wed, 13 Apr 2016 04:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6KTr2f45gq6xVqTkwb32OU1iRBPGQDGmNpwqf4IsGl8=; b=hnX9W52llVo+GPyhgY4ZUyDBv/pp7NnA1iv14wiOEbutkgGwlBKunc3ebxPO5QoY5tur9gX+rmlt36nuCLIok6KFs+A5zp+K39DYw44KXipct/4ykcPUet1buH/z52AGwsgjwyQyUWKlx65U4Y1lW4rgItpCb2dTXUtTrH9mDhk= Authentication-Results: ecitele.com; dkim=none (message not signed) header.d=none;ecitele.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.171.1.17) by VI1PR07MB1630.eurprd07.prod.outlook.com (10.166.142.148) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 11:57:05 +0000 Message-ID: <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> From: t.petch To: Alexander Vainshtein , Greg Mirsky , Eric C Rosen References: <570BB266.8090608@juniper.net> Date: Wed, 13 Apr 2016 12:53:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.1.17] X-ClientProxiedBy: HE1PR08CA0002.eurprd08.prod.outlook.com (10.161.112.12) To VI1PR07MB1630.eurprd07.prod.outlook.com (10.166.142.148) X-MS-Office365-Filtering-Correlation-Id: 0ff3e6a3-d198-400e-8b2f-08d36392bc23 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 2:rUxGfwTlSN+Kv1IKTkzVbO8jE8Mgux4e1lErTbF9wR9xNeh9gf09gFKPLRjC3gPwCjEvTd61Cjq7LEOY/pwrl/b+IZX7BiTzqYvMRXbZ2TawiWeMYu9FNS4OuXFIZs22o+gDsMvTEnoAmfXC0TxrRqgk9QrQIkc9LJnBSuBj7LfXL5OAlpLFbn2ZGEgbLYEP; 3:CkUmDoiM8TpZ35egi/q39rPiZKS8U6QXt29j/Dtlc+tQ9ii5Ps32Wn67gVlM5IRMHs7SXLklpzZJD/i2s4KiwS3w2afDaoKs0342jopS0+YhaxzHuNiXoUGvrc3ZJxyI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1630; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 25:KmY/ysHawV9a0SdDFjPS+QPXgx8UzrO/jbcSG5u4lajxqY7EkUJrVoAlH7vsX7kI8HnoisLIl+W4hCiiet/AOurFyVP2MHOMvVDXiQYr8LRa0yOP3OQeWFF9tkL6rO3NxIfLIyepAI7fKi7kQ797Xhk+xzlOoiLkC3ywzdzeOfIeUdAI+BFJa8QmVjlXo015B+jGmQszGCFcSHcZdF3aFv4PSh3uOfypQEq2jYg6zazHBANn1A0QXEsJbBOlF0iVhzABVOmCV0gowhz6yBVhyRb1cTLAJYar2gqxMP1GIeEq2PFz705WeNGir2qn+8fwpxa8CtWM7aqSBegZYGO1v0RbpDrqWXpBI9IPoF97rNogvTvcWQnXJWHIFeWedDgTfDXLFnzbxbGMKig0g2iaDU+WnQ0hjVnm83XzxEp4L5qHzI/gb245pUrvNQx8K6HEzFa4cNuEQK7HpQawD7g3UeXPW+007J4AhtbT2tymiQY1ODvWGbNBuxIBlTiFUzfTsURtpzpJbrIPaX5/OMmjsA1IePvvG2GxNbF3mz5OQ9rtBFDjVFpa4lG1LiXx62OVBV/k0TR1y6ooX0J9Mnw4OdjglmtOH+nVADgFEjG+3kJjm5uPIY9OU6ahkgh/UaE6J5hxZ4a3q2qmAgFO1qxsUtIrx8y4gtvtMQ34XTqrx1UTLnqs8iG/SF6MXJofZw51/8nviIvFhZDsa/N7lYuBiD9YGaLdzyJjHFtkj+qZBwqHZ200UD+h0kwyIMbe7As/bFSIsazlbcQKVPkz8np5oA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:VI1PR07MB1630; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1630; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 4:upgtx/TkYD87qEwy8yjE2vcJpoOvQnaOBToKkUHYd0ejyS/OYHAXQ8kXVQv5GuAz+EJlxNB68qvx1dUUu0gSLZs8aO/uHvLVBapCKHeSxHVU3ykkXwid4a2yce7vxvKEp1LOTPm3EP3xifquvaMery5in1VEAPsa3gkBffZi1VuhvVVjdVhN4p4oZX5BwI+7mhJJFwQ2IyjSylIs03G8VMEfMNcmeXpxoplWKV7v+XcK9yqLKADB7+peQ8GSbSkOrqmlNjZa7VHC+NOgOPmAmLfLEkDqmU6GVOm4A4WHGqaeD3FJVyS63yA6MeODDSc/fNYLsmKqgMQ6jCNTewrWkqdQBKdMZgc3LijCTKdncSzM/5uDIY6YT9vqn4/mr1BlBNpi/mRPQxo41/NdU4aD/ZSmUzaPtkwfH3Nfcs8vChH34LgcX3ItDV+wEebfG6ge X-Forefront-PRVS: 0911D5CE78 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(77096005)(86362001)(116806002)(50986999)(5004730100002)(1556002)(14496001)(81816999)(76176999)(15975445007)(81686999)(230700001)(23756003)(61296003)(50226001)(44736004)(33646002)(47776003)(50466002)(62236002)(44716002)(2906002)(4326007)(84392002)(66066001)(1941001)(6116002)(189998001)(81166005)(92566002)(19580405001)(5008740100001)(19580395003)(1456003)(42186005)(9686002)(1096002)(586003)(5001770100001)(3846002)(7059030)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1630; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1630; 23:C+IGr6dGGPdD697KG1DtPeeouh1nauoT6GVoiTD?= =?iso-8859-1?Q?PcbTpYn7kLOEXiunG5FIhhvy6Ypa8KzEaJ5EutAhO9aHNPUie/KaXv6wzf?= =?iso-8859-1?Q?/j2LDH6Uuv1EQJz3euNVg75TJGaBvYSwD3tcBO+ALUQb7CidyU6/nkZvL/?= =?iso-8859-1?Q?U6n8t4h139T6PL8UV5DxzBESxIRZ5e4RylJPJArUx8ebeR0reh+Qwa19aA?= =?iso-8859-1?Q?zVL4XgVKC23h7ms19KfjGdY7Mj1NmPvFIPGU9nPocv+rryY6bG8Gkn4TQi?= =?iso-8859-1?Q?yYwzbLJg+stjCVYiL3PrW7UfLeNcYwJxkV78ld24Pc/UpY9dYd5SZVewmf?= =?iso-8859-1?Q?QK9olsFa5pJPHyYbWsDTx6k5kzk1UhTPZWPOpEhdhpMOvYFwuYb9Y/iNJn?= =?iso-8859-1?Q?kd+CNYkaDMoU+/vhT209EY6yOoiYjeceTtRJjNS1yLR5yU4j/ZhCXwvPWg?= =?iso-8859-1?Q?kGBenj0gfu2I8/zKhRHfcYTixSeYAdnWbfEB8NFGbLU+SO7zzJpW3xxtSK?= =?iso-8859-1?Q?wIoTHzd4+fQLDZ/1kn2I2A4zdxpHaUnNHobhZOogxylgNgO9tyxqR3eWfh?= =?iso-8859-1?Q?9omUjJh00+jshWOWPlJf2fWPYH9URXrIZk5Dq+21XmN1CXpDCIUaEECRE3?= =?iso-8859-1?Q?kyf9IY/ftlDj1bdeJSGF0j+cXVsRAsHNyZenxiBRPfQNw4fzASQsCjEFR7?= =?iso-8859-1?Q?+hzfq3xql9icwws4BqTSispzSyE1YUNqeZLzRGFMcF51PXY8ohs8QMdhNy?= =?iso-8859-1?Q?inmB1GvHy/Li1nYV2a8kxcskYodDrDhDOBYL5bjFx8ihXmwaXFot3LUwEm?= =?iso-8859-1?Q?p2F5VfmRami4IMRQuDL3/n77dBv72y6VvN3lD1FqMONQjHXrIfzpF7x6zz?= =?iso-8859-1?Q?GajJC3dwl7+3SjKMQOaqlhQjkcSqUJ/tbhD7B8Gy41P9L78dJuGL8vCE8M?= =?iso-8859-1?Q?jN8YzHKhzP7893GoWRhWCuhKsndiFP/aq/GQsa5Ej7x9tFcsfVUKIJfLVU?= =?iso-8859-1?Q?rGlrmuZAFJ8U1B8VA2gZ1oN0WjvywNImmMIO/YrbhB/hCPHOETs7dmWJ3c?= =?iso-8859-1?Q?2oastZ7Efq0fC4s3JPKER+KaAcHad01TW6Ln2Ht+uVFZ5QhpRwO2D8khsi?= =?iso-8859-1?Q?ixz4kKUj3WUCxEBon5hXbvCGTiSgdlHvOxn/thmC2nhUOenWG7FvzuiLSy?= =?iso-8859-1?Q?lZWYijComNIVmvAYzRvXzWizZduZUxNfZS2CqLiwMU9gQKT+5JdCA+fdfL?= =?iso-8859-1?Q?YAqnB8ha/gJmFnjFc/rT9CxBdvYY40m74D2ygiA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1630; 5:lyT3IfqYN9z7q4Jzne/SexWe+JqDMLCfhAAoutZ6WmAar7rRlZtbjVap6WBRJINO9Ftfr8uEBVwKjgiHDeKzG9prsQElrGZm+fEAXfICIpFEkyqC9sBfDOCcoDZ6gbx3mREcTiMHuVhnu5qaiBElGtS1fCuSRC3j7vk4F8MvR1DvyZl1rKO2LiDOqgXYdxZ/; 24:d2U5yeo1q0v6jzPdUZmBhgZGrVjqBH4TJnbppNpyvHZNCP4jgjRxdh95Pw9Lt/u1KQEMtUkQXZ6UGznSPg5PwgKELEliZFTJYfbQgSsaQKM=; 7:O5FbHqfK0kQN1Q+uC5K7KPF8LDLqCZNjfBacZZ3ub25M8ONXrJ8N68l0hWLOkUN89LzcE5gaVB2chvRglg7OFCGVaxYZTi02Jd8rXDkVNYfVOuqCtxuvGq8KQl+uDvUa7yJD74NR4IpVbrC+FUfiimIX7TMIXHrnYXqlp0uKYgQRTCsRhF9U115qcrfRH7gVOLxE0i54FCM5XcN7Dobv5mIKBDevp3s4YVlEJdQe5cU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 11:57:05.4380 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1630 Archived-At: Cc: mpls@ietf.org, bier@ietf.org, "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:57:31 -0000 ----- Original Message ----- From: "Eric C Rosen" Sent: Monday, April 11, 2016 3:19 PM > (Removed sfc from the cc-list, this seems out of scope for that WG.) > > In designing the BIER header, the BIER WG is free to mandate any value > it chooses in the first nibble. These values do not come from a "first > nibble" registry. > > It seems prudent to put a value like 5 for the following reasons: > > - If a BIER packet is being parsed by an off-line tool, this is a good > hint (though just a hint) that the packet is actually a BIER packet; > > - If a BIER packet is traveling through an MPLS tunnel, and it traverses > a node that does its MPLS load splitting by guessing at the type of the > payload, then this is a good hint that the MPLS payload is not IPv4, > IPv6, or PW. > > This strategy does incur a risk. Suppose IPv5 gets designed, > implemented, and deployed, and folks start to deploy hardware that does Too late; see https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00 Discussion on the int-area list. Tom Petch > MPLS load balancing by inspecting the IPv5 headers of the MPLS > payloads. If a BIER packet is traversing an MPLS tunnel, inappropriate > load splitting may occur if the hardware thinks the payload is IPv5 > rather than BIER. > > This particular risk doesn't seem very significant to me. > > Thus I don't think there's anything here that needs fixing. > From nobody Wed Apr 13 05:16:10 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9408412D948 for ; Wed, 13 Apr 2016 05:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 Ja62wJngeHoG for ; Wed, 13 Apr 2016 05:16:07 -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 0241812D7D6 for ; Wed, 13 Apr 2016 05:16:07 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 04713180158D; Wed, 13 Apr 2016 14:16:04 +0200 (CEST) To: mpls@ietf.org, "tom p." References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> From: Loa Andersson Message-ID: <570E3879.309@pi.nu> Date: Wed, 13 Apr 2016 20:15:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 12:16:08 -0000 Tom, On 2016-04-13 19:53, t.petch wrote: > ----- Original Message ----- > From: "Eric C Rosen" > Sent: Monday, April 11, 2016 3:19 PM > > >> (Removed sfc from the cc-list, this seems out of scope for that WG.) >> >> In designing the BIER header, the BIER WG is free to mandate any value >> it chooses in the first nibble. These values do not come from a > "first >> nibble" registry. >> >> It seems prudent to put a value like 5 for the following reasons: >> >> - If a BIER packet is being parsed by an off-line tool, this is a good >> hint (though just a hint) that the packet is actually a BIER packet; >> >> - If a BIER packet is traveling through an MPLS tunnel, and it > traverses >> a node that does its MPLS load splitting by guessing at the type of > the >> payload, then this is a good hint that the MPLS payload is not IPv4, >> IPv6, or PW. >> >> This strategy does incur a risk. Suppose IPv5 gets designed, >> implemented, and deployed, and folks start to deploy hardware that > does > > Too late; see > > > https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00 Isn't this just in time - if IPv5 is made historic - we can safely use it. /Loa > > Discussion on the int-area list. > > Tom Petch > > > >> MPLS load balancing by inspecting the IPv5 headers of the MPLS >> payloads. If a BIER packet is traversing an MPLS tunnel, > inappropriate >> load splitting may occur if the hardware thinks the payload is IPv5 >> rather than BIER. >> >> This particular risk doesn't seem very significant to me. >> >> Thus I don't think there's anything here that needs fixing. >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Wed Apr 13 05:35:18 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFF12DFF0 for ; Wed, 13 Apr 2016 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 dMsJ-zMHS6CJ for ; Wed, 13 Apr 2016 05:35:14 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28BE12DF27 for ; Wed, 13 Apr 2016 05:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vYnRLsypKA66xf0od5SXaficp78W+xQdno7uSj7JDm8=; b=d5PocykmyL0f6Wnng9Rb11ujHXUFIMjHvIItYM464JxmXvsSYYTmrcyARLaHHT+Gv3Esz7w3EB9b0v5dHN283oFbDOqRPJ+56jR0uJqF4QY+Y71VmMjk/8KWbJrLo2Ma0xN0mfNBNO93XP42sNukpOM+N532Vnlq/nuhvq6i3F8= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 13 Apr 2016 12:35:11 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0453.029; Wed, 13 Apr 2016 12:35:11 +0000 From: Alexander Vainshtein To: Loa Andersson , "mpls@ietf.org" , tom p. Thread-Topic: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRlXuiV/nk+9f0n0aBL4+jEZNKHZ+H0XuAgAAFZb0= Date: Wed, 13 Apr 2016 12:35:11 +0000 Message-ID: References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net>,<570E3879.309@pi.nu> In-Reply-To: <570E3879.309@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [176.13.5.237] x-ms-office365-filtering-correlation-id: edb0d12a-13aa-495a-6f05-08d363980e65 x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:MCgnXMaHqFiUSYICHctxNIGE4gca3LcZy3BavDdxdCN81GxXUlixYNw3UNw7RmwrxZdJHXECZOz7emh3b6R4hBKR6igeNnO+1Oc9KFq8ul0+I7hpNVgdl/jUF6eWmdY+IlOezXunh29sbo4tB5rv/w==; 24:E38JZ7Rykv/nRqVz5Fno7mlDFhFfhM6KsEHLvEWHamJSjwAGhl0qYewtcHkO1pJQEs1mh4mliPnexD+tNIbtGO0xeR7YpelEuwBsFMaf/Mo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(13464003)(377454003)(24454002)(3660700001)(1220700001)(92566002)(1096002)(3280700002)(66066001)(2906002)(9686002)(19580395003)(87936001)(86362001)(11100500001)(2950100001)(10400500002)(19580405001)(2501003)(76176999)(50986999)(15975445007)(5008740100001)(5002640100001)(77096005)(106116001)(189998001)(81166005)(107886002)(6116002)(54356999)(586003)(5001770100001)(5004730100002)(102836003)(122556002)(33646002)(51650200001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 12:35:11.5516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 12:35:17 -0000 SSBjb25jdXIgd2l0aCBMb2EgLSB3aXRoIGEgcXVhbGlmaWVyOg0KQUZBSUsgdGhlcmUgaXMgbm8g c3VjaCB0aGluZyBhcyBhbiAiRWFybHkgSUFOQSBEZS1hbGxvY2F0aW9uIiBwcm9jZXNz8J+YiS4N ClNvIHdlIG1heSBzdGlsbCBoYXZlIHRvIHdhaXQgc29tZSB0aW1lIHVudGlsIHRoZXNlIHZhbHVl cyBiZWNvbWUgZm9ybWFsbHkgYXZhaWxhYmxlIGZvciByZXVzZS4NCg0KTXkgMmMuDQoNClRodW1i IHR5cGVkIG9uIG15IGNlbGxwaG9uZQ0KUmVnYXJkcywNClNhc2hhDQoNCi0tLS0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IExvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4NCkRh dGU6IFdlZCwgQXByaWwgMTMsIDIwMTYgMzoxNiBQTSArMDMwMA0KVG86IG1wbHNAaWV0Zi5vcmcs ICJ0b20gcC4iIDxkYWVkdWx1c0BidGNvbm5lY3QuY29tPg0KU3ViamVjdDogUmU6IFttcGxzXSBb c2ZjXSBUaGUgZmlyc3QgbmliYmxlIGlzc3VlIGFzc29jaWF0ZWQgd2l0aCBNUExTIGVuY2Fwc3Vs YXRpb24NCg0KDQpUb20sDQoNCg0KT24gMjAxNi0wNC0xMyAxOTo1MywgdC5wZXRjaCB3cm90ZToN Cj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiRXJpYyBDIFJvc2VuIiA8 ZXJvc2VuQGp1bmlwZXIubmV0Pg0KPiBTZW50OiBNb25kYXksIEFwcmlsIDExLCAyMDE2IDM6MTkg UE0NCj4NCj4NCj4+IChSZW1vdmVkIHNmYyBmcm9tIHRoZSBjYy1saXN0LCB0aGlzIHNlZW1zIG91 dCBvZiBzY29wZSBmb3IgdGhhdCBXRy4pDQo+Pg0KPj4gSW4gZGVzaWduaW5nIHRoZSBCSUVSIGhl YWRlciwgdGhlIEJJRVIgV0cgaXMgZnJlZSB0byBtYW5kYXRlIGFueSB2YWx1ZQ0KPj4gaXQgY2hv b3NlcyBpbiB0aGUgZmlyc3QgbmliYmxlLiAgVGhlc2UgdmFsdWVzIGRvIG5vdCBjb21lIGZyb20g YQ0KPiAiZmlyc3QNCj4+IG5pYmJsZSIgcmVnaXN0cnkuDQo+Pg0KPj4gSXQgc2VlbXMgcHJ1ZGVu dCB0byBwdXQgYSB2YWx1ZSBsaWtlIDUgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCj4+DQo+ PiAtIElmIGEgQklFUiBwYWNrZXQgaXMgYmVpbmcgcGFyc2VkIGJ5IGFuIG9mZi1saW5lIHRvb2ws IHRoaXMgaXMgYSBnb29kDQo+PiBoaW50ICh0aG91Z2gganVzdCBhIGhpbnQpIHRoYXQgdGhlIHBh Y2tldCBpcyBhY3R1YWxseSBhIEJJRVIgcGFja2V0Ow0KPj4NCj4+IC0gSWYgYSBCSUVSIHBhY2tl dCBpcyB0cmF2ZWxpbmcgdGhyb3VnaCBhbiBNUExTIHR1bm5lbCwgYW5kIGl0DQo+IHRyYXZlcnNl cw0KPj4gYSBub2RlIHRoYXQgZG9lcyBpdHMgTVBMUyBsb2FkIHNwbGl0dGluZyBieSBndWVzc2lu ZyBhdCB0aGUgdHlwZSBvZg0KPiB0aGUNCj4+IHBheWxvYWQsIHRoZW4gdGhpcyBpcyAgYSBnb29k IGhpbnQgdGhhdCB0aGUgTVBMUyBwYXlsb2FkIGlzIG5vdCBJUHY0LA0KPj4gSVB2Niwgb3IgUFcu DQo+Pg0KPj4gVGhpcyBzdHJhdGVneSBkb2VzIGluY3VyIGEgcmlzay4gIFN1cHBvc2UgSVB2NSBn ZXRzIGRlc2lnbmVkLA0KPj4gaW1wbGVtZW50ZWQsIGFuZCBkZXBsb3llZCwgYW5kIGZvbGtzIHN0 YXJ0IHRvIGRlcGxveSBoYXJkd2FyZSB0aGF0DQo+IGRvZXMNCj4NCj4gVG9vIGxhdGU7ICBzZWUN Cj4NCj4NCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1pcC12 ZXJzaW9uLTUtOC05LWhpc3RvcmljLTAwDQoNCklzbid0IHRoaXMganVzdCBpbiB0aW1lIC0gaWYg SVB2NSBpcyBtYWRlIGhpc3RvcmljIC0gd2UgY2FuIHNhZmVseSB1c2UNCml0Lg0KDQovTG9hDQo+ DQo+IERpc2N1c3Npb24gb24gdGhlIGludC1hcmVhIGxpc3QuDQo+DQo+IFRvbSBQZXRjaA0KPg0K Pg0KPg0KPj4gTVBMUyBsb2FkIGJhbGFuY2luZyBieSBpbnNwZWN0aW5nIHRoZSBJUHY1IGhlYWRl cnMgb2YgdGhlIE1QTFMNCj4+IHBheWxvYWRzLiAgSWYgYSBCSUVSIHBhY2tldCBpcyB0cmF2ZXJz aW5nIGFuIE1QTFMgdHVubmVsLA0KPiBpbmFwcHJvcHJpYXRlDQo+PiBsb2FkIHNwbGl0dGluZyBt YXkgb2NjdXIgaWYgdGhlIGhhcmR3YXJlIHRoaW5rcyB0aGUgcGF5bG9hZCBpcyBJUHY1DQo+PiBy YXRoZXIgdGhhbiBCSUVSLg0KPj4NCj4+IFRoaXMgcGFydGljdWxhciByaXNrIGRvZXNuJ3Qgc2Vl bSB2ZXJ5IHNpZ25pZmljYW50IHRvIG1lLg0KPj4NCj4+IFRodXMgSSBkb24ndCB0aGluayB0aGVy ZSdzIGFueXRoaW5nIGhlcmUgdGhhdCBuZWVkcyBmaXhpbmcuDQo+Pg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlz dA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Wed Apr 13 05:57:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@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 , "mpls@ietf.org" Subject: Re: [mpls] [Idr] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG 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 06:01:01 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9787412DF40 for ; Wed, 13 Apr 2016 06:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 I5cVMlJ1EACp for ; Wed, 13 Apr 2016 06:00:55 -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 8080612DD7A for ; Wed, 13 Apr 2016 06:00:55 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 4B14C1802B3F; Wed, 13 Apr 2016 15:00:53 +0200 (CEST) To: Alexander Vainshtein , "mpls@ietf.org" , "tom p." References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> <570E3879.309@pi.nu> From: Loa Andersson Message-ID: <570E42FB.4020801@pi.nu> Date: Wed, 13 Apr 2016 21:00:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 13:00:59 -0000 Sasha, I think that you are both right and wrong, there is no "Early IANA De-allocation" process😉. However, since we are not requesting a new value from any register, I think we are fine using right away. A packet in an mpls tunnel with the first nibble gives two pieces of information - it may be a bier packet - it is not IPv4 or IPv6, thus a node the do mpls load sharing not do that if the first nibble is 4 or 6 The first is just a hint, the second is a reality, but nothing of this comes from an IANA registry for first nibble. /Loa On 2016-04-13 20:35, Alexander Vainshtein wrote: > I concur with Loa - with a qualifier: > AFAIK there is no such thing as an "Early IANA De-allocation" process😉. > So we may still have to wait some time until these values become formally available for reuse. > > My 2c. > > Thumb typed on my cellphone > Regards, > Sasha > > -------- Original Message -------- > From: Loa Andersson > Date: Wed, April 13, 2016 3:16 PM +0300 > To: mpls@ietf.org, "tom p." > Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation > > > Tom, > > > On 2016-04-13 19:53, t.petch wrote: >> ----- Original Message ----- >> From: "Eric C Rosen" >> Sent: Monday, April 11, 2016 3:19 PM >> >> >>> (Removed sfc from the cc-list, this seems out of scope for that WG.) >>> >>> In designing the BIER header, the BIER WG is free to mandate any value >>> it chooses in the first nibble. These values do not come from a >> "first >>> nibble" registry. >>> >>> It seems prudent to put a value like 5 for the following reasons: >>> >>> - If a BIER packet is being parsed by an off-line tool, this is a good >>> hint (though just a hint) that the packet is actually a BIER packet; >>> >>> - If a BIER packet is traveling through an MPLS tunnel, and it >> traverses >>> a node that does its MPLS load splitting by guessing at the type of >> the >>> payload, then this is a good hint that the MPLS payload is not IPv4, >>> IPv6, or PW. >>> >>> This strategy does incur a risk. Suppose IPv5 gets designed, >>> implemented, and deployed, and folks start to deploy hardware that >> does >> >> Too late; see >> >> >> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00 > > Isn't this just in time - if IPv5 is made historic - we can safely use > it. > > /Loa >> >> Discussion on the int-area list. >> >> Tom Petch >> >> >> >>> MPLS load balancing by inspecting the IPv5 headers of the MPLS >>> payloads. If a BIER packet is traversing an MPLS tunnel, >> inappropriate >>> load splitting may occur if the hardware thinks the payload is IPv5 >>> rather than BIER. >>> >>> This particular risk doesn't seem very significant to me. >>> >>> Thus I don't think there's anything here that needs fixing. >>> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Wed Apr 13 06:08:21 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6366612DE26; Wed, 13 Apr 2016 06:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWeUoA7UWLQh; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (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 7DB7512DE0A; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) Received: by mail-ob0-x242.google.com with SMTP id rf6so3046761obc.3; Wed, 13 Apr 2016 06:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=EUbqB1yYDM+ceovJCiehlZg9ZLwHTFT5dpfiw8QBquF/WdhyeJn5pPecL7nvi5iNhO J8+izVPOHpUGzPcj14xjSZ6TWFBQYNjvwx60NyczoIgRGyiwfkYZ6VD4uPN7WTHlbKdc ybwUdGjW/vSCwvVNg3GPbQBHweWFz+uvO1iBkT+Cglku/E8cXo2jsFWdqqTf7cviOY8F wsXm8WesnEyI7UpCXvHY5bzY32jMlf74I6IcoGz7hf+rzy1t4jUd8WIQfGX1dxWYMKG3 3llEOfx+UO2wOJkAFbhCS6ufVcnWyHnUu54tZvCCJbjEsowiyEPWXAF1KnqQYvqwl8P2 ubQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jQGfI6CoA1NDL5G+b28rNKIqgv0dUr8+YwTWcSe7Myc=; b=JMNGV+Yfg7iOTHj2oQMnipT2qmtN7AcY6wJGpbG4jz+bE74iTkpTFMy+LHPQp2NzcZ o/lg7VzryVQffKj8C1M+QyiBSiPFhme77j/+oQTa1gicsIzqRwZ1ICpxddyH18VCHnZL u8SOIYu6xdmtRNkRj2z3by2umjdRHbgwokH9NBd4SuRPvsRl4cNYeOAhU8H6iPEVWfTB 8StgaNj8bIob+gproEWRaJsGPqYTqDpsJiLoBiKQQx5STvX2jcLwjz+T+gBgY08Cug8/ SVwLmzmH2XfnraHfiVAMYAi+IMGSoi6DzpS9h7uK5mGFzkiwHCOg9W5FkebgmyEUUI+r 1d2w== X-Gm-Message-State: AOPr4FWJ1rAmZTBDZqy848IR5IA2UPmLOMI/bhblIt8Kk1lJ+38SgJ/yEwNSoDva/1lS79Ph8wGNLsJw6TkxJw== MIME-Version: 1.0 X-Received: by 10.182.105.65 with SMTP id gk1mr4309394obb.37.1460552895791; Wed, 13 Apr 2016 06:08:15 -0700 (PDT) Received: by 10.202.62.133 with HTTP; Wed, 13 Apr 2016 06:08:15 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <20160411172332.GA22064@pfrc.org> <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> Date: Wed, 13 Apr 2016 18:38:15 +0530 Message-ID: From: Glen Kent To: Gregory Mirsky Content-Type: multipart/alternative; boundary=e89a8ff1cf9c87898a05305d78a3 Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 13:08:19 -0000 --e89a8ff1cf9c87898a05305d78a3 Content-Type: text/plain; charset=UTF-8 Gregory, You are using a special GAL label for BFD packets. This label exists only for the BFD packets. How can you then claim connectivity for other traffic which will not use this label? Glen On Wed, Apr 13, 2016 at 4:18 AM, Gregory Mirsky wrote: > Hi Jeff, > > thank you for adding more details to the discussions before RFC 7130. We > have submitted another draft that proposes to use MPLS encapsulation of BFD > control packets over MC-LAG interfaces. Would greatly appreciate reviews, > questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls > . > > > > Regards, > > Greg > > > > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, April 11, 2016 10:24 AM > To: Greg Mirsky > Cc: Reshad Rahman (rrahman); > draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org; mpls@ietf.org; > mpls-chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; > rtg-bfd-chairs@ietf.org > Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces > > > > Greg, > > > > This is more of a general comment on discussions from the development from > RFC 7130 than any specific comment on your draft. > > > > On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote: > > > yes, link local multicast may be used in MC-LAG scenario. The draft > > > states that it MAY be used while the broadcast has SHOULD normative. > > > But we are all open to the discussion. > > > > During our discussions across multiple vendors, including some hardware > vendors, it was determined that attempts to exercise the layer 3 mechanisms > would vary significantly across implementations depending on how packets > were encapsulated. Multicast in particular provided some problematic > issues for us beyond the initial bootstrapping phase of LAG for BFD wherein > we might not have ARP completed. > > > > My recommendation is to proceed with your drafts with similar caution. > Try to stay as true to pure IP as possible to best insure the L3 data paths > are exercised across implementations from various vendors. > > > > -- Jeff (speaking as an individual contributor) > --e89a8ff1cf9c87898a05305d78a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gregory,

You are using a special GAL la= bel for BFD packets. This label exists only for the BFD packets.=C2=A0

How can you then claim connectivity for other traffic = which will not use this label?

Glen

On Wed, Apr 13, 2016= at 4:18 AM, Gregory Mirsky <gregory.mirsky@ericsson.com>= wrote:

Hi Jeff,

thank you for adding more details to the discussions before RFC 7130. We= have submitted another draft that proposes to use MPLS encapsulation of BF= D control packets over MC-LAG interfaces. Would greatly appreciate reviews,= questions and comments on draft-tanmir-rtgwg-bfd-mc-lag-mpls.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg

=C2=A0

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, April 11, 2016 10:24 AM
To: Greg Mirsky
 Cc: Reshad Rahman (rrahman); draft-tanmir-rtgwg-bfd-mc-lag-ip@too= ls.ietf.org; mpls@ie= tf.org; mpls-= chairs@ietf.org; Alia Atlas (akatlas@gmail.com); rtg-bfd@ietf.org; rtg-bfd-chairs@ietf.org
Subject: Re: Two new drafts on (micro-)BFD over MC-LAG interfaces

=C2=A0

Greg,

=C2=A0

This is more of a general comment on discussions from the development fr= om RFC 7130 than any specific comment on your draft.=C2=A0

=C2=A0

On Fri, Apr 08, 2016 at 11:43:18AM -0700, Greg Mirsky wrote:

> yes, link local multicast may be used in MC-LAG scenario. The draft

> states that it MAY be used while the broadcast has SHOULD normative= .

> But we are all open to the discussion.

=C2=A0

During our discussions across multiple vendors, including some hardware = vendors, it was determined that attempts to exercise the layer 3 mechanisms= would vary significantly across implementations depending on how packets w= ere encapsulated.=C2=A0 Multicast in particular provided some problematic issues for us beyond the= initial bootstrapping phase of LAG for BFD wherein we might not have ARP c= ompleted.=C2=A0

=C2=A0

My recommendation is to proceed with your drafts with similar caution.= =C2=A0 Try to stay as true to pure IP as possible to best insure the L3 dat= a paths are exercised across implementations from various vendors.

=C2=A0

-- Jeff (speaking as an individual contributor)


--e89a8ff1cf9c87898a05305d78a3-- From nobody Wed Apr 13 07:48:26 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE09712E313; Wed, 13 Apr 2016 07:48:22 -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 hv9K7zKg9NwC; Wed, 13 Apr 2016 07:48:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490AF12E2E6; Wed, 13 Apr 2016 07:48:17 -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=yKEMAokHJuXZ8aYFbc90gr8Ng4ySj/cz7GyrSQDyu/k=; b=XhZXIR5vYHB3hGQ7txFi8KfyZyJo1Vjitgb45k9wctd+mN7tM7yKiy9oXq3jWxslm/6J134zZgGrvBWo8uQdhAnSii5X1A+tALeMiNyz7wh0rZtmEKAZLlyeYUDLrVm+mEbphJIv2UeBfUinvBC6zDot4m1i5IsjOf0ICg/5H3M= 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.28.32.220] (66.129.241.12) by BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 13 Apr 2016 14:47:59 +0000 To: "Carlos Pignataro (cpignata)" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> From: Eric C Rosen Message-ID: <570E5C1A.7010606@juniper.net> Date: Wed, 13 Apr 2016 10:47:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: DM3PR10CA0030.namprd10.prod.outlook.com (10.164.12.40) To BY2PR05MB789.namprd05.prod.outlook.com (10.141.225.18) X-MS-Office365-Filtering-Correlation-Id: 730b7b82-dfe2-45a4-ceff-08d363aa9c88 X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 2:v7A37LfDwsIuuzB/4M4CbznKoiEr9/xyVO0+vOgGFG4XCq3HTRgUS7K5jDyF3qTeYWpw1mgHyGYueyxT/B0hlWMbsqdqfo900Ez4U1/I9wPZwexsapNUw7GNGWg3a2vF2M8ctL1CURtYyuhovuawHQ2x4KiDKWh+yBflYvIqy6yA84dVjzCMmvFmXrjjPLom; 3:E6DnzCwL4nP/0CDy4F8/ZU9M3AUwOMl1RcGnliEIOoWds1CIfHeaL06Jjy3+m7RJi1xcjxvnXBuy/fEvKYKiqPWpEkj3ayOfaeCduHlZuKybcwcYWxPE0PBMTQnSdWBO X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB789; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 25:V/HiKG0rcc+X0OGkDnlhvXQpeMod8Mh9kSLEwMdXQJbHszNDCMo31rJc/iawIerJ5sVaRLi3E9xzacgSDjjXlNfWk/RPdZopzwDEyndC5Dh2iXIwMXwc4Y+UxIvarQBiQE3b6hLWRDQYpc0lmMK5NM7zO46FxTPYjSiTDArtttiEM7s+bY9STslfpuFGuzNFDTZqJOBdhcpWNUYhdM0C49/8w0R95cvfdfsAtgBE7wFvU9MRJLSe5GYA35StgX4EvpsZeJ0N14vhPZm9hwOHCfuqe/zwJw59yJy+6c+hSuqkkw4GI0518hJLLzNOR+AGYYFVZUNC4t5MIfIsw9aNfV+FwLzO/RcdxvxPa4ic7aZZPHJM3IY8Ob29khFbcSSvLv4gKgktlyKIY1FRmNCyjiPoidG04ZG0cO4Zv/g9AiqTMibrBUB+2Y6X0h3um2Vd+LkQsOqui31Fy/r9nhFvAl7vlwjTkl/tqRIanWYYNQ1Wg3pala6IWatFwPufbVxph/4GpMFZnusT11shcmWYvIWYaBK68SWLTQkcUwMazLT8LlfxUqE/496CynledyWZVfn5MYpaZbfBiXrKxpZRtdkDC3IP+YwKuXIrdHcBROuBqog6gL8hvk15UxqK0aaieYRmeDJs5Cczbkm/ZLXSKR7ONK1EWC05ePH6si3YlAWyR+K6WfvjkhQARvEF9PIy X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 20:Z9ebukr3Hw0xmEOZvJ7dbMeowlDOKBSJzJFB6yy+XyUo7OqJH5KWp2fY75AJIfCm+O1rs4bk7kOfCa39flUaTGnM2DC2mka4dHV6ry9ko3rOQXaZ3xm8GN51v2QIZjB3/s2dVpag9JSmiRDQ3jiRrVlIAI7oo5R7Wg0YlhfSgdJQccILpe8+ybzs1m5nISw+ud8t/txvQpQnxdopZzTt7D6bQPgiq4n37RO3Eh+TVP25aFs0PUkCR/Ag4yQ6vKAce0Cv/7uMLJbp69HG5u0xdGyqrF1rI9F2sUm+kw3ur4oFMD45JNleB6gxFbQJNZrnKnxCw47uPxzjZS7ZGHV8rY6EhQEFgAvG5FniJMPc+8SuAxzlghuXqyzB4utD1h7Mvrdur5hC3knq7V0rcSv3hU5xxse2uNvP9d0Mnae4NDMw/pfmU7ZfbYn6dzk6tXukf2sodTTFJ2aacQ0czcPR3B30ZHaCyei+llzo55gyV7AGhe4w5tB97+F3rWPGU3B2; 4:srqtS6hNpLj9gxb7S1sCoYeuq1CRwuFt23hsDYG6s/r9WxLl+Ahhf7FTyCqHaS/fXxU0GxdU2odxrYV7nP1vVQ8YydUvWiQnetLRfcFAsZKya8cmDe3zml+kBxN4lG4mylbFM3uJoMW7ffDEpNdRVQs/T7PD0NT20lRJ1e5JVd0ov95xD/f137sPFzza6Hwsis2TRtefHjhVmWqR12SlcrAw+eyNaJXeyXYSoOm02n3euru/f/a6hVmYsMdechHPzdpKNNz1wqSzLD36yhy0UJjxrc0UyZAMNWM55XsM/foDCF635d55oekcFczxUdJMgoBdUpx8Ugqepz2klEDOXEr9tOsJ9Ae0KrJ3Gi/x8QAdo6tuIVHcVb7Zf6Xm/8insjZdgAP70WPp/eYebKECqA== 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)(6055026); SRVR:BY2PR05MB789; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB789; X-Forefront-PRVS: 0911D5CE78 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(2950100001)(33656002)(80316001)(87266999)(54356999)(76176999)(50986999)(4326007)(42186005)(65816999)(77096005)(92566002)(81166005)(86362001)(2906002)(5008740100001)(50466002)(93886004)(5004730100002)(36756003)(47776003)(110136002)(83506001)(586003)(64126003)(4001350100001)(189998001)(6116002)(230700001)(66066001)(1096002)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB789; H:[172.28.32.220]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI3ODk7MjM6a0crOGZHNGJrWVZ4azExSjdwZlJOdFcxalBi?= =?utf-8?B?bjYvZ09scStqZk41aGMrTzB1TVhXbmVSbVBra3B5ZmJaMms5S2JMdDhRU3U5?= =?utf-8?B?VU92cEVQTFBFT2hLeUhaRHozQkwwWFh4T1RnTUNWNDM3Nm9KeHdWc3ZTRFRX?= =?utf-8?B?anI0TjhSRkF3SkwxMzR4dnFYd25lVklvWHpoaGw3STlVSXZRUndCWFd0VkpK?= =?utf-8?B?NFlxTnRaT0xRZ3ZPMmtRWjFldGY3Z2tMcXMxbDkwRVlsemRCMzY2Z0hoLy9n?= =?utf-8?B?RmR5bDhhb0F5WU5pQjZFK1hWYWU0TlY3WS9FOXJneG9xWXhUWUdXQW9lM3JK?= =?utf-8?B?ZXJYMU1NVFB6d1VHZTRINFFnMFkxV2liMWp2TEd3dzV5NjZLRDJNSVNJZFls?= =?utf-8?B?Sm1jS05DcGViRlJJSG9BSHh5bnM1UmxEWlNLd0Q3NHYzRytnVC9lLzU3RDJT?= =?utf-8?B?Z2kwMlZjSFAzSlJCZ3lPMnllVTM5ZnpWN01BVTNQNUt1Q0l5aFZ1NG1CZnZl?= =?utf-8?B?ZTlwUmRQMEVIbTQrQm9mYjZvQW5kcEVGWmsvbll4bGZKdUdKalQwckVFcnJR?= =?utf-8?B?eEFnclZUaURESUxDQVptZ1RvamRtQUlqZG5sVmw1ekI3Q3BUL2ZMNHFkKzIw?= =?utf-8?B?bHVNR2lNeFFQa09iQmxTNUovdWM1Rys4U2dsWEJRdFV3S2NiMGpSVHNvdTZq?= =?utf-8?B?SGNuNFNkbDZmbmZIUGhTVVAvaGNCY2JaZVlXL25TZ1VZSFpSb2t6SmY1eFpY?= =?utf-8?B?cnZBNXU0bDFxRzJXNHYwVmZ3U2pBVW1SblRNNEhzRW1FOHVVeUw5OTExQ3F4?= =?utf-8?B?RWFUaEpWQ2J0S1ZhZEpNUDR6UXJJS0hWZ2t4S3g4UDQ4cERVdDN4VldmSUJi?= =?utf-8?B?NVJONGswL1Zwc0VxeVVLRWo4OXZiaHN6QlBSOWNwWWJTY1REa0crckRueDFL?= =?utf-8?B?RWY2N3huTjU5NGJtOTBmQjFubzZoNEhVRytWWkxQWUhoNVFYU1JWSmtiOE1U?= =?utf-8?B?WHc5SmVKaUsrOVRMYWVtb0VMNGs3SGN0WjFqeGpsVTMzQzFWVUh5aVNNSHo2?= =?utf-8?B?S2lZU2xqVjhvclBzUEtHQi83c2VwNHgzWWV0TmxqbGpiSTNCV0hPR0R2RzRs?= =?utf-8?B?K1BPanFzMDB3Nkcrck1IR3llcTN2OVl3eVRMNnBEQ3AvaUNyVlg1aTgxVVho?= =?utf-8?B?VFFPbWZHY2gwYkExbjl6aUlJZFdEOWJaNDI4ejhXVFJmaU9DVzBvaWNNMm9v?= =?utf-8?B?aGFVRHZGMVUydm1xZU1ac1p5U0dtKytuQisxYmJPa3M0dlVLbGZUcFNCS1dV?= =?utf-8?Q?YkkEkbTSeWoWMxnQtzNYuHIwHyTZmXo=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB789; 5:gIzVts/gxkR5RoqedGYeGEPkoOEh+sP+OWU1Qu5eN1tkBg/EPqe52wSRVRYqA328GE2dvG5aBGuY+6vqlMbIZmtYG15fPTZoZ0ISXATxR4LW4DExfa94mgzkkEGPfoIrtVFQYQyup8L+H3zAUqQP1w==; 24:2QVxbyKMAkYLSKhAci0rKzeSU54l6OdVG5sJXIk93Ry13iQ3UZfxoe3O5wUeCB5s9XAWcFYXK8WrYiF0H4rY6p/WTZfUDWIgpCfcO9xVSXY= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 14:47:59.6071 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB789 Archived-At: Cc: "bier@ietf.org" , "mpls@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:48:23 -0000 On 4/11/2016 8:19 PM, Carlos Pignataro (cpignata) wrote: > The format of a BIER packet have enough constrained or self-defining > fields, that an off-line parsing tool like Wireshark can apply enough > heuristics to figure it out, without the 0x5. I haven't worked out for myself whether this is the case or not, but it certainly doesn't hurt to have the 0x05 there. > I understand why a mid-point LSR might want to not alias the MPLS > payload with IPv4 or IPv6, to prevent mis-hashing in the LB. Why would > a node be interested in knowing the payload is not a PW? What would it > do differently? I'm not sure if there is any hardware that performs PW-specific functions in the forwarding plane, based on the first nibble, but it seems prudent to avoid any possibility of confusion. > [It is interesting that the hint is, as described, to nudge a node > that the packet is *not* something, instead of the packet *is* BIER.] Well, of course, that's why the nibble is not a protocol type field ;-) In the MPLS encaps, the fact that the packet is BIER is determined from the MPLS label. In other proposed encapsulations, the encapsulating protocol would have a protocol type field. >> This strategy does incur a risk. Suppose IPv5 gets designed, implemented, and deployed, and folks start to deploy hardware that does MPLS load balancing by inspecting the IPv5 headers of the MPLS payloads. If a BIER packet is traversing an MPLS tunnel, inappropriate load splitting may occur if the hardware thinks the payload is IPv5 rather than BIER. >> >> This particular risk doesn't seem very significant to me. >> > I agree that risk is quite insignificant (null in practice). The real risk I believe is if some other application over MPLS uses 0x5 in the first nibble, because they do not want to be confused with IP either, and they do not like 0x0 or 0x1. That is possible, but I don't really see what the problem is. I guess it is true that we'll have to say that BIER is not 100% compliant with RFC 4928. I don't see that as a problem either, but it is certainly possible that some AD will make an issue of it. From nobody Wed Apr 13 08:49:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8912B008; Wed, 13 Apr 2016 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N79C8PU8eyOZ; Wed, 13 Apr 2016 08:49:24 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6C912D14B; Wed, 13 Apr 2016 08:49:23 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-60-570e6a5aaae7 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 00.00.03614.A5A6E075; Wed, 13 Apr 2016 17:48:43 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 13 Apr 2016 11:49:22 -0400 From: Gregory Mirsky To: Glen Kent Thread-Topic: Two new drafts on (micro-)BFD over MC-LAG interfaces Thread-Index: AdGOvsdErg6+dntrQsqNMvPnP9/byACNIV+ZABt/KgAADGd7oAANpwaAAAYagaD//+aOgIAAJa0AgASgtgD//lcisIAEhjSAgAAYQ7A= Date: Wed, 13 Apr 2016 15:49:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A4498F@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF11221A3CCED@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40584@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF11221A40773@eusaamb103.ericsson.se> <20160411172332.GA22064@pfrc.org> <7347100B5761DC41A166AC17F22DF11221A43F14@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyuXRPuG50Fl+4wb5uTotPDy8xWxzYdJDR Ys+J9ywW36Y9ZbXYf/Atq8W6y6fYLG4tXclqcW1FK7vFktv32C0+/9nG6MDlMeX3RlaPnbPu snssWfKTyeNy71ZWjy+XP7MFsEZx2aSk5mSWpRbp2yVwZeyYMY+t4EgrY8WO+4+ZGhh/NDJ2 MXJySAiYSDw68YsFwhaTuHBvPVsXIxeHkMBRRomvu+4yQjjLGSV6JkJ0sAkYSbzY2MPexcjB ISKgLPHmZgpIDbPACWaJTz1/mUFqhAUcJb7PvwZmiwg4SXy4spgVwi6TmNG9HWwbi4CqxP87 rWA2r4CvxMzGUywQy06zSrR2fmIHSXAKBEqcW3oCbBAj0HnfT61hArGZBcQlbj2ZzwRxtoDE kj3nmSFsUYmXj/+xQthKEpOWnmOFqM+XaD7VxAixTFDi5MwnLBMYRWchGTULSdksJGWzgP5k FtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYOUqLC3Jy040MNzECI/mYBJvjDsa9vZ6H GAU4GJV4eBMe8IYLsSaWFVfmHmKU4GBWEuEtyuALF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r HfkvTEggPbEkNTs1tSC1CCbLxMEp1cBoY3mtRvzt3Yem8wV0Ztx5wbHD7lq4UPidjY+cK7q+ XXodUCTCNOsSb/xVrRkJ9/VXrE068jlQ7eiJB0fM7j73SLKrlzptImPM+5Jzw32BcubomvyO Fc0Tbczf2k/u2qW38Nbk7OfCSkwr1gkeaD9QwnDT/5Q3w8RQ+5v/rqqqzmtxEwupZO1TYinO SDTUYi4qTgQAvf2/yeACAAA= Archived-At: Cc: "draft-tanmir-rtgwg-bfd-mc-lag-ip@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "Reshad Rahman \(rrahman\)" , "rtg-bfd@ietf.org" , "rtg-bfd-chairs@ietf.org" Subject: Re: [mpls] Two new drafts on (micro-)BFD over MC-LAG interfaces X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:49:26 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2xlbiwNCnRoYW5rIHlvdSBmb3IgeW91ciBxdWVzdGlvbi4gSSB3b3VsZCBub3Qgc2F5IHRo YXQgR0FMIGxhYmVsIOKAnGV4aXN0cyBvbmx5IGZvciB0aGUgQkZEIHBhY2tldHPigJ0uIFRoaXMg c3BlY2lhbCBwdXJwb3NlIGxhYmVsIGNhbiBiZSB1c2VkIGluIGluZmluaXRlIG51bWJlciBvZiBz Y2VuYXJpb3MsIGluY2x1ZGluZyBNQy1MQUcgZW52aXJvbm1lbnQuIEJ1dCBJIGFncmVlLCBhcyBp biB0aGUgZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXAsIHdlIG1ha2UgY2VydGFpbiBh c3N1bXB0aW9ucyBhYm91dCB0aGUgZm9yd2FyZGluZyBlbmdpbmVzIGFuZCB3aGV0aGVyIHByb3Bl ciBwcm9jZXNzaW5nIG9mIE1QTFMgZW5jYXBzdWxhdGVkIHBhY2tldCBtYXkgYmUgaW50ZXJwcmV0 ZWQgYXMgaW5kaWNhdGlvbiBvZiBwcm9wZXJseSBmdW5jdGlvbmluZyBMYXllciAyIGFuZC9vciBM YXllciAzLiBPciwgd2hhdCBtYXkgbW9yZSBpbXBvcnRhbnQgZm9yIG1vbml0b3JpbmcgbGluayBs YXllciwgZmFpbHVyZSBkZXRlY3RlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbiBtYXkgYmUgaW50 ZXJwcmV0ZWQgYXMgaW5kaWNhdGlvbiBvZiBhIGRlZmVjdCBpbiBMYXllciAyIGFuZC9vciBMYXll ciAzLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR3JlZw0KDQpGcm9tOiBHbGVuIEtlbnQgW21haWx0bzpnbGVuLmtlbnRAZ21haWwu Y29tXQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxMywgMjAxNiA2OjA4IEFNDQpUbzogR3JlZ29y eSBNaXJza3kNCkNjOiBKZWZmcmV5IEhhYXM7IEdyZWcgTWlyc2t5OyBkcmFmdC10YW5taXItcnRn d2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFp cnNAaWV0Zi5vcmc7IEFsaWEgQXRsYXMgKGFrYXRsYXNAZ21haWwuY29tKTsgUmVzaGFkIFJhaG1h biAocnJhaG1hbik7IHJ0Zy1iZmRAaWV0Zi5vcmc7IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogVHdvIG5ldyBkcmFmdHMgb24gKG1pY3JvLSlCRkQgb3ZlciBNQy1MQUcgaW50 ZXJmYWNlcw0KDQpHcmVnb3J5LA0KDQpZb3UgYXJlIHVzaW5nIGEgc3BlY2lhbCBHQUwgbGFiZWwg Zm9yIEJGRCBwYWNrZXRzLiBUaGlzIGxhYmVsIGV4aXN0cyBvbmx5IGZvciB0aGUgQkZEIHBhY2tl dHMuDQoNCkhvdyBjYW4geW91IHRoZW4gY2xhaW0gY29ubmVjdGl2aXR5IGZvciBvdGhlciB0cmFm ZmljIHdoaWNoIHdpbGwgbm90IHVzZSB0aGlzIGxhYmVsPw0KDQpHbGVuDQoNCk9uIFdlZCwgQXBy IDEzLCAyMDE2IGF0IDQ6MTggQU0sIEdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmlj c3Nvbi5jb208bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpI aSBKZWZmLA0KDQp0aGFuayB5b3UgZm9yIGFkZGluZyBtb3JlIGRldGFpbHMgdG8gdGhlIGRpc2N1 c3Npb25zIGJlZm9yZSBSRkMgNzEzMC4gV2UgaGF2ZSBzdWJtaXR0ZWQgYW5vdGhlciBkcmFmdCB0 aGF0IHByb3Bvc2VzIHRvIHVzZSBNUExTIGVuY2Fwc3VsYXRpb24gb2YgQkZEIGNvbnRyb2wgcGFj a2V0cyBvdmVyIE1DLUxBRyBpbnRlcmZhY2VzLiBXb3VsZCBncmVhdGx5IGFwcHJlY2lhdGUgcmV2 aWV3cywgcXVlc3Rpb25zIGFuZCBjb21tZW50cyBvbiBkcmFmdC10YW5taXItcnRnd2ctYmZkLW1j LWxhZy1tcGxzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5taXItcnRnd2ct YmZkLW1jLWxhZy1tcGxzLTAwPi4NCg0KDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBKZWZmcmV5IEhhYXMgW21haWx0bzpqaGFhc0BwZnJjLm9yZzxt YWlsdG86amhhYXNAcGZyYy5vcmc+XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMDoy NCBBTQ0KVG86IEdyZWcgTWlyc2t5DQpDYzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IGRyYWZ0 LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC10 YW5taXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZz47IG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1j aGFpcnNAaWV0Zi5vcmc+OyBBbGlhIEF0bGFzIChha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWth dGxhc0BnbWFpbC5jb20+KTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9y Zz47IHJ0Zy1iZmQtY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBUd28gbmV3IGRyYWZ0cyBvbiAobWljcm8tKUJGRCBvdmVyIE1DLUxB RyBpbnRlcmZhY2VzDQoNCg0KDQpHcmVnLA0KDQoNCg0KVGhpcyBpcyBtb3JlIG9mIGEgZ2VuZXJh bCBjb21tZW50IG9uIGRpc2N1c3Npb25zIGZyb20gdGhlIGRldmVsb3BtZW50IGZyb20gUkZDIDcx MzAgdGhhbiBhbnkgc3BlY2lmaWMgY29tbWVudCBvbiB5b3VyIGRyYWZ0Lg0KDQoNCg0KT24gRnJp LCBBcHIgMDgsIDIwMTYgYXQgMTE6NDM6MThBTSAtMDcwMCwgR3JlZyBNaXJza3kgd3JvdGU6DQoN Cj4geWVzLCBsaW5rIGxvY2FsIG11bHRpY2FzdCBtYXkgYmUgdXNlZCBpbiBNQy1MQUcgc2NlbmFy aW8uIFRoZSBkcmFmdA0KDQo+IHN0YXRlcyB0aGF0IGl0IE1BWSBiZSB1c2VkIHdoaWxlIHRoZSBi cm9hZGNhc3QgaGFzIFNIT1VMRCBub3JtYXRpdmUuDQoNCj4gQnV0IHdlIGFyZSBhbGwgb3BlbiB0 byB0aGUgZGlzY3Vzc2lvbi4NCg0KDQoNCkR1cmluZyBvdXIgZGlzY3Vzc2lvbnMgYWNyb3NzIG11 bHRpcGxlIHZlbmRvcnMsIGluY2x1ZGluZyBzb21lIGhhcmR3YXJlIHZlbmRvcnMsIGl0IHdhcyBk ZXRlcm1pbmVkIHRoYXQgYXR0ZW1wdHMgdG8gZXhlcmNpc2UgdGhlIGxheWVyIDMgbWVjaGFuaXNt cyB3b3VsZCB2YXJ5IHNpZ25pZmljYW50bHkgYWNyb3NzIGltcGxlbWVudGF0aW9ucyBkZXBlbmRp bmcgb24gaG93IHBhY2tldHMgd2VyZSBlbmNhcHN1bGF0ZWQuICBNdWx0aWNhc3QgaW4gcGFydGlj dWxhciBwcm92aWRlZCBzb21lIHByb2JsZW1hdGljIGlzc3VlcyBmb3IgdXMgYmV5b25kIHRoZSBp bml0aWFsIGJvb3RzdHJhcHBpbmcgcGhhc2Ugb2YgTEFHIGZvciBCRkQgd2hlcmVpbiB3ZSBtaWdo dCBub3QgaGF2ZSBBUlAgY29tcGxldGVkLg0KDQoNCg0KTXkgcmVjb21tZW5kYXRpb24gaXMgdG8g cHJvY2VlZCB3aXRoIHlvdXIgZHJhZnRzIHdpdGggc2ltaWxhciBjYXV0aW9uLiAgVHJ5IHRvIHN0 YXkgYXMgdHJ1ZSB0byBwdXJlIElQIGFzIHBvc3NpYmxlIHRvIGJlc3QgaW5zdXJlIHRoZSBMMyBk YXRhIHBhdGhzIGFyZSBleGVyY2lzZWQgYWNyb3NzIGltcGxlbWVudGF0aW9ucyBmcm9tIHZhcmlv dXMgdmVuZG9ycy4NCg0KDQoNCi0tIEplZmYgKHNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwgY29u dHJpYnV0b3IpDQoNCg== --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgR2xlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+dGhhbmsgeW91IGZvciB5b3VyIHF1ZXN0aW9uLiBJIHdvdWxkIG5vdCBzYXkgdGhhdCBHQUwg bGFiZWwg4oCcZXhpc3RzIG9ubHkgZm9yIHRoZSBCRkQgcGFja2V0c+KAnS4gVGhpcyBzcGVjaWFs IHB1cnBvc2UgbGFiZWwgY2FuIGJlIHVzZWQgaW4gaW5maW5pdGUgbnVtYmVyIG9mDQogc2NlbmFy aW9zLCBpbmNsdWRpbmcgTUMtTEFHIGVudmlyb25tZW50LiBCdXQgSSBhZ3JlZSwgYXMgaW4gdGhl IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMtbGFnLWlwLCB3ZSBtYWtlIGNlcnRhaW4gYXNzdW1w dGlvbnMgYWJvdXQgdGhlIGZvcndhcmRpbmcgZW5naW5lcyBhbmQgd2hldGhlciBwcm9wZXIgcHJv Y2Vzc2luZyBvZiBNUExTIGVuY2Fwc3VsYXRlZCBwYWNrZXQgbWF5IGJlIGludGVycHJldGVkIGFz IGluZGljYXRpb24gb2YgcHJvcGVybHkNCiBmdW5jdGlvbmluZyBMYXllciAyIGFuZC9vciBMYXll ciAzLiBPciwgd2hhdCBtYXkgbW9yZSBpbXBvcnRhbnQgZm9yIG1vbml0b3JpbmcgbGluayBsYXll ciwgZmFpbHVyZSBkZXRlY3RlZCB3aXRoIE1QTFMgZW5jYXBzdWxhdGlvbiBtYXkgYmUgaW50ZXJw cmV0ZWQgYXMgaW5kaWNhdGlvbiBvZiBhIGRlZmVjdCBpbiBMYXllciAyIGFuZC9vciBMYXllciAz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBHbGVuIEtlbnQgW21haWx0bzpnbGVu LmtlbnRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMTMs IDIwMTYgNjowOCBBTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8 L2I+IEplZmZyZXkgSGFhczsgR3JlZyBNaXJza3k7IGRyYWZ0LXRhbm1pci1ydGd3Zy1iZmQtbWMt bGFnLWlwQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9y ZzsgQWxpYSBBdGxhcyAoYWthdGxhc0BnbWFpbC5jb20pOyBSZXNoYWQgUmFobWFuIChycmFobWFu KTsgcnRnLWJmZEBpZXRmLm9yZzsgcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGlu dGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HcmVnb3J5LDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGFyZSB1c2lu ZyBhIHNwZWNpYWwgR0FMIGxhYmVsIGZvciBCRkQgcGFja2V0cy4gVGhpcyBsYWJlbCBleGlzdHMg b25seSBmb3IgdGhlIEJGRCBwYWNrZXRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgY2FuIHlvdSB0aGVuIGNsYWltIGNvbm5l Y3Rpdml0eSBmb3Igb3RoZXIgdHJhZmZpYyB3aGljaCB3aWxsIG5vdCB1c2UgdGhpcyBsYWJlbD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2xl bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIEFwciAxMywgMjAxNiBhdCA0OjE4IEFNLCBHcmVnb3J5IE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdy ZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cD5IaSBKZWZmLDxvOnA+PC9vOnA+PC9wPg0KPHA+dGhhbmsgeW91IGZv ciBhZGRpbmcgbW9yZSBkZXRhaWxzIHRvIHRoZSBkaXNjdXNzaW9ucyBiZWZvcmUgUkZDIDcxMzAu IFdlIGhhdmUgc3VibWl0dGVkIGFub3RoZXIgZHJhZnQgdGhhdCBwcm9wb3NlcyB0byB1c2UgTVBM UyBlbmNhcHN1bGF0aW9uIG9mIEJGRCBjb250cm9sIHBhY2tldHMgb3ZlciBNQy1MQUcgaW50ZXJm YWNlcy4gV291bGQgZ3JlYXRseSBhcHByZWNpYXRlIHJldmlld3MsIHF1ZXN0aW9ucyBhbmQgY29t bWVudHMgb24NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzLTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1tcGxzPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IEplZmZyZXkgSGFhcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqaGFhc0Bw ZnJjLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpoYWFzQHBmcmMub3JnPC9hPl0NCjxicj4NClNlbnQ6 IE1vbmRheSwgQXByaWwgMTEsIDIwMTYgMTA6MjQgQU08YnI+DQpUbzogR3JlZyBNaXJza3k8YnI+ DQpDYzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbik7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC10YW5t aXItcnRnd2ctYmZkLW1jLWxhZy1pcEB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K ZHJhZnQtdGFubWlyLXJ0Z3dnLWJmZC1tYy1sYWctaXBAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1wbHMtY2hhaXJzQGlldGYub3JnPC9hPjsgQWxpYSBBdGxhcyAoPGEgaHJlZj0ibWFpbHRv OmFrYXRsYXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWthdGxhc0BnbWFpbC5jb208L2E+ KTsNCjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRn LWJmZEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGctYmZkLWNoYWlyc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRnLWJmZC1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KU3Vi amVjdDogUmU6IFR3byBuZXcgZHJhZnRzIG9uIChtaWNyby0pQkZEIG92ZXIgTUMtTEFHIGludGVy ZmFjZXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+R3JlZyw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5UaGlzIGlzIG1vcmUgb2YgYSBnZW5lcmFsIGNvbW1lbnQgb24gZGlzY3Vzc2lvbnMgZnJvbSB0 aGUgZGV2ZWxvcG1lbnQgZnJvbSBSRkMgNzEzMCB0aGFuIGFueSBzcGVjaWZpYyBjb21tZW50IG9u IHlvdXIgZHJhZnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+T24gRnJpLCBBcHIgMDgsIDIwMTYgYXQgMTE6NDM6MThBTSAtMDcwMCwgR3JlZyBN aXJza3kgd3JvdGU6PG86cD48L286cD48L3A+DQo8cD4mZ3Q7IHllcywgbGluayBsb2NhbCBtdWx0 aWNhc3QgbWF5IGJlIHVzZWQgaW4gTUMtTEFHIHNjZW5hcmlvLiBUaGUgZHJhZnQgPG86cD48L286 cD48L3A+DQo8cD4mZ3Q7IHN0YXRlcyB0aGF0IGl0IE1BWSBiZSB1c2VkIHdoaWxlIHRoZSBicm9h ZGNhc3QgaGFzIFNIT1VMRCBub3JtYXRpdmUuIDxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBCdXQg d2UgYXJlIGFsbCBvcGVuIHRvIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5EdXJpbmcgb3VyIGRpc2N1c3Npb25zIGFjcm9zcyBtdWx0 aXBsZSB2ZW5kb3JzLCBpbmNsdWRpbmcgc29tZSBoYXJkd2FyZSB2ZW5kb3JzLCBpdCB3YXMgZGV0 ZXJtaW5lZCB0aGF0IGF0dGVtcHRzIHRvIGV4ZXJjaXNlIHRoZSBsYXllciAzIG1lY2hhbmlzbXMg d291bGQgdmFyeSBzaWduaWZpY2FudGx5IGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMgZGVwZW5kaW5n IG9uIGhvdyBwYWNrZXRzIHdlcmUgZW5jYXBzdWxhdGVkLiZuYnNwOyBNdWx0aWNhc3QgaW4NCiBw YXJ0aWN1bGFyIHByb3ZpZGVkIHNvbWUgcHJvYmxlbWF0aWMgaXNzdWVzIGZvciB1cyBiZXlvbmQg dGhlIGluaXRpYWwgYm9vdHN0cmFwcGluZyBwaGFzZSBvZiBMQUcgZm9yIEJGRCB3aGVyZWluIHdl IG1pZ2h0IG5vdCBoYXZlIEFSUCBjb21wbGV0ZWQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+TXkgcmVjb21tZW5kYXRpb24gaXMgdG8gcHJvY2Vl ZCB3aXRoIHlvdXIgZHJhZnRzIHdpdGggc2ltaWxhciBjYXV0aW9uLiZuYnNwOyBUcnkgdG8gc3Rh eSBhcyB0cnVlIHRvIHB1cmUgSVAgYXMgcG9zc2libGUgdG8gYmVzdCBpbnN1cmUgdGhlIEwzIGRh dGEgcGF0aHMgYXJlIGV4ZXJjaXNlZCBhY3Jvc3MgaW1wbGVtZW50YXRpb25zIGZyb20gdmFyaW91 cyB2ZW5kb3JzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4t LSBKZWZmIChzcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF11221A4498Feusaamb103erics_-- From nobody Wed Apr 13 09:16:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF88F12DB21 for ; Wed, 13 Apr 2016 09:16:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 PAQhE3uQXJVk for ; Wed, 13 Apr 2016 09:16:09 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C25F12DA01 for ; Wed, 13 Apr 2016 09:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NOwoFQF2C2VsYtDmDmRZzqHQG4XkdjqPIA5kjNbbscM=; b=fu1JPSURskdLI7DCqN7jprb2oRErYY98TupB12QfawGjxiF4ntg5xbI7VX+bypb6K6370tFkwRNspZ0MNZOodq4ygCoRq3KkL1Zu6vq4661Wo3xL3Ej0l0CNt0L+iNH1D0IDN4U/eZq/37E9vFMlj9oZiu70V7mBgQuHxd+XZ9g= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.171.1.17) by VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) with Microsoft SMTP Server (TLS) id 15.1.466.12; Wed, 13 Apr 2016 16:15:50 +0000 Message-ID: <00d801d1959f$51393f60$4001a8c0@gateway.2wire.net> From: t.petch To: , Loa Andersson References: <570BB266.8090608@juniper.net> <04c801d1957b$2be37ce0$4001a8c0@gateway.2wire.net> <570E3879.309@pi.nu> Date: Wed, 13 Apr 2016 17:00:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.171.1.17] X-ClientProxiedBy: DB3PR08CA0026.eurprd08.prod.outlook.com (10.161.51.164) To VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) X-MS-Office365-Filtering-Correlation-Id: f22a14be-c7af-4ec4-898c-08d363b6e1a4 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 2:M1QseQ77ZEEVCXnP/fGHwrfTg7djM7tf7xLAqS1HsPCUV/bqw6WMBnfslCWgTrDvh9QgzeHk1pPxEXCT7HJk5U8Npc5MpG/UAZTd8ueteD5TfBVQYYTkpQCUIGpyr2P8Yblnwzf+54I84FDszeuL8GdXL2YKCilbTujK5e/P8jOCzGpx0cN5Km8+VpaVgz1Y; 3:mtsKTdAfZ47kOM2pSkcV2JShwBGQUCx6UdG7QerVD9CS2yJbiCo8SCNlnrG2xSBdZSTO1tjkJaGFc0hmFWn0j77XmQR0gMI1L1byXMFlf4ILkuErd7xj+/oLWpRSVWrF; 25:2VHhiQ18KUGvIfwtiiw/+obJjAP1gD4x62LyqqpwTGhoQREXAjJT+MuhK6aAhlAm4jmA+xgbfD7BY/dQ1fdYBF3P3v2W+hOZPIBNYJK6/9Ui7+rWLUYZGopVwHbTMhNivQXFH9gZ+FwopqEGvu2e3YywQ4IyVFzxf9oM1z3WqqtE4sup4UkY5dh32Qk2qdvhTeZ9ldp2ZcU7l/+dF+DIMViQnirN5ds1QQ/nrD7D4hA2mtGSE7gdfLUoSPtqmfseo8suTCQuTefS3mimNcXn82sZoRFnHcR6RMupPZTcuB7iz6IKURs2gh/3vesRz2yo3oUsju9BHSkxpgNddztFmQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1632; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:VI1PR07MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1632; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 4:D3xsjNJy5UGTmGG47tbZa9ZoyKy1SinQGnfCekYikZBhSaIuwvxRS62a+uGOvaADbAoKoKqOFhuSQmzGYRbILrB7JOQ61nq6GJTWzRJJo/c6ERQWe7hHEkVaYE4MPGz/OtXDD/B2DMTmEkvHkJxWhATUeAsFHC0EggHDm189ec5IavB6HNTn0n+w5tTh4R8MUu761LrQaURTtB7GQR5AcXjHwOXdVTa8fjJXsxILHVLtR6qKoJd3Q4+kj+ZDJ9Ja7939tJ3LQnYsIwWolk1vRyVrd4pTh98Y0WL4Bc/J23t9KaZ0O6KF9Lz1k9ARICDSq/1rOop6oBocX4NThGyndaRdaq4Q0u22MQSHvhn8rQ9ZmxdFRyPI+GBZNQg7lJxubow4S7hz9d8tSHRMIrb6m7vEPYsHUT5g1f+gDnSaAoSaMI6U2KUTwj/K81NWsVEn X-Forefront-PRVS: 0911D5CE78 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377424004)(24454002)(377454003)(81166005)(50466002)(50226001)(107886002)(44716002)(9686002)(230700001)(5001770100001)(15975445007)(1456003)(62236002)(33646002)(42186005)(77096005)(5008740100001)(189998001)(1556002)(86362001)(66066001)(47776003)(3846002)(5004730100002)(84392002)(61296003)(50986999)(19580405001)(76176999)(6116002)(19580395003)(81816999)(81686999)(1096002)(2906002)(586003)(23746002)(92566002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1632; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR07MB1632; 23:pXwrYC7cy1soEUwGXhZmlKnk42M8EH2TBJ425?= =?Windows-1252?Q?XvDngh/xLvt5V5uVUurugprqE1oGTA2NW9J6DR3DytJeFTYNJweN+JT3?= =?Windows-1252?Q?McDl3Or+LFy7zveOwAOWIJ3z6pIrH2oVG6LMHd5DrUaxN9AahvVSJtZy?= =?Windows-1252?Q?tP7GS2z1GtXy8+h3OjGuUf5/yZD8Cl3LWowYlfkQOvkrYf1MwxOVaVU4?= =?Windows-1252?Q?zW9uHkge213ZRI4l93dpbAYnin9YhyeTHAtQ+IuW5ZHHMTcn4QdhP41l?= =?Windows-1252?Q?pnqTeV7ARfxX7OA6805keNUPJL6WhDqMpp2gvzWXA+xnfNdSufKyfXAH?= =?Windows-1252?Q?/lHTFOUymCl3ZXpIhBHPnuMRcZqiJYvcHNLGM0Ick1iPJc6MHtWcZdWw?= =?Windows-1252?Q?Mdec4wvECkBjIhVNfbJf6pNbjCu5Bw5gvo/pvLFTaMDzZ2lkIIwXwkEt?= =?Windows-1252?Q?X1l7I6GOjUofifYPjvtPmccuff/jw4Cpu0B/iePZXeCYWxB0ODC3Gosj?= =?Windows-1252?Q?UTnK7g1zjO9bthGyUQcl3ISacKZ+xLZ5yChLtRxpbBEfoQ5+58k11uFk?= =?Windows-1252?Q?5n0dwwky+7PR/guBs1jRUJYcI8gdLZoSNxxOh+MYKEzxgvjXsDFKLinR?= =?Windows-1252?Q?NaspWw3doLqFpZRgyy+5RfOuY8Go61pYDVm6VezOhgQ5jm4nc0Amd7LI?= =?Windows-1252?Q?krr8PmVrWO7LyY/Lv1Lc5djAms1MBAjgZSzuE7Zta2+FMAtnM0nydmDk?= =?Windows-1252?Q?9L20hXIHunCeBj+srwW8hVUqM0x/5mkxY3v3N+Ky20B5im8tnqk7g+GJ?= =?Windows-1252?Q?2bwYXJdaRA2r7wPHUUeWQmrCzTYzbzrMoRRnDTPJv2Kx0zHNv4RHQ2Yj?= =?Windows-1252?Q?7+Dp7/TY01v1kDhOYddB87GKO4EyTWNnQzJw5fQQSlzBSaN7xtELHqEo?= =?Windows-1252?Q?8xn/wSxAH/cbwh/t1nKlmtTL2SSX1dyjr+0QCYaes3v8Mx6XL6VXHf3w?= =?Windows-1252?Q?kOP4ptU1HkAdpmbHY6flMK6K19dQX/Jcn3G2aeNo5MdfLsKasX2+1Pzy?= =?Windows-1252?Q?gfuQpMoYfITBBZzM1GiGj/BHehGBACiyhGshU6QrXLCUixJy0/mxYECe?= =?Windows-1252?Q?o+oMp2TJ58Rv8Nx1fd7eymq0Ew11/hHBqJwcMvceNdV/UDUqUbcWInSm?= =?Windows-1252?Q?/uP6B21+JE6I+5cAy7UnU7Ss6IN54S4l/tVgFlZY6C5kHHz6v5WVsLKQ?= =?Windows-1252?Q?hao/6COuvCqV6/pFuSLv8m3K5MR/hwz8H5/76w=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 5:XHwGIuALiNT+4/NdtFlAXlsaRJFuN4iakdzWBhTgvcwzKFKUBzDV1pNJ7vfkAIKQDoZdaPDTvRq2Z9vByysLtYwpBCeMFDAwavbgYDNyTI3PWXzEo8470gY/0Ic6959EfxYApHfuTmBL54Y9WTaGE0F72IqYkW0QqQsx7BcFQvjkwMqehZk4H2iVhbJSVciY; 24:UrLjMHp3kzTOKgDq/XsLTmejtWCCCeokibpHCSqOcfbQkRpW9fD0/mlibuWoN2Dzck76kaZU074LPoLpasSohlmgK20VVtQImRbhwqwN7wo=; 7:IUW8E3Lo6Y4EkTGSfmeminrZ69IguTEhTnWU5z/qFjAHOec8cht8nCx6Ju4R96+btSMQXuBmFavBmshNm5od4kddMIqGbDKWK0f9RYBpj+0s2+LZp0IklnR4dBniS28eUXu4E9TtebTUxbXyzN+fnJG2tx2mklvksKK/nj+LPgeasa3hfs4NdQpkRQ/JQL15pPJKEtOHlgsojd88guBA3q7vdfc+F0NvIF2ivojIaYg= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2016 16:15:50.7257 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1632 Archived-At: Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:16:13 -0000 ----- Original Message ----- From: "Loa Andersson" To: ; "tom p." Sent: Wednesday, April 13, 2016 1:15 PM > Tom, > > > On 2016-04-13 19:53, t.petch wrote: > > ----- Original Message ----- > > From: "Eric C Rosen" > > Sent: Monday, April 11, 2016 3:19 PM > > > > > >> (Removed sfc from the cc-list, this seems out of scope for that WG.) > >> > >> In designing the BIER header, the BIER WG is free to mandate any value > >> it chooses in the first nibble. These values do not come from a > > "first > >> nibble" registry. > >> > >> It seems prudent to put a value like 5 for the following reasons: > >> > >> - If a BIER packet is being parsed by an off-line tool, this is a good > >> hint (though just a hint) that the packet is actually a BIER packet; > >> > >> - If a BIER packet is traveling through an MPLS tunnel, and it > > traverses > >> a node that does its MPLS load splitting by guessing at the type of > > the > >> payload, then this is a good hint that the MPLS payload is not IPv4, > >> IPv6, or PW. > >> > >> This strategy does incur a risk. Suppose IPv5 gets designed, > >> implemented, and deployed, and folks start to deploy hardware that > > does > > > > Too late; see > > > > > > https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-00 > > Isn't this just in time - if IPv5 is made historic - we can safely use > it. I think not ' A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. ' It doesn't mean it is not in use although that I-D does say 'Given that IPv6 is a deployment reality and there are no proven deployments of the aforementioned IP versions ...' My point was that IPv5 exists, as of now, and still will, even when made Historic. The I-D says ' IANA is requested to deallocate the version numbers' which I think wrong. If you are feeling paranoid - sometimes I do - then you will think that somewhere the value 5 is given a significance and it would be safer not to free it up for re-use. Tom Petch > > /Loa > > > > Discussion on the int-area list. > > > > Tom Petch > > > > > > > >> MPLS load balancing by inspecting the IPv5 headers of the MPLS > >> payloads. If a BIER packet is traversing an MPLS tunnel, > > inappropriate > >> load splitting may occur if the hardware thinks the payload is IPv5 > >> rather than BIER. > >> > >> This particular risk doesn't seem very significant to me. > >> > >> Thus I don't think there's anything here that needs fixing. > >> > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > From nobody Wed Apr 13 10:03:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB1812DC3A; Wed, 13 Apr 2016 10:03:24 -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 Tv20g1VsgStN; Wed, 13 Apr 2016 10:03:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0EB12DCBD; Wed, 13 Apr 2016 10:03: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=80Q+AxHEGUEOY+do6aDu4v2A4eEgjcXQG93luZgQHY8=; b=GODrK6hQx/7ZRHCr7wOLmNqubENSviadI1nrVJ84dtghPVF2ttS9y6Hfj6qt4JF1Ah9IrVKBV4Fr1XB1PbnZG6pRPflywawRtOBLYiGIxYnF+QvdOAHb5ruXt4WM7Wo05yFLjFmmJu6ZG8KAM647zWXnpLk8R8jrwg8E12OOZgc= Received: from SN1PR0501MB1840.namprd05.prod.outlook.com (10.163.131.150) by SN1PR0501MB1839.namprd05.prod.outlook.com (10.163.131.15) with Microsoft SMTP Server (TLS) id 15.1.453.26; Wed, 13 Apr 2016 17:03:00 +0000 Received: from SN1PR0501MB1840.namprd05.prod.outlook.com ([10.163.131.150]) by SN1PR0501MB1840.namprd05.prod.outlook.com ([10.163.131.150]) with mapi id 15.01.0453.029; Wed, 13 Apr 2016 17:03:00 +0000 From: Kireeti Kompella To: Loa Andersson , "mpls@ietf.org" Thread-Topic: IPR poll on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRlMFh7/dZ1U/Hxk+Qa5UGkM2ux5+IREyA Date: Wed, 13 Apr 2016 17:02:55 +0000 Message-ID: <27561FB1-DA9E-4C4F-B50C-C2846DE8053C@juniper.net> References: <570CFB90.8020706@pi.nu> In-Reply-To: <570CFB90.8020706@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-ms-office365-filtering-correlation-id: 7b4a89b4-ff0b-4aed-fc9b-08d363bd77e0 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1839; 5:F1gNt2Ntjjf3Oxj4C7pKv1sin+czCU7ttSaLsjhkvpdVx7liOFOrDNyXJcmQeY92/aP3nC8JtFUKEJJF+/+G/jFKJ0GQAius/X+LDaeroXNiY/DRgXJku+l0aSHsIe1IqdSOkKbBoELmtAb5dAKE/g==; 24:+9LAIDy6Z7xVo+Y4TxyB3npra+hkulhqFJ4gH8mN2KWcpMntd1PdYJMy5dkKy7RqI4rV5xYfZr5AWWJkQ0yxyqayz9YdXUTxAN1AXTL52x4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1839; 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)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1839; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1839; x-forefront-prvs: 0911D5CE78 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(54356999)(19580395003)(82746002)(2900100001)(83506001)(36756003)(83716003)(50986999)(122556002)(77096005)(87936001)(19580405001)(86362001)(5004730100002)(76176999)(230783001)(2950100001)(81166005)(106116001)(92566002)(1220700001)(1096002)(2501003)(2906002)(4326007)(586003)(4001350100001)(3280700002)(11100500001)(3660700001)(3846002)(6116002)(102836003)(189998001)(107886002)(10400500002)(4001430100002)(5008740100001)(5002640100001)(33656002)(66066001)(5001770100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1839; H:SN1PR0501MB1840.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <0D49BD9B5D0804459FF0C1EBCFB03270@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2016 17:02:55.5572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1839 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , Kireeti Kompella , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 17:03:24 -0000 Tm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQpLaXJlZXRpLg0K DQpPbiA0LzEyLzE2LCAxNTo0MyAsICJMb2EgQW5kZXJzc29uIiA8bG9hQHBpLm51PiB3cm90ZToN Cg0KPldvcmtpbmcgR3JvdXAsDQo+DQo+VGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1tcGxzLXNw cmluZy1lbnRyb3B5LWxhYmVsIGhhcyB0b2xkIHVzIHRoYXQNCj50aGUgZG9jdW1lbnQgaXMgcmVh ZHkgdG8gYmUgY29uc2lkZXJlZCBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwuDQo+DQo+V2Ug d2lsbCBkbyBhbiBJUFIgcG9sbCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHdnIGxhc3QgY2Fs bC4NCj4NCj5UaGlzIG1haWwgc3RhcnRzIHRoZSBJUFIgcG9sbC4NCj4NCj5BcmUgeW91IGF3YXJl IG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9w eS0NCj5sYWJlbD8NCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KPihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5 IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KPg0KPlRoZXJlIGFyZSBubyBJUFIgZGlzY2xv c3VyZXMgZmlsZWQgZGlyZWN0bHkgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPg0KPklmIHlvdSBh cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNw b25kIHRvDQo+dGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUg YXdhcmUgb2YgYW55IHJlbGV2YW50DQo+SVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNl bnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiogVGhlDQo+ZG9jdW1lbnQgd2lsbCBub3Qg YWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuDQo+cmVj ZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+DQo+SWYgeW91IGFyZSBv biB0aGUgTVBMUyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Ig b3INCj5jb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYg eW91IGFyZSBhd2FyZSBvZiBhbnkNCj5JUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+DQo+DQo+L0xvYQ0KPm1wbHMgd2cg Y28tY2hhaXINCj4tLSANCj4NCj4NCj5Mb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAg ICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPlNlbmlvciBNUExTIEV4cGVydCAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51DQo+SHVhd2VpIFRlY2hub2xvZ2llcyAoY29u c3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+DQoNCg0KDQo= From nobody Wed Apr 13 10:49:46 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88ED12D90D; Wed, 13 Apr 2016 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 92nXRUTxsu9v; Wed, 13 Apr 2016 10:49:37 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C4812D77F; Wed, 13 Apr 2016 10:49:36 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id s79so72203450oie.1; Wed, 13 Apr 2016 10:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=J2bjLA7HL7oG6V3Rcv6Wdd8TcvvJxhxuAiKRlGnmMPU=; b=QalieEDmGiniEmgmyX1fs2Aql7bBpW8esmUGe50JbDAXBa7ZEQ4RTyPI5NLvfySO2U A9/Cu3xW4r3X+tibrVXd6OsFXtVGUeXA/86SonONnXtgIxjXyCS63lvSSN6TvUD/jKEu MWR1/R55KC66Zfth0NHRD/NUJoEwsKdEeV3fXnuAYDy+ws73L7Qv2fT+Dp0/Z68cxdKv ywaON6FjMf1/Vf4cSl1g+d+1Um6IBVN409zw4XxSuHGM46YHlx2Ic+3MAqEmJJNZa4tK u6qRlHAO2FKNQheYZYIQyOUqVksXIP5pWkVM12mcjj/Li20sQadRCAGj+vFscKrW+RNW 1E5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=J2bjLA7HL7oG6V3Rcv6Wdd8TcvvJxhxuAiKRlGnmMPU=; b=DZ65uXmeRQ14BHkWYuZTnNLAn8nR+4Na0kClEz6nFwjIQBQlx/cNGJFG1k0kHUGvZK TOwGA/pk/gLp6Vf/9fAmkjOOb6ficGvMjYx960htg+FlOye7f/sG25lzTfS0fxzYit+X a1Q+Sn13WLaL4srIkhoCfrIAUuqQpeT1wamkELayWPaUOIehI5XFQcxLccLdcefKrXGk FkY40KOtDvtXr7s6BP4c7QsJ56e40KSMEpKHlKXAcXF40SenkrfWPrw2oxGjS7zn+WOR TG0mf2Lq8ztNjpd/oaYpipBze9zh2LDuZFnMZ5Dj9h4NxOpA8HwKQAXVMJ09vhtmS4Cg 8CLA== X-Gm-Message-State: AOPr4FXXpiqpC3R0a+rgPhwy8L2C59f3nt60HblhRsPAIgPITJmeR50jpAGIKv3pDcConQ== X-Received: by 10.157.37.193 with SMTP id q59mr4807001ota.12.1460569776227; Wed, 13 Apr 2016 10:49:36 -0700 (PDT) Received: from ?IPv6:2605:6001:e3c2:6700:c970:2877:2f21:ad45? ([2605:6001:e3c2:6700:c970:2877:2f21:ad45]) by smtp.gmail.com with ESMTPSA id e9sm12215963oig.11.2016.04.13.10.49.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2016 10:49:35 -0700 (PDT) To: Stewart Bryant , The IESG References: <20160107043320.4920.88068.idtracker@ietfa.amsl.com> <57064F5A.2050401@gmail.com> From: Spencer Dawkins at IETF Message-ID: <570E86AD.8020305@gmail.com> Date: Wed, 13 Apr 2016 12:49:33 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57064F5A.2050401@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, mpls-chairs@ietf.org Subject: Re: [mpls] Spencer Dawkins' No Objection on draft-ietf-mpls-rfc6374-udp-return-path-04: (with COMMENT) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 17:49:38 -0000 Hi, Stewart, On 04/07/2016 07:15 AM, Stewart Bryant wrote: > > > On 07/01/2016 04:33, Spencer Dawkins wrote: >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-mpls-rfc6374-udp-return-path-04: 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-mpls-rfc6374-udp-return-path/ >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I would be fine keeping the to-be-deleted text explaining alternatives >> that were not selected, especially if it was moved to an appendix. If >> anyone ever wonders about the alternatives, that would mean they didn't >> have to dig through e-mail archives to see what was considered and why >> the alternatives were rejected. >> >> I'm not understanding why >> >> When the MPLS-PLDM Response is requested out-of-band by setting the >> Control Code of the MPLS-PLDM query to "Out-of-band Response >> Requested", and the URO is present, the responder SHOULD send the >> response back to querier on the specified destination UDP port at >> the >> specified destination IP address contained in the URO. >> is a SHOULD. Could you help me with that? >> >> > > There are certain conditions where such a response is not possible. > These are > described in the text. I take SHOULD to mean "MUST unless there are > extenuating > circumstances" and MUST to mean "Unconditionally do". > > Stewart Thanks for the clue! Spencer From nobody Wed Apr 13 20:07:19 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B21012DFA5; Wed, 13 Apr 2016 20:07:15 -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 P1WIrOh7SZo2; Wed, 13 Apr 2016 20:07:13 -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 3EBA812DEC4; Wed, 13 Apr 2016 20:07:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMD15174; Thu, 14 Apr 2016 03:07:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 04:07:09 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 11:07:06 +0800 From: Xuxiaohu To: Eric C Rosen , "Carlos Pignataro (cpignata)" Thread-Topic: [bier] [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRlZODxyb0YWE87kOEgjOaa5qR65+IxvJA Date: Thu, 14 Apr 2016 03:07:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539EF2@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570E5C1A.7010606@juniper.net> In-Reply-To: <570E5C1A.7010606@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.570F095E.00D5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1715b35fb911aa155092b33cf697fcc5 Archived-At: Cc: "bier@ietf.org" , "Dr. Tony Przygienda" , "mpls@ietf.org" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:07:15 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRXJpYyBDIFJvc2VuIFtt YWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEzLCAy MDE2IDEwOjQ4IFBNDQo+IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNCj4gQ2M6IEFs ZXhhbmRlciBWYWluc2h0ZWluOyBHcmVnIE1pcnNreTsgbXBsc0BpZXRmLm9yZzsgYmllckBpZXRm Lm9yZzsgWHV4aWFvaHU7DQo+IERyLiBUb255IFByenlnaWVuZGENCj4gU3ViamVjdDogUmU6IFti aWVyXSBbbXBsc10gVGhlIGZpcnN0IG5pYmJsZSBpc3N1ZSBhc3NvY2lhdGVkIHdpdGggTVBMUw0K PiBlbmNhcHN1bGF0aW9uDQo+IA0KPiANCj4gT24gNC8xMS8yMDE2IDg6MTkgUE0sIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4gPiBUaGUgZm9ybWF0IG9mIGEgQklFUiBwYWNr ZXQgaGF2ZSBlbm91Z2ggY29uc3RyYWluZWQgb3Igc2VsZi1kZWZpbmluZw0KPiA+IGZpZWxkcywg dGhhdCBhbiBvZmYtbGluZSBwYXJzaW5nIHRvb2wgbGlrZSBXaXJlc2hhcmsgY2FuIGFwcGx5IGVu b3VnaA0KPiA+IGhldXJpc3RpY3MgdG8gZmlndXJlIGl0IG91dCwgd2l0aG91dCB0aGUgMHg1Lg0K PiANCj4gSSBoYXZlbid0IHdvcmtlZCBvdXQgZm9yIG15c2VsZiB3aGV0aGVyIHRoaXMgaXMgdGhl IGNhc2Ugb3Igbm90LCBidXQgaXQgY2VydGFpbmx5DQo+IGRvZXNuJ3QgaHVydCB0byBoYXZlIHRo ZSAweDA1IHRoZXJlLg0KPiANCj4gPiBJIHVuZGVyc3RhbmQgd2h5IGEgbWlkLXBvaW50IExTUiBt aWdodCB3YW50IHRvIG5vdCBhbGlhcyB0aGUgTVBMUw0KPiA+IHBheWxvYWQgd2l0aCBJUHY0IG9y IElQdjYsIHRvIHByZXZlbnQgbWlzLWhhc2hpbmcgaW4gdGhlIExCLiBXaHkgd291bGQNCj4gPiBh IG5vZGUgYmUgaW50ZXJlc3RlZCBpbiBrbm93aW5nIHRoZSBwYXlsb2FkIGlzIG5vdCBhIFBXPyBX aGF0IHdvdWxkIGl0DQo+ID4gZG8gZGlmZmVyZW50bHk/DQo+IA0KPiBJJ20gbm90IHN1cmUgaWYg dGhlcmUgaXMgYW55IGhhcmR3YXJlIHRoYXQgcGVyZm9ybXMgUFctc3BlY2lmaWMgZnVuY3Rpb25z IGluIHRoZQ0KPiBmb3J3YXJkaW5nIHBsYW5lLCBiYXNlZCBvbiB0aGUgZmlyc3QgbmliYmxlLCBi dXQgaXQgc2VlbXMgcHJ1ZGVudCB0byBhdm9pZCBhbnkNCj4gcG9zc2liaWxpdHkgb2YgY29uZnVz aW9uLg0KPiANCj4gPiBbSXQgaXMgaW50ZXJlc3RpbmcgdGhhdCB0aGUgaGludCBpcywgYXMgZGVz Y3JpYmVkLCB0byBudWRnZSBhIG5vZGUNCj4gPiB0aGF0IHRoZSBwYWNrZXQgaXMgKm5vdCogc29t ZXRoaW5nLCBpbnN0ZWFkIG9mIHRoZSBwYWNrZXQgKmlzKiBCSUVSLl0NCj4gDQo+IFdlbGwsIG9m IGNvdXJzZSwgdGhhdCdzIHdoeSB0aGUgbmliYmxlIGlzIG5vdCBhIHByb3RvY29sIHR5cGUgZmll bGQgOy0pIEluIHRoZSBNUExTDQoNCklmIHdlIHBpY2sgZGlmZmVyZW50IHZhbHVlcyBmb3IgdGhl IGZpcnN0IG5pYmJsZSBvZiBkaWZmZXJlbnQgTVBMUyBwYXlsb2FkcywgdGhlIGZpcnN0IG5pYmJs ZSBhY3R1YWxseSBwbGF5cyB0aGUgcm9sZSBvZiBhIHByb3RvY29sIHR5cGUgZmllbGQuIEluIGZh Y3QsIHRoZXJlIGlzIGFuIGF0dGVtcHQgdG8gaGF2ZSBhIHJlZ2lzdHJ5IGZvciB0aGUgZmlyc3Qg bmliYmxlIChhLmsuYS4sIE1QTFMgcGF5bG9hZCB0eXBlIGZpZWxkKS4NCg0KQmVzdCByZWdhcmRz LA0KWGlhb2h1DQoNCj4gZW5jYXBzLCB0aGUgZmFjdCB0aGF0IHRoZSBwYWNrZXQgaXMgQklFUiBp cyBkZXRlcm1pbmVkIGZyb20gdGhlIE1QTFMgbGFiZWwuICBJbg0KPiBvdGhlciBwcm9wb3NlZCBl bmNhcHN1bGF0aW9ucywgdGhlIGVuY2Fwc3VsYXRpbmcgcHJvdG9jb2wgd291bGQgaGF2ZSBhDQo+ IHByb3RvY29sIHR5cGUgZmllbGQuDQo+IA0KPiA+PiBUaGlzIHN0cmF0ZWd5IGRvZXMgaW5jdXIg YSByaXNrLiAgU3VwcG9zZSBJUHY1IGdldHMgZGVzaWduZWQsIGltcGxlbWVudGVkLA0KPiBhbmQg ZGVwbG95ZWQsIGFuZCBmb2xrcyBzdGFydCB0byBkZXBsb3kgaGFyZHdhcmUgdGhhdCBkb2VzIE1Q TFMgbG9hZCBiYWxhbmNpbmcNCj4gYnkgaW5zcGVjdGluZyB0aGUgSVB2NSBoZWFkZXJzIG9mIHRo ZSBNUExTIHBheWxvYWRzLiAgSWYgYSBCSUVSIHBhY2tldCBpcw0KPiB0cmF2ZXJzaW5nIGFuIE1Q TFMgdHVubmVsLCBpbmFwcHJvcHJpYXRlIGxvYWQgc3BsaXR0aW5nIG1heSBvY2N1ciBpZiB0aGUN Cj4gaGFyZHdhcmUgdGhpbmtzIHRoZSBwYXlsb2FkIGlzIElQdjUgcmF0aGVyIHRoYW4gQklFUi4N Cj4gPj4NCj4gPj4gVGhpcyBwYXJ0aWN1bGFyIHJpc2sgZG9lc24ndCBzZWVtIHZlcnkgc2lnbmlm aWNhbnQgdG8gbWUuDQo+ID4+DQo+ID4gSSBhZ3JlZSB0aGF0IHJpc2sgaXMgcXVpdGUgaW5zaWdu aWZpY2FudCAobnVsbCBpbiBwcmFjdGljZSkuIFRoZSByZWFsIHJpc2sgSSBiZWxpZXZlIGlzIGlm DQo+IHNvbWUgb3RoZXIgYXBwbGljYXRpb24gb3ZlciBNUExTIHVzZXMgMHg1IGluIHRoZSBmaXJz dCBuaWJibGUsIGJlY2F1c2UgdGhleSBkbw0KPiBub3Qgd2FudCB0byBiZSBjb25mdXNlZCB3aXRo IElQIGVpdGhlciwgYW5kIHRoZXkgZG8gbm90IGxpa2UgMHgwIG9yIDB4MS4NCj4gDQo+IFRoYXQg aXMgcG9zc2libGUsIGJ1dCBJIGRvbid0IHJlYWxseSBzZWUgd2hhdCB0aGUgcHJvYmxlbSBpcy4N Cj4gDQo+IEkgZ3Vlc3MgaXQgaXMgdHJ1ZSB0aGF0IHdlJ2xsIGhhdmUgdG8gc2F5IHRoYXQgQklF UiBpcyBub3QgMTAwJQ0KPiBjb21wbGlhbnQgd2l0aCBSRkMgNDkyOC4gICBJIGRvbid0IHNlZSB0 aGF0IGFzIGEgcHJvYmxlbSBlaXRoZXIsIGJ1dCBpdA0KPiBpcyBjZXJ0YWlubHkgcG9zc2libGUg dGhhdCBzb21lIEFEIHdpbGwgbWFrZSBhbiBpc3N1ZSBvZiBpdC4NCj4gDQoNCg== From nobody Wed Apr 13 20:45:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8038E12DA2C; Wed, 13 Apr 2016 20:45:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 yXYFKsApVMqw; Wed, 13 Apr 2016 20:45:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C115D12D583; Wed, 13 Apr 2016 20:45:23 -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=6BHUg3Xz939hBYkCfBLexjosHCdBMzprN+VluVsR4cI=; b=KKfj8g5ySFnoAoVz+n7Q7ByFewEIFYtn7Vs/bucYgr3i6mOAQw6/hTF11Esqk1XJ/m+i4s2rtxk2dyfGq6VCjcN/lOu0tx9mQ2rE7zen7jbMR95/iagjQQA7tttFDQZgBR6ysz3wKGdCZ9c3n1PlXw8o0mMX6QKwPh+uOVUtC9w= Received: from CY1PR05MB2492.namprd05.prod.outlook.com (10.167.10.25) by CY1PR05MB2491.namprd05.prod.outlook.com (10.167.10.24) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 03:45:04 +0000 Received: from CY1PR05MB2492.namprd05.prod.outlook.com ([10.167.10.25]) by CY1PR05MB2492.namprd05.prod.outlook.com ([10.167.10.25]) with mapi id 15.01.0453.030; Thu, 14 Apr 2016 03:45:04 +0000 From: Balaji Rajagopalan To: "George Swallow -X (swallow - CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" , "Nagendra Kumar Nainar (naikumar)" , Loa Andersson , "mpls@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: [mpls] IPR poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRhE0kDDcGdCKOzk6KxJC2V6HzQZ+JU6aA Date: Thu, 14 Apr 2016 03:45:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.10] x-ms-office365-filtering-correlation-id: de7e16d9-e954-4ed7-ebfe-08d364172a28 x-microsoft-exchange-diagnostics: 1; CY1PR05MB2491; 5:PBu3lY+s0IZ3bUjks3wZCPH3vFqZhIT+BR1In8yr2uv3umcN/mn8ghnIfVVyx102qs54MmKrvahYeiXxsHpbJU0RQL50I/Msdly1c2FWqwptRsF0Ttlq486GJPIusZbuLWb77nglvS3G19BN7QPumg==; 24:F9PhxDM0J2USpoqaVRQT70Do7iQBM64DYOlvi9o6rToUAQ8Eem4lVeRsOlj+pAMU97dxp1IKO+iaGyJ42XcBuVgBgruIVuDv879c2w5YZ18= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB2491; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB2491; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB2491; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(252514010)(3280700002)(54356999)(76176999)(66066001)(164054004)(2906002)(2950100001)(2900100001)(50986999)(230783001)(122556002)(2501003)(92566002)(3660700001)(19617315012)(107886002)(11100500001)(19580405001)(99286002)(19580395003)(5008740100001)(16236675004)(77096005)(83506001)(87936001)(5002640100001)(4001350100001)(5004730100002)(86362001)(15975445007)(189998001)(81166005)(36756003)(1096002)(5001770100001)(10400500002)(2201001)(1220700001)(106116001)(6116002)(3846002)(586003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2491; H:CY1PR05MB2492.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3350FF52A4F7balajirjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 03:45:04.2472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2491 Archived-At: Subject: Re: [mpls] IPR poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:45:26 -0000 --_000_D3350FF52A4F7balajirjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCg0KLS0NCkJh bGFqaSBSYWphZ29wYWxhbg0KDQpGcm9tOiBtcGxzIDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiR2VvcmdlIFN3YWxsb3cg LVggKHN3YWxsb3cgLSBDTEVBUlBBVEggV09SS0ZPUkNFIE1BTkFHRU1FTlQgSU5DIGF0IENpc2Nv KSIgPHN3YWxsb3dAY2lzY28uY29tPG1haWx0bzpzd2FsbG93QGNpc2NvLmNvbT4+DQpEYXRlOiBU dWVzZGF5LCAyMiBNYXJjaCAyMDE2IDg6NDEgcG0NClRvOiAiTmFnZW5kcmEgS3VtYXIgTmFpbmFy IChuYWlrdW1hcikiIDxuYWlrdW1hckBjaXNjby5jb208bWFpbHRvOm5haWt1bWFyQGNpc2NvLmNv bT4+LCBMb2EgQW5kZXJzc29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+LCAibXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4iIDxtcGxzQGlldGYub3JnPG1haWx0bzptcGxz QGlldGYub3JnPj4sICJkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmdAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWt1bWFya2luaS1tcGxzLXNwcmluZy1sc3AtcGluZ0B0b29s cy5pZXRmLm9yZz4iIDxkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmdAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWt1bWFya2luaS1tcGxzLXNwcmluZy1sc3AtcGluZ0B0b29s cy5pZXRmLm9yZz4+LCAibXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGll dGYub3JnPiIgPG1wbHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW21wbHNdIElQUiBwb2xsIG9uIGRyYWZ0LWt1bWFya2luaS1tcGxz LXNwcmluZy1sc3AtcGluZw0KDQpJIGFtIGF3YXJlIG9mIG5vIElQUi4NCg0KR2VvcmdlDQoNCk9u IDMvMjIvMTYsIDg6NTcgQU0sICJtcGxzIG9uIGJlaGFsZiBvZiBOYWdlbmRyYSBLdW1hciBOYWlu YXIgKG5haWt1bWFyKSINCjxtcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG5haWt1bWFyQGNpc2NvLmNvbTxtYWlsdG86bmFpa3Vt YXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCkhpIExvYSwNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55 IElQUi4NCg0KVGhhbmtzLA0KTmFnZW5kcmENCg0KT24gMy8yMi8xNiwgODoyOCBBTSwgIkxvYSBB bmRlcnNzb24iIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0KDQpXb3JraW5n IEdyb3VwLA0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNw LXBpbmcgaGFzIHRvbGQgdXMgdGhhdA0KdGhlIGRvY3VtZW50IGlzIHJlYWR5IHRvIGJlIGNvbnNp ZGVyZWQgZm9yIHdvcmtpbmcgYWRvcHRpb24uDQoNClRoZSBkb2N1bWVudCBiZWVuIHRocm91Z2gg TVBMUy1SVCByZXZpZXcuIFdlIHdpbGwgZG8gYW4gSVBSIHBvbGwNCnByaW9yIHRvIHRoZSBzdGFy dCBvZiB0aGUgYWRvcHRpb24gcG9sbC4NCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwu DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQta3VtYXJr aW5pLW1wbHMtc3ByaW5nLQ0KbHNwLXBpbmc/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3 OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KVGhlcmUgYXJlIG5v IElQUiBkaXNjbG9zdXJlIGZpbGVkIGRpcmVjdGx5IGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0K SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxl YXNlIHJlc3BvbmQgdG8NCnRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5 b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0KSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRv IGJlIHNlbnQgdG8gdGhlIE1QTFMgd2cgbWFpbGluZyBsaXN0LiogVGhlDQpkb2N1bWVudCB3aWxs IG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4N CnJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJl IG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv ciBvcg0KY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlm IHlvdSBhcmUgYXdhcmUgb2YgYW55DQpJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNCg0KL0xvYQ0KbXBscyB3ZyBjby1j aGFpcg0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KU2Vu aW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRv OmxvYUBwaS5udT4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTog KzQ2IDczOSA4MSAyMSA2NA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFp bGluZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_D3350FF52A4F7balajirjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <7CA04B98AAB6504B9FCC0526DE32ECDE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NXB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SSdtIG5vdCBh d2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pi0tPC9kaXY+DQo8ZGl2PkJhbGFqaSBSYWphZ29wYWxhbjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0 OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj5tcGxzICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg JnF1b3Q7R2VvcmdlIFN3YWxsb3cgLVggKHN3YWxsb3cgLSBDTEVBUlBBVEggV09SS0ZPUkNFIE1B TkFHRU1FTlQgSU5DIGF0IENpc2NvKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3YWxsb3dA Y2lzY28uY29tIj5zd2FsbG93QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCAyMiBNYXJjaCAyMDE2IDg6NDEg cG08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtO YWdlbmRyYSBLdW1hciBOYWluYXIgKG5haWt1bWFyKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5haWt1bWFyQGNpc2NvLmNvbSI+bmFpa3VtYXJAY2lzY28uY29tPC9hPiZndDssIExvYSBBbmRl cnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPiZn dDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWt1bWFya2luaS1tcGxzLXNwcmluZy1s c3AtcGluZ0B0b29scy5pZXRmLm9yZyI+ZHJhZnQta3VtYXJraW5pLW1wbHMtc3ByaW5nLWxzcC1w aW5nQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWt1 bWFya2luaS1tcGxzLXNwcmluZy1sc3AtcGluZ0B0b29scy5pZXRmLm9yZyI+ZHJhZnQta3VtYXJr aW5pLW1wbHMtc3ByaW5nLWxzcC1waW5nQHRvb2xzLmlldGYub3JnPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8 L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZyI+bXBs cy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFttcGxzXSBJUFIgcG9sbCBvbiBkcmFmdC1rdW1hcmtp bmktbXBscy1zcHJpbmctbHNwLXBpbmc8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg MCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5JIGFtIGF3YXJlIG9mIG5vIElQUi48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkdlb3JnZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+T24gMy8yMi8xNiwgODo1NyBBTSwgJnF1b3Q7bXBscyBvbiBiZWhhbGYgb2YgTmFnZW5k cmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikmcXVvdDs8L2Rpdj4NCjxkaXY+Jmx0OzxhIGhyZWY9 Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT4g b24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86bmFpa3VtYXJAY2lzY28uY29tIj5uYWlrdW1h ckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXY+SGkgTG9hLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbSBu b3QgYXdhcmUgb2YgYW55IElQUi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5r cyw8L2Rpdj4NCjxkaXY+TmFnZW5kcmE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9u IDMvMjIvMTYsIDg6MjggQU0sICZxdW90O0xvYSBBbmRlcnNzb24mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAg MCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj5Xb3JraW5nIEdyb3VwLDwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGF1dGhvcnMgb2YgZHJhZnQta3VtYXJraW5pLW1wbHMtc3By aW5nLWxzcC1waW5nIGhhcyB0b2xkIHVzIHRoYXQ8L2Rpdj4NCjxkaXY+dGhlIGRvY3VtZW50IGlz IHJlYWR5IHRvIGJlIGNvbnNpZGVyZWQgZm9yIHdvcmtpbmcgYWRvcHRpb24uPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZG9jdW1lbnQgYmVlbiB0aHJvdWdoIE1QTFMtUlQgcmV2 aWV3LiBXZSB3aWxsIGRvIGFuIElQUiBwb2xsPC9kaXY+DQo8ZGl2PnByaW9yIHRvIHRoZSBzdGFy dCBvZiB0aGUgYWRvcHRpb24gcG9sbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo aXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1rdW1hcmtp bmktbXBscy1zcHJpbmctPC9kaXY+DQo8ZGl2PmxzcC1waW5nPzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlh bmNlIHdpdGggSUVURiBJUFIgcnVsZXM8L2Rpdj4NCjxkaXY+KHNlZSBSRkNzIDM5NzksIDQ4Nzks IDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmUgZmlsZWQgZGlyZWN0bHkgYWdhaW5z dCB0aGlzIGRvY3VtZW50LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgeW91IGFy ZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3Bv bmQgdG88L2Rpdj4NCjxkaXY+dGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90 IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50PC9kaXY+DQo8ZGl2PklQUi4gKlRoZSByZXNw b25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZTwv ZGl2Pg0KPGRpdj5kb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVu dGlsIGEgcmVzcG9uc2UgaGFzIGJlZW48L2Rpdj4NCjxkaXY+cmVjZWl2ZWQgZnJvbSBlYWNoIGF1 dGhvciBhbmQgY29udHJpYnV0b3IuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB5 b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu IGF1dGhvciBvcjwvZGl2Pg0KPGRpdj5jb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRs eSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnk8L2Rpdj4NCjxkaXY+SVBSIHRo YXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1 bGVzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi9M b2E8L2Rpdj4NCjxkaXY+bXBscyB3ZyBjby1jaGFpcjwvZGl2Pg0KPGRpdj4tLSA8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Mb2EgQW5kZXJzc29uJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpsb2FAbWFp bDAxLmh1YXdlaS5jb20iPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjwvZGl2Pg0KPGRpdj5T ZW5pb3IgTVBMUyBFeHBlcnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+PC9kaXY+DQo8ZGl2Pkh1 YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBo b25lOiAmIzQzOzQ2IDczOSA4MSAyMSA2NDwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L2Rpdj4NCjxkaXY+bXBscyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+PGEgaHJlZj0i bWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+bXBscyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxk aXY+PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+PC9kaXY+ DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3350FF52A4F7balajirjunipernet_-- From nobody Thu Apr 14 02:31:40 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4175C12D61D; Thu, 14 Apr 2016 02:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIbYPwLJAxUH; Thu, 14 Apr 2016 02:31:36 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61ECA12D619; Thu, 14 Apr 2016 02:31:36 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n3so116970482wmn.0; Thu, 14 Apr 2016 02:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hbEnJweM1pN89JA5RGjVa2ZI3SOTNwr6BeNHZl+FBeY=; b=GBw288Bi4Y+ESyqv67XjcOBL7jftJRPbtnpx4QRe4iat+WnwzzP3MeQbC1oOtFPKae Op75nqFDKdN+GYxlD81x3Lsaq3V9nK02/52CdD6qEcM5bDSlppxj+scvscZKWzgnL7pU Pn6tjKgAb+WKDroWbtLqaiL4SvvPux2KMEknpwGerkb4mE2hOTKjsKTNgERw1Rl9o2MF FNj8FuGNk+iREF1/Q44RLkOKx35LHyF0WwoV1/yO+mpcQV1VybXaSld41WWmovWK7HGQ VY1tVfiIIUIIVEJ6SVZTEXQGObu/gSBjHuVDNjp53IM5lB+/tXyOYVSXFbT33BUuWGF+ FVXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hbEnJweM1pN89JA5RGjVa2ZI3SOTNwr6BeNHZl+FBeY=; b=HmqnGZXsZBaarKeBiXEeq8bX+8ASzALIcNzAUd+B3iZygFZdrHqkHZ+WoM9t5sCsqx LOCSxY6HlSJhtL94x/50VyiX0YyZesUDlOPg7y2NgMqJuWtfv5tJA/7ijcqy+0PFLJUT 6MtUOBiRSkCsViRy5pOMrVZ6u7POH/USkxD6X6WyLf9Tbt/+sBuf4O5DpEvJqEMHTBb1 TcdAYRZ4SWX0Sdsg41URDBG7tXACm6n8JqRjd1+OLiCdBnRPn71VkTJDI24UFNoUC8Qw sWYTukDSiCS5U8UnjpRxRETppM9CmVs3kE2BtyRPwcfrQM1n5vtSmTyEv23prke0FL9e 4vMA== X-Gm-Message-State: AD7BkJK+l+CGu4Q4radaCUJXYsGww6M/9SWpCygMF2gGsQVbjy+hjPxjwBdQafcLyhyftw== X-Received: by 10.28.50.133 with SMTP id y127mr34982077wmy.4.1460626294935; Thu, 14 Apr 2016 02:31:34 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id a73sm5581617wme.2.2016.04.14.02.31.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 02:31:33 -0700 (PDT) To: Eric C Rosen , Alexander Vainshtein , Greg Mirsky References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> From: Stewart Bryant Message-ID: <570F6374.6030406@gmail.com> Date: Thu, 14 Apr 2016 10:31:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <570BB266.8090608@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 09:31:38 -0000 I am not sure zero is PW so much as "type undefined - don't ECMP". That was certainly the definition that we were talking about at the time. The nibble value is recorded in the IP types registry and any wish to take another value really needs to be discussed with the INT area. Also the code space is so small that we really need to be super conservative in its allocation. Given it's true purpose, I suggest that we only have the unused deprecated values of 0 (taken), 1 (taken), 2, 3 and possibly 5 available for use (for ever). Seven and up really should be kept available to the IP protocol itself. Five of course was deployed. It was used for some form of streaming protocol, but it is probably safe to assume that it is no longer in the wild. Whilst Eric makes a case for 5, I think there is also a strong case for zero. If there is a need for subtyping zero for wireshark etc, we could take a look at what the use is made of the second nibble in PWs and see if there is a set of values never in practise used and thus available for subtyping. - Stewart On 11/04/2016 15:19, Eric C Rosen wrote: > (Removed sfc from the cc-list, this seems out of scope for that WG.) > > In designing the BIER header, the BIER WG is free to mandate any value > it chooses in the first nibble. These values do not come from a > "first nibble" registry. > > It seems prudent to put a value like 5 for the following reasons: > > - If a BIER packet is being parsed by an off-line tool, this is a good > hint (though just a hint) that the packet is actually a BIER packet; > > - If a BIER packet is traveling through an MPLS tunnel, and it > traverses a node that does its MPLS load splitting by guessing at the > type of the payload, then this is a good hint that the MPLS payload > is not IPv4, IPv6, or PW. > > This strategy does incur a risk. Suppose IPv5 gets designed, > implemented, and deployed, and folks start to deploy hardware that > does MPLS load balancing by inspecting the IPv5 headers of the MPLS > payloads. If a BIER packet is traversing an MPLS tunnel, > inappropriate load splitting may occur if the hardware thinks the > payload is IPv5 rather than BIER. > > This particular risk doesn't seem very significant to me. > > Thus I don't think there's anything here that needs fixing. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 14 03:06:49 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B9412E1FE; Thu, 14 Apr 2016 03:06:37 -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=eci365.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 rZDJBSPkBz24; Thu, 14 Apr 2016 03:06:34 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::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 5EAB012E20D; Thu, 14 Apr 2016 03:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mx+CIL3OZ0aPPT4plrWDbDNguzaTke9JSY+MpUADYjw=; b=TRo+1iAH/SQgtb/y/UshnJkJr6PPZDy9LKbU0ghkHWnz2fvjJ0EDrbDa/0dB6fwhgMdIwbDl4Im+1/mIHJMtheWR4JGjMvqR+S0RQYnBSJxqtqIXoAoVydUIZ/A1l5orUjx4hkVBh2zVs4ssN2DdvvO8h2IU6i3Vr482Z+678KE= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 14 Apr 2016 10:06:12 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0466.020; Thu, 14 Apr 2016 10:06:12 +0000 From: Alexander Vainshtein To: Stewart Bryant Thread-Topic: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRljBxDa8CpN5y/0moBrflyXhalp+JOvXg Date: Thu, 14 Apr 2016 10:06:12 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> In-Reply-To: <570F6374.6030406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: f90efde3-2a17-4a35-f8e2-08d3644c6895 x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:a88wUwAwbMkvjIlLWerZ90PmLg2sGDpt0SD8NLQJzBtKEtSOvhgZ87z0LDUJ7kAvVuMQQuYXUkbjPAgjYVx/rXY3lSM4uek+cw5zUK1sCotaL6DY9uKxwQqRhvcydIu2LQ6PEhhg895ZI0DmKuTfgh7PSh/TeLNBnd/4SX0a3QPNIIBlpF005w/GSRb9ruLC; 24:La0Lxnpw+f+HJkKYVhYJsgWQDc016+K4JBv8Lsfi1vQAzPF6cKg2H7mCo3TvxSfSSN/eIaNyH/YqiYRjaksjzkwcCE7nNN4Bv2ZoHrL+Q5c=; 7:ZQs4E4HtATLyBvsrFY6f5zNRG8LDXMMFJZaqG2Q55f/Mlw44HCcE34Ny2avsFMQMQ6d7Qdp1MT2A5lpy76KH58D3YLXklHY6XEaanNV1pQF93/tdVJgiEbFd5NlbeiJ/raO7zQOUC1pK08i6CSo74pOhmzRI2zFyyIi4tUAQBvkqb9R852Upxy2JGHYKKvxI7VnPomh0CdeyfZEdtxGL13CA532PpWa8QufwupFzSt8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; 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)(6055026); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(252514010)(24454002)(5002640100001)(87936001)(122556002)(81166005)(15975445007)(74316001)(11100500001)(5003600100002)(2950100001)(92566002)(93886004)(5008740100001)(2900100001)(106116001)(9686002)(10400500002)(66066001)(86362001)(4326007)(189998001)(110136002)(3660700001)(76576001)(1220700001)(102836003)(76176999)(6116002)(3846002)(33656002)(3280700002)(77096005)(5004730100002)(19580405001)(19580395003)(50986999)(54356999)(586003)(2906002)(1096002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.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: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 10:06:12.2916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:06:37 -0000 Stewart and all, I concur with Stewart that there is a strong case for 0 in the first nibble= for all non-IP flows. As for the need for sub-typing:=20 AFAIK quite a few implementations (including some HW-based packet processor= s) treat 0 in the first nibble after the label stack as an indication of an= Ethernet PW. Some of them go as far as to hash on the assumed L2 headers for ECMP. This = causes serious problems, e.g., with the TDM PWs that could be reordered if = handled by such packet processors in transit LSRs. This makes quite a case for sub-typing IMO regardless of BIER. At the same time, it seems that all the bits in CW structure are used - at = least for some PW types in some cases. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Stewart Bryant [mailto:stewart.bryant@gmail.com]=20 Sent: Thursday, April 14, 2016 12:32 PM To: Eric C Rosen; Alexander Vainshtein; Greg Mirsky Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encap= sulation I am not sure zero is PW so much as "type undefined - don't ECMP". That was certainly the definition that we were talking about at the time. The nibble value is recorded in the IP types registry and any wish to take= another value really needs to be discussed with the INT area. Also the code space is so small that we really need to be super conservativ= e in its allocation. Given it's true purpose, I suggest that we only have t= he unused deprecated values of 0 (taken), 1 (taken), 2, 3 and possibly 5 av= ailable for use (for ever). Seven and up really should be kept available to the IP protocol itself. Five of course was deployed. It was used for some form of streaming protoco= l, but it is probably safe to assume that it is no longer in the wild. Whilst Eric makes a case for 5, I think there is also a strong case for zer= o. If there is a need for subtyping zero for wireshark etc, we could take a lo= ok at what the use is made of the second nibble in PWs and see if there is = a set of values never in practise used and thus available for subtyping. - Stewart On 11/04/2016 15:19, Eric C Rosen wrote: > (Removed sfc from the cc-list, this seems out of scope for that WG.) > > In designing the BIER header, the BIER WG is free to mandate any value=20 > it chooses in the first nibble. These values do not come from a=20 > "first nibble" registry. > > It seems prudent to put a value like 5 for the following reasons: > > - If a BIER packet is being parsed by an off-line tool, this is a good=20 > hint (though just a hint) that the packet is actually a BIER packet; > > - If a BIER packet is traveling through an MPLS tunnel, and it=20 > traverses a node that does its MPLS load splitting by guessing at the=20 > type of the payload, then this is a good hint that the MPLS payload=20 > is not IPv4, IPv6, or PW. > > This strategy does incur a risk. Suppose IPv5 gets designed,=20 > implemented, and deployed, and folks start to deploy hardware that=20 > does MPLS load balancing by inspecting the IPv5 headers of the MPLS=20 > payloads. If a BIER packet is traversing an MPLS tunnel,=20 > inappropriate load splitting may occur if the hardware thinks the=20 > payload is IPv5 rather than BIER. > > This particular risk doesn't seem very significant to me. > > Thus I don't think there's anything here that needs fixing. > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 14 03:56:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2358C12DEE6; Thu, 14 Apr 2016 03:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, 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 bxDLwSQ9fS3H; Thu, 14 Apr 2016 03:56:16 -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 0FA9112DF46; Thu, 14 Apr 2016 03:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25590; q=dns/txt; s=iport; t=1460631375; x=1461840975; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=DWbnyvTKfjdlPak3ShgW/j/4Bdovdpkxzcyse/gyzvQ=; b=F/W/i0vVdQNDlFS43M27T0QjgXBJMvjcrHwzpGFGu383CJjjH3TCzpLH 0o1SS41/bVt/8wLrYyYr2ETgZKf1hPjveUyAnGaXGCTNUu7Y7zgkYdq/E AJoNymFOG4NOsqo/zlOLVjYSBf+WRBoXUln7G+VC4T0i9xeGfGh8PcOVs 0=; X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208,217";a="635179379" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 10:56:13 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3EAuCM7018643; Thu, 14 Apr 2016 10:56:12 GMT To: Liaison Statement Management Tool , ietf@wjcerveny.com, joelja@bogus.com, adrian@olddog.co.uk, rcallon@juniper.net, ietf@trammell.ch, swallow.ietf@gmail.com, bill.wu@huawei.com, loa@pi.nu References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <570F774B.1080907@cisco.com> Date: Thu, 14 Apr 2016 12:56:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080402020209000801080607" Archived-At: Cc: L3VPN Service Model Discussion List , Multiprotocol Label Switching Discussion List , IP Performance Metrics Discussion List , Bill Bjorkman , Nan Chen , Martin Stiemerling , The IETF Chair , Spencer Dawkins , rraghu@ciena.com Subject: Re: [mpls] New Liaison Statement, "Liaison from MEF on IP Service Attributes" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 10:56:20 -0000 This is a multi-part message in MIME format. --------------080402020209000801080607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, The L3SM, IPPM, MPLS, and the OPS Area would like to thank the MEF for informing us of your effort on IP Service Attributes [1]. We're pleased that you mentioned the L3VPN service model (L3SM) work in your liaison. The L3SM work covers an abstracted view of the Layer 3 IPVPN service configuration components, with its "YANG Data Model for L3VPN service delivery" [2] deliverable. From your liaison statement, we read "In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a service and the customer of that service." You will be glad to hear that we use the same definition in our L3SM work. As such, the MEF initiative on IP service attributes clearly relates to L3SM. The L3SM chairs and working group have examined the proposed scope of the initial phase of the MEF IP Service Attributes project: -Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs -IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs -OAM across the external interface (by reference to IETF protocols and mechanisms) -Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions) -Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols. -Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc. -IPv4, IPv6 and dual stack services -Inter-operator IP-VPN services using options A, B or C from RFC4364 -Unicast only (multicast is defered to a future phase). -Other topics may be added as the project progresses. The L3SM work already covers most of the items in this list, including multicast. However, we should observe that: 1. L3SM has initially focused on the interface between the customer and the service provider, not the interface between services providers or between service provider domains. The current service model supports the configuration of the RFC 4364 option A (as this is a subset of the existing site model), and we're considering whether to add option B and C. 2. The L3SM work does not cover either the Service Level Specification definitions or the Lifecycle Service Orchestration as described in the MEF Lifecycle Service Orchestration (LSO) Reference Architecture & Framework. The L3SM work started about a year ago and is in the final stage of standardization. Therefore, we would encourage anyone who is interested to review and provide feedback on the future standard by sending a message to the L3SM mailing list as soon as possible (details at [3]). Please keep us informed of any gaps you identify that are needed to satisfy the requirements in your specifications, without the need for a formal liaison. I hope you will agree that it is important to not duplicate work within standardization. Therefore, I hope you will work to produce extensions to the L3SM YANG model for additional features such as the Service Level Specification, and will not repeat any of the function already provided by that model. If you need further information, don't hesitate to contact us. We are always available for further discussions or conference calls regarding the L3SM specifications content. Regards, Benoit Claise (OPS Area Director) [1] https://datatracker.ietf.org/liaison/1458/ [2] https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ [3] https://datatracker.ietf.org/wg/l3sm/charter/ > Title: Liaison from MEF on IP Service Attributes > Submission Date: 2016-02-26 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1458/ > > From: "Raghu Ranganathan" > To: bclaise@cisco.com, joelja@bogus.com, ietf@trammell.ch>, ietf@wjcerveny.com, loa@pi.nu, swallow.ietf@gmail.com, rcallon@juniper.net, adrian@olddog.co.uk, bill.wu@huawei.com > Cc: Alvaro Retana ,Joel Jaeggli ,Deborah Brungard ,IP Performance Metrics Discussion List ,Multiprotocol Label Switching Discussion List ,Adrian Farrel ,Qin Wu ,Bill Cerveny ,Brian Trammell ,Spencer Dawkins ,George Swallow ,Alia Atlas ,The IETF Chair ,Nan Chen ,Ross Callon ,Loa Andersson ,Benoit Claise ,L3VPN Service Model Discussion List ,Bill Bjorkman ,Martin Stiemerling ,Raghu Ranganathan , > Response Contacts: rraghu@ciena.com > Technical Contacts: > Purpose: For information > > Body: We would like to inform you that during our 1Q2016 meeting, MEF has approved a new project on IP Service Attributes. We have set out some background and further details below. > > MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF 6.2, MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 and MEF 26.1). In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a serviceand the customer of that service. These attributes are independent of how the service is implemented; for example a CE service could be > implemented using Provider Backbone Bridging (802.1Q) or using VPLS (RFC 4761/4762) to provide the connectivity across the service provider's network. MEF defines both end-to-end services agreed between a subscriber and a service provider, where the end points are all User-Network Interfaces (UNIs), and inter-provider services supplied by one service provider or operator to another, where the end points may be UNIs or External Network-Network Interfaces (ENNIs). > > Note that this differs from how the word "service" is sometimes used in IETF, e.g. to describe a particular technology (as in "Virtual Private LAN Service"). > > Although IP Services are widely deployed, there is currently no standard definition of the attributes and values used to describe them. Each Service Provider has their own way of describing IP services (including in some cases their own terminology); this makes it hard for customers to compare service offerings from different providers, and in particular makes it hard for providers to interconnect with each other – each Service Provider must form a specific bilateral agreement with each other Service Provider they wish to connect with. > > Furthermore, there is a desire among service providers to improve service delivery times by automating the service ordering and configuration process. This is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim of MEF LSO is to deliver the MEF Third Network vision, to provide Assured, Agile and Orchestrated services. MEF LSO enables automation and orchestration of service ordering and management between service providers ("East/West interfaces") through the creation of standard data models and APIs. However, a pre-requisite for defining those is to have a standard definition of the service that is to be managed. > > The new project is intended to address these issues by providing a standard definition of IP Services, including both end-to-end services and inter-provider services, through the definition of a standard set of Service Attributes that can be used in each case. The scope is limited to IP-VPN and Internet Access services (IP peering/transit for internet traffic is precluded). It is intended that this project is the first step in enabling multi-operator service orchestration of IP Services using MEF LSO, and that later projects will use the Service Attributes to create standard data models and APIs. The intent of LSO is to provide a common framework across different service technologies; MEF is working with TMF and ONF to create common models for services, and the standard data models and APIs for IP Services will tie into this framework. > > We have noted that IETF is working on a Yang model for Layer 3 Services in the L3SM working group. Although the scope of that project in IETF is different, it is clear there is some synergy between the L3SM work and this MEF project. We believe that both projects can benefit from input from each other and we hope to work closely with the L3SM working group to ensure our specifications are aligned. > > The scope of the initial phase of the IP Service Attributes project includes: > -Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs > -IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs > -OAM across the external interface (by reference to IETF protocols and mechanisms) > -Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions) > -Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols. > -Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc. > -IPv4, IPv6 and dual stack services > -Inter-operator IP-VPN services using options A, B or C from RFC4364 > -Unicast only (multicast is defered to a future phase). > -Other topics may be added as the project progresses. > > It is important to note that we intend to make extensive reference to existing IETF RFCs where applicable; it is not our intent to specify new protocols or mechanisms where there are existing solutions. > > Note: further information about MEF LSO can be found in the LSO Reference Architecture. The final verison is expected to be published in March; in the meantime, the latest approved draft is available as below: > https://mef.net/liaison-login > Username: mef > Attachments: > > Liaison > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-02-26-mef-ippm-mpls-l3sm-ops-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf > > . > --------------080402020209000801080607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

The L3SM, IPPM, MPLS, and the OPS Area would like to thank the MEF for informing us of your effort on IP Service Attributes  [1].

We're pleased that you mentioned the L3VPN service model (L3SM) work in your liaison. The L3SM work covers an abstracted view of the Layer 3 IPVPN service configuration components, with its "YANG Data Model for L3VPN service delivery" [2] deliverable.

From your liaison statement, we read "In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a service and the customer of that service." You will be glad to hear that we use the same definition in our L3SM work. As such, the MEF initiative on IP service attributes clearly relates to L3SM.

The L3SM chairs and working group have examined the proposed scope of the initial phase of the MEF IP Service Attributes project:
-Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs
-IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
-OAM across the external interface (by reference to IETF protocols and
mechanisms)
-Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions)
-Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols.
-Multi-CoS services (i.e. QoS classification) and classification of
Green/Yellow packets including diffserv, Bandwidth profiles, etc.
-IPv4, IPv6 and dual stack services
-Inter-operator IP-VPN services using options A, B or C from RFC4364
-Unicast only (multicast is defered to a future phase).
-Other topics may be added as the project progresses.

The L3SM work already covers most of the items in this list, including multicast.  However, we should observe that:
1.  L3SM has initially focused on the interface between the customer and the service provider, not the interface between services providers or between service provider domains. The current service model supports the configuration of the RFC 4364 option A (as this is a subset of the existing site model), and we're considering whether to add option B and C.
2.  The L3SM work does not cover either the Service Level Specification definitions or the Lifecycle Service Orchestration as described in the MEF Lifecycle Service Orchestration (LSO) Reference Architecture & Framework.

The L3SM work started about a year ago and is in the final stage of standardization. Therefore, we would encourage anyone who is interested to review and provide feedback on the future standard by sending a message to the L3SM mailing list as soon as possible (details at [3]). Please keep us informed of any gaps you identify that are needed to satisfy the requirements in your specifications, without the need for a formal liaison.

I hope you will agree that it is important to not duplicate work within standardization. Therefore, I hope you will work to produce extensions to the L3SM YANG model for additional features such as the Service Level Specification, and will not repeat any of the function already provided by that model. If you need further information, don't hesitate to contact us. We are always available for further discussions or conference calls regarding the L3SM specifications content.

Regards, Benoit Claise (OPS Area Director)

[1] https://datatracker.ietf.org/liaison/1458/
[2] https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/
[3] https://datatracker.ietf.org/wg/l3sm/charter/



Title: Liaison from MEF on IP Service Attributes
Submission Date: 2016-02-26
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1458/

From: "Raghu Ranganathan" <rraghu@ciena.com>
To: bclaise@cisco.com, joelja@bogus.com, ietf@trammell.ch>, ietf@wjcerveny.com, loa@pi.nu, swallow.ietf@gmail.com, rcallon@juniper.net, adrian@olddog.co.uk, bill.wu@huawei.com
Cc: Alvaro Retana <aretana@cisco.com>,Joel Jaeggli <joelja@bogus.com>,Deborah Brungard <db3546@att.com>,IP Performance Metrics Discussion List <ippm@ietf.org>,Multiprotocol Label Switching Discussion List <mpls@ietf.org>,Adrian Farrel <adrian@olddog.co.uk>,Qin Wu <bill.wu@huawei.com>,Bill Cerveny <ietf@wjcerveny.com>,Brian Trammell <iet
f@trammell.ch>,Spencer Dawkins <spencerdawkins.ietf@gmail.com>,George Swallow <swallow.ietf@gmail.com>,Alia Atlas <akatlas@gmail.com>,The IETF Chair <chair@ietf.org>,Nan Chen <nan@metroethernetforum.org>,Ross Callon <rcallon@juniper.net>,Loa Andersson <loa@pi.nu>,Benoit Claise <bclaise@cisco.com>,L3VPN Service Model  Discussion List <l3sm@ietf.org>,Bill Bjorkman <bill@metroethernetforum.net>,Martin Stiemerling <mls.ietf@gmail.com>,Raghu Ranganathan <rraghu@ciena.com>,
Response Contacts: rraghu@ciena.com
Technical Contacts: 
Purpose: For information

Body: We would like to inform you that during our 1Q2016 meeting, MEF has approved a new project on IP Service Attributes. We have set out some background and further details below.

MEF is well known for the definition of Carrier Ethernet (CE) services (in MEF 6.2, MEF 33 and MEF 51) based on service attributes (defined in MEF 10.3 and MEF 26.1). In MEF terms, a "service" refers to the set of attributes and their values that are agreed between the provider of a serviceand the customer of that service. These attributes are independent of how the service is implemented; for example a CE service could be
implemented using Provider Backbone Bridging (802.1Q) or using VPLS (RFC 4761/4762) to provide the connectivity across the service provider's network. MEF defines both end-to-end services agreed between a subscriber and a service provider, where the end points are all User-Network Interfaces (UNIs), and inter-provider services supplied by one service provider or operator to another, where the end points may be UNIs or External Network-Network Interfaces (ENNIs).

Note that this differs from how the word "service" is sometimes used in IETF, e.g. to describe a particular technology (as in "Virtual Private LAN Service").

Although IP Services are widely deployed, there is currently no standard definition of the attributes and values used to describe them. Each Service Provider has their own way of describing IP services (including in some cases their own terminology); this makes it hard for customers to compare service offerings from different providers, and in particular makes it hard for providers to interconnect with each other – each Service Provider must form a specific bilateral agreement with each other Service Provider they wish to connect with.

Furthermore, there is a desire among service providers to improve service delivery times by automating the service ordering and configuration process. This is a key aspect of MEF Lifecycle Services Orchestration (LSO). The aim of MEF LSO is to deliver the MEF Third Network vision, to provide Assured, Agile and Orchestrated services. MEF LSO enables automation and orchestration of service ordering and management between service providers ("East/West interfaces") through the creation of standard data models and APIs. However, a pre-requisite for defining those is to have a standard definition of the service that is to be managed.

The new project is intended to address these issues by providing a standard definition of IP Services, including both end-to-end services and inter-provider services, through the definition of a standard set of Service Attributes that can be used in each case. The scope is limited to IP-VPN and Internet Access services  (IP peering/transit for internet traffic is precluded). It is intended that this project is the first step in enabling multi-operator service orchestration of IP Services using MEF LSO, and that later projects will use the Service Attributes to create standard data models and APIs. The intent of LSO is to provide a common framework across different service technologies; MEF is working with TMF and ONF to create common models for services, and the standard data models and APIs for IP Services will tie into this framework.

We have noted that IETF is working on a Yang model for Layer 3 Services in the L3SM working group. Although the scope of that project in IETF is different, it is clear there is some synergy between the L3SM work and this MEF project. We believe that both projects can benefit from input from each other and we hope to work closely with the L3SM working group to ensure our specifications are aligned.

The scope of the initial phase of the IP Service Attributes project includes:
-Definition of attributes for IP-capable UNIs and NNIs, for IP Service connections, and for IP Service End Points at UNIs and ENNIs
-IP address allocations and IP control protocols (e.g. DHCP) etc at UNIs
-OAM across the external interface (by reference to IETF protocols and mechanisms)
-Service Level Specification (SLS) definitions including performance monitoring/constraints (by reference to IETF protocols and metric definitions)
-Redundant links at an external interface (Subscriber/Service provider or between Service Providers), including options for different routing protocols.
-Multi-CoS services (i.e. QoS classification) and classification of Green/Yellow packets including diffserv, Bandwidth profiles, etc.
-IPv4, IPv6 and dual stack services
-Inter-operator IP-VPN services using options A, B or C from RFC4364
-Unicast only (multicast is defered to a future phase).
-Other topics may be added as the project progresses.

It is important to note that we intend to make extensive reference to existing IETF RFCs where applicable; it is not our intent to specify new protocols or mechanisms where there are existing solutions.

Note: further information about MEF LSO can be found in the LSO Reference Architecture. The final verison is expected to be published in March; in the meantime, the latest approved draft is available as below:
https://mef.net/liaison-login
Username: mef
Attachments:

    Liaison
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-02-26-mef-ippm-mpls-l3sm-ops-liaison-from-mef-on-ip-service-attributes-attachment-1.pdf

.

--------------080402020209000801080607-- From nobody Thu Apr 14 04:06:37 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6405A12DC71; Thu, 14 Apr 2016 04:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 C4yGloXSh3kG; Thu, 14 Apr 2016 04:06:33 -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 EDC6012DBEF; Thu, 14 Apr 2016 04:06:32 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 214B81802C2F; Thu, 14 Apr 2016 13:06:29 +0200 (CEST) To: Alexander Vainshtein , Stewart Bryant References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> From: Loa Andersson Message-ID: <570F79AB.9070107@pi.nu> Date: Thu, 14 Apr 2016 19:06:19 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 11:06:35 -0000 Sasha and Stewart, On 2016-04-14 18:06, Alexander Vainshtein wrote: > Stewart and all, > I concur with Stewart that there is a strong case for 0 in the first nibble for all non-IP flows. While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: It is REQUIRED, however, that applications depend upon in-order packet delivery restrict the first nibble values to 0x0 and 0x1. If that is what we want for bier, there is a case to use 0x0 or 0x1 for bier- /Loa > > As for the need for sub-typing: > AFAIK quite a few implementations (including some HW-based packet processors) treat 0 in the first nibble after the label stack as an indication of an Ethernet PW. > > Some of them go as far as to hash on the assumed L2 headers for ECMP. This causes serious problems, e.g., with the TDM PWs that could be reordered if handled by such packet processors in transit LSRs. > > This makes quite a case for sub-typing IMO regardless of BIER. > At the same time, it seems that all the bits in CW structure are used - at least for some PW types in some cases. > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: Stewart Bryant [mailto:stewart.bryant@gmail.com] > Sent: Thursday, April 14, 2016 12:32 PM > To: Eric C Rosen; Alexander Vainshtein; Greg Mirsky > Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda > Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation > > I am not sure zero is PW so much as "type undefined - don't ECMP". > That was certainly the definition that we were talking about at the time. > > The nibble value is recorded in the IP types registry and any wish to take another value really needs to be discussed with the INT area. > > Also the code space is so small that we really need to be super conservative in its allocation. Given it's true purpose, I suggest that we only have the unused deprecated values of 0 (taken), 1 (taken), 2, 3 and possibly 5 available for use (for ever). > Seven and up really should be kept available to the IP protocol itself. > > Five of course was deployed. It was used for some form of streaming protocol, but it is probably safe to assume that it is no longer in the wild. > > Whilst Eric makes a case for 5, I think there is also a strong case for zero. > > If there is a need for subtyping zero for wireshark etc, we could take a look at what the use is made of the second nibble in PWs and see if there is a set of values never in practise used and thus available for subtyping. > > - Stewart > > > On 11/04/2016 15:19, Eric C Rosen wrote: >> (Removed sfc from the cc-list, this seems out of scope for that WG.) >> >> In designing the BIER header, the BIER WG is free to mandate any value >> it chooses in the first nibble. These values do not come from a >> "first nibble" registry. >> >> It seems prudent to put a value like 5 for the following reasons: >> >> - If a BIER packet is being parsed by an off-line tool, this is a good >> hint (though just a hint) that the packet is actually a BIER packet; >> >> - If a BIER packet is traveling through an MPLS tunnel, and it >> traverses a node that does its MPLS load splitting by guessing at the >> type of the payload, then this is a good hint that the MPLS payload >> is not IPv4, IPv6, or PW. >> >> This strategy does incur a risk. Suppose IPv5 gets designed, >> implemented, and deployed, and folks start to deploy hardware that >> does MPLS load balancing by inspecting the IPv5 headers of the MPLS >> payloads. If a BIER packet is traversing an MPLS tunnel, >> inappropriate load splitting may occur if the hardware thinks the >> payload is IPv5 rather than BIER. >> >> This particular risk doesn't seem very significant to me. >> >> Thus I don't think there's anything here that needs fixing. >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Thu Apr 14 05:06:38 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B8F12DDCA; Thu, 14 Apr 2016 05:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mZFSw3FKYKZI; Thu, 14 Apr 2016 05:06:31 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 E6F9112DBB6; Thu, 14 Apr 2016 05:06:31 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3EC41pp022486; Thu, 14 Apr 2016 08:06:16 -0400 Received: from vawvcgsie2k1302.ciena.com (lin1-118-36-36.ciena.com [63.118.36.36]) by mx0a-00103a01.pphosted.com with ESMTP id 22aauur0rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Apr 2016 08:06:15 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVCGSIE2K1302.ciena.com (10.4.62.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:06:14 -0400 Received: from ONWVEXCHMB03.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 14 Apr 2016 08:06:13 -0400 From: "Ranganathan, Raghu" To: Benoit Claise , Liaison Statement Management Tool , "ietf@wjcerveny.com" , "joelja@bogus.com" , "adrian@olddog.co.uk" , "rcallon@juniper.net" , "ietf@trammell.ch" , "swallow.ietf@gmail.com" , "bill.wu@huawei.com" , "loa@pi.nu" Date: Thu, 14 Apr 2016 08:06:11 -0400 Thread-Topic: New Liaison Statement, "Liaison from MEF on IP Service Attributes" Thread-Index: AdGWPEUQ+cgXtqgnRCi+qLjmB7N2hwACYRmw Message-ID: <679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3A@ONWVEXCHMB03.ciena.com> References: <20160226180541.18278.30437.idtracker@ietfa.amsl.com> <570F774B.1080907@cisco.com> In-Reply-To: <570F774B.1080907@cisco.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-22258.006 x-tm-as-result: No--48.009100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603180000 definitions=main-1604140173 Archived-At: Cc: L3VPN Service Model Discussion List , Multiprotocol Label Switching Discussion List , IP Performance Metrics Discussion List , Bill Bjorkman , Nan Chen , Martin Stiemerling , The IETF Chair , Spencer Dawkins Subject: Re: [mpls] New Liaison Statement, "Liaison from MEF on IP Service Attributes" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:06:35 -0000 --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVub2l0DQpUaGFua3MuIEkgd2lsbCBwb3N0IHRoaXMgdG8gdGhlIGF0dGVudGlvbiBvZiBvdXIg bWVtYmVycyBmb3IgcmV2aWV3IGR1cmluZyB0aGUgdXBjb21pbmcgUTIgbWVldGluZyBpbiBSb21l LCBJdGFseSAoQXByaWwgMjUtMjgpLg0KLS1SYWdodQ0KDQpGcm9tOiBCZW5vaXQgQ2xhaXNlIFtt YWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTQsIDIwMTYg NTo1NiBBTQ0KVG86IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQgVG9vbDsgaWV0ZkB3amNl cnZlbnkuY29tOyBqb2VsamFAYm9ndXMuY29tOyBhZHJpYW5Ab2xkZG9nLmNvLnVrOyByY2FsbG9u QGp1bmlwZXIubmV0OyBpZXRmQHRyYW1tZWxsLmNoOyBzd2FsbG93LmlldGZAZ21haWwuY29tOyBi aWxsLnd1QGh1YXdlaS5jb207IGxvYUBwaS5udQ0KQ2M6IFJhbmdhbmF0aGFuLCBSYWdodTsgSVAg UGVyZm9ybWFuY2UgTWV0cmljcyBEaXNjdXNzaW9uIExpc3Q7IE11bHRpcHJvdG9jb2wgTGFiZWwg U3dpdGNoaW5nIERpc2N1c3Npb24gTGlzdDsgTmFuIENoZW47IEwzVlBOIFNlcnZpY2UgTW9kZWwg RGlzY3Vzc2lvbiBMaXN0OyBTcGVuY2VyIERhd2tpbnM7IE1hcnRpbiBTdGllbWVybGluZzsgQmls bCBCam9ya21hbjsgQWxpYSBBdGxhczsgVGhlIElFVEYgQ2hhaXI7IERlYm9yYWggQnJ1bmdhcmQ7 IEFsdmFybyBSZXRhbmENClN1YmplY3Q6IFJlOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJMaWFp c29uIGZyb20gTUVGIG9uIElQIFNlcnZpY2UgQXR0cmlidXRlcyINCg0KRGVhciBhbGwsDQoNClRo ZSBMM1NNLCBJUFBNLCBNUExTLCBhbmQgdGhlIE9QUyBBcmVhIHdvdWxkIGxpa2UgdG8gdGhhbmsg dGhlIE1FRiBmb3IgaW5mb3JtaW5nIHVzIG9mIHlvdXIgZWZmb3J0IG9uIElQIFNlcnZpY2UgQXR0 cmlidXRlczxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQ1OC8+ICBbMV0u DQoNCldlJ3JlIHBsZWFzZWQgdGhhdCB5b3UgbWVudGlvbmVkIHRoZSBMM1ZQTiBzZXJ2aWNlIG1v ZGVsIChMM1NNKSB3b3JrIGluIHlvdXIgbGlhaXNvbi4gVGhlIEwzU00gd29yayBjb3ZlcnMgYW4g YWJzdHJhY3RlZCB2aWV3IG9mIHRoZSBMYXllciAzIElQVlBOIHNlcnZpY2UgY29uZmlndXJhdGlv biBjb21wb25lbnRzLCB3aXRoIGl0cyAiWUFORyBEYXRhIE1vZGVsIGZvciBMM1ZQTiBzZXJ2aWNl IGRlbGl2ZXJ5IiBbMl0gZGVsaXZlcmFibGUuDQoNCkZyb20geW91ciBsaWFpc29uIHN0YXRlbWVu dCwgd2UgcmVhZCAiSW4gTUVGIHRlcm1zLCBhICJzZXJ2aWNlIiByZWZlcnMgdG8gdGhlIHNldCBv ZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJldHdlZW4gdGhl IHByb3ZpZGVyIG9mIGEgc2VydmljZSBhbmQgdGhlIGN1c3RvbWVyIG9mIHRoYXQgc2VydmljZS4i IFlvdSB3aWxsIGJlIGdsYWQgdG8gaGVhciB0aGF0IHdlIHVzZSB0aGUgc2FtZSBkZWZpbml0aW9u IGluIG91ciBMM1NNIHdvcmsuIEFzIHN1Y2gsIHRoZSBNRUYgaW5pdGlhdGl2ZSBvbiBJUCBzZXJ2 aWNlIGF0dHJpYnV0ZXMgY2xlYXJseSByZWxhdGVzIHRvIEwzU00uDQoNClRoZSBMM1NNIGNoYWly cyBhbmQgd29ya2luZyBncm91cCBoYXZlIGV4YW1pbmVkIHRoZSBwcm9wb3NlZCBzY29wZSBvZiB0 aGUgaW5pdGlhbCBwaGFzZSBvZiB0aGUgTUVGIElQIFNlcnZpY2UgQXR0cmlidXRlcyBwcm9qZWN0 Og0KLURlZmluaXRpb24gb2YgYXR0cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklz LCBmb3IgSVAgU2VydmljZSBjb25uZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2lu dHMgYXQgVU5JcyBhbmQgRU5OSXMNCi1JUCBhZGRyZXNzIGFsbG9jYXRpb25zIGFuZCBJUCBjb250 cm9sIHByb3RvY29scyAoZS5nLiBESENQKSBldGMgYXQgVU5Jcw0KLU9BTSBhY3Jvc3MgdGhlIGV4 dGVybmFsIGludGVyZmFjZSAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJvdG9jb2xzIGFuZA0KbWVj aGFuaXNtcykNCi1TZXJ2aWNlIExldmVsIFNwZWNpZmljYXRpb24gKFNMUykgZGVmaW5pdGlvbnMg aW5jbHVkaW5nIHBlcmZvcm1hbmNlIG1vbml0b3JpbmcvY29uc3RyYWludHMgKGJ5IHJlZmVyZW5j ZSB0byBJRVRGIHByb3RvY29scyBhbmQgbWV0cmljIGRlZmluaXRpb25zKQ0KLVJlZHVuZGFudCBs aW5rcyBhdCBhbiBleHRlcm5hbCBpbnRlcmZhY2UgKFN1YnNjcmliZXIvU2VydmljZSBwcm92aWRl ciBvciBiZXR3ZWVuIFNlcnZpY2UgUHJvdmlkZXJzKSwgaW5jbHVkaW5nIG9wdGlvbnMgZm9yIGRp ZmZlcmVudCByb3V0aW5nIHByb3RvY29scy4NCi1NdWx0aS1Db1Mgc2VydmljZXMgKGkuZS4gUW9T IGNsYXNzaWZpY2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24gb2YNCkdyZWVuL1llbGxvdyBwYWNr ZXRzIGluY2x1ZGluZyBkaWZmc2VydiwgQmFuZHdpZHRoIHByb2ZpbGVzLCBldGMuDQotSVB2NCwg SVB2NiBhbmQgZHVhbCBzdGFjayBzZXJ2aWNlcw0KLUludGVyLW9wZXJhdG9yIElQLVZQTiBzZXJ2 aWNlcyB1c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQNCi1VbmljYXN0IG9ubHkg KG11bHRpY2FzdCBpcyBkZWZlcmVkIHRvIGEgZnV0dXJlIHBoYXNlKS4NCi1PdGhlciB0b3BpY3Mg bWF5IGJlIGFkZGVkIGFzIHRoZSBwcm9qZWN0IHByb2dyZXNzZXMuDQoNClRoZSBMM1NNIHdvcmsg YWxyZWFkeSBjb3ZlcnMgbW9zdCBvZiB0aGUgaXRlbXMgaW4gdGhpcyBsaXN0LCBpbmNsdWRpbmcg bXVsdGljYXN0LiAgSG93ZXZlciwgd2Ugc2hvdWxkIG9ic2VydmUgdGhhdDoNCjEuICBMM1NNIGhh cyBpbml0aWFsbHkgZm9jdXNlZCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGN1c3RvbWVy IGFuZCB0aGUgc2VydmljZSBwcm92aWRlciwgbm90IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBzZXJ2 aWNlcyBwcm92aWRlcnMgb3IgYmV0d2VlbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbnMuIFRoZSBj dXJyZW50IHNlcnZpY2UgbW9kZWwgc3VwcG9ydHMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFJG QyA0MzY0IG9wdGlvbiBBIChhcyB0aGlzIGlzIGEgc3Vic2V0IG9mIHRoZSBleGlzdGluZyBzaXRl IG1vZGVsKSwgYW5kIHdlJ3JlIGNvbnNpZGVyaW5nIHdoZXRoZXIgdG8gYWRkIG9wdGlvbiBCIGFu ZCBDLg0KMi4gIFRoZSBMM1NNIHdvcmsgZG9lcyBub3QgY292ZXIgZWl0aGVyIHRoZSBTZXJ2aWNl IExldmVsIFNwZWNpZmljYXRpb24gZGVmaW5pdGlvbnMgb3IgdGhlIExpZmVjeWNsZSBTZXJ2aWNl IE9yY2hlc3RyYXRpb24gYXMgZGVzY3JpYmVkIGluIHRoZSBNRUYgTGlmZWN5Y2xlIFNlcnZpY2Ug T3JjaGVzdHJhdGlvbiAoTFNPKSBSZWZlcmVuY2UgQXJjaGl0ZWN0dXJlICYgRnJhbWV3b3JrLg0K DQpUaGUgTDNTTSB3b3JrIHN0YXJ0ZWQgYWJvdXQgYSB5ZWFyIGFnbyBhbmQgaXMgaW4gdGhlIGZp bmFsIHN0YWdlIG9mIHN0YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCB3ZSB3b3VsZCBlbmNvdXJh Z2UgYW55b25lIHdobyBpcyBpbnRlcmVzdGVkIHRvIHJldmlldyBhbmQgcHJvdmlkZSBmZWVkYmFj ayBvbiB0aGUgZnV0dXJlIHN0YW5kYXJkIGJ5IHNlbmRpbmcgYSBtZXNzYWdlIHRvIHRoZSBMM1NN IG1haWxpbmcgbGlzdCBhcyBzb29uIGFzIHBvc3NpYmxlIChkZXRhaWxzIGF0IFszXSkuIFBsZWFz ZSBrZWVwIHVzIGluZm9ybWVkIG9mIGFueSBnYXBzIHlvdSBpZGVudGlmeSB0aGF0IGFyZSBuZWVk ZWQgdG8gc2F0aXNmeSB0aGUgcmVxdWlyZW1lbnRzIGluIHlvdXIgc3BlY2lmaWNhdGlvbnMsIHdp dGhvdXQgdGhlIG5lZWQgZm9yIGEgZm9ybWFsIGxpYWlzb24uDQoNCkkgaG9wZSB5b3Ugd2lsbCBh Z3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBub3QgZHVwbGljYXRlIHdvcmsgd2l0aGluIHN0 YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCBJIGhvcGUgeW91IHdpbGwgd29yayB0byBwcm9kdWNl IGV4dGVuc2lvbnMgdG8gdGhlIEwzU00gWUFORyBtb2RlbCBmb3IgYWRkaXRpb25hbCBmZWF0dXJl cyBzdWNoIGFzIHRoZSBTZXJ2aWNlIExldmVsIFNwZWNpZmljYXRpb24sIGFuZCB3aWxsIG5vdCBy ZXBlYXQgYW55IG9mIHRoZSBmdW5jdGlvbiBhbHJlYWR5IHByb3ZpZGVkIGJ5IHRoYXQgbW9kZWwu IElmIHlvdSBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIGRvbid0IGhlc2l0YXRlIHRvIGNvbnRh Y3QgdXMuIFdlIGFyZSBhbHdheXMgYXZhaWxhYmxlIGZvciBmdXJ0aGVyIGRpc2N1c3Npb25zIG9y IGNvbmZlcmVuY2UgY2FsbHMgcmVnYXJkaW5nIHRoZSBMM1NNIHNwZWNpZmljYXRpb25zIGNvbnRl bnQuDQoNClJlZ2FyZHMsIEJlbm9pdCBDbGFpc2UgKE9QUyBBcmVhIERpcmVjdG9yKQ0KDQpbMV0g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvDQpbMl0gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9k ZWwvDQpbM10gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9sM3NtL2NoYXJ0ZXIvDQoN Cg0KDQpUaXRsZTogTGlhaXNvbiBmcm9tIE1FRiBvbiBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXMNCg0K U3VibWlzc2lvbiBEYXRlOiAyMDE2LTAyLTI2DQoNClVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvDQoNCg0KDQpGcm9tOiAi UmFnaHUgUmFuZ2FuYXRoYW4iIDxycmFnaHVAY2llbmEuY29tPjxtYWlsdG86cnJhZ2h1QGNpZW5h LmNvbT4NCg0KVG86IGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4s IGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+LCBpZXRmQHRyYW1tZWxs LmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj4sIGlldGZAd2pjZXJ2ZW55LmNvbTxtYWlsdG86 aWV0ZkB3amNlcnZlbnkuY29tPiwgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+LCBzd2FsbG93 LmlldGZAZ21haWwuY29tPG1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29tPiwgcmNhbGxvbkBq dW5pcGVyLm5ldDxtYWlsdG86cmNhbGxvbkBqdW5pcGVyLm5ldD4sIGFkcmlhbkBvbGRkb2cuY28u dWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+LCBiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRv OmJpbGwud3VAaHVhd2VpLmNvbT4NCg0KQ2M6IEFsdmFybyBSZXRhbmEgPGFyZXRhbmFAY2lzY28u Y29tPjxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+LEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3Vz LmNvbT48bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+LERlYm9yYWggQnJ1bmdhcmQgPGRiMzU0NkBh dHQuY29tPjxtYWlsdG86ZGIzNTQ2QGF0dC5jb20+LElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgRGlz Y3Vzc2lvbiBMaXN0IDxpcHBtQGlldGYub3JnPjxtYWlsdG86aXBwbUBpZXRmLm9yZz4sTXVsdGlw cm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgRGlzY3Vzc2lvbiBMaXN0IDxtcGxzQGlldGYub3JnPjxt YWlsdG86bXBsc0BpZXRmLm9yZz4sQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az48 bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+LFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPjxt YWlsdG86YmlsbC53dUBodWF3ZWkuY29tPixCaWxsIENlcnZlbnkgPGlldGZAd2pjZXJ2ZW55LmNv bT48bWFpbHRvOmlldGZAd2pjZXJ2ZW55LmNvbT4sQnJpYW4gVHJhbW1lbGwgPGlldDxtYWlsdG86 aWV0ZkB0cmFtbWVsbC5jaD4NCg0KZkB0cmFtbWVsbC5jaD48bWFpbHRvOmlldGZAdHJhbW1lbGwu Y2g+LFNwZW5jZXIgRGF3a2lucyA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PG1haWx0 bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4sR2VvcmdlIFN3YWxsb3cgPHN3YWxsb3cu aWV0ZkBnbWFpbC5jb20+PG1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29tPixBbGlhIEF0bGFz IDxha2F0bGFzQGdtYWlsLmNvbT48bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPixUaGUgSUVURiBD aGFpciA8Y2hhaXJAaWV0Zi5vcmc+PG1haWx0bzpjaGFpckBpZXRmLm9yZz4sTmFuIENoZW4gPG5h bkBtZXRyb2V0aGVybmV0Zm9ydW0ub3JnPjxtYWlsdG86bmFuQG1ldHJvZXRoZXJuZXRmb3J1bS5v cmc+LFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PjxtYWlsdG86cmNhbGxvbkBqdW5p cGVyLm5ldD4sTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PjxtYWlsdG86bG9hQHBpLm51PixCZW5v aXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPixM M1ZQTiBTZXJ2aWNlIE1vZGVsICBEaXNjdXNzaW9uIExpc3QgPGwzc21AaWV0Zi5vcmc+PG1haWx0 bzpsM3NtQGlldGYub3JnPixCaWxsIEJqb3JrbWFuIDxiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5u ZXQ+PG1haWx0bzpiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5uZXQ+LE1hcnRpbiBTdGllbWVybGlu ZyA8bWxzLmlldGZAZ21haWwuY29tPjxtYWlsdG86bWxzLmlldGZAZ21haWwuY29tPixSYWdodSBS YW5nYW5hdGhhbiA8cnJhZ2h1QGNpZW5hLmNvbT48bWFpbHRvOnJyYWdodUBjaWVuYS5jb20+LA0K DQpSZXNwb25zZSBDb250YWN0czogcnJhZ2h1QGNpZW5hLmNvbTxtYWlsdG86cnJhZ2h1QGNpZW5h LmNvbT4NCg0KVGVjaG5pY2FsIENvbnRhY3RzOg0KDQpQdXJwb3NlOiBGb3IgaW5mb3JtYXRpb24N Cg0KDQoNCkJvZHk6IFdlIHdvdWxkIGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IGR1cmluZyBvdXIg MVEyMDE2IG1lZXRpbmcsIE1FRiBoYXMgYXBwcm92ZWQgYSBuZXcgcHJvamVjdCBvbiBJUCBTZXJ2 aWNlIEF0dHJpYnV0ZXMuIFdlIGhhdmUgc2V0IG91dCBzb21lIGJhY2tncm91bmQgYW5kIGZ1cnRo ZXIgZGV0YWlscyBiZWxvdy4NCg0KDQoNCk1FRiBpcyB3ZWxsIGtub3duIGZvciB0aGUgZGVmaW5p dGlvbiBvZiBDYXJyaWVyIEV0aGVybmV0IChDRSkgc2VydmljZXMgKGluIE1FRiA2LjIsIE1FRiAz MyBhbmQgTUVGIDUxKSBiYXNlZCBvbiBzZXJ2aWNlIGF0dHJpYnV0ZXMgKGRlZmluZWQgaW4gTUVG IDEwLjMgYW5kIE1FRiAyNi4xKS4gSW4gTUVGIHRlcm1zLCBhICJzZXJ2aWNlIiByZWZlcnMgdG8g dGhlIHNldCBvZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJl dHdlZW4gdGhlIHByb3ZpZGVyIG9mIGEgc2VydmljZWFuZCB0aGUgY3VzdG9tZXIgb2YgdGhhdCBz ZXJ2aWNlLiBUaGVzZSBhdHRyaWJ1dGVzIGFyZSBpbmRlcGVuZGVudCBvZiBob3cgdGhlIHNlcnZp Y2UgaXMgaW1wbGVtZW50ZWQ7IGZvciBleGFtcGxlIGEgQ0Ugc2VydmljZSBjb3VsZCBiZQ0KDQpp bXBsZW1lbnRlZCB1c2luZyBQcm92aWRlciBCYWNrYm9uZSBCcmlkZ2luZyAoODAyLjFRKSBvciB1 c2luZyBWUExTIChSRkMgNDc2MS80NzYyKSB0byBwcm92aWRlIHRoZSBjb25uZWN0aXZpdHkgYWNy b3NzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4gTUVGIGRlZmluZXMgYm90aCBlbmQt dG8tZW5kIHNlcnZpY2VzIGFncmVlZCBiZXR3ZWVuIGEgc3Vic2NyaWJlciBhbmQgYSBzZXJ2aWNl IHByb3ZpZGVyLCB3aGVyZSB0aGUgZW5kIHBvaW50cyBhcmUgYWxsIFVzZXItTmV0d29yayBJbnRl cmZhY2VzIChVTklzKSwgYW5kIGludGVyLXByb3ZpZGVyIHNlcnZpY2VzIHN1cHBsaWVkIGJ5IG9u ZSBzZXJ2aWNlIHByb3ZpZGVyIG9yIG9wZXJhdG9yIHRvIGFub3RoZXIsIHdoZXJlIHRoZSBlbmQg cG9pbnRzIG1heSBiZSBVTklzIG9yIEV4dGVybmFsIE5ldHdvcmstTmV0d29yayBJbnRlcmZhY2Vz IChFTk5JcykuDQoNCg0KDQpOb3RlIHRoYXQgdGhpcyBkaWZmZXJzIGZyb20gaG93IHRoZSB3b3Jk ICJzZXJ2aWNlIiBpcyBzb21ldGltZXMgdXNlZCBpbiBJRVRGLCBlLmcuIHRvIGRlc2NyaWJlIGEg cGFydGljdWxhciB0ZWNobm9sb2d5IChhcyBpbiAiVmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNl IikuDQoNCg0KDQpBbHRob3VnaCBJUCBTZXJ2aWNlcyBhcmUgd2lkZWx5IGRlcGxveWVkLCB0aGVy ZSBpcyBjdXJyZW50bHkgbm8gc3RhbmRhcmQgZGVmaW5pdGlvbiBvZiB0aGUgYXR0cmlidXRlcyBh bmQgdmFsdWVzIHVzZWQgdG8gZGVzY3JpYmUgdGhlbS4gRWFjaCBTZXJ2aWNlIFByb3ZpZGVyIGhh cyB0aGVpciBvd24gd2F5IG9mIGRlc2NyaWJpbmcgSVAgc2VydmljZXMgKGluY2x1ZGluZyBpbiBz b21lIGNhc2VzIHRoZWlyIG93biB0ZXJtaW5vbG9neSk7IHRoaXMgbWFrZXMgaXQgaGFyZCBmb3Ig Y3VzdG9tZXJzIHRvIGNvbXBhcmUgc2VydmljZSBvZmZlcmluZ3MgZnJvbSBkaWZmZXJlbnQgcHJv dmlkZXJzLCBhbmQgaW4gcGFydGljdWxhciBtYWtlcyBpdCBoYXJkIGZvciBwcm92aWRlcnMgdG8g aW50ZXJjb25uZWN0IHdpdGggZWFjaCBvdGhlciDigJMgZWFjaCBTZXJ2aWNlIFByb3ZpZGVyIG11 c3QgZm9ybSBhIHNwZWNpZmljIGJpbGF0ZXJhbCBhZ3JlZW1lbnQgd2l0aCBlYWNoIG90aGVyIFNl cnZpY2UgUHJvdmlkZXIgdGhleSB3aXNoIHRvIGNvbm5lY3Qgd2l0aC4NCg0KDQoNCkZ1cnRoZXJt b3JlLCB0aGVyZSBpcyBhIGRlc2lyZSBhbW9uZyBzZXJ2aWNlIHByb3ZpZGVycyB0byBpbXByb3Zl IHNlcnZpY2UgZGVsaXZlcnkgdGltZXMgYnkgYXV0b21hdGluZyB0aGUgc2VydmljZSBvcmRlcmlu ZyBhbmQgY29uZmlndXJhdGlvbiBwcm9jZXNzLiBUaGlzIGlzIGEga2V5IGFzcGVjdCBvZiBNRUYg TGlmZWN5Y2xlIFNlcnZpY2VzIE9yY2hlc3RyYXRpb24gKExTTykuIFRoZSBhaW0gb2YgTUVGIExT TyBpcyB0byBkZWxpdmVyIHRoZSBNRUYgVGhpcmQgTmV0d29yayB2aXNpb24sIHRvIHByb3ZpZGUg QXNzdXJlZCwgQWdpbGUgYW5kIE9yY2hlc3RyYXRlZCBzZXJ2aWNlcy4gTUVGIExTTyBlbmFibGVz IGF1dG9tYXRpb24gYW5kIG9yY2hlc3RyYXRpb24gb2Ygc2VydmljZSBvcmRlcmluZyBhbmQgbWFu YWdlbWVudCBiZXR3ZWVuIHNlcnZpY2UgcHJvdmlkZXJzICgiRWFzdC9XZXN0IGludGVyZmFjZXMi KSB0aHJvdWdoIHRoZSBjcmVhdGlvbiBvZiBzdGFuZGFyZCBkYXRhIG1vZGVscyBhbmQgQVBJcy4g SG93ZXZlciwgYSBwcmUtcmVxdWlzaXRlIGZvciBkZWZpbmluZyB0aG9zZSBpcyB0byBoYXZlIGEg c3RhbmRhcmQgZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSB0aGF0IGlzIHRvIGJlIG1hbmFnZWQu DQoNCg0KDQpUaGUgbmV3IHByb2plY3QgaXMgaW50ZW5kZWQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1 ZXMgYnkgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZGVmaW5pdGlvbiBvZiBJUCBTZXJ2aWNlcywgaW5j bHVkaW5nIGJvdGggZW5kLXRvLWVuZCBzZXJ2aWNlcyBhbmQgaW50ZXItcHJvdmlkZXIgc2Vydmlj ZXMsIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2YgYSBzdGFuZGFyZCBzZXQgb2YgU2VydmljZSBB dHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4gZWFjaCBjYXNlLiBUaGUgc2NvcGUgaXMgbGlt aXRlZCB0byBJUC1WUE4gYW5kIEludGVybmV0IEFjY2VzcyBzZXJ2aWNlcyAgKElQIHBlZXJpbmcv dHJhbnNpdCBmb3IgaW50ZXJuZXQgdHJhZmZpYyBpcyBwcmVjbHVkZWQpLiBJdCBpcyBpbnRlbmRl ZCB0aGF0IHRoaXMgcHJvamVjdCBpcyB0aGUgZmlyc3Qgc3RlcCBpbiBlbmFibGluZyBtdWx0aS1v cGVyYXRvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gb2YgSVAgU2VydmljZXMgdXNpbmcgTUVGIExT TywgYW5kIHRoYXQgbGF0ZXIgcHJvamVjdHMgd2lsbCB1c2UgdGhlIFNlcnZpY2UgQXR0cmlidXRl cyB0byBjcmVhdGUgc3RhbmRhcmQgZGF0YSBtb2RlbHMgYW5kIEFQSXMuIFRoZSBpbnRlbnQgb2Yg TFNPIGlzIHRvIHByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGFjcm9zcyBkaWZmZXJlbnQgc2Vy dmljZSB0ZWNobm9sb2dpZXM7IE1FRiBpcyB3b3JraW5nIHdpdGggVE1GIGFuZCBPTkYgdG8gY3Jl YXRlIGNvbW1vbiBtb2RlbHMgZm9yIHNlcnZpY2VzLCBhbmQgdGhlIHN0YW5kYXJkIGRhdGEgbW9k ZWxzIGFuZCBBUElzIGZvciBJUCBTZXJ2aWNlcyB3aWxsIHRpZSBpbnRvIHRoaXMgZnJhbWV3b3Jr Lg0KDQoNCg0KV2UgaGF2ZSBub3RlZCB0aGF0IElFVEYgaXMgd29ya2luZyBvbiBhIFlhbmcgbW9k ZWwgZm9yIExheWVyIDMgU2VydmljZXMgaW4gdGhlIEwzU00gd29ya2luZyBncm91cC4gQWx0aG91 Z2ggdGhlIHNjb3BlIG9mIHRoYXQgcHJvamVjdCBpbiBJRVRGIGlzIGRpZmZlcmVudCwgaXQgaXMg Y2xlYXIgdGhlcmUgaXMgc29tZSBzeW5lcmd5IGJldHdlZW4gdGhlIEwzU00gd29yayBhbmQgdGhp cyBNRUYgcHJvamVjdC4gV2UgYmVsaWV2ZSB0aGF0IGJvdGggcHJvamVjdHMgY2FuIGJlbmVmaXQg ZnJvbSBpbnB1dCBmcm9tIGVhY2ggb3RoZXIgYW5kIHdlIGhvcGUgdG8gd29yayBjbG9zZWx5IHdp dGggdGhlIEwzU00gd29ya2luZyBncm91cCB0byBlbnN1cmUgb3VyIHNwZWNpZmljYXRpb25zIGFy ZSBhbGlnbmVkLg0KDQoNCg0KVGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsIHBoYXNlIG9mIHRoZSBJ UCBTZXJ2aWNlIEF0dHJpYnV0ZXMgcHJvamVjdCBpbmNsdWRlczoNCg0KLURlZmluaXRpb24gb2Yg YXR0cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklzLCBmb3IgSVAgU2VydmljZSBj b25uZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2ludHMgYXQgVU5JcyBhbmQgRU5O SXMNCg0KLUlQIGFkZHJlc3MgYWxsb2NhdGlvbnMgYW5kIElQIGNvbnRyb2wgcHJvdG9jb2xzIChl LmcuIERIQ1ApIGV0YyBhdCBVTklzDQoNCi1PQU0gYWNyb3NzIHRoZSBleHRlcm5hbCBpbnRlcmZh Y2UgKGJ5IHJlZmVyZW5jZSB0byBJRVRGIHByb3RvY29scyBhbmQgbWVjaGFuaXNtcykNCg0KLVNl cnZpY2UgTGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKSBkZWZpbml0aW9ucyBpbmNsdWRpbmcgcGVy Zm9ybWFuY2UgbW9uaXRvcmluZy9jb25zdHJhaW50cyAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJv dG9jb2xzIGFuZCBtZXRyaWMgZGVmaW5pdGlvbnMpDQoNCi1SZWR1bmRhbnQgbGlua3MgYXQgYW4g ZXh0ZXJuYWwgaW50ZXJmYWNlIChTdWJzY3JpYmVyL1NlcnZpY2UgcHJvdmlkZXIgb3IgYmV0d2Vl biBTZXJ2aWNlIFByb3ZpZGVycyksIGluY2x1ZGluZyBvcHRpb25zIGZvciBkaWZmZXJlbnQgcm91 dGluZyBwcm90b2NvbHMuDQoNCi1NdWx0aS1Db1Mgc2VydmljZXMgKGkuZS4gUW9TIGNsYXNzaWZp Y2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24gb2YgR3JlZW4vWWVsbG93IHBhY2tldHMgaW5jbHVk aW5nIGRpZmZzZXJ2LCBCYW5kd2lkdGggcHJvZmlsZXMsIGV0Yy4NCg0KLUlQdjQsIElQdjYgYW5k IGR1YWwgc3RhY2sgc2VydmljZXMNCg0KLUludGVyLW9wZXJhdG9yIElQLVZQTiBzZXJ2aWNlcyB1 c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQNCg0KLVVuaWNhc3Qgb25seSAobXVs dGljYXN0IGlzIGRlZmVyZWQgdG8gYSBmdXR1cmUgcGhhc2UpLg0KDQotT3RoZXIgdG9waWNzIG1h eSBiZSBhZGRlZCBhcyB0aGUgcHJvamVjdCBwcm9ncmVzc2VzLg0KDQoNCg0KSXQgaXMgaW1wb3J0 YW50IHRvIG5vdGUgdGhhdCB3ZSBpbnRlbmQgdG8gbWFrZSBleHRlbnNpdmUgcmVmZXJlbmNlIHRv IGV4aXN0aW5nIElFVEYgUkZDcyB3aGVyZSBhcHBsaWNhYmxlOyBpdCBpcyBub3Qgb3VyIGludGVu dCB0byBzcGVjaWZ5IG5ldyBwcm90b2NvbHMgb3IgbWVjaGFuaXNtcyB3aGVyZSB0aGVyZSBhcmUg ZXhpc3Rpbmcgc29sdXRpb25zLg0KDQoNCg0KTm90ZTogZnVydGhlciBpbmZvcm1hdGlvbiBhYm91 dCBNRUYgTFNPIGNhbiBiZSBmb3VuZCBpbiB0aGUgTFNPIFJlZmVyZW5jZSBBcmNoaXRlY3R1cmUu IFRoZSBmaW5hbCB2ZXJpc29uIGlzIGV4cGVjdGVkIHRvIGJlIHB1Ymxpc2hlZCBpbiBNYXJjaDsg aW4gdGhlIG1lYW50aW1lLCB0aGUgbGF0ZXN0IGFwcHJvdmVkIGRyYWZ0IGlzIGF2YWlsYWJsZSBh cyBiZWxvdzoNCg0KaHR0cHM6Ly9tZWYubmV0L2xpYWlzb24tbG9naW4NCg0KVXNlcm5hbWU6IG1l Zg0KDQpBdHRhY2htZW50czoNCg0KDQoNCiAgICBMaWFpc29uDQoNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9saWIvZHQvZG9jdW1lbnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTAyLTI2LW1lZi1p cHBtLW1wbHMtbDNzbS1vcHMtbGlhaXNvbi1mcm9tLW1lZi1vbi1pcC1zZXJ2aWNlLWF0dHJpYnV0 ZXMtYXR0YWNobWVudC0xLnBkZg0KDQoNCg0KLg0KDQoNCg0K --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPVByb2dJZCBjb250ZW50PVdv cmQuRG9jdW1lbnQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQiPjxtZXRhIG5hbWU9T3JpZ2luYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCI+PGxp bmsgcmVsPUZpbGUtTGlzdCBocmVmPSJjaWQ6ZmlsZWxpc3QueG1sQDAxRDE5NjFDLjIwN0U2NEUw Ij48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQo8 bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxp bmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6R3JhbW1hclN0YXRlPkNsZWFuPC93 OkdyYW1tYXJTdGF0ZT4NCjx3OlRyYWNrTW92ZXMvPg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3 OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1M SW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50 PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRl eHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFG Lz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1l QXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+ WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpE b05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxp dFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNv bXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRo Ii8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1 Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJn aW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJj ZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06 dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48 L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgRGVmU2VtaUhpZGRlbj0idHJ1ZSIgRGVmUUZvcm1hdD0iZmFsc2UiIERlZlBy aW9yaXR5PSI5OSIgTGF0ZW50U3R5bGVDb3VudD0iMjY3Ij4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp bmcgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM1IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJjYXB0aW9uIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBOYW1lPSJEZWZhdWx0 IFBhcmFncmFwaCBGb250Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjExIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIyMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUGxhY2Vob2xkZXIgVGV4dCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFj aW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBH cmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNo YWRpbmcgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBo YXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0 bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIE5hbWU9 IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjwvdzpMYXRlbnRTdHls ZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1m b250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1z aWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJ bXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1z by1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEw NzM3ODYxMTEgMSAwIDQxNSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCglt c28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsN Cgltc28tZm9udC1zaWduYXR1cmU6LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1m YW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVy ZTotNTIwMDkyOTI5IDEwNzM4MDY1OTEgOSAwIDQxNSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHls ZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6 IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRp b246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5v c2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1hc2NpaS1m b250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDb25zb2xhczsNCgltc28tYmlkaS1mb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1s b2NrZWQ6eWVzOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCW1zby1hbnNpLWZv bnQtc2l6ZTo4LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpUYWhvbWE7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6 VGFob21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlRhaG9tYTsNCgljb2xvcjpibGFjazt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVp bjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1h bFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93 YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsN Cgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46 MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3 aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGUgc3R5bGU9J3RhYi1pbnRlcnZhbDouNWlu Jz48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO2NvbG9yOiMxRjQ5N0QnPkJlbm9pdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPlRoYW5rcy4gSSB3aWxsIHBv c3QgdGhpcyB0byB0aGUgYXR0ZW50aW9uIG9mIG91ciBtZW1iZXJzIGZvciByZXZpZXcgZHVyaW5n IHRoZSB1cGNvbWluZyBRMiBtZWV0aW5nIGluIFJvbWUsIEl0YWx5IChBcHJpbCAyNS0yOCkuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7Y29s b3I6IzFGNDk3RCc+LS1SYWdodTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO21zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO2NvbG9yOndp bmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7Y29sb3I6d2luZG93dGV4dCc+IEJlbm9pdCBDbGFpc2UgW21haWx0 bzpiY2xhaXNlQGNpc2NvLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMTQs IDIwMTYgNTo1NiBBTTxicj48Yj5Ubzo8L2I+IExpYWlzb24gU3RhdGVtZW50IE1hbmFnZW1lbnQg VG9vbDsgaWV0ZkB3amNlcnZlbnkuY29tOyBqb2VsamFAYm9ndXMuY29tOyBhZHJpYW5Ab2xkZG9n LmNvLnVrOyByY2FsbG9uQGp1bmlwZXIubmV0OyBpZXRmQHRyYW1tZWxsLmNoOyBzd2FsbG93Lmll dGZAZ21haWwuY29tOyBiaWxsLnd1QGh1YXdlaS5jb207IGxvYUBwaS5udTxicj48Yj5DYzo8L2I+ IFJhbmdhbmF0aGFuLCBSYWdodTsgSVAgUGVyZm9ybWFuY2UgTWV0cmljcyBEaXNjdXNzaW9uIExp c3Q7IE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIERpc2N1c3Npb24gTGlzdDsgTmFuIENo ZW47IEwzVlBOIFNlcnZpY2UgTW9kZWwgRGlzY3Vzc2lvbiBMaXN0OyBTcGVuY2VyIERhd2tpbnM7 IE1hcnRpbiBTdGllbWVybGluZzsgQmlsbCBCam9ya21hbjsgQWxpYSBBdGxhczsgVGhlIElFVEYg Q2hhaXI7IERlYm9yYWggQnJ1bmdhcmQ7IEFsdmFybyBSZXRhbmE8YnI+PGI+U3ViamVjdDo8L2I+ IFJlOiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICZxdW90O0xpYWlzb24gZnJvbSBNRUYgb24gSVAg U2VydmljZSBBdHRyaWJ1dGVzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiInPkRlYXIgYWxsLDxicj48YnI+VGhlIEwzU00sIElQUE0sIE1QTFMsIGFuZCB0aGUgT1BT IEFyZWEgd291bGQgbGlrZSB0byB0aGFuayB0aGUgTUVGIGZvciBpbmZvcm1pbmcgdXMgb2YgeW91 ciBlZmZvcnQgb24gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u LzE0NTgvIj5JUCBTZXJ2aWNlIEF0dHJpYnV0ZXM8L2E+Jm5ic3A7IFsxXS48YnI+PGJyPldlJ3Jl IHBsZWFzZWQgdGhhdCB5b3UgbWVudGlvbmVkIHRoZSBMM1ZQTiBzZXJ2aWNlIG1vZGVsIChMM1NN KSB3b3JrIGluIHlvdXIgbGlhaXNvbi4gVGhlIEwzU00gd29yayBjb3ZlcnMgYW4gYWJzdHJhY3Rl ZCB2aWV3IG9mIHRoZSBMYXllciAzIElQVlBOIHNlcnZpY2UgY29uZmlndXJhdGlvbiBjb21wb25l bnRzLCB3aXRoIGl0cyAmcXVvdDtZQU5HIERhdGEgTW9kZWwgZm9yIEwzVlBOIHNlcnZpY2UgZGVs aXZlcnkmcXVvdDsgWzJdIGRlbGl2ZXJhYmxlLiA8YnI+PGJyPkZyb20geW91ciBsaWFpc29uIHN0 YXRlbWVudCwgd2UgcmVhZCAmcXVvdDtJbiBNRUYgdGVybXMsIGEgJnF1b3Q7c2VydmljZSZxdW90 OyByZWZlcnMgdG8gdGhlIHNldCBvZiBhdHRyaWJ1dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBh cmUgYWdyZWVkIGJldHdlZW4gdGhlIHByb3ZpZGVyIG9mIGEgc2VydmljZSBhbmQgdGhlIGN1c3Rv bWVyIG9mIHRoYXQgc2VydmljZS4mcXVvdDsgWW91IHdpbGwgYmUgZ2xhZCB0byBoZWFyIHRoYXQg d2UgdXNlIHRoZSBzYW1lIGRlZmluaXRpb24gaW4gb3VyIEwzU00gd29yay4gQXMgc3VjaCwgdGhl IE1FRiBpbml0aWF0aXZlIG9uIElQIHNlcnZpY2UgYXR0cmlidXRlcyBjbGVhcmx5IHJlbGF0ZXMg dG8gTDNTTS48YnI+PGJyPlRoZSBMM1NNIGNoYWlycyBhbmQgd29ya2luZyBncm91cCBoYXZlIGV4 YW1pbmVkIHRoZSBwcm9wb3NlZCBzY29wZSBvZiB0aGUgaW5pdGlhbCBwaGFzZSBvZiB0aGUgTUVG IElQIFNlcnZpY2UgQXR0cmlidXRlcyBwcm9qZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iJz4tRGVmaW5pdGlvbiBvZiBhdHRyaWJ1dGVzIGZvciBJUC1jYXBhYmxlIFVO SXMgYW5kIE5OSXMsIGZvciBJUCBTZXJ2aWNlIGNvbm5lY3Rpb25zLCBhbmQgZm9yIElQIFNlcnZp Y2UgRW5kIFBvaW50cyBhdCBVTklzIGFuZCBFTk5Jczxicj4tSVAgYWRkcmVzcyBhbGxvY2F0aW9u cyBhbmQgSVAgY29udHJvbCBwcm90b2NvbHMgKGUuZy4gREhDUCkgZXRjIGF0IFVOSXM8YnI+LU9B TSBhY3Jvc3MgdGhlIGV4dGVybmFsIGludGVyZmFjZSAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJv dG9jb2xzIGFuZDxicj5tZWNoYW5pc21zKTxicj4tU2VydmljZSBMZXZlbCBTcGVjaWZpY2F0aW9u IChTTFMpIGRlZmluaXRpb25zIGluY2x1ZGluZyBwZXJmb3JtYW5jZSBtb25pdG9yaW5nL2NvbnN0 cmFpbnRzIChieSByZWZlcmVuY2UgdG8gSUVURiBwcm90b2NvbHMgYW5kIG1ldHJpYyBkZWZpbml0 aW9ucyk8YnI+LVJlZHVuZGFudCBsaW5rcyBhdCBhbiBleHRlcm5hbCBpbnRlcmZhY2UgKFN1YnNj cmliZXIvU2VydmljZSBwcm92aWRlciBvciBiZXR3ZWVuIFNlcnZpY2UgUHJvdmlkZXJzKSwgaW5j bHVkaW5nIG9wdGlvbnMgZm9yIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scy48YnI+LU11bHRp LUNvUyBzZXJ2aWNlcyAoaS5lLiBRb1MgY2xhc3NpZmljYXRpb24pIGFuZCBjbGFzc2lmaWNhdGlv biBvZjxicj5HcmVlbi9ZZWxsb3cgcGFja2V0cyBpbmNsdWRpbmcgZGlmZnNlcnYsIEJhbmR3aWR0 aCBwcm9maWxlcywgZXRjLjxicj4tSVB2NCwgSVB2NiBhbmQgZHVhbCBzdGFjayBzZXJ2aWNlczxi cj4tSW50ZXItb3BlcmF0b3IgSVAtVlBOIHNlcnZpY2VzIHVzaW5nIG9wdGlvbnMgQSwgQiBvciBD IGZyb20gUkZDNDM2NDxicj4tVW5pY2FzdCBvbmx5IChtdWx0aWNhc3QgaXMgZGVmZXJlZCB0byBh IGZ1dHVyZSBwaGFzZSkuPGJyPi1PdGhlciB0b3BpY3MgbWF5IGJlIGFkZGVkIGFzIHRoZSBwcm9q ZWN0IHByb2dyZXNzZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdtc28tZmFyZWFzdC1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+PGJyPlRoZSBMM1NNIHdvcmsgYWxyZWFkeSBjb3Zl cnMgbW9zdCBvZiB0aGUgaXRlbXMgaW4gdGhpcyBsaXN0LCBpbmNsdWRpbmcgbXVsdGljYXN0LiZu YnNwOyBIb3dldmVyLCB3ZSBzaG91bGQgb2JzZXJ2ZSB0aGF0Ojxicj4xLiZuYnNwOyBMM1NNIGhh cyBpbml0aWFsbHkgZm9jdXNlZCBvbiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIGN1c3RvbWVy IGFuZCB0aGUgc2VydmljZSBwcm92aWRlciwgbm90IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBzZXJ2 aWNlcyBwcm92aWRlcnMgb3IgYmV0d2VlbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbnMuIFRoZSBj dXJyZW50IHNlcnZpY2UgbW9kZWwgc3VwcG9ydHMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIFJG QyA0MzY0IG9wdGlvbiBBIChhcyB0aGlzIGlzIGEgc3Vic2V0IG9mIHRoZSBleGlzdGluZyBzaXRl IG1vZGVsKSwgYW5kIHdlJ3JlIGNvbnNpZGVyaW5nIHdoZXRoZXIgdG8gYWRkIG9wdGlvbiBCIGFu ZCBDLjxicj4yLiZuYnNwOyBUaGUgTDNTTSB3b3JrIGRvZXMgbm90IGNvdmVyIGVpdGhlciB0aGUg U2VydmljZSBMZXZlbCBTcGVjaWZpY2F0aW9uIGRlZmluaXRpb25zIG9yIHRoZSBMaWZlY3ljbGUg U2VydmljZSBPcmNoZXN0cmF0aW9uIGFzIGRlc2NyaWJlZCBpbiB0aGUgTUVGIExpZmVjeWNsZSBT ZXJ2aWNlIE9yY2hlc3RyYXRpb24gKExTTykgUmVmZXJlbmNlIEFyY2hpdGVjdHVyZSAmYW1wOyBG cmFtZXdvcmsuIDxicj48YnI+VGhlIEwzU00gd29yayBzdGFydGVkIGFib3V0IGEgeWVhciBhZ28g YW5kIGlzIGluIHRoZSBmaW5hbCBzdGFnZSBvZiBzdGFuZGFyZGl6YXRpb24uIFRoZXJlZm9yZSwg d2Ugd291bGQgZW5jb3VyYWdlIGFueW9uZSB3aG8gaXMgaW50ZXJlc3RlZCB0byByZXZpZXcgYW5k IHByb3ZpZGUgZmVlZGJhY2sgb24gdGhlIGZ1dHVyZSBzdGFuZGFyZCBieSBzZW5kaW5nIGEgbWVz c2FnZSB0byB0aGUgTDNTTSBtYWlsaW5nIGxpc3QgYXMgc29vbiBhcyBwb3NzaWJsZSAoZGV0YWls cyBhdCBbM10pLiBQbGVhc2Uga2VlcCB1cyBpbmZvcm1lZCBvZiBhbnkgZ2FwcyB5b3UgaWRlbnRp ZnkgdGhhdCBhcmUgbmVlZGVkIHRvIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50cyBpbiB5b3VyIHNw ZWNpZmljYXRpb25zLCB3aXRob3V0IHRoZSBuZWVkIGZvciBhIGZvcm1hbCBsaWFpc29uLiA8YnI+ PGJyPkkgaG9wZSB5b3Ugd2lsbCBhZ3JlZSB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBub3QgZHVw bGljYXRlIHdvcmsgd2l0aGluIHN0YW5kYXJkaXphdGlvbi4gVGhlcmVmb3JlLCBJIGhvcGUgeW91 IHdpbGwgd29yayB0byBwcm9kdWNlIGV4dGVuc2lvbnMgdG8gdGhlIEwzU00gWUFORyBtb2RlbCBm b3IgYWRkaXRpb25hbCBmZWF0dXJlcyBzdWNoIGFzIHRoZSBTZXJ2aWNlIExldmVsIFNwZWNpZmlj YXRpb24sIGFuZCB3aWxsIG5vdCByZXBlYXQgYW55IG9mIHRoZSBmdW5jdGlvbiBhbHJlYWR5IHBy b3ZpZGVkIGJ5IHRoYXQgbW9kZWwuIElmIHlvdSBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIGRv bid0IGhlc2l0YXRlIHRvIGNvbnRhY3QgdXMuIFdlIGFyZSBhbHdheXMgYXZhaWxhYmxlIGZvciBm dXJ0aGVyIGRpc2N1c3Npb25zIG9yIGNvbmZlcmVuY2UgY2FsbHMgcmVnYXJkaW5nIHRoZSBMM1NN IHNwZWNpZmljYXRpb25zIGNvbnRlbnQuPGJyPjxicj5SZWdhcmRzLCBCZW5vaXQgQ2xhaXNlIChP UFMgQXJlYSBEaXJlY3Rvcik8YnI+PGJyPlsxXSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2xpYWlzb24vMTQ1OC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlh aXNvbi8xNDU4LzwvYT48YnI+WzJdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsLyI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwv PC9hPiA8YnI+WzNdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvbDNz bS9jaGFydGVyLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9sM3NtL2NoYXJ0ZXIv PC9hPjxicj48YnIgc3R5bGU9J21zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrJz48IVtp ZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0nbXNvLXNwZWNpYWwtY2hhcmFj dGVyOmxpbmUtYnJlYWsnPjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHBy ZT5UaXRsZTogTGlhaXNvbiBmcm9tIE1FRiBvbiBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXM8bzpwPjwv bzpwPjwvcHJlPjxwcmU+U3VibWlzc2lvbiBEYXRlOiAyMDE2LTAyLTI2PG86cD48L286cD48L3By ZT48cHJlPlVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9saWFpc29uLzE0NTgvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2xpYWlzb24vMTQ1OC88L2E+PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+PHByZSBzdHlsZT0nbXNvLW91dGxpbmUtbGV2ZWw6MSc+RnJvbTogJnF1b3Q7UmFnaHUg UmFuZ2FuYXRoYW4mcXVvdDsgPGEgaHJlZj0ibWFpbHRvOnJyYWdodUBjaWVuYS5jb20iPiZsdDty cmFnaHVAY2llbmEuY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+VG86IDxhIGhyZWY9 Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+YmNsYWlzZUBjaXNjby5jb208L2E+LCA8YSBocmVm PSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT4sIDxhIGhyZWY9 Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDssIDxhIGhy ZWY9Im1haWx0bzppZXRmQHdqY2VydmVueS5jb20iPmlldGZAd2pjZXJ2ZW55LmNvbTwvYT4sIDxh IGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT4sIDxhIGhyZWY9Im1haWx0bzpz d2FsbG93LmlldGZAZ21haWwuY29tIj5zd2FsbG93LmlldGZAZ21haWwuY29tPC9hPiwgPGEgaHJl Zj0ibWFpbHRvOnJjYWxsb25AanVuaXBlci5uZXQiPnJjYWxsb25AanVuaXBlci5uZXQ8L2E+LCA8 YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+YWRyaWFuQG9sZGRvZy5jby51azwv YT4sIDxhIGhyZWY9Im1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNv bTwvYT48bzpwPjwvbzpwPjwvcHJlPjxwcmU+Q2M6IEFsdmFybyBSZXRhbmEgPGEgaHJlZj0ibWFp bHRvOmFyZXRhbmFAY2lzY28uY29tIj4mbHQ7YXJldGFuYUBjaXNjby5jb20mZ3Q7PC9hPixKb2Vs IEphZWdnbGkgPGEgaHJlZj0ibWFpbHRvOmpvZWxqYUBib2d1cy5jb20iPiZsdDtqb2VsamFAYm9n dXMuY29tJmd0OzwvYT4sRGVib3JhaCBCcnVuZ2FyZCA8YSBocmVmPSJtYWlsdG86ZGIzNTQ2QGF0 dC5jb20iPiZsdDtkYjM1NDZAYXR0LmNvbSZndDs8L2E+LElQIFBlcmZvcm1hbmNlIE1ldHJpY3Mg RGlzY3Vzc2lvbiBMaXN0IDxhIGhyZWY9Im1haWx0bzppcHBtQGlldGYub3JnIj4mbHQ7aXBwbUBp ZXRmLm9yZyZndDs8L2E+LE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIERpc2N1c3Npb24g TGlzdCA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+Jmx0O21wbHNAaWV0Zi5vcmcmZ3Q7 PC9hPixBZHJpYW4gRmFycmVsIDxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrIj4m bHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDs8L2E+LFFpbiBXdSA8YSBocmVmPSJtYWlsdG86Ymls bC53dUBodWF3ZWkuY29tIj4mbHQ7YmlsbC53dUBodWF3ZWkuY29tJmd0OzwvYT4sQmlsbCBDZXJ2 ZW55IDxhIGhyZWY9Im1haWx0bzppZXRmQHdqY2VydmVueS5jb20iPiZsdDtpZXRmQHdqY2VydmVu eS5jb20mZ3Q7PC9hPixCcmlhbiBUcmFtbWVsbCA8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVs bC5jaCI+Jmx0O2lldDxvOnA+PC9vOnA+PC9hPjwvcHJlPjxwcmU+PHNwYW4gY2xhc3M9TXNvSHlw ZXJsaW5rPjxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5mQHRyYW1tZWxsLmNoJmd0 OzwvYT48L3NwYW4+LFNwZW5jZXIgRGF3a2lucyA8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20iPiZsdDtzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSZndDs8 L2E+LEdlb3JnZSBTd2FsbG93IDxhIGhyZWY9Im1haWx0bzpzd2FsbG93LmlldGZAZ21haWwuY29t Ij4mbHQ7c3dhbGxvdy5pZXRmQGdtYWlsLmNvbSZndDs8L2E+LEFsaWEgQXRsYXMgPGEgaHJlZj0i bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj4mbHQ7YWthdGxhc0BnbWFpbC5jb20mZ3Q7PC9hPixU aGUgSUVURiBDaGFpciA8YSBocmVmPSJtYWlsdG86Y2hhaXJAaWV0Zi5vcmciPiZsdDtjaGFpckBp ZXRmLm9yZyZndDs8L2E+LE5hbiBDaGVuIDxhIGhyZWY9Im1haWx0bzpuYW5AbWV0cm9ldGhlcm5l dGZvcnVtLm9yZyI+Jmx0O25hbkBtZXRyb2V0aGVybmV0Zm9ydW0ub3JnJmd0OzwvYT4sUm9zcyBD YWxsb24gPGEgaHJlZj0ibWFpbHRvOnJjYWxsb25AanVuaXBlci5uZXQiPiZsdDtyY2FsbG9uQGp1 bmlwZXIubmV0Jmd0OzwvYT4sTG9hIEFuZGVyc3NvbiA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51 Ij4mbHQ7bG9hQHBpLm51Jmd0OzwvYT4sQmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNs YWlzZUBjaXNjby5jb20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+LEwzVlBOIFNlcnZp Y2UgTW9kZWw8c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+wqAgPC9zcGFuPkRpc2N1c3Np b24gTGlzdCA8YSBocmVmPSJtYWlsdG86bDNzbUBpZXRmLm9yZyI+Jmx0O2wzc21AaWV0Zi5vcmcm Z3Q7PC9hPixCaWxsIEJqb3JrbWFuIDxhIGhyZWY9Im1haWx0bzpiaWxsQG1ldHJvZXRoZXJuZXRm b3J1bS5uZXQiPiZsdDtiaWxsQG1ldHJvZXRoZXJuZXRmb3J1bS5uZXQmZ3Q7PC9hPixNYXJ0aW4g U3RpZW1lcmxpbmcgPGEgaHJlZj0ibWFpbHRvOm1scy5pZXRmQGdtYWlsLmNvbSI+Jmx0O21scy5p ZXRmQGdtYWlsLmNvbSZndDs8L2E+LFJhZ2h1IFJhbmdhbmF0aGFuIDxhIGhyZWY9Im1haWx0bzpy cmFnaHVAY2llbmEuY29tIj4mbHQ7cnJhZ2h1QGNpZW5hLmNvbSZndDs8L2E+LDxvOnA+PC9vOnA+ PC9wcmU+PHByZT5SZXNwb25zZSBDb250YWN0czogPGEgaHJlZj0ibWFpbHRvOnJyYWdodUBjaWVu YS5jb20iPnJyYWdodUBjaWVuYS5jb208L2E+PG86cD48L286cD48L3ByZT48cHJlPlRlY2huaWNh bCBDb250YWN0czogPG86cD48L286cD48L3ByZT48cHJlPlB1cnBvc2U6IEZvciBpbmZvcm1hdGlv bjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Qm9keTog V2Ugd291bGQgbGlrZSB0byBpbmZvcm0geW91IHRoYXQgZHVyaW5nIG91ciAxUTIwMTYgbWVldGlu ZywgTUVGIGhhcyBhcHByb3ZlZCBhIG5ldyBwcm9qZWN0IG9uIElQIFNlcnZpY2UgQXR0cmlidXRl cy4gV2UgaGF2ZSBzZXQgb3V0IHNvbWUgYmFja2dyb3VuZCBhbmQgZnVydGhlciBkZXRhaWxzIGJl bG93LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+TUVG IGlzIHdlbGwga25vd24gZm9yIHRoZSBkZWZpbml0aW9uIG9mIENhcnJpZXIgRXRoZXJuZXQgKENF KSBzZXJ2aWNlcyAoaW4gTUVGIDYuMiwgTUVGIDMzIGFuZCBNRUYgNTEpIGJhc2VkIG9uIHNlcnZp Y2UgYXR0cmlidXRlcyAoZGVmaW5lZCBpbiBNRUYgMTAuMyBhbmQgTUVGIDI2LjEpLiBJbiBNRUYg dGVybXMsIGEgJnF1b3Q7c2VydmljZSZxdW90OyByZWZlcnMgdG8gdGhlIHNldCBvZiBhdHRyaWJ1 dGVzIGFuZCB0aGVpciB2YWx1ZXMgdGhhdCBhcmUgYWdyZWVkIGJldHdlZW4gdGhlIHByb3ZpZGVy IG9mIGEgc2VydmljZWFuZCB0aGUgY3VzdG9tZXIgb2YgdGhhdCBzZXJ2aWNlLiBUaGVzZSBhdHRy aWJ1dGVzIGFyZSBpbmRlcGVuZGVudCBvZiBob3cgdGhlIHNlcnZpY2UgaXMgaW1wbGVtZW50ZWQ7 IGZvciBleGFtcGxlIGEgQ0Ugc2VydmljZSBjb3VsZCBiZTxvOnA+PC9vOnA+PC9wcmU+PHByZT5p bXBsZW1lbnRlZCB1c2luZyBQcm92aWRlciBCYWNrYm9uZSBCcmlkZ2luZyAoODAyLjFRKSBvciB1 c2luZyBWUExTIChSRkMgNDc2MS80NzYyKSB0byBwcm92aWRlIHRoZSBjb25uZWN0aXZpdHkgYWNy b3NzIHRoZSBzZXJ2aWNlIHByb3ZpZGVyJ3MgbmV0d29yay4gTUVGIGRlZmluZXMgYm90aCBlbmQt dG8tZW5kIHNlcnZpY2VzIGFncmVlZCBiZXR3ZWVuIGEgc3Vic2NyaWJlciBhbmQgYSBzZXJ2aWNl IHByb3ZpZGVyLCB3aGVyZSB0aGUgZW5kIHBvaW50cyBhcmUgYWxsIFVzZXItTmV0d29yayBJbnRl cmZhY2VzIChVTklzKSwgYW5kIGludGVyLXByb3ZpZGVyIHNlcnZpY2VzIHN1cHBsaWVkIGJ5IG9u ZSBzZXJ2aWNlIHByb3ZpZGVyIG9yIG9wZXJhdG9yIHRvIGFub3RoZXIsIHdoZXJlIHRoZSBlbmQg cG9pbnRzIG1heSBiZSBVTklzIG9yIEV4dGVybmFsIE5ldHdvcmstTmV0d29yayBJbnRlcmZhY2Vz IChFTk5JcykuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHBy ZT5Ob3RlIHRoYXQgdGhpcyBkaWZmZXJzIGZyb20gaG93IHRoZSB3b3JkICZxdW90O3NlcnZpY2Um cXVvdDsgaXMgc29tZXRpbWVzIHVzZWQgaW4gSUVURiwgZS5nLiB0byBkZXNjcmliZSBhIHBhcnRp Y3VsYXIgdGVjaG5vbG9neSAoYXMgaW4gJnF1b3Q7VmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNl JnF1b3Q7KS48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJl PkFsdGhvdWdoIElQIFNlcnZpY2VzIGFyZSB3aWRlbHkgZGVwbG95ZWQsIHRoZXJlIGlzIGN1cnJl bnRseSBubyBzdGFuZGFyZCBkZWZpbml0aW9uIG9mIHRoZSBhdHRyaWJ1dGVzIGFuZCB2YWx1ZXMg dXNlZCB0byBkZXNjcmliZSB0aGVtLiBFYWNoIFNlcnZpY2UgUHJvdmlkZXIgaGFzIHRoZWlyIG93 biB3YXkgb2YgZGVzY3JpYmluZyBJUCBzZXJ2aWNlcyAoaW5jbHVkaW5nIGluIHNvbWUgY2FzZXMg dGhlaXIgb3duIHRlcm1pbm9sb2d5KTsgdGhpcyBtYWtlcyBpdCBoYXJkIGZvciBjdXN0b21lcnMg dG8gY29tcGFyZSBzZXJ2aWNlIG9mZmVyaW5ncyBmcm9tIGRpZmZlcmVudCBwcm92aWRlcnMsIGFu ZCBpbiBwYXJ0aWN1bGFyIG1ha2VzIGl0IGhhcmQgZm9yIHByb3ZpZGVycyB0byBpbnRlcmNvbm5l Y3Qgd2l0aCBlYWNoIG90aGVyIOKAkyBlYWNoIFNlcnZpY2UgUHJvdmlkZXIgbXVzdCBmb3JtIGEg c3BlY2lmaWMgYmlsYXRlcmFsIGFncmVlbWVudCB3aXRoIGVhY2ggb3RoZXIgU2VydmljZSBQcm92 aWRlciB0aGV5IHdpc2ggdG8gY29ubmVjdCB3aXRoLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+RnVydGhlcm1vcmUsIHRoZXJlIGlzIGEgZGVzaXJlIGFt b25nIHNlcnZpY2UgcHJvdmlkZXJzIHRvIGltcHJvdmUgc2VydmljZSBkZWxpdmVyeSB0aW1lcyBi eSBhdXRvbWF0aW5nIHRoZSBzZXJ2aWNlIG9yZGVyaW5nIGFuZCBjb25maWd1cmF0aW9uIHByb2Nl c3MuIFRoaXMgaXMgYSBrZXkgYXNwZWN0IG9mIE1FRiBMaWZlY3ljbGUgU2VydmljZXMgT3JjaGVz dHJhdGlvbiAoTFNPKS4gVGhlIGFpbSBvZiBNRUYgTFNPIGlzIHRvIGRlbGl2ZXIgdGhlIE1FRiBU aGlyZCBOZXR3b3JrIHZpc2lvbiwgdG8gcHJvdmlkZSBBc3N1cmVkLCBBZ2lsZSBhbmQgT3JjaGVz dHJhdGVkIHNlcnZpY2VzLiBNRUYgTFNPIGVuYWJsZXMgYXV0b21hdGlvbiBhbmQgb3JjaGVzdHJh dGlvbiBvZiBzZXJ2aWNlIG9yZGVyaW5nIGFuZCBtYW5hZ2VtZW50IGJldHdlZW4gc2VydmljZSBw cm92aWRlcnMgKCZxdW90O0Vhc3QvV2VzdCBpbnRlcmZhY2VzJnF1b3Q7KSB0aHJvdWdoIHRoZSBj cmVhdGlvbiBvZiBzdGFuZGFyZCBkYXRhIG1vZGVscyBhbmQgQVBJcy4gSG93ZXZlciwgYSBwcmUt cmVxdWlzaXRlIGZvciBkZWZpbmluZyB0aG9zZSBpcyB0byBoYXZlIGEgc3RhbmRhcmQgZGVmaW5p dGlvbiBvZiB0aGUgc2VydmljZSB0aGF0IGlzIHRvIGJlIG1hbmFnZWQuPG86cD48L286cD48L3By ZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5UaGUgbmV3IHByb2plY3QgaXMgaW50 ZW5kZWQgdG8gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgYnkgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZGVm aW5pdGlvbiBvZiBJUCBTZXJ2aWNlcywgaW5jbHVkaW5nIGJvdGggZW5kLXRvLWVuZCBzZXJ2aWNl cyBhbmQgaW50ZXItcHJvdmlkZXIgc2VydmljZXMsIHRocm91Z2ggdGhlIGRlZmluaXRpb24gb2Yg YSBzdGFuZGFyZCBzZXQgb2YgU2VydmljZSBBdHRyaWJ1dGVzIHRoYXQgY2FuIGJlIHVzZWQgaW4g ZWFjaCBjYXNlLiBUaGUgc2NvcGUgaXMgbGltaXRlZCB0byBJUC1WUE4gYW5kIEludGVybmV0IEFj Y2VzcyBzZXJ2aWNlczxzcGFuIHN0eWxlPSdtc28tc3BhY2VydW46eWVzJz7CoCA8L3NwYW4+KElQ IHBlZXJpbmcvdHJhbnNpdCBmb3IgaW50ZXJuZXQgdHJhZmZpYyBpcyBwcmVjbHVkZWQpLiBJdCBp cyBpbnRlbmRlZCB0aGF0IHRoaXMgcHJvamVjdCBpcyB0aGUgZmlyc3Qgc3RlcCBpbiBlbmFibGlu ZyBtdWx0aS1vcGVyYXRvciBzZXJ2aWNlIG9yY2hlc3RyYXRpb24gb2YgSVAgU2VydmljZXMgdXNp bmcgTUVGIExTTywgYW5kIHRoYXQgbGF0ZXIgcHJvamVjdHMgd2lsbCB1c2UgdGhlIFNlcnZpY2Ug QXR0cmlidXRlcyB0byBjcmVhdGUgc3RhbmRhcmQgZGF0YSBtb2RlbHMgYW5kIEFQSXMuIFRoZSBp bnRlbnQgb2YgTFNPIGlzIHRvIHByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGFjcm9zcyBkaWZm ZXJlbnQgc2VydmljZSB0ZWNobm9sb2dpZXM7IE1FRiBpcyB3b3JraW5nIHdpdGggVE1GIGFuZCBP TkYgdG8gY3JlYXRlIGNvbW1vbiBtb2RlbHMgZm9yIHNlcnZpY2VzLCBhbmQgdGhlIHN0YW5kYXJk IGRhdGEgbW9kZWxzIGFuZCBBUElzIGZvciBJUCBTZXJ2aWNlcyB3aWxsIHRpZSBpbnRvIHRoaXMg ZnJhbWV3b3JrLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+V2UgaGF2ZSBub3RlZCB0aGF0IElFVEYgaXMgd29ya2luZyBvbiBhIFlhbmcgbW9kZWwgZm9y IExheWVyIDMgU2VydmljZXMgaW4gdGhlIEwzU00gd29ya2luZyBncm91cC4gQWx0aG91Z2ggdGhl IHNjb3BlIG9mIHRoYXQgcHJvamVjdCBpbiBJRVRGIGlzIGRpZmZlcmVudCwgaXQgaXMgY2xlYXIg dGhlcmUgaXMgc29tZSBzeW5lcmd5IGJldHdlZW4gdGhlIEwzU00gd29yayBhbmQgdGhpcyBNRUYg cHJvamVjdC4gV2UgYmVsaWV2ZSB0aGF0IGJvdGggcHJvamVjdHMgY2FuIGJlbmVmaXQgZnJvbSBp bnB1dCBmcm9tIGVhY2ggb3RoZXIgYW5kIHdlIGhvcGUgdG8gd29yayBjbG9zZWx5IHdpdGggdGhl IEwzU00gd29ya2luZyBncm91cCB0byBlbnN1cmUgb3VyIHNwZWNpZmljYXRpb25zIGFyZSBhbGln bmVkLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhl IHNjb3BlIG9mIHRoZSBpbml0aWFsIHBoYXNlIG9mIHRoZSBJUCBTZXJ2aWNlIEF0dHJpYnV0ZXMg cHJvamVjdCBpbmNsdWRlczo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LURlZmluaXRpb24gb2YgYXR0 cmlidXRlcyBmb3IgSVAtY2FwYWJsZSBVTklzIGFuZCBOTklzLCBmb3IgSVAgU2VydmljZSBjb25u ZWN0aW9ucywgYW5kIGZvciBJUCBTZXJ2aWNlIEVuZCBQb2ludHMgYXQgVU5JcyBhbmQgRU5OSXM8 bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUlQIGFkZHJlc3MgYWxsb2NhdGlvbnMgYW5kIElQIGNvbnRy b2wgcHJvdG9jb2xzIChlLmcuIERIQ1ApIGV0YyBhdCBVTklzPG86cD48L286cD48L3ByZT48cHJl Pi1PQU0gYWNyb3NzIHRoZSBleHRlcm5hbCBpbnRlcmZhY2UgKGJ5IHJlZmVyZW5jZSB0byBJRVRG IHByb3RvY29scyBhbmQgbWVjaGFuaXNtcyk8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LVNlcnZpY2Ug TGV2ZWwgU3BlY2lmaWNhdGlvbiAoU0xTKSBkZWZpbml0aW9ucyBpbmNsdWRpbmcgcGVyZm9ybWFu Y2UgbW9uaXRvcmluZy9jb25zdHJhaW50cyAoYnkgcmVmZXJlbmNlIHRvIElFVEYgcHJvdG9jb2xz IGFuZCBtZXRyaWMgZGVmaW5pdGlvbnMpPG86cD48L286cD48L3ByZT48cHJlPi1SZWR1bmRhbnQg bGlua3MgYXQgYW4gZXh0ZXJuYWwgaW50ZXJmYWNlIChTdWJzY3JpYmVyL1NlcnZpY2UgcHJvdmlk ZXIgb3IgYmV0d2VlbiBTZXJ2aWNlIFByb3ZpZGVycyksIGluY2x1ZGluZyBvcHRpb25zIGZvciBk aWZmZXJlbnQgcm91dGluZyBwcm90b2NvbHMuPG86cD48L286cD48L3ByZT48cHJlPi1NdWx0aS1D b1Mgc2VydmljZXMgKGkuZS4gUW9TIGNsYXNzaWZpY2F0aW9uKSBhbmQgY2xhc3NpZmljYXRpb24g b2YgR3JlZW4vWWVsbG93IHBhY2tldHMgaW5jbHVkaW5nIGRpZmZzZXJ2LCBCYW5kd2lkdGggcHJv ZmlsZXMsIGV0Yy48bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUlQdjQsIElQdjYgYW5kIGR1YWwgc3Rh Y2sgc2VydmljZXM8bzpwPjwvbzpwPjwvcHJlPjxwcmU+LUludGVyLW9wZXJhdG9yIElQLVZQTiBz ZXJ2aWNlcyB1c2luZyBvcHRpb25zIEEsIEIgb3IgQyBmcm9tIFJGQzQzNjQ8bzpwPjwvbzpwPjwv cHJlPjxwcmU+LVVuaWNhc3Qgb25seSAobXVsdGljYXN0IGlzIGRlZmVyZWQgdG8gYSBmdXR1cmUg cGhhc2UpLjxvOnA+PC9vOnA+PC9wcmU+PHByZT4tT3RoZXIgdG9waWNzIG1heSBiZSBhZGRlZCBh cyB0aGUgcHJvamVjdCBwcm9ncmVzc2VzLjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPjxwcmU+SXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB3ZSBpbnRlbmQg dG8gbWFrZSBleHRlbnNpdmUgcmVmZXJlbmNlIHRvIGV4aXN0aW5nIElFVEYgUkZDcyB3aGVyZSBh cHBsaWNhYmxlOyBpdCBpcyBub3Qgb3VyIGludGVudCB0byBzcGVjaWZ5IG5ldyBwcm90b2NvbHMg b3IgbWVjaGFuaXNtcyB3aGVyZSB0aGVyZSBhcmUgZXhpc3Rpbmcgc29sdXRpb25zLjxvOnA+PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+Tm90ZTogZnVydGhlciBp bmZvcm1hdGlvbiBhYm91dCBNRUYgTFNPIGNhbiBiZSBmb3VuZCBpbiB0aGUgTFNPIFJlZmVyZW5j ZSBBcmNoaXRlY3R1cmUuIFRoZSBmaW5hbCB2ZXJpc29uIGlzIGV4cGVjdGVkIHRvIGJlIHB1Ymxp c2hlZCBpbiBNYXJjaDsgaW4gdGhlIG1lYW50aW1lLCB0aGUgbGF0ZXN0IGFwcHJvdmVkIGRyYWZ0 IGlzIGF2YWlsYWJsZSBhcyBiZWxvdzo8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly9tZWYubmV0L2xpYWlzb24tbG9naW4iPmh0dHBzOi8vbWVmLm5ldC9saWFpc29uLWxvZ2lu PC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT5Vc2VybmFtZTogbWVmPG86cD48L286cD48L3ByZT48 cHJlPkF0dGFjaG1lbnRzOjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPjxwcmU+PHNwYW4gc3R5bGU9J21zby1zcGFjZXJ1bjp5ZXMnPsKgwqDCoCA8L3NwYW4+TGlh aXNvbjxvOnA+PC9vOnA+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0nbXNvLXNwYWNlcnVuOnllcyc+ wqDCoMKgIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9saWIvZHQvZG9jdW1l bnRzL0xJQUlTT04vbGlhaXNvbi0yMDE2LTAyLTI2LW1lZi1pcHBtLW1wbHMtbDNzbS1vcHMtbGlh aXNvbi1mcm9tLW1lZi1vbi1pcC1zZXJ2aWNlLWF0dHJpYnV0ZXMtYXR0YWNobWVudC0xLnBkZiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbGliL2R0L2RvY3VtZW50cy9MSUFJU09OL2xpYWlzb24tMjAx Ni0wMi0yNi1tZWYtaXBwbS1tcGxzLWwzc20tb3BzLWxpYWlzb24tZnJvbS1tZWYtb24taXAtc2Vy dmljZS1hdHRyaWJ1dGVzLWF0dGFjaG1lbnQtMS5wZGY8L2E+PG86cD48L286cD48L3ByZT48cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT4uPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+PC9ibG9ja3F1b3RlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_679E55ADEABC9443947F5AD6F3ED464A21C0BA0E3AONWVEXCHMB03c_-- From nobody Thu Apr 14 05:59:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65FD12D591; Thu, 14 Apr 2016 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 8fZUu6WCUGCo; Thu, 14 Apr 2016 05:59:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F9212D10E; Thu, 14 Apr 2016 05:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6861; q=dns/txt; s=iport; t=1460638750; x=1461848350; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=U6M4Fw1qAF6zqUMwTTvEKB+KgnEjQ9CKuJGUiCAO3AA=; b=C27cWAE8QG245XcfrBztl5chMB4kCf0yj4v9ohN9gyIzUS9dRF0TeVaq ZyrZSxLoXmV9dgA3AJj8sWlKuRgJJszxu8Uve0ql0wvfySDo4JiwDNNXX Sjk/+9iuuZLRIooKF1Cjl5AAyJfQ2Nb/vL+yECwmMEzw1yee1IzO3vFN4 A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAwCrkw9X/5JdJa1egmtNgVAGtTaCZ?= =?us-ascii?q?IIPDoFxhg4CgTQ4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6?= =?us-ascii?q?IEwiwDZJDAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF1glaHPyuCKwEEmAsBg?= =?us-ascii?q?yOBZokDjxCPKAEeAUODZ2yISH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="asc'?scan'208,217";a="91762122" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 12:59:09 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3ECx8H9002176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 12:59:09 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:59:08 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 08:59:08 -0400 From: "Carlos Pignataro (cpignata)" To: Xuxiaohu Thread-Topic: [bier] [mpls] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRlZN9PVrX2Wi8F0+nxhEebuX+pp+JDVoAgAClZwA= Date: Thu, 14 Apr 2016 12:59:08 +0000 Message-ID: <6FF3596A-DC0A-4EBE-889D-2FF3DD2A5B8A@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570E5C1A.7010606@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539EF2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539EF2@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.210.95] Content-Type: multipart/signed; boundary="Apple-Mail=_3957F221-A2E8-42A6-A675-2C7B3AAD2477"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "bier@ietf.org" , "mpls@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 12:59:11 -0000 --Apple-Mail=_3957F221-A2E8-42A6-A675-2C7B3AAD2477 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C08CE0D-795E-4A6B-BCD1-8BF6F3224105" --Apple-Mail=_3C08CE0D-795E-4A6B-BCD1-8BF6F3224105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 13, 2016, at 11:07 PM, Xuxiaohu wrote: >=20 >> Well, of course, that's why the nibble is not a protocol type field = ;-) In the MPLS >=20 > If we pick different values for the first nibble of different MPLS = payloads, the first nibble actually plays the role of a protocol type = field. No. Really no. > In fact, there is an attempt to have a registry for the first nibble = (a.k.a., MPLS payload type field). >=20 Let=E2=80=99s not. Thanks, =E2=80=94 Carlos. > Best regards, > Xiaohu --Apple-Mail=_3C08CE0D-795E-4A6B-BCD1-8BF6F3224105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 13, 2016, at 11:07 PM, Xuxiaohu <xuxiaohu@huawei.com>= wrote:

Well, of course, that's why the nibble is not a protocol type = field ;-) In the MPLS

If we pick different values for the first = nibble of different MPLS payloads, the first nibble actually plays the = role of a protocol type field.

No. Really no.

In fact, there is an attempt to have a registry = for the first nibble (a.k.a., MPLS payload type field).


Let=E2=80=99s not.

Thanks,

=E2=80=94= Carlos.

Best regards,
Xiaohu

= --Apple-Mail=_3C08CE0D-795E-4A6B-BCD1-8BF6F3224105-- --Apple-Mail=_3957F221-A2E8-42A6-A675-2C7B3AAD2477 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXD5QaAAoJEIXgpQGOZny9g6QP/jPp8taK6TXhXa5A0JhSJIkh EZl8+f9ovq4MgNy2BW+QHQQMC37Sic9og0Z4byPQwei4QkB2d4C5aA131R1OsvMo Lq04G/BKI/DOVh0cU4k+HSzf/UJGDhFhvv54+VWCYw7Fd2W5Gv/BqEMIv58mL0R6 S/Kdcw0bTdkBhhWS9IkvlDGOEicFhBQnEWLjIExplmS5SgTVDk5Y+iG5laBKAV7e 4GyrrkMwhrwWTjavh2VIXy7DlIIvtP7gV7oXxNWH1iNI3ndKOIl2CeWRLiEWThL9 KbTgGqTPJNSBGl4TCJh2q2KkApGdF4Ca/+Foi6zWQn29iEuatb1S1dM4286jod2c /u5FpvvgQTTtJgU3McSjBiaF2VC8FNMJ1tLfFYKOG0Tjq0Qs0ixHrB3/AhXv88sH 386HL3RDP/+Zh2o8RsHh+4NYlJRewQHpUZSDkyQGFflnZT3CBIk6hTZ0EZaKqQMo jZdnXAGTOSksjBrrgskF1n/YCRxm7Cyrwe2VouZhFDXiTnNBeZ59UAGzXTHS7Df4 B3jUVrYg0SfreapKDmb7RoRwjgsH6rUiJc29Zf00r8ni1bGSfMl6eQCnHUO9Asyr ZepcCN9YUd3VDWm29QNHXWftuseEHTddT71eQGQ0YKpNytS/ACJMliU1ypZpIHMi /kC8HDlwbS8wjPhwpqQ+ =XuXn -----END PGP SIGNATURE----- --Apple-Mail=_3957F221-A2E8-42A6-A675-2C7B3AAD2477-- From nobody Thu Apr 14 06:19:32 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0333112DEDD; Thu, 14 Apr 2016 06:19:32 -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 UbUaFNyYMyJS; Thu, 14 Apr 2016 06:19:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCCC712DF63; Thu, 14 Apr 2016 06:19:24 -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=v+C4yjCQGGYvmZVxenEVY4b0tsHNC8cT9AzAXaJ8U2s=; b=k3kGsuUPuFXzTXhDrntdsFU1Xy21efIos+8sLsKp2MPjlOU2bZS33AN6vy2jBkGXEBXHVuvVSz8sr8j83w9WMkYGUTIoBD9YqilsXESQMjgo8fa6Lz455diNlS/NU7INIAeBhkAfSVdBmKBOYGWf73tHe3kW5VvDjPvfedIS3Eg= 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.34.60] (66.129.241.10) by CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 13:19:02 +0000 To: Alexander Vainshtein , Stewart Bryant References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> From: Eric C Rosen Message-ID: <570F9901.2080406@juniper.net> Date: Thu, 14 Apr 2016 09:20:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: BLUPR17CA0070.namprd17.prod.outlook.com (10.162.85.166) To CO2PR05MB794.namprd05.prod.outlook.com (10.141.226.19) X-MS-Office365-Filtering-Correlation-Id: 21b25512-4ce6-4d78-a630-08d364675955 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 2:JCMZ6Nzx9TKb/U7ClSmRk5zdGsTrks0LdLGplEANh5lopf+PC73W0yiHUWqA9M9lSyEjCPyOVq7KnoMykISiFbu/6lmmCyFqA/85t7QVxPA0+GaMp/RZNLlwB3IA+0pytv9ZqXJ7KtaEc2VEma6+lzhuyJp5imEtfVpKp2BQixqrsNZH5SB2c16TfyGtN25M; 3:lsHUDLYuji9jQbxx/wnJ622F3K5Skc4mdSWF9kl2OnuBFYaNos1I/lNpHTAhNHSTohIJ/8wvuMjeqvNd/6uvWjznhKBf/svD98GqbpwUTPwcpbbg87QmCKSirBGHuwC3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB794; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 25:G5NhXqL7sdDMjcEbQtvgi8CoxlIMjjAOMTXk1ADbhvaDz7M8oUaDQsUhx+E8CXPGNdy3YLx3CnKtv7zPmYagxZ3xYML2WTAkGsVz1c+qMgPk01cTDd8ntfCtcYstIGK8zGXHdziP2BYxAbjb/6ZjFsMJ5TvuoCXruAMgPDLyv/+supShFTSQc9s9ETsFjihu4CxZtyPfw/2Msfhi1P0zya8Z1sDCUbH6K0cZVRLg/EAHZBjAi2cKavz6pzMvpecMNuHi/Eww+EteBwZ5Lh4N7okMGiw8wN/Ymuf+y796hYenXScYi9G+X6FvPynDi9RR60Jm80xaORIVgbvz7O/Fgnzl70IXbBe5EUhHk9mfmvCmsfIDCCXG+XB6Kf7vjq2ixdo+yHSvkE3SfbF3lR1ldtbcHNsp6qlx6zJDWiGC/eS9leqtURmSn8ptbsdcC9452txyhsNpdor2JIQeNu4reVTPR55COHBQhaNeonu9AtmFo9CeGjsHVLxAbBaIDRD8aUldBnBHjKBJWVVgAltcuH6QxZ0/UGM3OVoHPxGHgu6F8rt0ZSG5pbeecld9G3EYHB7jVIYyqK59wSCu4kIT3jg/FCOvy3YLmOGjf917/hHeH/whR+QNNYJ3B5wrNQwu0lxkEioZ1SrLtdwWLX3wLDkgRGfocs3BMC8BnuVKx7cPa/qUspHZ/Pgjwh7FMi6L X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 20:AssvXvgRRXQUqrJyaTW46pX4vCW15aT4DOad+KpIa60wdbmZdiRpCiwD9vGjsXQ+tG69Y+Y37AdGzOfAvdnEpNYm+Ot7qjnv3k1dqC0SkE3WGyA4KGlRKSLpi6y/RXBCqi5r38pF53EtY4M3E7U7QRFKU/VRzWL+Z3utmJCcTBq8ptglH9gTqyVKDNpwWDldCUWLPZNtbTMiqrngK1JnBaAb465udDbs4TK5ziDzaUS+NVsjntzG/7CZrWWHRyjKt9TG6lmiWghUPvzHOSH8Oib9dtFio4+/9KsxnHNiW4ltdmt/m1rc0Gwsq4SIFdOT/RjogyX+ip06qMDBtJ8UaWXiL9WkDnmopaNe+b4C+OxDeKVkBQ8x6E+b9Eo4A3tOhodXkxORGcLmrlUCZJm+XQBP0YOO5MhfnDeNI/Q4LlwTFIQCHMaO4ii9XB1jq+8bdr/Ei6eAXMhyJ0H0JTku5viDHmag29z3f6kn3F8ol+19oaaTBRzybP02EszC+LEi; 4:JDT64ghJvPPHIWAm0F3FmTIRZ38/KH8pUd73soUjvAlm3XUA1e7m5ChiRcrmb06HxkWeR641IrcsrQFsUe2V7DoSTS6MIa3uZx5w6wxqrSmWmrWvoIO+QDY9iN3Kili0v7+pJSYx/+18ctxCI9q3xQTKNjVnjMAFpEVbrotoGOkCDbiTErlrVSDSrp5Tt/icRG/6kQp+Dfv8NHEfgiN78/MDl8GqTU4BfOP4L9ahtBpic/Ikc/Li4kL3e6K0hrcg8DLRUxRJUgsEHxJXnjQy0L3CyU7qksnXtCrAccNnb8XMGMMYZ73JHSHsx6m8expn86bZTez0kSkui3FArbhBF99kvKLjMQ6tlSJ/agLAvEuvLx0d1wWnD24GRYcCf8IBYgS2gNhrxAAmar+20Qk4nQ== 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)(10201501046)(3002001)(6055026); SRVR:CO2PR05MB794; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB794; X-Forefront-PRVS: 0912297777 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6049001)(6009001)(24454002)(377454003)(77096005)(81166005)(189998001)(5001770100001)(230700001)(83506001)(65816999)(76176999)(86362001)(2950100001)(87266999)(54356999)(4001350100001)(5008740100001)(36756003)(59896002)(1096002)(65806001)(50986999)(50466002)(92566002)(23746002)(4326007)(586003)(6116002)(5004730100002)(47776003)(80316001)(93886004)(65956001)(2906002)(3846002)(64126003)(33656002)(42186005)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB794; H:[172.29.34.60]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CO2PR05MB794; 23:wMO59qU0k47xgOhABuicvEUGaNy/+t6jdM7Zqb?= =?Windows-1252?Q?Y5WT00BRTd1SH2oe7R4zrPCY5dMWKfZTeku/tbvCtUscH6I8/eG1lT00?= =?Windows-1252?Q?t20u+tkNsgV03R+eGh7APjv2pCCBUD1IoP+ReGA3amaCVjkLfh5pyzqG?= =?Windows-1252?Q?/2HNG2GYKfo5vXgxPpkoQePrVGBBHEW6L2pGMq5WBGubK4mvcCIErNsc?= =?Windows-1252?Q?AW+GB46cHPMciTkRaPBb3Zb348YiqOOBU4RG8RXqxtwNrFoq4neFI9Ks?= =?Windows-1252?Q?KckiUCpOiyJb7UVSYLQ4ZfkXarFPtCZSKD7nX+36EoygqE6SQR6GX/sF?= =?Windows-1252?Q?mXNSLdNbeo1CQ5AGNqfr5OR+XHp5Zt9+hfSRrfHWPgTT4gwpCsROYmuH?= =?Windows-1252?Q?nIl5SvETUEH9uBKLfAOPBFP71Y+hDrjA0dgyd4bvnknO466MgDqP3FuG?= =?Windows-1252?Q?Q0GbRFd4mtMdQ/0ihWbp3MH2Fjl9hheBt1HHddn4YtJKD4WUQCcVvhHK?= =?Windows-1252?Q?PDzxRKaDSqTRGJBSVb70HIelhR2rEUpfQnTVhHPX52ry7xUrjgEUUtAw?= =?Windows-1252?Q?MH45HLzpqDNoYio/kNPgxP2X5NirXDWG0HVi4mCyhz/Kuru4Rk8hw86J?= =?Windows-1252?Q?sYcETDQ5c25gEERJlOsFHb0nCx/6P8Mhoozn4IdrX4xwHdwfpARiUVw0?= =?Windows-1252?Q?10judr+Y8ym8ebPDwrcpbASwLQJmibRaVlg7VzxqCIpgNYRy0hNUSyuL?= =?Windows-1252?Q?gB8QC95qcE3/HzwC3+lRpxetKpTBZrsSI5rQdl0zTpe5x0wSInlTZBri?= =?Windows-1252?Q?zb174/Iv32JM4ReMm2Li4uB7J7X7xYeAit3LqBL9fMbJLhSEAPUpjVFF?= =?Windows-1252?Q?Relci15kCC01Tx0J5MORrKdxoPCS/RolAUdPkKtKhhMcGL4tT5PXDmVY?= =?Windows-1252?Q?T/bl0wMNJtrgUfCzMwFbXrlTdMzHmwTLV7nmckVH24SUmjsfZYY2Lzrs?= =?Windows-1252?Q?EEIkJUYpty3DEUrp5yB6hUJbycKOLXGsKG4N9cebmE7N0bnsduUOpP7u?= =?Windows-1252?Q?O+qAGcpZWa0BM0B0MevZNxTU22jGuvW9+t6FC8W9LvE2g5VLZ7bA1gli?= =?Windows-1252?Q?EnUyvOyz8Bf/kBctqvzCVuo9OP/Tzg/AEqG96gTinvm7P1YWZZR4/y2J?= =?Windows-1252?Q?PzZcNTxNmXNPUneSzZyEdZ8nK+YNxQbIw9MuRCDc0RqZI5jmb4USc+CH?= =?Windows-1252?Q?fbhZAae1S3+76CvbXA6+Tm6+rwWB/rP3R6rDE=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB794; 5:wBy0lGCHmYB4GphNKpxlA6fBT63c2fpPQZG/zLYUHo4yxjSrnlsYV3cjvU0Q1/BAqil2YXpJm3lgdPWDO034TLWl/oLtJhxxA1pXdP38e5lCWcNtmLZvtiS2ZVGje1NePI7+Ha92LdazIpVjgAiW8A==; 24:1g6HlNCMBOpioI0aXSxa188COyyimQYV+Y96WOXlRMrciFAcLDVV12DRgmEfzyslWJcnP4EPFpMOSEBHq+jmSjWdRsC/VeCsCRgI2osYKHw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2016 13:19:02.2722 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB794 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:19:32 -0000 On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: > Stewart and all, > I concur with Stewart that there is a strong case for 0 in the first nibble for all non-IP flows. > > As for the need for sub-typing: > AFAIK quite a few implementations (including some HW-based packet processors) treat 0 in the first nibble after the label stack as an indication of an Ethernet PW. > > Some of them go as far as to hash on the assumed L2 headers for ECMP. This causes serious problems, e.g., with the TDM PWs that could be reordered if handled by such packet processors in transit LSRs. > > This makes quite a case for sub-typing IMO regardless of BIER. > At the same time, it seems that all the bits in CW structure are used - at least for some PW types in some cases. It seems to me that Sasha's reasoning supports the conclusion that it is best to avoid 0 in the first nibble (even if this is not the conclusion he drew!) I don't think sub-typing is a solution, because it doesn't offer any protection against the behavior of existing hardware. On 4/14/2016 5:31 AM, Stewart Bryant wrote: > The nibble value is recorded in the IP types registry > and any wish to take another value really needs to be discussed > with the INT area. Are you referring to the IP Version Number registry? (I am not aware of an "IP types registry".) We're not asking for any modification to that, since we're not doing another version of IP. I don't see any need to get into one of those long and non-productive arguments that the INT area seems to relish. On 4/13/2016 11:07 PM, Xuxiaohu wrote: > In fact, there is an attempt to have a registry for the first nibble (a.k.a., MPLS payload type field). Hopefully that attempt won't succeed! On 4/14/2016 7:06 AM, Loa Andersson wrote: > While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: > > It is REQUIRED, however, that applications depend upon in-order > packet delivery restrict the first nibble values to 0x0 and 0x1. > > If that is what we want for bier, there is a case to use 0x0 or 0x1 for > bier- Strictly speaking, RFC 4928 needs to be updated, as the reasoning given there does not really support the above "requirement". But the effort to do that hardly seems worthwhile. RFC 4928 already makes clear that the above requirement is protecting against the risk that IPv5 ECMP will affect some MPLS packets inappropriately. No one seems to think that that is a real risk. From nobody Thu Apr 14 06:28:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF61112DF64; Thu, 14 Apr 2016 06:28:13 -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=eci365.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 k7LMMmtDJ7pZ; Thu, 14 Apr 2016 06:28:12 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2801912DEF0; Thu, 14 Apr 2016 06:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lOexkwukhbKaJWaSEDgKZ/OK41yCqkkkb7YC35K+dqc=; b=L2ZGJtOy2fX4OUZ6eZf8wLdamRfm6z0lQNO0OLabq5DmMeU0UwBMqoKQKJE4/+O2tqaqnizH0Xl3GoGmmd0kKu7v2WvWpfRIUWV8UWq319BQPcgUG6UUm+uKhhJPusEHnP1Us6u8K3YX0Z7sjlcp7GXt1BcnXCkQ/ebO2nYBK4c= Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0777.eurprd03.prod.outlook.com (10.161.54.27) with Microsoft SMTP Server (TLS) id 15.1.466.19; Thu, 14 Apr 2016 13:27:55 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0466.020; Thu, 14 Apr 2016 13:27:55 +0000 From: Alexander Vainshtein To: Eric C Rosen Thread-Topic: [mpls] [bier] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRllA6BIS7R/2LtUKjKvnrhpryyJ+JdShQ Date: Thu, 14 Apr 2016 13:27:55 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> In-Reply-To: <570F9901.2080406@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 31e35eb0-2ad8-4258-947e-08d36468968f x-microsoft-exchange-diagnostics: 1; DB3PR03MB0777; 5:Km9XeE6e13bIncs91Aggxb05ezyefuvibMiOvWFGw///1QAlFdf56qrKmwL5K8+uUhBaBTRqUCA+hWjTb9baGZMWQYEZA3WekBDstRk8E/tZny3D+i3xgFmFvKXVF8eM5HsYNVTzS9qgwVNCltICNoQXm7yiyYydH0O2p35ACbKk4nPbCis2F88YV8bvFDkv; 24:CiwivTqhzZexfs6zuolFd4/Gq02hNnpks6J13AR/NVZA0SukbSvzcRXfE/OSuru7zM02iRPtXCQGp7pRY1fU8gBJ0zskVHiCWD6+YIYVQNM=; 7:BE8qc3l4epeH0ZRk5X2Va9AT046Pco7EK5Fw1LlUscQlOfDAUNnBFpK9yZK7oEY9xAZsUjqQwrNeOhUwf5b5l90qpKGjerhQcAEXPWtgZkrq+r8B8md7dK1bICRcexvi3s1BjNbwf7r33M3KKsuq4C6hROUwsCpHoLG2VnStqRbthjKWntRLLOdlknEMSVZ0Bq7yefxh0u7h88HiJi4iu2JYuvchaQQU1lAhw51jN0E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0777; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB3PR03MB0777; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0777; x-forefront-prvs: 0912297777 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(252514010)(24454002)(5002640100001)(122556002)(87936001)(81166005)(74316001)(11100500001)(5003600100002)(2950100001)(92566002)(93886004)(5008740100001)(2900100001)(9686002)(106116001)(10400500002)(66066001)(86362001)(4326007)(1220700001)(189998001)(110136002)(3660700001)(76576001)(102836003)(76176999)(3846002)(6116002)(1941001)(33656002)(3280700002)(77096005)(5004730100002)(19580395003)(50986999)(19580405001)(586003)(54356999)(2906002)(1096002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0777; H:DB3PR03MB0780.eurprd03.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: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2016 13:27:55.3334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0777 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:28:14 -0000 Eric, I suspect (will have to check) that the packet processor I've mentioned act= ually would not differentiate between 0 and 5 in the first nibble. They tend to consider anything with neither 4 or 6 in the first nibble as E= thernet PWs. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Eric C Rosen [mailto:erosen@juniper.net]=20 Sent: Thursday, April 14, 2016 4:20 PM To: Alexander Vainshtein; Stewart Bryant Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda; Greg Mirsky Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS enca= psulation On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: > Stewart and all, > I concur with Stewart that there is a strong case for 0 in the first nibb= le for all non-IP flows. > > As for the need for sub-typing: > AFAIK quite a few implementations (including some HW-based packet process= ors) treat 0 in the first nibble after the label stack as an indication of = an Ethernet PW. > > Some of them go as far as to hash on the assumed L2 headers for ECMP. Thi= s causes serious problems, e.g., with the TDM PWs that could be reordered i= f handled by such packet processors in transit LSRs. > > This makes quite a case for sub-typing IMO regardless of BIER. > At the same time, it seems that all the bits in CW structure are used - a= t least for some PW types in some cases. It seems to me that Sasha's reasoning supports the conclusion that it is be= st to avoid 0 in the first nibble (even if this is not the conclusion he dr= ew!) I don't think sub-typing is a solution, because it doesn't offer any = protection against the behavior of existing hardware. On 4/14/2016 5:31 AM, Stewart Bryant wrote: > The nibble value is recorded in the IP types registry and any wish to=20 > take another value really needs to be discussed with the INT area. Are you referring to the IP Version Number registry? (I am not aware of=20 an "IP types registry".) We're not asking for any modification to=20 that, since we're not doing another version of IP. I don't see any need to = get into one of those long and non-productive arguments that the INT area = seems to relish. On 4/13/2016 11:07 PM, Xuxiaohu wrote: > In fact, there is an attempt to have a registry for the first nibble (a.k= .a., MPLS payload type field). Hopefully that attempt won't succeed! On 4/14/2016 7:06 AM, Loa Andersson wrote: > While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: > > It is REQUIRED, however, that applications depend upon in-order > packet delivery restrict the first nibble values to 0x0 and 0x1. > > If that is what we want for bier, there is a case to use 0x0 or 0x1=20 > for > bier- Strictly speaking, RFC 4928 needs to be updated, as the reasoning given the= re does not really support the above "requirement". But the effort to do t= hat hardly seems worthwhile. RFC 4928 already makes clear that the above r= equirement is protecting against the risk that IPv5 ECMP will affect some M= PLS packets inappropriately. No one seems to think that that is a real risk= . From nobody Thu Apr 14 07:41:47 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93A12E442; Thu, 14 Apr 2016 07:41:46 -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 cNpYnxB9X-75; Thu, 14 Apr 2016 07:41:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB7112E3E7; Thu, 14 Apr 2016 07:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3328; q=dns/txt; s=iport; t=1460644904; x=1461854504; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MGbomDxw7Qtxcp/k1fATf4Pl7dur5jWIMzdcf+9Feos=; b=gn6QKP6x+DSnfAaPQbulNoA5kEG5sryNAgNAXXnt/4feLS1YriI4c6dz 6UacWvZ9XTcS9jVXMc4G9ZiQz4qOU38zCR38WXCb6FreWSa5Mr8x3+CDe GjAJ0gR8HSVcI7gRUHxWEDXVLxqLqNV91AhciIOa+QA/uSLfka5uTZVO1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgCZqw9X/4sNJK1UCoM4U30GuikBD?= =?us-ascii?q?YFxFwuFbAKBNzgUAQEBAQEBAWUnhEIBAQQBAQFrCxACAQgYLicLJQIEAQ0FG4g?= =?us-ascii?q?ODsJKAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKbIQVKIVYBY4KigEBiGmFI48Qj?= =?us-ascii?q?ygBHgEBQoIDGoFKbIhIfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="91456867" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 14:41:43 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3EEfhft024662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 14:41:43 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 09:41:43 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 09:41:43 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Eric C Rosen , Alexander Vainshtein , Stewart Bryant Thread-Topic: [mpls] [bier] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRllBPnKj84mXOL0uPk6xlEkdjZJ+Jm6UA Date: Thu, 14 Apr 2016 14:41:43 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> In-Reply-To: <570F9901.2080406@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.172.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <369626A8A294504F9D9C36DA926324FF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:41:46 -0000 Hi, Per IANA registry, 0-1 are =B3Reserved=B2 and so is not strictly assigned w= ith PW. Something like a modified CW beneath LSE?. Further, BIER is hop-by-hop lookup based. So I think we don=B9t need to include this always. Instead, w= e could conditionally include this, if the next BFR is tunneled (not directly connected). The receiving node will use the label to identify the payload/FEC. So I think, the presence of modified CW should not confuse it with PW. Thanks, Nagendra On 4/14/16, 9:20 AM, "mpls on behalf of Eric C Rosen" wrote: >On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >> Stewart and all, >> I concur with Stewart that there is a strong case for 0 in the first >>nibble for all non-IP flows. >> >> As for the need for sub-typing: >> AFAIK quite a few implementations (including some HW-based packet >>processors) treat 0 in the first nibble after the label stack as an >>indication of an Ethernet PW. >> >> Some of them go as far as to hash on the assumed L2 headers for ECMP. >>This causes serious problems, e.g., with the TDM PWs that could be >>reordered if handled by such packet processors in transit LSRs. >> >> This makes quite a case for sub-typing IMO regardless of BIER. >> At the same time, it seems that all the bits in CW structure are used - >>at least for some PW types in some cases. > >It seems to me that Sasha's reasoning supports the conclusion that it is >best to avoid 0 in the first nibble (even if this is not the conclusion >he drew!) I don't think sub-typing is a solution, because it doesn't >offer any protection against the behavior of existing hardware. > >On 4/14/2016 5:31 AM, Stewart Bryant wrote: >> The nibble value is recorded in the IP types registry >> and any wish to take another value really needs to be discussed >> with the INT area. > >Are you referring to the IP Version Number registry? (I am not aware of >an "IP types registry".) We're not asking for any modification to >that, since we're not doing another version of IP. I don't see any need >to get into one of those long and non-productive arguments that the INT >area seems to relish. > >On 4/13/2016 11:07 PM, Xuxiaohu wrote: >> In fact, there is an attempt to have a registry for the first nibble >>(a.k.a., MPLS payload type field). > >Hopefully that attempt won't succeed! > >On 4/14/2016 7:06 AM, Loa Andersson wrote: >> While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: >> >> It is REQUIRED, however, that applications depend upon in-order >> packet delivery restrict the first nibble values to 0x0 and 0x1. >> >> If that is what we want for bier, there is a case to use 0x0 or 0x1 for >> bier-=20 > >Strictly speaking, RFC 4928 needs to be updated, as the reasoning given >there does not really support the above "requirement". But the effort >to do that hardly seems worthwhile. RFC 4928 already makes clear that >the above requirement is protecting against the risk that IPv5 ECMP will >affect some MPLS packets inappropriately. No one seems to think that >that is a real risk. > > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 14 08:12:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B151612D889; Thu, 14 Apr 2016 08:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 LMHncxPoSfR5; Thu, 14 Apr 2016 08:12:07 -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 0239B12DAAD; Thu, 14 Apr 2016 08:12:03 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 4AD81180156F; Thu, 14 Apr 2016 17:11:59 +0200 (CEST) To: "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein , Stewart Bryant References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> From: Loa Andersson Message-ID: <570FB333.5080509@pi.nu> Date: Thu, 14 Apr 2016 23:11:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:12:10 -0000 Nagendra, The IANA registry you refer to is the IP Version numbers http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1 Please note that this registry does not globally define what needs to be in the first nibble of a packet carried over mpls, it the payload is IP you are correct. If the payload is e.g. a PW then 0x0 in the first nibble of the payload indicates that it is PW the first nibble refer to to the PWMCW (Pseudowire MPLS Control Word), if the first nibble is 0x1 it tells you that this packet belongs to GACh. /Loa On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > Per IANA registry, 0-1 are Reserved and so is not strictly assigned with > PW. Something like a modified CW beneath LSE?. Further, BIER is hop-by-hop > lookup based. So I think we dont need to include this always. Instead, we > could conditionally include this, if the next BFR is tunneled (not > directly connected). > > The receiving node will use the label to identify the payload/FEC. So I > think, the presence of modified CW should not confuse it with PW. > > Thanks, > Nagendra > > > On 4/14/16, 9:20 AM, "mpls on behalf of Eric C Rosen" > wrote: > >> On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >>> Stewart and all, >>> I concur with Stewart that there is a strong case for 0 in the first >>> nibble for all non-IP flows. >>> >>> As for the need for sub-typing: >>> AFAIK quite a few implementations (including some HW-based packet >>> processors) treat 0 in the first nibble after the label stack as an >>> indication of an Ethernet PW. >>> >>> Some of them go as far as to hash on the assumed L2 headers for ECMP. >>> This causes serious problems, e.g., with the TDM PWs that could be >>> reordered if handled by such packet processors in transit LSRs. >>> >>> This makes quite a case for sub-typing IMO regardless of BIER. >>> At the same time, it seems that all the bits in CW structure are used - >>> at least for some PW types in some cases. >> >> It seems to me that Sasha's reasoning supports the conclusion that it is >> best to avoid 0 in the first nibble (even if this is not the conclusion >> he drew!) I don't think sub-typing is a solution, because it doesn't >> offer any protection against the behavior of existing hardware. >> >> On 4/14/2016 5:31 AM, Stewart Bryant wrote: >>> The nibble value is recorded in the IP types registry >>> and any wish to take another value really needs to be discussed >>> with the INT area. >> >> Are you referring to the IP Version Number registry? (I am not aware of >> an "IP types registry".) We're not asking for any modification to >> that, since we're not doing another version of IP. I don't see any need >> to get into one of those long and non-productive arguments that the INT >> area seems to relish. >> >> On 4/13/2016 11:07 PM, Xuxiaohu wrote: >>> In fact, there is an attempt to have a registry for the first nibble >>> (a.k.a., MPLS payload type field). >> >> Hopefully that attempt won't succeed! >> >> On 4/14/2016 7:06 AM, Loa Andersson wrote: >>> While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: >>> >>> It is REQUIRED, however, that applications depend upon in-order >>> packet delivery restrict the first nibble values to 0x0 and 0x1. >>> >>> If that is what we want for bier, there is a case to use 0x0 or 0x1 for >>> bier- >> >> Strictly speaking, RFC 4928 needs to be updated, as the reasoning given >> there does not really support the above "requirement". But the effort >> to do that hardly seems worthwhile. RFC 4928 already makes clear that >> the above requirement is protecting against the risk that IPv5 ECMP will >> affect some MPLS packets inappropriately. No one seems to think that >> that is a real risk. >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > From nobody Thu Apr 14 11:06:19 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49512D72A; Thu, 14 Apr 2016 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehOeEsKqcJ83; Thu, 14 Apr 2016 11:06:15 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 F20B912D6E0; Thu, 14 Apr 2016 11:06:14 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n3so137906909wmn.0; Thu, 14 Apr 2016 11:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SKG0GpXPAPu11jLNObBU5etFGDsX+PPW2XSw1FDt6P8=; b=DemucUhndEAVGm/Irvu32oUGuilXT+/+YABixtu4R4TCXtVcEppouQYoLVwDMdAIJe PDLj/slMPMussVblhB5qmTInenY3YnBRM5j8VpQdITcp6QSWOlGriseOVl69lCUiq0uv rCbhEkIUQspnOpkHnhUOerlJ1EHD4O/A2iu6lUBHHnN/9eUZTCbg+xEGd6T2d8p8FX9A 7JrFWVWkaq1//WAhABDnkjH1/Ti0aPRbLYhfW3YiPb23GF5Wo0RJ3EBQfJx2OX/svzWw uOsBn6NFPX5xbsuIy+/12qsYmPOO2dzAo+tbpAnPumUi7OQMSzfa8m/k3aXB7t9sBHHS 0GLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=SKG0GpXPAPu11jLNObBU5etFGDsX+PPW2XSw1FDt6P8=; b=lRxGXNnkfglI1Kmp5PCvNfJ7wPJwfrcE91mYZVLBD4CNqdVpc1q1xUOvz08vblXR5G HZRHzVt4Guy9bLwzojp8O6RjPqbvjffQd9Jq5A2hlham+mrF9mnRfnU30wwICM9CdB4X UBsMpLlFw2Hn4MWC441pMLlbqtGdC08tw88QCKRgZ6E8+2uFSLO/tXJFRO0qHMyG2wBh UERyT8x6NzZbrdCrhqtYa+Z6S9iqr0ANCCDj+oEPNK3tZaUQ9xbjKxTQmgNU25443bDt 2sg0UTP2k+DRWjr+r28Bk60Ydq/7eHvmP0aw/km9JsFoQGHU26TAOLsGESTdYgkm72AE QfRg== X-Gm-Message-State: AOPr4FWDtZSwvQ2g5dvFdwqOGBat735lyzTmzTFNZKcLv2vFvYlk7dbpeowUjEHzWlUe8w== X-Received: by 10.194.63.8 with SMTP id c8mr17867516wjs.89.1460657173497; Thu, 14 Apr 2016 11:06:13 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id gt7sm45188321wjc.1.2016.04.14.11.06.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 11:06:12 -0700 (PDT) To: Loa Andersson , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F79AB.9070107@pi.nu> From: Stewart Bryant Message-ID: <570FDC12.6090505@gmail.com> Date: Thu, 14 Apr 2016 19:06:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <570F79AB.9070107@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 18:06:17 -0000 On 14/04/2016 12:06, Loa Andersson wrote: > Sasha and Stewart, > > > On 2016-04-14 18:06, Alexander Vainshtein wrote: >> Stewart and all, >> I concur with Stewart that there is a strong case for 0 in the first >> nibble for all non-IP flows. > > While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: > > It is REQUIRED, however, that applications depend upon in-order > packet delivery restrict the first nibble values to 0x0 and 0x1. > > If that is what we want for bier, there is a case to use 0x0 or 0x1 for > bier- 0x1 is of course the OAM identifier, i.e. the GACH indicator, which BIER is also free to use with appropriate channel type. Stewart > > /Loa >> >> As for the need for sub-typing: >> AFAIK quite a few implementations (including some HW-based packet >> processors) treat 0 in the first nibble after the label stack as an >> indication of an Ethernet PW. >> >> Some of them go as far as to hash on the assumed L2 headers for ECMP. >> This causes serious problems, e.g., with the TDM PWs that could be >> reordered if handled by such packet processors in transit LSRs. >> >> This makes quite a case for sub-typing IMO regardless of BIER. >> At the same time, it seems that all the bits in CW structure are used >> - at least for some PW types in some cases. >> >> Regards, >> Sasha >> >> Office: +972-39266302 >> Cell: +972-549266302 >> Email: Alexander.Vainshtein@ecitele.com >> >> -----Original Message----- >> From: Stewart Bryant [mailto:stewart.bryant@gmail.com] >> Sent: Thursday, April 14, 2016 12:32 PM >> To: Eric C Rosen; Alexander Vainshtein; Greg Mirsky >> Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda >> Subject: Re: [mpls] [sfc] The first nibble issue associated with MPLS >> encapsulation >> >> I am not sure zero is PW so much as "type undefined - don't ECMP". >> That was certainly the definition that we were talking about at the >> time. >> >> The nibble value is recorded in the IP types registry and any wish >> to take another value really needs to be discussed with the INT area. >> >> Also the code space is so small that we really need to be super >> conservative in its allocation. Given it's true purpose, I suggest >> that we only have the unused deprecated values of 0 (taken), 1 >> (taken), 2, 3 and possibly 5 available for use (for ever). >> Seven and up really should be kept available to the IP protocol itself. >> >> Five of course was deployed. It was used for some form of streaming >> protocol, but it is probably safe to assume that it is no longer in >> the wild. >> >> Whilst Eric makes a case for 5, I think there is also a strong case >> for zero. >> >> If there is a need for subtyping zero for wireshark etc, we could >> take a look at what the use is made of the second nibble in PWs and >> see if there is a set of values never in practise used and thus >> available for subtyping. >> >> - Stewart >> >> >> On 11/04/2016 15:19, Eric C Rosen wrote: >>> (Removed sfc from the cc-list, this seems out of scope for that WG.) >>> >>> In designing the BIER header, the BIER WG is free to mandate any value >>> it chooses in the first nibble. These values do not come from a >>> "first nibble" registry. >>> >>> It seems prudent to put a value like 5 for the following reasons: >>> >>> - If a BIER packet is being parsed by an off-line tool, this is a good >>> hint (though just a hint) that the packet is actually a BIER packet; >>> >>> - If a BIER packet is traveling through an MPLS tunnel, and it >>> traverses a node that does its MPLS load splitting by guessing at the >>> type of the payload, then this is a good hint that the MPLS payload >>> is not IPv4, IPv6, or PW. >>> >>> This strategy does incur a risk. Suppose IPv5 gets designed, >>> implemented, and deployed, and folks start to deploy hardware that >>> does MPLS load balancing by inspecting the IPv5 headers of the MPLS >>> payloads. If a BIER packet is traversing an MPLS tunnel, >>> inappropriate load splitting may occur if the hardware thinks the >>> payload is IPv5 rather than BIER. >>> >>> This particular risk doesn't seem very significant to me. >>> >>> Thus I don't think there's anything here that needs fixing. >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> From nobody Thu Apr 14 12:31:50 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C211B12E1D8; Thu, 14 Apr 2016 12:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSkgan7lnU3D; Thu, 14 Apr 2016 12:31:48 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D16FF12E1C0; Thu, 14 Apr 2016 12:31:47 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id u206so2742438wme.1; Thu, 14 Apr 2016 12:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rkGqqN+IaknXm6o/zvVPp/DYztSQXJ5AlMUyb8jMHOQ=; b=uS2jJKgZS1vkK4ik4Ep9HDmkBDZDVoPPMTuUikd86jIrLa4ogEXCedA8vRYWxA6IkO 7RM8ZNNF/H7rCowkuzILCxs9EKBEoOWFQj/TyWGpJYZ8Pp/UnJbHBKs1T+b6gPm+jcO/ nE8XKj6/3THYU7fxXKB20fcc7C7IkULZyagvP2eveP7mNxTMqGcxMkmE0DgaAMAOAVpN hdJVT1rgRN4+lMIrRVimk6is2/q1Naom9ixKmygHQ4N9mtuhXIcTnpCFkRz4avPAXMK1 0wiT7O/ZoRxHutLGwLnt8IyBIrXedZevw6UtCwHT+CMvSzr6QaB7TQ8BBSMc5ihXxRGl mNlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rkGqqN+IaknXm6o/zvVPp/DYztSQXJ5AlMUyb8jMHOQ=; b=hXR+bRW8gN01tr/alJ9HT881lmKHra0OYTlXzESXith0eFKEXTN2UiYTvCS7FyeFWh h2Vv9EfwvNZEXBtbeVdlKdUe6gtvsVBGRfT+tODNsqT3qyjRHqO7AAMnnio2NmS3Vi/3 98DzG2ucq9h6pPRP8xZ+1PW1d58aP+oBShhkuR8lO59y4eHlSUV1aNoLyMYZV6fU89R+ WxaASJ1nDKSZBbrjJvPj46m6M3F669khrDAXU5S4OfJtRFvqSQ+V/45OaJDggtm75503 hzdwpUzBckHmiVjOq0WQVOcbvVn0gEhyjJwRRI1zGY2qDhqVbOS7Mk+nQqj2nSbZsvTO BOYw== X-Gm-Message-State: AOPr4FW8cZGSkis7lizDkrAW0YW4uaDTDYbbzEcolTWCQ5RTpFQGVBFh6UecC0qXfDvMRQ== X-Received: by 10.194.26.4 with SMTP id h4mr614172wjg.104.1460662306343; Thu, 14 Apr 2016 12:31:46 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y3sm34749103wmy.17.2016.04.14.12.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 12:31:45 -0700 (PDT) To: Eric C Rosen , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> From: Stewart Bryant Message-ID: <570FF01F.6090403@gmail.com> Date: Thu, 14 Apr 2016 20:31:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <570F9901.2080406@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:31:50 -0000 On 14/04/2016 14:20, Eric C Rosen wrote: > On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >> Stewart and all, >> I concur with Stewart that there is a strong case for 0 in the first >> nibble for all non-IP flows. >> >> As for the need for sub-typing: >> AFAIK quite a few implementations (including some HW-based packet >> processors) treat 0 in the first nibble after the label stack as an >> indication of an Ethernet PW. Well there will be Ethernet PWs not using the CW that can put any Ethernet address in the first nibble, so if there are Ethernet addresses that start with 5 they will look like BIER packets. >> >> Some of them go as far as to hash on the assumed L2 headers for ECMP. >> This causes serious problems, e.g., with the TDM PWs that could be >> reordered if handled by such packet processors in transit LSRs. >> >> This makes quite a case for sub-typing IMO regardless of BIER. >> At the same time, it seems that all the bits in CW structure are used >> - at least for some PW types in some cases. > > It seems to me that Sasha's reasoning supports the conclusion that it > is best to avoid 0 in the first nibble (even if this is not the > conclusion he drew!) I don't think sub-typing is a solution, because > it doesn't offer any protection against the behavior of existing > hardware. There is no truly safe position until we mandate that all deployed PWs use the CW, but that is not going to happen for a while. > > On 4/14/2016 5:31 AM, Stewart Bryant wrote: >> The nibble value is recorded in the IP types registry >> and any wish to take another value really needs to be discussed >> with the INT area. > > Are you referring to the IP Version Number registry? (I am not aware > of an "IP types registry".) We're not asking for any modification to > that, since we're not doing another version of IP. I don't see any > need to get into one of those long and non-productive arguments that > the INT area seems to relish. > Sorry I meant version number. Before we assign a member of this very small number range to BIER, I would like some confidence that it will see any significant deployment. When PW took 0 and 1, it was already a widely deployed protocol. Stewart - Stewart From nobody Thu Apr 14 12:35:14 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65612DFD9; Thu, 14 Apr 2016 12:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6RoNUgjUEzk; Thu, 14 Apr 2016 12:35:12 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 DE28512DFB7; Thu, 14 Apr 2016 12:35:11 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u206so2857827wme.1; Thu, 14 Apr 2016 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=J8lx4kqjWfOwH54VdrJNiT2tXtGfqC9nGMmR1W2LX3s=; b=bmhjquclwxmSuKgRPsntmrpNO0x2mDEwFN/TP5bHrfA+0752RoOxv0admxkxDGe/oH BHue6a5YBqXmtuHuPEGzIy0THkU036bIWkNcuvy2CqERvbfUXttv2efwBgh3B3fWl8Wt ixFXDh+a34gRkRqFpajuOK88jhfRsFcpV3H8eBAsZmloRY3/s8Ub9mKlqDtdXDV6UaKs PtPaQv5UDP69JAyCTHr4FCGskLzR7QFF524Yf7dbJpTAtuCfZhTxF92XPxC0NHWyBoKA C9ifpMXFHVycnvYfIR2tuHrgx4JocGd9VsuFApXpNlE05n4qLYmX//CeR9rEz0/92+sY 8PNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=J8lx4kqjWfOwH54VdrJNiT2tXtGfqC9nGMmR1W2LX3s=; b=Or0zVGWUHcrdv/3GO6oH7tDfHDnmQSOtCO11Pl3vc3QOciy0CJwJID3nmnyDJlyYWm H4fHZpqB4/uYMva0wAEwZWLezEyjq2LXta0Dj0y9tSftYdPTMSvAK0VrINMFhdhNhZyc fCJ8CMOYILySo/CWHSL+BMzeGHs/v18BnN2+ehnX+kUuQFQpsmEw1/sseHBfWD/GIy4U a8cKWCMNPAYK18OTtmw5NEOmi71mSPJ1yK1A82T8OFwBifkLfHqzaxDgYeuODNPUrYAp 6v0gfRLjldtDj+GFoHWb5axSSwV+mtSYSIaTgU+ZlwbNElwcOpn7T0eQR/w8WaazHwLZ guTg== X-Gm-Message-State: AOPr4FUilgoUPMTReZ5IZ+Z5HH75EJilVaDDHzgEMdIb01lBS570aVq5pt2H0zKo3Rx/xQ== X-Received: by 10.194.123.65 with SMTP id ly1mr17897143wjb.125.1460662510502; Thu, 14 Apr 2016 12:35:10 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id dj8sm3999681wjc.28.2016.04.14.12.35.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 12:35:09 -0700 (PDT) To: "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> From: Stewart Bryant Message-ID: <570FF0EB.6070106@gmail.com> Date: Thu, 14 Apr 2016 20:35:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:35:13 -0000 On 14/04/2016 15:41, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > Per IANA registry, 0-1 are Reserved and so is not strictly assigned with > PW. True, but PW caused then to be reserved so as to prevent future clashes. Stewart From nobody Thu Apr 14 12:36:36 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E127612E0EB; Thu, 14 Apr 2016 12:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmcEY_9FS4XW; Thu, 14 Apr 2016 12:36:27 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 491F812DA58; Thu, 14 Apr 2016 12:36:26 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n3so2972446wmn.0; Thu, 14 Apr 2016 12:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=vOBRWpNYAy66lSlgFdLCoAOyIbSOLXeoojpME7eKc7s=; b=c4y0+rJ4aYNs3+jSOVRlZBFyaM/VCSyplYHpjvhqm8Z07rZsxw2w6msOh5BDle8MwQ p1zx7vWAxqXmCI75UXFfGHdq6yV5kHrq+q0+lAhgULbl7abvuhSAygR8plrVbdO8xbli OWTeFGp3vXoHkR25C7HeM5VxgS6EvPGsJSdt6S96rMi3+cmtzr7ytJfkpeoZV167B/yO +biaZhd1XO1s9EMk5I4lRLzek1f9U+qU0o36ecr7ns+hxR4eIK0Kb/nKkkGQ+kaZqwpy H0gHJNyKsaw+gSHn353eHjNwr/VCqNZ1SdXCepxrnrgyUAVuFDv6xzLyWy4OSFZg5Tv9 SrWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=vOBRWpNYAy66lSlgFdLCoAOyIbSOLXeoojpME7eKc7s=; b=m6lFHUiMHB4lCmayyQWcUDU+x5VApkDNJw4VaS2MtWyCYAjtW/+Pk6eNJWo9SRL79v ZDDCoJvngMXuy5pqCBX2ESDT600fC5DMhcrW78jxbQZtxvKJ4tCncTGKH5YF+akUM/lz 1i7DHyTEFlVEsFvJtgPXpX9ER07Z/VQ/dy1spmHUKO4TTvSc3kdVA48aALIKwaZ6AG2o Koq1nW62Dqn4zdflusBvg1DE6kpjJQg3OK1tE9D4/+e/viV5+glelVHw7xScYPS6pQCy 4aaFFbDY2GirqG6YVy3ihO4MrH6liqscbqJyExri5y4OYDRorlN5YpqcLOGrttFnunmt fTDg== X-Gm-Message-State: AOPr4FUYwREa1rj/iHWVgFuG3ApqoNbJNfud9zgp9n/9yWIpAPazcpUx0e5fWDUfO+au5g== X-Received: by 10.28.173.15 with SMTP id w15mr352947wme.32.1460662584821; Thu, 14 Apr 2016 12:36:24 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ll9sm45495273wjc.29.2016.04.14.12.36.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 12:36:23 -0700 (PDT) To: Loa Andersson , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> From: Stewart Bryant Message-ID: <570FF136.7030600@gmail.com> Date: Thu, 14 Apr 2016 20:36:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <570FB333.5080509@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:36:35 -0000 On 14/04/2016 16:11, Loa Andersson wrote: > > > /Loa > > On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: >> Hi, >> >> Per IANA registry, 0-1 are Reserved and so is not strictly assigned >> with >> PW. Something like a modified CW beneath LSE?. Further, BIER is >> hop-by-hop >> lookup based. So I think we dont need to include this always. >> Instead, we >> could conditionally include this, if the next BFR is tunneled (not >> directly connected). >> >> The receiving node will use the label to identify the payload/FEC. So I >> think, the presence of modified CW should not confuse it with PW. Not quite Loa. It could be an Ethernet PW with no CW. Stewart From nobody Thu Apr 14 12:48:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB2512DF8B; Thu, 14 Apr 2016 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 mkQFVo6XMh9D; Thu, 14 Apr 2016 12:48:14 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8925412DEF2; Thu, 14 Apr 2016 12:48:13 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-ae-570fed61f0e2 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 28.A7.09012.16DEF075; Thu, 14 Apr 2016 21:20:02 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 15:48:12 -0400 From: Gregory Mirsky To: Stewart Bryant , Eric C Rosen , Alexander Vainshtein Thread-Topic: [mpls] [bier] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRllBODDlK1XlDUUCMzgo6JOQUU5+KHvqA//+/xkA= Date: Thu, 14 Apr 2016 19:48:10 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A45986@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FF01F.6090403@gmail.com> In-Reply-To: <570FF01F.6090403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPiG7SW/5wg+bP/BZTt35gtlg6Yw+T xboNQNatpStZLU49SLTY/WAjiwObx6Z/xxk9ds66y+6xZMlPJo/rTVfZA1iiuGxSUnMyy1KL 9O0SuDJmbrvFWHBesuLvK+8Gxg0iXYwcHBICJhJLzph0MXICmWISF+6tZ+ti5OIQEjjKKNH2 8jqUs5xR4vbOa+wgVWwCRhIvNvawgyREBLoZJe48nMsEkmAWKJaYcvMRmC0sECaxr6eFCWSD iEC4xIXdcSBhEQEriZajs9hAbBYBVYme079ZQGxeAV+J36vfskMsm80qceLcfbA5nAKaEsv3 7WUGsRmBzvt+ag3ULnGJW0/mM0GcLSCxZM95ZghbVOLl43+sELaixL7+6ewQ9ToSC3Z/YoOw tSWWLXzNDLFYUOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFFaXJCTm25ksIkRGF/HJNh0 dzDen+55iFGAg1GJhzdhEX+4EGtiWXFl7iFGCQ5mJRFet1dAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4ryNwf/ChATSE0tSs1NTC1KLYLJMHJxSDYzpbK+vP3ff+7T/zxmXRZs8OTc/zLi9w73Y 7OG11UFO/0+uDnzQOGFlU0DpH6brE5ms+Rdb9X4sXTTF+/3GZZ6NPMGTw6Q/fzHzWeDnNXdF s9DZWPuf6h2pG0y/PJyUEjP1h56tjmbPkjqjaasKvuVP3rl6d4qCYZy+87TM2MB/bEt1hLKa g3qUWIozEg21mIuKEwG3w2CUqwIAAA== Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 19:48:15 -0000 Hi Stewart, et. al, just wanted to clarify, though that likely was stated on the thread already= , that the problem of the first nibble is only on transient, i.e. P, nodes = that are not aware of the context of the BoS label. And with the fact that = there are old and very old P nodes out there in the network there might be = no absolutely safe solution to the First Nibble issue/concern. Though we ca= n recommend safer policies to handle ECMP on P nodes, e.g. use EL. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, April 14, 2016 12:32 PM To: Eric C Rosen; Alexander Vainshtein Cc: mpls@ietf.org; bier@ietf.org; Dr. Tony Przygienda Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS enca= psulation On 14/04/2016 14:20, Eric C Rosen wrote: > On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >> Stewart and all, >> I concur with Stewart that there is a strong case for 0 in the first=20 >> nibble for all non-IP flows. >> >> As for the need for sub-typing: >> AFAIK quite a few implementations (including some HW-based packet >> processors) treat 0 in the first nibble after the label stack as an=20 >> indication of an Ethernet PW. Well there will be Ethernet PWs not using the CW that can put any Ethernet = address in the first nibble, so if there are Ethernet addresses that start = with 5 they will look like BIER packets. >> >> Some of them go as far as to hash on the assumed L2 headers for ECMP.=20 >> This causes serious problems, e.g., with the TDM PWs that could be=20 >> reordered if handled by such packet processors in transit LSRs. >> >> This makes quite a case for sub-typing IMO regardless of BIER. >> At the same time, it seems that all the bits in CW structure are used >> - at least for some PW types in some cases. > > It seems to me that Sasha's reasoning supports the conclusion that it=20 > is best to avoid 0 in the first nibble (even if this is not the=20 > conclusion he drew!) I don't think sub-typing is a solution, because=20 > it doesn't offer any protection against the behavior of existing=20 > hardware. There is no truly safe position until we mandate that all deployed PWs use = the CW, but that is not going to happen for a while. > > On 4/14/2016 5:31 AM, Stewart Bryant wrote: >> The nibble value is recorded in the IP types registry and any wish=20 >> to take another value really needs to be discussed with the INT area. > > Are you referring to the IP Version Number registry? (I am not aware=20 > of an "IP types registry".) We're not asking for any modification to=20 > that, since we're not doing another version of IP. I don't see any=20 > need to get into one of those long and non-productive arguments that=20 > the INT area seems to relish. > Sorry I meant version number. Before we assign a member of this very small number range to BIER, I would = like some confidence that it will see any significant deployment.=20 When PW took 0 and 1, it was already a widely deployed protocol. Stewart - Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 14 14:43:36 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D63D12DD9C; Thu, 14 Apr 2016 14:43:32 -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 vOyTjVcYuqca; Thu, 14 Apr 2016 14:43:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3A212E46E; Thu, 14 Apr 2016 14:43:27 -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=yS3yzWof/wfjqD6uh3pcg4KyjyiH6RQrPqAxdPalcj8=; b=SNKZj7Kumh7pGW934RqLcKUDKyOfEEHgs5e+ipL8rtaO5dcIUfEo5X0snuQIk50y4cG3uU3ajCBuIXcV5xL9EbBStn4zO5GoFAGk53yUDHjpnZdQ/khV66+aMW+7vx2uRBWVFxVeFoaTGrH7L040l4XGbLw/so5PcJLX4b4PZYg= 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.34.60] (66.129.241.10) by BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 14 Apr 2016 21:43:05 +0000 To: Stewart Bryant , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FF01F.6090403@gmail.com> From: Eric C Rosen Message-ID: <57100EE4.60601@juniper.net> Date: Thu, 14 Apr 2016 17:43:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570FF01F.6090403@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: DM2PR21CA0032.namprd21.prod.outlook.com (10.161.137.170) To BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) X-MS-Office365-Filtering-Correlation-Id: 9a30c831-3001-49d1-37ce-08d364adc3f2 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 2:5yi65tpZqsaY7h/WX57SLAXxzPtvpzdC5Jc9rt6J+RqqBaSZzj2Ke6xEkj9lBeGQgNzdf9sNPZV/44ffpGJwmSrIxrWIE05dCazOKfVL/hIy3lP6K8DGWQoZFdnRqv3Gc0oNpEWg5BkMtG8Q0m7bNDqnrfWdxR5Cwfrh/kkBqrz3WPbFQsCE2ExPZkop6arn; 3:S5HhHssmwgDVXKhTMNUKefS02YXfcGI641ILWJxUK4ggzNWLeVL/hf9sjrKBjlw1ePcYp3m5TbiGtuO3Hrp9jLoanezwzTLdp4bOU79zxxEXVq6HRyUm0v4Ial4XyyRn X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB788; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 25:nbZBoluzZI7h2fjkE3qhgX5ybqnWHkPuvUQlgiw+EQEl1DW7YVx3RTLdQm6blCxg6BQPmSN95xy7OuTnWgu+zVpOfFX60Rc7oMWX5SZX+r+09lbE8rv+ZfdRPtznq6LT8RzqVKu3wCfNcM0oa5ctEGsMcfTJrvixiIYlef08yc4Mmi3j8HUgysfS6bVPBx8f+93QlCCELIXLezYhI9+89kiFGph6ll8E3zdS1u1YnhiO3rcWoA9em2Pg4O+F9PewanPDP1iFv0d0ZR6DEtY6uwumr55yj6veoptX6Px7nqNhUtuc6q4Y7R6wPkd6PdMeIsD9D6aLx0Z5ouXgGh3U/pI3sb64BgFlndFsiF5XJVzcs1geZ0ZNmh4iLG+0geP5FXRkgs+0LuiHYS+8NSW2ysVGNix5AvvYMlkPFCe3Vv9A3x9wBe6wpENgcZvFfv3umX0+kPo1ykROH8f7foNC8RO+pDw2hidy+TPdAZLZW2QllJ1pqOrh71bO+3obtQpOp8eAGcow02VXT53S1DvpogpO80tt8yyWRgxcU6RjH7qO4B1Dk2AFOL7GtE0a7R4dZUupYpQTpBg/npS5hKEe6mvMCZ0wGzen1hcvk8Dxwr+GXxi/iE92n1Gn6GzP7dY2XeXV2atS3Is+rMS6M18zx/U6u65bSH2JT82pBp5OikQ= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 20:W7atiZvA/WvmF7dIuJqS9mZP+f7RzLzoM8QvsVcqKov56XL62Wgsn0ndagD1Zz1CorhNgFU3BVS8qESsNpDMa5CZjLjkf0L0PegbKpGMQFCrS7GcTWlvzxF41AVBGkFxfgB5vktiK3E1v3s79l79vHq/vHN4riTirZ+PvSvhVIjguDBidn4wCL+bXXucDDZq5Fjv1kQPaCdlxAhy6JCFTGpt1fbWs5QMEwIeunazL8yWA1WcwBbeHHTLkPiX2Uwfitx3N5Fl8yr/uuQeN9VdO59SogmIXs9rxoDrlKMspb8cBNw0OVJVFQgoKgjE6pjut0vMoqP4Xh1hHHk24p9VvKgOO4pcuk41Yxm96Ze+vcYoNXSlhJ57i57RoZQWyuswD+nTcU62F2TAmbC+jlQ7moHK1EPaRjX3IbDitdJ4mtks05NBk+6+TSFz5xgktH40tQ0d1blg3CdmB93CTDML/tYZYLnse/N+ejUetavTPAGXYV0+llEyrK7gH/SoBNHR; 4:LONSxu2sPXOEP8qMymBsve3CwPcuCw/0k/uWSoVj5ltRdrLG1oPHnMePo1Go0+HJKA4PFxQEfpg4TTotcQeKwAXU0qW9IgGk1UsL6EtqLV2okm7CDO7xIEVp9Ox3S9isycp3ogy+ajoeWx5DS80d9xcUGninD5b9sPtmELheymq1RsJIb89s0ebCjQXZghNa5ut8Ck8wARj4R9KVzYsZJYEeA3t6I4H31hFJilaAO1OOCLKHcT/G10mQUHi71G/rgt5V2R6TbJUsJK8Cscxr53zKK/phBBtxsAr0KxFdV6UssCOeQpOkou6EwJw6Px/vPtMaA9n8zqogy2DtMG4EQ2Csaa2Wvyj9nmZkSeiRXyajfKr4A/LUD6zvxS2VTnxbzFs0Zws1ZRiBvdOLozY8og== 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)(6055026); SRVR:BLUPR05MB788; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB788; X-Forefront-PRVS: 0912297777 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(377454003)(86362001)(92566002)(33656002)(189998001)(93886004)(42186005)(65806001)(65956001)(47776003)(66066001)(23746002)(6116002)(50466002)(5004730100002)(77096005)(4326007)(3846002)(586003)(54356999)(50986999)(76176999)(36756003)(81166005)(5001770100001)(5008740100001)(230700001)(2906002)(4001350100001)(65816999)(1096002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB788; H:[172.29.34.60]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB788; 23:QUaDlpJz5216+FMOVUpny9b9N93JWsOxz4ZRv1?= =?Windows-1252?Q?2317ZWrqdes9DNE9tIYkp03QEO2TuUGgLVwdv4XL3diMAPxi9cAAXRDS?= =?Windows-1252?Q?b0PuXP+xALvinJXEYTHdpI693O+JmAvwkrFdQa2Q9+pebRyHC3CQL3Dl?= =?Windows-1252?Q?6Qmb1rNV6j4TZHamoPcBvYFYiXKJWe/Wb8niZpRy2+KlZjdh72ziNZK/?= =?Windows-1252?Q?WSDPjCAbrn93hxeIf1B5T3KjR1dOvL/ifXcKjlvH9oB1NLMb6GDQvEfI?= =?Windows-1252?Q?OJ/Np8bXGaP32/YpXHawaM54Tnz2lrkCbdShH1Bvq6FNXIClgQmd600S?= =?Windows-1252?Q?KEIObNiiZF1UbFfBh8GaxcFUEQwtrpY5x2CBiZS8JMjQ31Gwpbhurwdp?= =?Windows-1252?Q?mzt40cLsCx+rsnfpEUqpheL8RXNlK52ypRUbB8JO6QrgmU8MsZqarh7N?= =?Windows-1252?Q?YqiWI6tGp1o7h/4L1KKQaj2zuQbDmFaGTMAIPDVDu8/F/3+IIU237Idd?= =?Windows-1252?Q?V4v5yx4OExm3GjRXOxDDIJ2mc8UJezgs2lGJRfRlldvQ1iqZMp9dLt7S?= =?Windows-1252?Q?DSRlj69z9y6WfTrNvfa24VWSte9azi0QjP43cA+RtHQdpx3mFCfJBrCf?= =?Windows-1252?Q?rdfOw/+XNZT1pYQvkPobNIGzLo3LJdESlJT7KFAnCRdGm/LPsxmcTu+Y?= =?Windows-1252?Q?aMTgSKS5T7YRxIP1Uw5Z1uzrFhdHO/V5Nl0DaCYYjavcqN7oEXeC1wN2?= =?Windows-1252?Q?tyseTDLueUtBTdnA+nCagMwJlg0qjDdbm0G5hpYjrNW3g6xi4qwOtRUT?= =?Windows-1252?Q?Do1Y2uhu7NmZxyD9ce5a3CbB702pn/CyIFA/1QjPNK1dDj7nk/BdEBsA?= =?Windows-1252?Q?QXobaht/T+nXnz5xPG92nxY07aCamdPaZC7IFcApN18IwCDQyVz9mpWj?= =?Windows-1252?Q?rJN9nDwQm8Bq20KCiklq5ZJ/jaMIPzRX+eUR+E1bayPK1kv5S2IX7uUY?= =?Windows-1252?Q?eEUlooEPb5LFI45ciWdDFfTinW7Hao8n+IPezAoM/tis7xsw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 5:2xPKFUI+EJ9wOrUuHVZ+ROwmm7KcIEtWn+dNkUzz1DWpGleGV3dLu/cDdwSrPY1vX231l532aMzEF6DvGi04Lq/WTGBfB+OMy/65Kbv4ceESYjgAqbR1kywejMdhCZ3+GXmb/eUADTC2DMVvLFISbQ==; 24:3+aXSli+M7b7zpS2e9fDkzPQ1ZPqxXqKi+Uxf/csXvxZ1jwuRSBnoLOzmdwV1DhwLbDPp8oUhYG5EFnAvQYjewo0ZclhWCwaNzo7pV1VWeI= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2016 21:43:05.8922 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB788 Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" , "Dr. Tony Przygienda" Subject: Re: [mpls] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 21:43:32 -0000 On 4/14/2016 3:31 PM, Stewart Bryant wrote: > Well there will be Ethernet PWs not using the CW that can put any > Ethernet address in the first nibble, so > if there are Ethernet addresses that start with 5 they will look like > BIER packets. What problem will that cause? > Sorry I meant version number. > > Before we assign a member of this very small number range to BIER, The first nibble of the BIER header does not have to have a value taken from the IP version number registry. > I would like some confidence that it will see any significant > deployment. When PW took 0 and 1, it was already a widely deployed > protocol. Note though that when PW started using 0 and 1 in the first nibble, it was not already a widely deployed protocol. I'd say it was a mistake to reserve 0 and 1 in the IP version number registry, as those reservations have no practical impact, and just cause a lot of unproductive discussions to take place. From nobody Thu Apr 14 16:50:40 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07912D662; Thu, 14 Apr 2016 16:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M86YBvoSSXYW; Thu, 14 Apr 2016 16:50:35 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9920812D18E; Thu, 14 Apr 2016 16:50:34 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-e7-57102ca1ee06 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 86.92.03614.1AC20175; Fri, 15 Apr 2016 01:49:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 19:50:33 -0400 From: Gregory Mirsky To: Loa Andersson , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein , Stewart Bryant Thread-Topic: [Bier] [mpls] [bier] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRllBODDlK1XlDUUCMzgo6JOQUU5+JzfOAgAAIZ4CAAE0KAA== Date: Thu, 14 Apr 2016 23:50:32 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A45C47@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> In-Reply-To: <570FB333.5080509@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXSPt+5CHYFwgxnTBC2mbv3AbLF0xh4m i3UbgKx/c+cwW9xaupLV4vXEqWwWpx4kOrB7TPm9kdVj07/jjB47Z91l91iy5CeTx/Wmq+we s6a3sQWwRXHZpKTmZJalFunbJXBlXGz+zFzwXL1i+YGL7A2MXQpdjJwcEgImEgv2H2CGsMUk LtxbzwZiCwkcZZR41F7RxcgFZC9nlOjYswwswSZgJPFiYw87iC0i8JBR4vUDPhCbWcBFYnP/ UbC4sECsxPnJi6Bq4iSmHn7ADGE7SXzbtZkVxGYRUJWYdxNiDq+Ar8TM35uZIZbtY5VYfHMC WIITqGjHvQ4WEJsR6Lrvp9YwQSwTl7j1ZD4TxNUCEkv2nIf6QFTi5eN/rBC2osS+/unsEPV6 EjemTmGDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWlyQk5tuZLiJ ERh/xyTYHHcw7u31PMQowMGoxMObsIg/XIg1say4MvcQowQHs5IIb4K6QLgQb0piZVVqUX58 UWlOavEhRmkOFiVxXu/If2FCAumJJanZqakFqUUwWSYOTqkGxrVT2g9P7vi1dtvloCO8v5xP iD64Je9QGT2H7XdFfkXY6191L3ZMi2pItJprrfdRVCaoWWrixtsH7y8R3+G8LW7rn+/lJWeP /nqVu2Txk0myy7fvzNixd/d5YZ6WOrX2rcsuTBJf5dW3ufPavruHo7/MnnvLlu310sikWylB EZWHu18IFn/6Me+6EktxRqKhFnNRcSIA52VvhrsCAAA= Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 23:50:38 -0000 Hi Loa, et. al, assuming that deployed nodes understand some, at least 0x04 and 0x06, value= s of the first nibble, wouldn't it be sufficient to define one new value as= None-of-the-Above? Though we're still exposed to Ethernet PW without CW ca= se. Regards, Greg -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, April 14, 2016 8:12 AM To: Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexander Vainshtein; S= tewart Bryant Cc: mpls@ietf.org; bier@ietf.org Subject: Re: [Bier] [mpls] [bier] The first nibble issue associated with MP= LS encapsulation Nagendra, The IANA registry you refer to is the IP Version numbers http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#versi= on-numbers-1 Please note that this registry does not globally define what needs to be in= the first nibble of a packet carried over mpls, it the payload is IP you a= re correct. If the payload is e.g. a PW then 0x0 in the first nibble of the payload ind= icates that it is PW the first nibble refer to to the PWMCW (Pseudowire MPL= S Control Word), if the first nibble is 0x1 it tells you that this packet b= elongs to GACh. /Loa On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > Per IANA registry, 0-1 are =B3Reserved=B2 and so is not strictly assigned= =20 > with PW. Something like a modified CW beneath LSE?. Further, BIER is=20 > hop-by-hop lookup based. So I think we don=B9t need to include this=20 > always. Instead, we could conditionally include this, if the next BFR=20 > is tunneled (not directly connected). > > The receiving node will use the label to identify the payload/FEC. So=20 > I think, the presence of modified CW should not confuse it with PW. > > Thanks, > Nagendra > > > On 4/14/16, 9:20 AM, "mpls on behalf of Eric C Rosen" > wrote: > >> On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >>> Stewart and all, >>> I concur with Stewart that there is a strong case for 0 in the first=20 >>> nibble for all non-IP flows. >>> >>> As for the need for sub-typing: >>> AFAIK quite a few implementations (including some HW-based packet >>> processors) treat 0 in the first nibble after the label stack as an=20 >>> indication of an Ethernet PW. >>> >>> Some of them go as far as to hash on the assumed L2 headers for ECMP. >>> This causes serious problems, e.g., with the TDM PWs that could be=20 >>> reordered if handled by such packet processors in transit LSRs. >>> >>> This makes quite a case for sub-typing IMO regardless of BIER. >>> At the same time, it seems that all the bits in CW structure are=20 >>> used - at least for some PW types in some cases. >> >> It seems to me that Sasha's reasoning supports the conclusion that it=20 >> is best to avoid 0 in the first nibble (even if this is not the=20 >> conclusion he drew!) I don't think sub-typing is a solution, because=20 >> it doesn't offer any protection against the behavior of existing hardwar= e. >> >> On 4/14/2016 5:31 AM, Stewart Bryant wrote: >>> The nibble value is recorded in the IP types registry and any wish=20 >>> to take another value really needs to be discussed with the INT=20 >>> area. >> >> Are you referring to the IP Version Number registry? (I am not aware of >> an "IP types registry".) We're not asking for any modification to >> that, since we're not doing another version of IP. I don't see any=20 >> need to get into one of those long and non-productive arguments that=20 >> the INT area seems to relish. >> >> On 4/13/2016 11:07 PM, Xuxiaohu wrote: >>> In fact, there is an attempt to have a registry for the first nibble=20 >>> (a.k.a., MPLS payload type field). >> >> Hopefully that attempt won't succeed! >> >> On 4/14/2016 7:06 AM, Loa Andersson wrote: >>> While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: >>> >>> It is REQUIRED, however, that applications depend upon in-order >>> packet delivery restrict the first nibble values to 0x0 and 0x1. >>> >>> If that is what we want for bier, there is a case to use 0x0 or 0x1=20 >>> for >>> bier- >> >> Strictly speaking, RFC 4928 needs to be updated, as the reasoning=20 >> given there does not really support the above "requirement". But the=20 >> effort to do that hardly seems worthwhile. RFC 4928 already makes=20 >> clear that the above requirement is protecting against the risk that=20 >> IPv5 ECMP will affect some MPLS packets inappropriately. No one seems=20 >> to think that that is a real risk. >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier From nobody Thu Apr 14 19:36:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36812E651; Thu, 14 Apr 2016 19:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 FFw4xTifT4Os; Thu, 14 Apr 2016 19:36:09 -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 3D70912E649; Thu, 14 Apr 2016 19:36:09 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 E880A1802AB8; Fri, 15 Apr 2016 04:36:04 +0200 (CEST) To: Gregory Mirsky , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein , Stewart Bryant References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> <7347100B5761DC41A166AC17F22DF11221A45C47@eusaamb103.ericsson.se> From: Loa Andersson Message-ID: <57105391.1090403@pi.nu> Date: Fri, 15 Apr 2016 10:36:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A45C47@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 02:36:12 -0000 Greg, On 2016-04-15 07:50, Gregory Mirsky wrote: > Hi Loa, et. al, > assuming that deployed nodes understand some, at least 0x04 and 0x06, values of the first nibble, wouldn't it be sufficient to define one new value as None-of-the-Above? Though we're still exposed to Ethernet PW without CW case. > The "none-of-the-above" approach might be sufficient, though I struggling to understand if we gain anything extra putting a specific number there. /Loa > Regards, > Greg > > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, April 14, 2016 8:12 AM > To: Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexander Vainshtein; Stewart Bryant > Cc: mpls@ietf.org; bier@ietf.org > Subject: Re: [Bier] [mpls] [bier] The first nibble issue associated with MPLS encapsulation > > Nagendra, > > The IANA registry you refer to is the IP Version numbers > http://www.iana.org/assignments/version-numbers/version-numbers.xhtml#version-numbers-1 > > Please note that this registry does not globally define what needs to be in the first nibble of a packet carried over mpls, it the payload is IP you are correct. > > If the payload is e.g. a PW then 0x0 in the first nibble of the payload indicates that it is PW the first nibble refer to to the PWMCW (Pseudowire MPLS Control Word), if the first nibble is 0x1 it tells you that this packet belongs to GACh. > > /Loa > > On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: >> Hi, >> >> Per IANA registry, 0-1 are Reserved and so is not strictly assigned >> with PW. Something like a modified CW beneath LSE?. Further, BIER is >> hop-by-hop lookup based. So I think we dont need to include this >> always. Instead, we could conditionally include this, if the next BFR >> is tunneled (not directly connected). >> >> The receiving node will use the label to identify the payload/FEC. So >> I think, the presence of modified CW should not confuse it with PW. >> >> Thanks, >> Nagendra >> >> >> On 4/14/16, 9:20 AM, "mpls on behalf of Eric C Rosen" >> wrote: >> >>> On 4/14/2016 6:06 AM, Alexander Vainshtein wrote: >>>> Stewart and all, >>>> I concur with Stewart that there is a strong case for 0 in the first >>>> nibble for all non-IP flows. >>>> >>>> As for the need for sub-typing: >>>> AFAIK quite a few implementations (including some HW-based packet >>>> processors) treat 0 in the first nibble after the label stack as an >>>> indication of an Ethernet PW. >>>> >>>> Some of them go as far as to hash on the assumed L2 headers for ECMP. >>>> This causes serious problems, e.g., with the TDM PWs that could be >>>> reordered if handled by such packet processors in transit LSRs. >>>> >>>> This makes quite a case for sub-typing IMO regardless of BIER. >>>> At the same time, it seems that all the bits in CW structure are >>>> used - at least for some PW types in some cases. >>> >>> It seems to me that Sasha's reasoning supports the conclusion that it >>> is best to avoid 0 in the first nibble (even if this is not the >>> conclusion he drew!) I don't think sub-typing is a solution, because >>> it doesn't offer any protection against the behavior of existing hardware. >>> >>> On 4/14/2016 5:31 AM, Stewart Bryant wrote: >>>> The nibble value is recorded in the IP types registry and any wish >>>> to take another value really needs to be discussed with the INT >>>> area. >>> >>> Are you referring to the IP Version Number registry? (I am not aware of >>> an "IP types registry".) We're not asking for any modification to >>> that, since we're not doing another version of IP. I don't see any >>> need to get into one of those long and non-productive arguments that >>> the INT area seems to relish. >>> >>> On 4/13/2016 11:07 PM, Xuxiaohu wrote: >>>> In fact, there is an attempt to have a registry for the first nibble >>>> (a.k.a., MPLS payload type field). >>> >>> Hopefully that attempt won't succeed! >>> >>> On 4/14/2016 7:06 AM, Loa Andersson wrote: >>>> While I can live with 0x0000, 0x0010 or 0x0101, RFC 4928 actually says: >>>> >>>> It is REQUIRED, however, that applications depend upon in-order >>>> packet delivery restrict the first nibble values to 0x0 and 0x1. >>>> >>>> If that is what we want for bier, there is a case to use 0x0 or 0x1 >>>> for >>>> bier- >>> >>> Strictly speaking, RFC 4928 needs to be updated, as the reasoning >>> given there does not really support the above "requirement". But the >>> effort to do that hardly seems worthwhile. RFC 4928 already makes >>> clear that the above requirement is protecting against the risk that >>> IPv5 ECMP will affect some MPLS packets inappropriately. No one seems >>> to think that that is a real risk. >>> >>> >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > From nobody Thu Apr 14 19:53:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1C12E6DA; Thu, 14 Apr 2016 19:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 XGKEgdpa0p9N; Thu, 14 Apr 2016 19:53:41 -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 40DF312E6D7; Thu, 14 Apr 2016 19:53:41 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 0F21A1802AB8; Fri, 15 Apr 2016 04:53:37 +0200 (CEST) To: Stewart Bryant , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> <570FF136.7030600@gmail.com> From: Loa Andersson Message-ID: <571057AE.6090305@pi.nu> Date: Fri, 15 Apr 2016 10:53:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570FF136.7030600@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 02:53:42 -0000 Stewart, On 2016-04-15 03:36, Stewart Bryant wrote: > > > On 14/04/2016 16:11, Loa Andersson wrote: >> >> >> /Loa >> >> On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: >>> Hi, >>> >>> Per IANA registry, 0-1 are Reserved and so is not strictly assigned >>> with >>> PW. Something like a modified CW beneath LSE?. Further, BIER is >>> hop-by-hop >>> lookup based. So I think we dont need to include this always. >>> Instead, we >>> could conditionally include this, if the next BFR is tunneled (not >>> directly connected). >>> >>> The receiving node will use the label to identify the payload/FEC. So I >>> think, the presence of modified CW should not confuse it with PW. > > Not quite Loa. > > It could be an Ethernet PW with no CW. Yes - you are right, how much of a problem is this in a P node? Any value, except 4 and 6, will stop the P node from doing ECMP/Load Sharing, right? A P node will never look for the control word. So an Ethernet PW that carries the same value in the first nibble that we specify for bier will be treated the same way as a bier packet. This does not effect the bier packets, and is the right way to treat the PW. So where do we have the problem? BIER would be in the clear, as it will carry any value but 4 or 6 in the first nibble, right? PWs with control word will have 0 (or 1) and not be effected by a P node that are doing ECMP/Load Sharing. Ethernet PWs without control word might have any value in the first nibble, if there is 4 or 6 a P node might to ECMP/Load Sharing. It seems to me that specifying the first nibble in a bier packet would be good, for the time being I don't care if we say 0 or 5. If there are problems with Ethernet PWs without control word, this has to be solved in the context of PWs. /Loa > > Stewart From nobody Thu Apr 14 20:55:52 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B5D12DFB7; Thu, 14 Apr 2016 20:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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, 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 rebVZCVVanRB; Thu, 14 Apr 2016 20:55:49 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C4112DF35; Thu, 14 Apr 2016 20:55:49 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-d7-57105fa6b704 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id C2.A8.09012.6AF50175; Fri, 15 Apr 2016 05:27:34 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Thu, 14 Apr 2016 23:55:44 -0400 From: Gregory Mirsky To: Loa Andersson , Stewart Bryant , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein Thread-Topic: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation Thread-Index: AQHRloT8vzhXQ8QBukG0nHM9+FvEPJ+KmgQA///L7QA= Date: Fri, 15 Apr 2016 03:55:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A45EC0@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> <570FF136.7030600@gmail.com> <571057AE.6090305@pi.nu> In-Reply-To: <571057AE.6090305@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXSPt+6yeIFwg5ZDkhZTt35gtlg6Yw+T xboNQNa/uXOYLW4tXclq8XriVDaLUw8SHdg9pvzeyOqx6d9xRo+ds+6yeyxZ8pPJ43rTVXaP WdPb2ALYorhsUlJzMstSi/TtErgybs1Zwl6wXKLi2a5tbA2MS4S7GDk5JARMJF6+msoCYYtJ XLi3ng3EFhI4yigx54hZFyMXkL2cUeLky8VMIAk2ASOJFxt72EESIgIPGSX2zlnDDpJgFnCR 2Nx/FMjm4BAWiJX4uCoVJCwiECfR0vGCCcK2kvh7bhoTSAmLgKrEj4VgN/AK+Ep8n3iPBWLX N1aJG9c6wcZwAtXM2yACUsMIdNv3U2uYIDaJS9x6Mp8J4mYBiSV7zjND2KISLx//Y4WwlSTm vL7GDFGvJ3Fj6hQ2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcUF ObnpRgabGIGxd0yCTXcH4/3pnocYBTgYlXh4ExbxhwuxJpYVV+YeYpTgYFYS4e1MEQgX4k1J rKxKLcqPLyrNSS0+xCjNwaIkztsY/C9MSCA9sSQ1OzW1ILUIJsvEwSnVwJhipXdvxtOUAyFm nJPVXCaufGX1Xt3QyC9p5U6n91oTf0WGzz3u7aRlUxvQlDdbR2TyPLdFb3OuhM264/y2Lb2N f7azHEtg/8eTwteYJef+0M/xvb1+8R4T+TONf+8sk5/vmLtjh1FN/kGxJxJTij6fnPD54KJd b3h8PvOEnVhRLXfD5fQ0sTdKLMUZiYZazEXFiQAgRTRKuQIAAA== Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:55:51 -0000 Hi Loa, I think that use of value 5 in the first nibble for MPLS encapsulated BIER = packets is to differentiate them from all other variants that use the first= nibble as the hint to P node on what use as flow characteristic informatio= n for ECMP. I don't think, though we should consult with BIER WG and author= s of draft-ietf-bier-mpls-encapsulation, that the first nibble not supposed= to be used as payload type identifier but only to differentiate from other= types of the first nibble at P nodes to avoid incidental hashing of BIER p= ackets assumed to be something else, IP or Ethernet. If that is the case, t= hen the same value 5 may be used as None-of-the-Above indicator, including = SFC. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Thursday, April 14, 2016 7:54 PM To: Stewart Bryant; Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexand= er Vainshtein Cc: mpls@ietf.org; bier@ietf.org Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MP= LS encapsulation Stewart, On 2016-04-15 03:36, Stewart Bryant wrote: > > > On 14/04/2016 16:11, Loa Andersson wrote: >> >> >> /Loa >> >> On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: >>> Hi, >>> >>> Per IANA registry, 0-1 are =B3Reserved=B2 and so is not strictly=20 >>> assigned with PW. Something like a modified CW beneath LSE?.=20 >>> Further, BIER is hop-by-hop lookup based. So I think we don=B9t need=20 >>> to include this always. >>> Instead, we >>> could conditionally include this, if the next BFR is tunneled (not=20 >>> directly connected). >>> >>> The receiving node will use the label to identify the payload/FEC.=20 >>> So I think, the presence of modified CW should not confuse it with PW. > > Not quite Loa. > > It could be an Ethernet PW with no CW. Yes - you are right, how much of a problem is this in a P node? Any value, = except 4 and 6, will stop the P node from doing ECMP/Load Sharing, right? A= P node will never look for the control word. So an Ethernet PW that carries the same value in the first nibble that we s= pecify for bier will be treated the same way as a bier packet. This does not effect the bier packets, and is the right way to treat the PW= . So where do we have the problem? BIER would be in the clear, as it will carry any value but 4 or 6 in the fi= rst nibble, right? PWs with control word will have 0 (or 1) and not be effected by a P node th= at are doing ECMP/Load Sharing. Ethernet PWs without control word might have any value in the first nibble,= if there is 4 or 6 a P node might to ECMP/Load Sharing. It seems to me that specifying the first nibble in a bier packet would be g= ood, for the time being I don't care if we say 0 or 5. If there are problems with Ethernet PWs without control word, this has to b= e solved in the context of PWs. /Loa > > Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Fri Apr 15 00:10:03 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD01E12D806; Fri, 15 Apr 2016 00:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 ty9zTCfS8c3L; Fri, 15 Apr 2016 00:09:57 -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 4BACF12D0C2; Fri, 15 Apr 2016 00:09:57 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 DA5D41802ADB; Fri, 15 Apr 2016 09:09:53 +0200 (CEST) To: Gregory Mirsky , Stewart Bryant , "Nagendra Kumar Nainar (naikumar)" , Eric C Rosen , Alexander Vainshtein References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53871C@NKGEML515-MBX.china.huawei.com> <570BB266.8090608@juniper.net> <570F6374.6030406@gmail.com> <570F9901.2080406@juniper.net> <570FB333.5080509@pi.nu> <570FF136.7030600@gmail.com> <571057AE.6090305@pi.nu> <7347100B5761DC41A166AC17F22DF11221A45EC0@eusaamb103.ericsson.se> From: Loa Andersson Message-ID: <571093BE.7070803@pi.nu> Date: Fri, 15 Apr 2016 15:09:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A45EC0@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "mpls@ietf.org" , "bier@ietf.org" Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 07:10:00 -0000 Greg, I think the position of the mpls wg should be that LSRs (P node) may do load sharing if the the first nibble is 4 or 6, otherwise not. Other wg may decide on which of the "none of the above"-values to use in the cases they specify. When specifying such values it should be clear that the first nibble is not a general payload indicator, it is an indicator whether load sharing (if available) may be wanted or not. For some PW application the first nibble have a meaning slightly different from this, as far as I can see this is OK and deployed. It also means that other wg may want to distinguish the payload that wg specifies from PWs, but in doing so they should not assume that the value they chose is a indicator that is 100% sure to identify that payload. /Loa On 2016-04-15 11:55, Gregory Mirsky wrote: > Hi Loa, > I think that use of value 5 in the first nibble for MPLS encapsulated BIER packets is to differentiate them from all other variants that use the first nibble as the hint to P node on what use as flow characteristic information for ECMP. I don't think, though we should consult with BIER WG and authors of draft-ietf-bier-mpls-encapsulation, that the first nibble not supposed to be used as payload type identifier but only to differentiate from other types of the first nibble at P nodes to avoid incidental hashing of BIER packets assumed to be something else, IP or Ethernet. If that is the case, then the same value 5 may be used as None-of-the-Above indicator, including SFC. > > Regards, > Greg > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Thursday, April 14, 2016 7:54 PM > To: Stewart Bryant; Nagendra Kumar Nainar (naikumar); Eric C Rosen; Alexander Vainshtein > Cc: mpls@ietf.org; bier@ietf.org > Subject: Re: [mpls] [Bier] [bier] The first nibble issue associated with MPLS encapsulation > > Stewart, > > On 2016-04-15 03:36, Stewart Bryant wrote: >> >> >> On 14/04/2016 16:11, Loa Andersson wrote: >>> >>> >>> /Loa >>> >>> On 2016-04-14 22:41, Nagendra Kumar Nainar (naikumar) wrote: >>>> Hi, >>>> >>>> Per IANA registry, 0-1 are Reserved and so is not strictly >>>> assigned with PW. Something like a modified CW beneath LSE?. >>>> Further, BIER is hop-by-hop lookup based. So I think we dont need >>>> to include this always. >>>> Instead, we >>>> could conditionally include this, if the next BFR is tunneled (not >>>> directly connected). >>>> >>>> The receiving node will use the label to identify the payload/FEC. >>>> So I think, the presence of modified CW should not confuse it with PW. >> >> Not quite Loa. >> >> It could be an Ethernet PW with no CW. > > Yes - you are right, how much of a problem is this in a P node? Any value, except 4 and 6, will stop the P node from doing ECMP/Load Sharing, right? A P node will never look for the control word. > > So an Ethernet PW that carries the same value in the first nibble that we specify for bier will be treated the same way as a bier packet. > This does not effect the bier packets, and is the right way to treat the PW. > > So where do we have the problem? > > BIER would be in the clear, as it will carry any value but 4 or 6 in the first nibble, right? > PWs with control word will have 0 (or 1) and not be effected by a P node that are doing ECMP/Load Sharing. > Ethernet PWs without control word might have any value in the first nibble, if there is 4 or 6 a P node might to ECMP/Load Sharing. > > It seems to me that specifying the first nibble in a bier packet would be good, for the time being I don't care if we say 0 or 5. > > If there are problems with Ethernet PWs without control word, this has to be solved in the context of PWs. > > /Loa >> >> Stewart > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > From nobody Tue Apr 19 05:22:54 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5812DF6A; Tue, 19 Apr 2016 05:22:52 -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 b1kXszTELd8u; Tue, 19 Apr 2016 05:22:50 -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 0C26412DDE2; Tue, 19 Apr 2016 05:22:49 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 18B4C3B4445; Tue, 19 Apr 2016 14:22:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E91104C069; Tue, 19 Apr 2016 14:22:47 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Tue, 19 Apr 2016 14:22:47 +0200 From: To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRlMFhYP1TVuc5zkmUMH7AqQ5q8Z+RQtEg Date: Tue, 19 Apr 2016 12:22:47 +0000 Message-ID: <13936_1461068568_57162317_13936_8997_1_9E32478DFA9976438E7A22F69B08FF921BB05AC0@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <570CFB90.8020706@pi.nu> In-Reply-To: <570CFB90.8020706@pi.nu> Accept-Language: fr-FR, en-US Content-Language: en-US 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.19.112417 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:22:53 -0000 Hi, I am not aware of IPR related to this draft -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, April 12, 2016 15:44 To: mpls@ietf.org Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls-chairs@ietf.o= rg Subject: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label Working Group, The authors of draft-ietf-mpls-spring-entropy-label has told us that the do= cument is ready to be considered for working group last call. We will do an IPR poll prior to the start of the wg last call. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- la= bel? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details). There are no IPR disclosures filed directly against this document. If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. *Th= e response needs to be sent to the MPLS wg mailing list.* The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the MPLS WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. /Loa mpls wg co-chair --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ 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 19 19:01:22 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40FA12E9C6; Tue, 19 Apr 2016 19:01:21 -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 cX6YddvJaQRe; Tue, 19 Apr 2016 19:01:19 -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 172A112E9BD; Tue, 19 Apr 2016 19:01:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMR03637; Wed, 20 Apr 2016 02:01:16 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 20 Apr 2016 03:01:15 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 20 Apr 2016 10:01:11 +0800 From: Xuxiaohu To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRlMFz1oZqUcCTdUSt1oPcfIHS6p+SJlGQ Date: Wed, 20 Apr 2016 02:01:11 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53B26C@NKGEML515-MBX.china.huawei.com> References: <570CFB90.8020706@pi.nu> In-Reply-To: <570CFB90.8020706@pi.nu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A020203.5716E2EC.0176, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ecd15236cd7f963e5950cfe96d6fd8b6 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 02:01:22 -0000 I'm not aware of any relevant IPR. Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, April 12, 2016 9:44 PM > To: mpls@ietf.org > Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls-chairs@ietf= .org > Subject: [mpls] IPR poll on draft-ietf-mpls-spring-entropy-label >=20 > Working Group, >=20 > The authors of draft-ietf-mpls-spring-entropy-label has told us that the > document is ready to be considered for working group last call. >=20 > We will do an IPR poll prior to the start of the wg last call. >=20 > This mail starts the IPR poll. >=20 > Are you aware of any IPR that applies to draft-ietf-mpls-spring-entropy- = label? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > There are no IPR disclosures filed directly against this document. >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. *Th= e > response needs to be sent to the MPLS wg mailing list.* The document will= not > advance to the next stage until a response has been received from each au= thor > and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR that > has not yet been disclosed in conformance with IETF rules. >=20 >=20 > /Loa > mpls wg co-chair > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Apr 20 15:35:22 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448012DEF8; Wed, 20 Apr 2016 15:35:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160420223521.796.6053.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 15:35:21 -0700 Archived-At: Cc: mpls@ietf.org, mpls-chairs@ietf.org, draft-ietf-mpls-rfc6374-udp-return-path@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [mpls] Protocol Action: 'RFC6374 UDP Return Path' to Proposed Standard (draft-ietf-mpls-rfc6374-udp-return-path-05.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 22:35:21 -0000 The IESG has approved the following document: - 'RFC6374 UDP Return Path' (draft-ietf-mpls-rfc6374-udp-return-path-05.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching 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-mpls-rfc6374-udp-return-path/ Technical Summary The MPLS Packet Loss and Delay Measurement protocol is defined in RFC6374. RFC 6374 defines how to send and process MPLS performance management responses for Loss and Delay measurement. This document specifies the procedure to be used when an out of band UDP/IP return path is available. Working Group Summary There were nothing exceptional in the working group process other than the WG Chairs had to ask twice during the wglc to get any response at all. I guess that this is one of those document that is of very strong interest for a small group within the working group, while the rest of the working understands that it need to be done, being happy that someone takes on the work. Document Quality We currently are aware of prototyping, as well as plans to any implement this specification, we have an ongoing implementation poll and the write-up will be updated if and when we get further news. There should be implementations since we made early allocations based on upcoming testing. No special purpose reviews has been necessary. The document is well reviewed in mpls-rt and at working adoption poll, even though the wglc gave nothing but supportive comments. Personnel Loa Andersson is the Document Shepherd. Deborah Brungard is the Responsible Area Director From nobody Thu Apr 21 01:59:34 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1623212D760 for ; Thu, 21 Apr 2016 01:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrpgfIfNotrD for ; Thu, 21 Apr 2016 01:59:30 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CFD12D167 for ; Thu, 21 Apr 2016 01:59:30 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id i5so5843210pag.3 for ; Thu, 21 Apr 2016 01:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=6rr1MQEu1ds3o8RI+uEQp+z1LxOEDhM0cLr8mszctTI=; b=rGr0FOLr8VjAVZiSXzivofA3+HoV2/tR0MZmgCoRNzwNR2+kui2U/xd8mBeahAZyMM nglWRiUoosIEcuuoJZWbYf6Ld35iMnpSJ4Ijk5i5UyBJp8l8FVZ3ypK4+WNfNQMaVC94 bHMLqEjZPn2WsQkgTvO7PScivrlyYNTz840Ikm2R+7UeSPhNPlMg6p8gK7PtELAQ1ky/ Hnjn0Bpl85Yfc4iM3HEVj/ZOyWMhmRCtWcQpnfu2rrdZyRRafZ4k7qwJcov8pxip+uHe t3Uf0MBfrfr9Z7rjlDxTM6yRr4lisU3H5UjtcyDBePv467BbSzurRZc43r8y8HBQ+TaE WZVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=6rr1MQEu1ds3o8RI+uEQp+z1LxOEDhM0cLr8mszctTI=; b=ATNBtggZPnKB62GH99PGwZ1XzFLAJ8ZQC2mUi0LR/Qq4+TuFQKBA4c32O0LN6gHSun i7VTmBwt3Ut1LvEOZTKcwRDwTWbIIHczINv0XppDVBK7JmVubK6Wq7VS7LGao57iY1nL Mr6pbwpfv74SKUjABgc+c2cD8BXHIZlrE292nRpyT5/yIhDXFroTwpvHZcNI99peJLe8 +kbpx7U5vq1XupngdO5HsqF0ZB5Pa/M3r5ad0/mKqJIl6cLlVV3wqGKWL5d+pC2D/6/8 SwUtuUorssYRmxMz/2RF3Bw3RUJC6U2466diKvSHRDEP6750t/3UaOqBAjTSm0nxSSzG 2q3w== X-Gm-Message-State: AOPr4FWLetPLLNtZGNaZqgZ0n5TAdn2uTTy3Q++evHLTT6ILoHuOhlaMj3hv77u2aYLt3g== X-Received: by 10.66.180.68 with SMTP id dm4mr19186883pac.76.1461229169705; Thu, 21 Apr 2016 01:59:29 -0700 (PDT) Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id z7sm3112819pfb.9.2016.04.21.01.59.28 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 01:59:29 -0700 (PDT) To: Jeff Tantsura , mpls@ietf.org References: <896EBEE8-E1D5-461B-9AD0-044BFE20F846@gmail.com> From: Pushpasis Sarkar Message-ID: <5718966E.6000807@gmail.com> Date: Thu, 21 Apr 2016 14:29:26 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <896EBEE8-E1D5-461B-9AD0-044BFE20F846@gmail.com> Content-Type: multipart/alternative; boundary="------------080009050801090304060805" Archived-At: Subject: Re: [mpls] WGLC on draft-ietf-rtgwg-rlfa-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:59:32 -0000 This is a multi-part message in MIME format. --------------080009050801090304060805 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Jeff, Many many thanks for starting the WGLC call. FYI, I am not aware of any IPR other than the one already disclosed (by Juniper and Cisco). Thanks and Regards, -Pushpasis On Thursday 21 April 2016 01:12 PM, Jeff Tantsura wrote: > Dear RTGWG, > The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the > draft is ready for working group last call (WGLC). > Before we do the WGLC we want to do an IPR poll on the document. > This mail starts that IPR poll. > Are you aware of any IPR that applies to > draft-ietf-rtgwg-rlfa-node-protection? > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > Currently there are two IPR disclosures on > draft-psarkar-rtgwg-rlfa-node-protection > (which was the pre-working group version of > draft-ietf-rtgwg-rlfa-node-protection): > https://datatracker.ietf.org/ipr/2334/ > https://datatracker.ietf.org/ipr/2346/ > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > document will not advance to the next stage until a response has been > received from each author and contributor. > If you are on the RTGWG email list but 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. > Thanks, > Jeff and Chris > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------080009050801090304060805 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Jeff,

Many many thanks for starting the WGLC call.

FYI, I am not aware of any IPR other than the one already disclosed (by Juniper and Cisco).

Thanks and Regards,
-Pushpasis

On Thursday 21 April 2016 01:12 PM, Jeff Tantsura wrote:
Dear RTGWG,
The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the
draft is ready for working group last call (WGLC).
Before we do the WGLC we want to do an IPR poll on the document.
This mail starts that IPR poll.
Are you aware of any IPR that applies to draft-ietf-rtgwg-rlfa-node-protection?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
Currently there are two IPR disclosures on draft-psarkar-rtgwg-rlfa-node-protection
(which was the pre-working group version of draft-ietf-rtgwg-rlfa-node-protection):

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.
If you are on the RTGWG email list but 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.
Thanks,
Jeff and Chris


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

--------------080009050801090304060805-- From nobody Thu Apr 21 02:02:04 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CCB12DB87; Thu, 21 Apr 2016 02:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 fPj_ZWTQt__i; Thu, 21 Apr 2016 02:02:00 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 D4A8E12DC98; Thu, 21 Apr 2016 02:02:00 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id zm5so27254281pac.0; Thu, 21 Apr 2016 02:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=x7BDsk/XsfKphJuziy1N4NG7J3lnK56oqTblthfbonU=; b=FK2glPCSsB/tEiu47WLBO6205ZMocD60wfBAvUEEl7JV3iX+mGhEVRyd8VX82+ZI0c MCGgWWjqawAyKkbqusxhB7OTvwn1EG55umjk6QpMj324gnYUpCF6J8pVb5YX1ee5kTUQ LAm4lRZVNISlqiCEixHvdrhtQX7OcRnuBy8/qL5upXjkVHzZDYVq2EH0aVjZpVCXSJ60 pgJhYRKKjj8HmHJfZ7fiO6JfyccxvUSXXo5DVytYKdtNG9wp6WLtmEF1cOMgWPLqnFFQ 2bwfGXypD3of2HLHjnETo3Bl9ivwmMjLkD1xwzvOGVtohSp+btbVwBVX7cNl12cqqHrM e71w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=x7BDsk/XsfKphJuziy1N4NG7J3lnK56oqTblthfbonU=; b=GsP0qaPf5eb/vBzKI5l4wyOWsjjRmJR0hUB/slN4S0LndRtjiDegv3tWsop1b7s7Om 43Y/+Zn0yfx2Bi8V4RYwhEL6ZCsRkny5Ypz2yLrlLrVlXNMDHQlJfD8ZA2lzL0FsCnS/ 1OIGbNS/3Z8BfyyuzyRXSkOEXtl/t2dDaMgtdAKKUsDg32bEoL2tTsHKgqjM0qAmP6rm HSNCf/+FUQm7iojTHwdv6bvfa3sK6gvU7Wd4tLdZ7QUpfiJC9UIxKC7nX8ei2dzXGpFV Smfv6svsl+iZ+DRKr8MkFYDFytQNuYFg82B+P4goKQc/pbpVWJXK5QSKK0a/y27aJs/e iWGg== X-Gm-Message-State: AOPr4FWH8d72A5y6hre8Rqq7b26BTK4Uo7KlyqPCNNmeDD+N7w9rCuXYWuvrWnqzYkhP1A== X-Received: by 10.66.88.104 with SMTP id bf8mr18966130pab.129.1461229316748; Thu, 21 Apr 2016 02:01:56 -0700 (PDT) Received: from [192.168.1.13] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id l88sm3084387pfb.79.2016.04.21.02.01.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 02:01:55 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 21 Apr 2016 02:01:54 -0700 From: Jeff Tantsura To: Pushpasis Sarkar , Message-ID: Thread-Topic: WGLC on draft-ietf-rtgwg-rlfa-node-protection References: <896EBEE8-E1D5-461B-9AD0-044BFE20F846@gmail.com> <5718966E.6000807@gmail.com> In-Reply-To: <5718966E.6000807@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3544048915_1918849520" Archived-At: Cc: rtgwg@ietf.org Subject: Re: [mpls] WGLC on draft-ietf-rtgwg-rlfa-node-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 09:02:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3544048915_1918849520 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Thanks Pushpasis, including RTGWG. From: Pushpasis Sarkar Date: Thursday, April 21, 2016 at 1:59 AM To: Jeff Tantsura , Subject: Re: WGLC on draft-ietf-rtgwg-rlfa-node-protection Hi Jeff, Many many thanks for starting the WGLC call. FYI, I am not aware of any IPR other than the one already disclosed (by Juniper and Cisco). Thanks and Regards, -Pushpasis On Thursday 21 April 2016 01:12 PM, Jeff Tantsura wrote: Dear RTGWG, The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the draft is ready for working group last call (WGLC). Before we do the WGLC we want to do an IPR poll on the document. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-rtgwg-rlfa-node-protection? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). Currently there are two IPR disclosures on draft-psarkar-rtgwg-rlfa-node-protection (which was the pre-working group version of draft-ietf-rtgwg-rlfa-node-protection): https://datatracker.ietf.org/ipr/2334/ https://datatracker.ietf.org/ipr/2346/ If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the RTGWG email list but 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. Thanks, Jeff and Chris _______________________________________________ rtgwg mailing list rtgwg@ietf.orghttps://www.ietf.org/mailman/listinfo/rtgwg --B_3544048915_1918849520 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Thanks Pushpasis, including RTGWG. 

From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Date: Thursday, April 21, 2016 at 1:59 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>, <mpls@ietf.org>
Subje= ct: Re: WGLC on draft-ietf-rtgwg-rlfa-node-protection
=
Hi Jeff,

Many many thanks for starting the WGLC call.

FYI, I am not aware of any IPR other than the one already disclosed (by Juniper and Cisco).

Thanks and Regards,
-Pushpasis

On Thursday 21 April 2016 01:12 PM, Jeff Tantsura wrote:
Dear RTGWG,
 
The authors of draft-ietf-rtgwg-rlfa-node-protection have told us that the
draft is ready for working group last call (WGLC).
 
Before we do the WGLC we want to do an IPR poll on the document.
 
This mail starts that IPR poll.
 
Are you aware of any IPR that applies to draft-ietf-rtgwg-rlfa-node-protection?
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
Currently there are two IPR disclosures on draft-psarkar-rtgwg-rlfa-node-protection
(which was the pre-working group version of draft-ietf-rtgwg-rlfa-node-protection):

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant
IPR. *The response needs to be sent to the MPLS wg mailing list.* The
document will not advance to the next stage until a response has been
received from each author and contributor.
 
If you are on the RTGWG email list but 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.
 
Thanks, <= /div>
Jeff and Chris


_______________________________________________
rtgwg mailing list
rtgwg@ietf=
.orghttps://www.ietf.org/mailman/listinfo/rtgwg

--B_3544048915_1918849520-- From nobody Fri Apr 22 06:03:25 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF5912EA60; Fri, 22 Apr 2016 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 oBFZ2bIrbqYN; Fri, 22 Apr 2016 06:03:20 -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 9DF8F12E53D; Fri, 22 Apr 2016 06:03:20 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 B2F6018013C8; Fri, 22 Apr 2016 15:03:17 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" Message-ID: <571A2101.9050106@pi.nu> Date: Fri, 22 Apr 2016 21:02:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:03:24 -0000 Working Group, This is to start a two week poll to see if we have consensus to adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. There are no IPR disclosures against this document. All the authors has stated that they are not aware of any IPRs that relate to this document. In all but one case this has been done on the on the mpls wg mailing list, in the last case this has been stated in a mail to the wg chairs. The working group adoption poll ends May 7, 2016. /Loa MPLS wg co-chair. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 22 06:06:04 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDC12EB92; Fri, 22 Apr 2016 06:06:04 -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_H4=-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 mLLmsi0EzVnY; Fri, 22 Apr 2016 06:06:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E6C12E897; Fri, 22 Apr 2016 06:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1147; q=dns/txt; s=iport; t=1461330362; x=1462539962; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PdWGPo1LYRI642Dcq58QLDzoaaUs8tKitJy6VICKibY=; b=UTHJ2z1d+OTv3LidUgTv3jNh+gQ9QHms1LFiS58jgs391ZNMgDoqh6qb rHdmQ1HlbfPpL7qMiDijFCckPTfrtPjValgschtECmU4hAW3BqxZSEAMV x1d00UPdUtl7uUf1ErJ97ZIUwJj9wpClBPrh8W+MjoFJUVwVetQbk6A8t s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDYIBpX/4kNJK1egziBUAa6AAENg?= =?us-ascii?q?XOGDgKBJDgUAQEBAQEBAWUnhEIBAQQ6MQMZAgIBCDYQGxclAgQBEogqvycBAQE?= =?us-ascii?q?BAQEBAQIBAQEBAQEaBIpohA8QAgGFcwWYDwGOE4FmhE2IXY8uAR4BAUKDa2yHe?= =?us-ascii?q?H8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="263961356" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2016 13:06:02 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3MD61bK006515 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 13:06:01 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 08:06:00 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 08:06:00 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" Thread-Topic: working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJddzqkY0U9qGUC1KAUo83dCRZ+WBwKA Date: Fri, 22 Apr 2016 13:06:00 +0000 Message-ID: References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.224.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 13:06:04 -0000 Hi, Support as a co-author. Regards, Nagendra On 4/22/16, 9:02 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll to see if we have consensus to >adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working >group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There are no IPR disclosures against this document. > >All the authors has stated that they are not aware of any IPRs that >relate to this document. In all but one case this has been done on the >on the mpls wg mailing list, in the last case this has been stated in a >mail to the wg chairs. > >The working group adoption poll ends May 7, 2016. > >/Loa > >MPLS wg co-chair. >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 22 09:37:13 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01812EB6F; Fri, 22 Apr 2016 09:37:12 -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_H4=-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 IgD_uDIq-7iT; Fri, 22 Apr 2016 09:37:11 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81A0312EB58; Fri, 22 Apr 2016 09:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1461343031; x=1462552631; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TVhYfAfrWE/uCp9tMNDReiRgs1I84kPM+Y1N6bcrM7Y=; b=ZP17iErl80VRYb9ay6lOv/FwW+re8PwZaEThf058iXuAn9fKQOciiWxd h8F6kKr/Uf7UQw35ZmmMd6dPiRil4fzmg0R4Zy5ZPGDNUiZXcq90iCjsZ GbvbvJMfJNbHXkuCcpP8g+8MmUi4vDF+/o4IPlGP933plIGgl1tVunNCg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgBMUhpX/5NdJa1egziBUAa6AAENg?= =?us-ascii?q?XOGDgKBKTgUAQEBAQEBAWUnhEIBAQRuBhUCAQgYLjIlAgQBEogqv3cBAQEBAQE?= =?us-ascii?q?BAQIBAQEBAQEaimyEDxACAYVzAQSYDwGOE4FmhE2DKYU0jy4BHgEBQoNrbId8f?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="263355001" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2016 16:37:10 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3MGbA1N013685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 16:37:10 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 11:37:09 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 11:37:10 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-app-aware-tldp@ietf.org" , "mpls-chairs@ietf.org" Thread-Topic: Corection - [mpls] IPR poll on draft-ietf-mpls-app-aware-tldp Thread-Index: AQHRkQBsJ2U0Wfgi+kiNeukH4dTjW5+AMCyAgBYo+oA= Date: Fri, 22 Apr 2016 16:37:10 +0000 Message-ID: References: <5706AF5A.5070108@pi.nu> <57078417.3070700@pi.nu> In-Reply-To: <57078417.3070700@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.243.41] Content-Type: text/plain; charset="Windows-1252" Content-ID: <476783CE6ACB9B4098C6730010295684@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Corection - IPR poll on draft-ietf-mpls-app-aware-tldp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 16:37:12 -0000 I am not aware of any IPR associated with this draft. Thanks. =8B Kamran On 2016-04-08, 6:12 AM, "Loa Andersson" wrote: >WG, > >Sorry I had a cut and paste error in the two first paragraphs of this >mail, it should have read: > > The authors of draft-ietf-mpls-app-aware-tldp has told us that > the document is ready for working group last call. > > We will do an IPR poll prior to the start of wglc. > >I apologize for the mistake! > >/Loa > > > >On 2016-04-08 03:04, Loa Andersson wrote: >> Working Group, >> >> The authors of draft-ietf-mpls-app-aware-tldp has told us that >> the document is ready to be considered for working adoption. >> >> The document been through MPLS-RT review. We will do an IPR poll >> prior to the start of the adoption poll. >> >> This mail starts the IPR poll. >> >> Are you aware of any IPR that applies to draft-ietf-mpls-app-aware-tldp? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> There is one IPR disclosure filed directly against this document. >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> document will not advance to the next stage until a response has been >> received from each author and contributor. >> >> If you are on the MPLS WG email list but 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. >> >> >> /Loa >> mpls wg co-chair From nobody Sat Apr 23 00:53:54 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CC412E6F0; Sat, 23 Apr 2016 00:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 qHUd6tducSmq; Sat, 23 Apr 2016 00:53:51 -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 4B64212E0A3; Sat, 23 Apr 2016 00:53:51 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 D7C5718013E4; Sat, 23 Apr 2016 09:53:47 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" Message-ID: <571B29F8.1060301@pi.nu> Date: Sat, 23 Apr 2016 15:53:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 07:53:53 -0000 Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-spring-entropy-label. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors and contributors (with one exception) have stated on the working group mailing list that they are not aware of any other IPRs that relates to this draft. This working group last call ends May 12, 2016. /Loa for the MPLS wg chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Apr 23 02:55:15 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BC812D811; Sat, 23 Apr 2016 02:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqd-YjhSoXFL; Sat, 23 Apr 2016 02:55:08 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FAD12D8FA; Sat, 23 Apr 2016 02:55:08 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id m9so31999905ige.1; Sat, 23 Apr 2016 02:55:08 -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=ogDh3og92RJBpLQnHaPyNoS3wMsSxyJpSahZwDWSFLk=; b=fuVVUjOJ/Wn6rLTqkRDIzszGtzBqcQz7SBTIj1YGRkUitKRNHFA8MNoqlZOiynzp+6 svH7wcn00DvekdPpHEuVOGdo5nwDM5jWEvZu49jCItwF0FnqSePLvGAlLE7zQkoeHYJK auUfKi2Qj0r/CIyxefR6m3EfVk/wZJ4zmjM2bB/i7fDqNY0D4IfDU6DTvyYWdv0xHYmC e8HjGwnlFxaYYroOiUJZWpNxgRgeBL/qym7eETqvcdqniNUnzdEBDhbBNKtdmGXDexUv vzJvyqt0BEBkQO7uD6IGZfVlFg4ZBuy2M0BXXSHL2H1qyOIlRzKVBCkrgCxW3Krnt/sw zOsg== 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=ogDh3og92RJBpLQnHaPyNoS3wMsSxyJpSahZwDWSFLk=; b=WIwwV7UhjePD/TrCChKKd2BvlR1gI76HGVat3azRmWldlEyQ/EsMizEjgKryZ4NDJm HMZwXkVIMGo2B6dJFucNlQGh1stIsqfxdNYcRlZrArsMWOAZTBBAFm1xCb1POzpp5ggI GLd5qGjGr7l75I68Gg9dA9eeONlqEL2D2fbhdTeT4dRbdD0k/42Mpgvfd6zqoUv0e+/Z IFRdfPxht8lsNfLCxxnTQVBwB3ipn2BfOr3N1JCvOdDnGIPY7VaZZpINHSwDaS805h4j 6Taf7LHgybFhO3+o4eAi2Awuffg55TCCUQhDxE+O2NcYgd4TIgXogG/HLPKVoMU0IBpn QLug== X-Gm-Message-State: AOPr4FUhRgXBXBKwbm2VSGK4l1A14DZWfABAPESbsIv2Iu2ZTgZ7iSOjjSvvDcyHjJadVi7wCRmX1Uk3otl2ug== MIME-Version: 1.0 X-Received: by 10.50.77.5 with SMTP id o5mr1716048igw.33.1461405306467; Sat, 23 Apr 2016 02:55:06 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.222.71 with HTTP; Sat, 23 Apr 2016 02:55:06 -0700 (PDT) In-Reply-To: <571A2101.9050106@pi.nu> References: <571A2101.9050106@pi.nu> Date: Sat, 23 Apr 2016 15:25:06 +0530 X-Google-Sender-Auth: gReUyWXJ04m5yOhhvqCCvJxQ0UU Message-ID: From: Dhruv Dhody To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7bdc0ce82a3ff4053123f025 Archived-At: Cc: "mpls@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 09:55:11 -0000 --047d7bdc0ce82a3ff4053123f025 Content-Type: text/plain; charset=UTF-8 Support for adoption, good base for WG to work on! Regards, Dhruv On Fri, Apr 22, 2016 at 6:32 PM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll to see if we have consensus to > adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > There are no IPR disclosures against this document. > > All the authors has stated that they are not aware of any IPRs that > relate to this document. In all but one case this has been done on the > on the mpls wg mailing list, in the last case this has been stated in a > mail to the wg chairs. > > The working group adoption poll ends May 7, 2016. > > /Loa > > MPLS wg co-chair. > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7bdc0ce82a3ff4053123f025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support for adoption, good base for WG to wo= rk on!=C2=A0

Regards,
Dhruv

On Fri, Apr 22, 2016 at 6:32 PM, Loa Andersson &= lt;loa@pi.nu> = wrote:
Working Group,

This is to start a two week poll to see if we have consensus to
adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There are no IPR disclosures against this document.

All the authors has stated that they are not aware of any IPRs that
relate to this document. In all but one case this has been done on the
on the mpls wg mailing list, in the last case this has been stated in a
mail to the wg chairs.

The working group adoption poll ends May 7, 2016.

/Loa

MPLS wg co-chair.
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

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

--047d7bdc0ce82a3ff4053123f025-- From nobody Sat Apr 23 03:07:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5008312E056; Sat, 23 Apr 2016 03:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBbvYHLDLwNn; Sat, 23 Apr 2016 03:07:24 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 06FF312E083; Sat, 23 Apr 2016 03:07:24 -0700 (PDT) Received: by mail-ob0-x232.google.com with SMTP id j9so60376328obd.3; Sat, 23 Apr 2016 03:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z9a9NpkfFTlFe3ClNSYEChzbAnYK39mPN6LIb1uYWDQ=; b=qA4aJnlTCOC5E+lNGOGIaJvzPFBgyJw3T0QZM9Kg4hkVkgXa2T/iRwdJVYdHF1mawW /Kr1ApjcmP8iIjw0vTYLQ2tW0jch1zDtERl6ke8HJK3G948TJB8L1nEhdYJBC+iF8cvS h+30YfgJid+Bmew8uxFo6KmQbSZ1Ktz/ak0jWzPE+XGiQFfKLHWqhGy5tXLp/9AuI7Qq tUtlpJXmCVJQBjq1BELY+Dv6lae/gmgEytQKL6O14Qw0t6m97U2Nd6MglWutWbHIpNTB /GPHdQzRIasY2MtLMYfkNh+dV2m0noDFmtmfMYLuucYGsGdY1gkupSt5EirSIXCwhIlT Akag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z9a9NpkfFTlFe3ClNSYEChzbAnYK39mPN6LIb1uYWDQ=; b=NGbF5uLJ2+z7TYeK5iH3lIU+g8Enf88uK7WhOlVFxrZgjb8feZzB/A2z2ExFNME4jO 8xcJEjAiz7ZouAh8UHvM/eBFiafatgGpm3CHEIfR5JT8RWlrGJxxdeLMQ9boXnWw0qfX vHhUabHOQgyFTb95JlEsj+ooApWMVwcWWV9YyEL+UqmVTciwa4hM++JNVdmarYYG/5kP it6JQCIfG/vgpM4CTNR6cuqXr62AesYDMX5/0mgXBjQL3YMl0pj5lxEBuaO165zUhjn3 fDC34sG2IZAjD29ioMGYlCvseEJbKUN59M+0rePbRYzCnsGEzr9VXHHta1+geLqSccFO uaRQ== X-Gm-Message-State: AOPr4FUZUnk6fddLTjX6f6u81GU7xdCL4qeKhwxPNXhotQzF4Ol+T2ceKlAeGMt/8Z2KTx+03oEsTI6A4Vmrtw== X-Received: by 10.182.174.10 with SMTP id bo10mr11040485obc.38.1461406043395; Sat, 23 Apr 2016 03:07:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Sat, 23 Apr 2016 03:06:53 -0700 (PDT) In-Reply-To: <571B29F8.1060301@pi.nu> References: <571B29F8.1060301@pi.nu> From: Sri Date: Sat, 23 Apr 2016 05:06:53 -0500 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=e89a8f643e3c16de4d0531241c91 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 10:07:25 -0000 --e89a8f643e3c16de4d0531241c91 Content-Type: text/plain; charset=UTF-8 Hi, Support as co-author. Sri On Sat, Apr 23, 2016 at 2:53 AM, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --e89a8f643e3c16de4d0531241c91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Support as co-author.
Sri

On Sat, Apr 23, 2016 at 2:53 AM, Loa Andersson = <loa@pi.nu>= wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--e89a8f643e3c16de4d0531241c91-- From nobody Sat Apr 23 03:08:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CFE12E0D2; Sat, 23 Apr 2016 03:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_bbmVOU4u28; Sat, 23 Apr 2016 03:08:45 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 357C412E15B; Sat, 23 Apr 2016 03:08:45 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id x201so137851961oif.3; Sat, 23 Apr 2016 03:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3TGaNp2avZOGWbzJXN0lx5KitDCPCDWA8IEhdpGwgd8=; b=xc6EhA5Ul3vJ633LFfULCqN7KCmSKz1akITR4mz22OXIAuTaiiPffE2UqPIwz596ys XpgNm5fovs0zkFcNzYKFGWAZaNpUwaqUJUdHkm5AYtdleN7c1BLQABxxCr0tdEJF1eeD 6SOYAwnhVmM758VT+J1rzHatxQ009pv9qP8dUYabeWQQcX/Et4ULz7FZW3Ad4u8R0BBf jja2pbnut61rhsVstgQUc0g30o0b3Va5cM3iJTf0dUl8zERLWQ/uO3gO5lP7SfLn9uqp 5AEZroEhCNUHqkCqZ/zWuVq1ulTSWjf+D+GeUqOJJ5YHJo+pMihmeOijNgEEe6L9cyF1 1jdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3TGaNp2avZOGWbzJXN0lx5KitDCPCDWA8IEhdpGwgd8=; b=CFstuXVAbg8aydVWeiyoU+Oy84MLgkvrZNrzdtGem3XKYtme/McMSlPkGqCGNeedLW x2/aPLG6ow+tG/zjcX1KIL61CxzV7Bhj9HEs9hQlxxGX6e90/R2wISRBAahDdEkpqSPi /DXzFRnGltb1kX5EkxCOBmQi+Dyldw80uBJ9PFlB/QvPlnCIeNdxehx3yhwTEC6z8DQB tsvIw9q1QVeicPvXbb4DflKR05pwr8zNXlDRxLzwOk18JJ84eZR9DARHMlsRDUfYUnno YzAlBVqFXbkuyqiQ6bN0AofAERfaGCD444laqj9yCqhE2y7D8dNx0HJ0B8WlRRk4zo9e J2jA== X-Gm-Message-State: AOPr4FUsx4EzrLHfpkBUu5/CtLWjfAqFRNJ8XbvI4oRf+THNaZum3Bu+VBIkbTa183T3TddU6gLAm6BxjlrdMQ== X-Received: by 10.202.94.132 with SMTP id s126mr10169289oib.34.1461406124587; Sat, 23 Apr 2016 03:08:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Sat, 23 Apr 2016 03:08:14 -0700 (PDT) In-Reply-To: References: <571A2101.9050106@pi.nu> From: Sri Date: Sat, 23 Apr 2016 05:08:14 -0500 Message-ID: To: "Nagendra Kumar Nainar (naikumar)" Content-Type: multipart/alternative; boundary=001a113d5160ede46b053124202a Archived-At: Cc: "mpls@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 10:08:47 -0000 --001a113d5160ede46b053124202a Content-Type: text/plain; charset=UTF-8 Support as co-author Sri On Fri, Apr 22, 2016 at 8:06 AM, Nagendra Kumar Nainar (naikumar) < naikumar@cisco.com> wrote: > Hi, > > Support as a co-author. > > Regards, > Nagendra > > On 4/22/16, 9:02 AM, "Loa Andersson" wrote: > > >Working Group, > > > >This is to start a two week poll to see if we have consensus to > >adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working > >group document. > > > >Please send your comments (support/not support) to the mpls working > >group mailing list (mpls@ietf.org). Please give a technical > >motivation for your support/not support, especially if you think that > >the document should not be adopted as a working group document. > > > >There are no IPR disclosures against this document. > > > >All the authors has stated that they are not aware of any IPRs that > >relate to this document. In all but one case this has been done on the > >on the mpls wg mailing list, in the last case this has been stated in a > >mail to the wg chairs. > > > >The working group adoption poll ends May 7, 2016. > > > >/Loa > > > >MPLS wg co-chair. > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113d5160ede46b053124202a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support as co-author

Sri

On Fri, Apr 22, 2016= at 8:06 AM, Nagendra Kumar Nainar (naikumar) <naikumar@cisco.com>= wrote:
Hi,

Support as a co-author.

Regards,
Nagendra

On 4/22/16, 9:02 AM, "Loa Andersson" <loa@pi.nu> wrote:

>Working Group,
>
>This is to start a two week poll to see if we have consensus to
>adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working
>group document.
>
>Please send your comments (support/not support) to the mpls working
>group mailing list (mpls@ietf.org)= . Please give a technical
>motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document.
>
>There are no IPR disclosures against this document.
>
>All the authors has stated that they are not aware of any IPRs that
>relate to this document. In all but one case this has been done on the<= br> >on the mpls wg mailing list, in the last case this has been stated in a=
>mail to the wg chairs.
>
>The working group adoption poll ends May 7, 2016.
>
>/Loa
>
>MPLS wg co-chair.
>--
>
>
>Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
>Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
>Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64<= br>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--001a113d5160ede46b053124202a-- From nobody Sat Apr 23 10:57:53 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D32812D508; Sat, 23 Apr 2016 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.617 X-Spam-Level: X-Spam-Status: No, score=-13.617 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 P5YzgeWeRloe; Sat, 23 Apr 2016 10:57:50 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9616612D1B7; Sat, 23 Apr 2016 10:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3848; q=dns/txt; s=iport; t=1461434270; x=1462643870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LlE5tkjIdjuP+vssVQSWrKrOjAMR7P47IrJ/pivdaiQ=; b=FtwE43mJWYfDJzPzwkvtJW99HcLhUH2gJeVxdExUXyCNdaBb2Cqaur1f DvRlrKV0+Gu0jUrExs49SjqZPyzC+NMe3u0daYkMON8S8AcgYiZZn8l5/ bkMLR3+Z/24yntlpunvEfQpDQ5juOV/8uWpxah8iiu0q9gTAW5Lbdygk+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgDLthtX/4kNJK1egzhTfQa5bAENg?= =?us-ascii?q?XUXC4VsAhyBAzgUAQEBAQEBAWUnhEIBAQQBAQELFRExBgMLDgICAQgaAiYCAgI?= =?us-ascii?q?ZDAsVEAIEAQ0FiCoOrkCQcAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBHiJcIQPE?= =?us-ascii?q?QEcGIJqglYFh36HB4kKAY4TgWaETYhdjy4BHgEBQoIFG4FLbIdGNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,523,1454976000"; d="scan'208";a="265350476" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2016 17:57:49 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3NHvnL9017100 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Apr 2016 17:57:49 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; Sat, 23 Apr 2016 13:57:48 -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; Sat, 23 Apr 2016 13:57:48 -0400 From: "Acee Lindem (acee)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnYml/l4Oy2kisUCFQARxWDWjpw== Date: Sat, 23 Apr 2016 17:57:48 +0000 Message-ID: References: <571B29F8.1060301@pi.nu> In-Reply-To: <571B29F8.1060301@pi.nu> 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: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 17:57:52 -0000 SSBzdXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgd29yay4gSSBoYXZlIHRoZSBmb2xsb3dpbmcg ZWRpdG9yaWFsDQpjb21tZW50czoNCg0KMjA4LDIwOWMyMDgsMjA5DQo8ICAgIHNvdXJjZSByb3V0 ZWQgbGFiZWwgc3RhY2tzLiAgTGV0cyBMX04tUCBkZW5vdGUgdGhlIGxhYmVsIHRvIGJlIHVzZWQN CjwgICAgdG8gcmVhY2ggdGhlIG5vZGUgU0lEIG9mIExTUiBQLiAgTGV0IExfQS1MbiBkZW5vdGUg dGhlIGxhYmVsIHVzZWQgZm9yDQotLS0NCj4gICAgc291cmNlIHJvdXRlZCBsYWJlbCBzdGFja3Mu ICBMZXQgTF9OLVAzIGRlbm90ZSB0aGUgbGFiZWwgdG8gYmUgdXNlZA0KPiAgICB0byByZWFjaCB0 aGUgbm9kZSBTSUQgb2YgTFNSIFAzLiAgTGV0IExfQS1MbiBkZW5vdGUgdGhlIGxhYmVsIHVzZWQg Zm9yDQozMjJjMzIyDQo8ICAgIGxhYmVsIHN0YWNrLiAgSW4gdGhlIGV4YW1wbGUgZGVzY3JpYmVk IGluIFNlY3Rpb24gMyBpdCB3aWxsIHJlc3VsdCBpbg0KLS0tDQo+ICAgIGxhYmVsIHN0YWNrLiAg SW4gdGhlIGV4YW1wbGUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMywgaXQgd2lsbCByZXN1bHQgaW4N CjMzMGMzMzANCjwgICAgU2VjdGlvbiAzIHRoZSBMU1IgUDEgd291bGQgcG9vcmx5IGxvYWQtYmFs YW5jZSB0cmFmZmljIG9uIHRoZQ0KLS0tDQo+ICAgIFNlY3Rpb24gMywgdGhlIExTUiBQMSB3b3Vs ZCBwb29ybHkgbG9hZC1iYWxhbmNlIHRyYWZmaWMgb24gdGhlDQozNDljMzQ5DQo8ICAgIFRoaXMg b3B0aW9uIHdhcyBkaXNjb3VudGVkIHNpbmNlIHRoZXJlIGV4aXN0IGEgbnVtYmVyIG9mIGhhcmR3 YXJlDQotLS0NCj4gICAgVGhpcyBvcHRpb24gd2FzIHJlamVjdGVkIHNpbmNlIHRoZXJlIGFyZSBh IG51bWJlciBvZiBoYXJkd2FyZQ0KMzUxLDM1MmMzNTEsMzUyDQo8ICAgIENob29zaW5nIHRoaXMg b3B0aW9uIGNhbiBsZWFkIHRvIGEgbG9zcyBvZiBsb2FkLWJhbGFuY2luZyB1c2luZyBFTCBpbg0K PCAgICBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIG5ldHdvcmsgYnV0IHRoYXQgaXMgYSBjcml0 aWNhbCByZXF1aXJlbWVudA0KLS0tDQo+ICAgIENob29zaW5nIHRoaXMgb3B0aW9uIGNhbiBsZWFk IHRvIEVMIGxvYWQtYmFsYW5jaW5nIGludGVycnVwdGlvbnMgaW4NCj4gICAgYSBzaWduaWZpY2Fu dCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGFuZCB0aGF0IGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQN CjM3N2MzNzcNCjwgICAgVGhpcyBvcHRpb24gd2FzIGRpc2NvdW50ZWQgZHVlIHRvIHRoZSBleGlz dGVuY2Ugb2YgaGFyZHdhcmUNCi0tLQ0KPiAgICBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgZHVl IHRvIHRoZSBleGlzdGVuY2Ugb2YgaGFyZHdhcmUNCjM4MWMzODENCjwgICAgcmVzdHJpY3QgdGhl IG51bWJlciBvZiB0dW5uZWxzIHRoYXQgY2FuIGZvcm0gYSBMU1AgYW5kIGNvbnN0cmFpbiB0aGUN Ci0tLQ0KPiAgICByZXN0cmljdCB0aGUgbnVtYmVyIG9mIExTUnMgdGhhdCBjYW4gZm9ybSBhbiBM U1AgYW5kIGNvbnN0cmFpbiB0aGUNCjQxOWM0MTkNCjwgICAgVGhpcyBvcHRpb24gd2FzIGRpc2Nv dW50ZWQgZHVlIHRvIHRoZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gbGFiZWwNCi0tLQ0KPiAgICBU aGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgZHVlIHRvIHRoZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4g bGFiZWwNCjQzMmM0MzINCjwgICAgVGhpcyBvcHRpb24gd2FzIGRpc2NvdW50ZWQgZHVlIHRvIHRo ZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gbGFiZWwNCi0tLQ0KPiAgICBUaGlzIG9wdGlvbiB3YXMg cmVqZWN0ZWQgZHVlIHRvIHRoZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gbGFiZWwNCg0KDQpUaGFu a3MsDQpBY2VlIA0KDQpPbiA0LzIzLzE2LCAzOjUzIEFNLCAibXBscyBvbiBiZWhhbGYgb2YgTG9h IEFuZGVyc3NvbiINCjxtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxvYUBwaS5u dT4gd3JvdGU6DQoNCj5Xb3JraW5nIEdyb3VwLA0KPg0KPlRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0 d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPmRyYWZ0LWlldGYtbXBscy1zcHJp bmctZW50cm9weS1sYWJlbC4NCj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBt cGxzIHdnIG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZykuDQo+DQo+VGhlcmUgYXJlIG5vIElQ UiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+DQo+QWxsIHRoZSBhdXRob3Jz IGFuZCBjb250cmlidXRvcnMgKHdpdGggb25lIGV4Y2VwdGlvbikgaGF2ZSBzdGF0ZWQgb24NCj50 aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2Yg YW55IG90aGVyDQo+SVBScyB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4NCj4NCj5UaGlzIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgTWF5IDEyLCAyMDE2Lg0KPg0KPg0KPi9Mb2ENCj5m b3IgdGhlIE1QTFMgd2cgY2hhaXJzDQo+LS0gDQo+DQo+DQo+TG9hIEFuZGVyc3NvbiAgICAgICAg ICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj5TZW5pb3IgTVBM UyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPkh1YXdlaSBUZWNo bm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWls aW5nIGxpc3QNCj5tcGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tcGxzDQoNCg== From nobody Sat Apr 23 20:23:06 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF1512D0C7; Sat, 23 Apr 2016 20:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em1YkZOtJV0o; Sat, 23 Apr 2016 20:23:03 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1E612B03D; Sat, 23 Apr 2016 20:23:03 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-64-571c3beb302d Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id AC.2F.03614.BEB3C175; Sun, 24 Apr 2016 05:22:19 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Sat, 23 Apr 2016 23:23:01 -0400 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRndiZ9h3KhfOc80GnngyOQOW4DQ== Date: Sun, 24 Apr 2016 03:22:58 +0000 Message-ID: <7D8E6195-FC3B-4871-A97E-07639F9ED41B@ericsson.com> References: <571B29F8.1060301@pi.nu> In-Reply-To: <571B29F8.1060301@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: <4F654E73A3D91441B6F67EE4BB128F5D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyuXRPrO5ra5lwgx8XpCzOnTvFaPFv7hxm i3WXT7FZ3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr4+znCewFTdwV XxZuZmtgvMPVxcjJISFgInF08x42CFtM4sK99UA2F4eQwFFGiRPn26Cc5YwS16++A6tiEzCQ +P/tOAuILSJgJ7Hx1T9GkCJmgUWMEvenH2MESQgLhEqcPTOXDaIoTGLn/NlMELaexIsf/4Di HBwsAqoS23e5gIR5BewlXjf3MYPYQgIqEjemTmEHsTmBSu7/mww2khHouu+n1oCNYRYQl7j1 ZD4TxNUCEkv2nGeGsEUlXj7+xwpiiwroSry4u5YFIq4k8fH3fHaQtcwCmhLrd+lDjLGW6G++ xAxhK0pM6X7IDnGOoMTJmU9YJjBKzEKybRZC9ywk3bOQdM9C0r2AkXUVI0dpcUFObrqR4SZG YCQek2Bz3MG4t9fzEKMAB6MSD+8CDZlwIdbEsuLK3EOMEhzMSiK8z82BQrwpiZVVqUX58UWl OanFhxilOViUxHm9I/+FCQmkJ5akZqemFqQWwWSZODilGhjjI19JFjYax167PCtHRpEvOdZk PvuqsrqQ4FsNcou5pZ0P192YaiB56x6rFzvjnD/PY7c+mmnjkyoVrXf/GMv7+nUuUjx/nDX/ SPgEPTDMeWLeunX/enNNfZ6kd1mnF0XNcsr2XOMefDdURnvmqSXusn25rs+3dtSvXDvL6NWr uTeksjwmWCqxFGckGmoxFxUnAgBq/epQwAIAAA== Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 03:23:05 -0000 SGkgTG9hLA0KDQpTdXBwb3J0IGFzIGEgY28tYXV0aG9yLg0KDQpUaGFua3MsDQpKZWZmDQoNCg0K DQpPbiA0LzIzLzE2LCAxMjo1MyBBTSwgIm1wbHMgb24gYmVoYWxmIG9mIExvYSBBbmRlcnNzb24i IDxtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxvYUBwaS5udT4gd3JvdGU6DQoN Cj5Xb3JraW5nIEdyb3VwLA0KPg0KPlRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPmRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1s YWJlbC4NCj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxp bmcgbGlzdCAobXBsc0BpZXRmLm9yZykuDQo+DQo+VGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJl cyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+DQo+QWxsIHRoZSBhdXRob3JzIGFuZCBjb250cmli dXRvcnMgKHdpdGggb25lIGV4Y2VwdGlvbikgaGF2ZSBzdGF0ZWQgb24NCj50aGUgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyDQo+ SVBScyB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4NCj4NCj5UaGlzIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGVuZHMgTWF5IDEyLCAyMDE2Lg0KPg0KPg0KPi9Mb2ENCj5mb3IgdGhlIE1QTFMg d2cgY2hhaXJzDQo+LS0gDQo+DQo+DQo+TG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAg ICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj5TZW5pb3IgTVBMUyBFeHBlcnQgICAg ICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPkh1YXdlaSBUZWNobm9sb2dpZXMgKGNv bnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5t cGxzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo= From nobody Sat Apr 23 20:24:31 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDF212B03D; Sat, 23 Apr 2016 20:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwM4QAFPke1G; Sat, 23 Apr 2016 20:24:27 -0700 (PDT) Received: from mail-pa0-x244.google.com (mail-pa0-x244.google.com [IPv6:2607:f8b0:400e:c03::244]) (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 D3B2412B030; Sat, 23 Apr 2016 20:24:27 -0700 (PDT) Received: by mail-pa0-x244.google.com with SMTP id vv3so13932979pab.0; Sat, 23 Apr 2016 20:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=YqpXywJEH++ioJeiVhp1wOI88VH71FWndOodr50yvlM=; b=wbZk05plErfTsvnZqJ0sW/eFdKG13ythI/6mZhpINiN/s3m/ocRzoVZy9ZmsVuHn+q yPpe4dGJ/5M320Bc/dTnj+w7dW26T/sAFJZ2aJuUH2/893Ec9VpjdGGQDQy0tJmg0ZIZ 35chdJGNoaKwUfUTewdnXjIq6fxNXHcOjsyBN118jG7dwzJyiY4EUjmzjLg/W9UVC5CQ 6mu8qpeI89DPHsdRqtjwQsHU4wysTrfzcQZwdIkoGs4reV8SyRWBDRvLhRuaXUGz/RLQ Dv4MdCiRw3Gezge/2smdrlpm1ubRABgoOBlpmm0Wk/EPgINEL/4gO/e+VWN+/bSdJsBe T5ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=YqpXywJEH++ioJeiVhp1wOI88VH71FWndOodr50yvlM=; b=f5AdcJXMxrWpUx/7h/nZMVxjZZzOzk5imOM4avyeDmf4GCp7GIXXFFnyhZOAlNA/cx 0yNAcXzUSq5VLNHAn5SR+4qHkjiZmDe0nVrbEOu28fv61GDuIPt7K6Q0Uku2ZsJHQUc1 qr9cRwzqlavd4SUji43fKiF2dAjBmQ2/xUUqTUy2udCojvuNrmIKO+5uQgEtbnnv6EES p1d4cv9QgzG1By9nFd/0oTAubiQjwyASf6FJoMALTDSe04IIUV7LtDRe8eclfXaRRjDd OfuMngYQIjKCfGZ+0AOwF+OUN6bBsWJA+8YJ8Tv5jhQqkzS4Kn7CjnNr9b+w9k3BSsz8 BTvw== X-Gm-Message-State: AOPr4FVzrMxm2TcyZ0hdhUjUJ8844NjBKJ/LjpbLOw8/Qt1xwXjiYaSmA8a6rHJLLiGvxQ== X-Received: by 10.67.2.41 with SMTP id bl9mr39131599pad.39.1461468267456; Sat, 23 Apr 2016 20:24:27 -0700 (PDT) Received: from [192.168.0.117] (66-189-255-235.dhcp.reno.nv.charter.com. [66.189.255.235]) by smtp.gmail.com with ESMTPSA id g5sm19507336pac.1.2016.04.23.20.24.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2016 20:24:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Sat, 23 Apr 2016 20:24:25 -0700 From: Jeff Tantsura To: Loa Andersson , "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label References: <571B29F8.1060301@pi.nu> <7D8E6195-FC3B-4871-A97E-07639F9ED41B@ericsson.com> In-Reply-To: <7D8E6195-FC3B-4871-A97E-07639F9ED41B@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 03:24:30 -0000 Now with correct email Support as a co-author. Thanks, Jeff >On 4/23/16, 12:53 AM, "mpls on behalf of Loa Andersson" wrote: > >>Working Group, >> >>This is to initiate a two week working group last call on >>draft-ietf-mpls-spring-entropy-label. >> >>Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >>There are no IPR disclosures against this document. >> >>All the authors and contributors (with one exception) have stated on >>the working group mailing list that they are not aware of any other >>IPRs that relates to this draft. >> >>This working group last call ends May 12, 2016. >> >> >>/Loa >>for the MPLS wg chairs >>-- >> >> >>Loa Andersson email: loa@mail01.huawei.com >>Senior MPLS Expert loa@pi.nu >>Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>_______________________________________________ >>mpls mailing list >>mpls@ietf.org >>https://www.ietf.org/mailman/listinfo/mpls >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Apr 23 20:27:16 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F307F12B03D; Sat, 23 Apr 2016 20:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 memnQH5Dn81G; Sat, 23 Apr 2016 20:27:13 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (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 5797012B030; Sat, 23 Apr 2016 20:27:13 -0700 (PDT) Received: by mail-pa0-x242.google.com with SMTP id zy2so14336105pac.2; Sat, 23 Apr 2016 20:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=tBn7UNp2W1YVZL7sn3Dpsxn7DzXgtjCyjpH6sGAmt80=; b=03XLZ9/5B7Ff3JYnki+DJf7zDEFlySJvDKuwOBwEPAdQeCih7Ld98DfsGHXox/6BIl zhhoF/SPdvxV6xn7zVPhisSytOzLOGrimOpFJIXXX8yJF/gqeDELhFZI5uavvdGirIxu iZwk80n75Tr2Ll4NOnIZl4eJpQatZFMQvYQncUdHCUHaXGGRyRQT9p6UTOreWFmyeynY VwgYYDZsnH6mc/Iem/YcHWHACZ2yai77zxUht1DsyzGEKv+g/lLszbWKNxIaNKlwdAIT iwCS2y7AwilSEe0Zh8HX/9xZk2yhgCs21BzdU3EWKJK+K9X9vAaQbpyhs3N0pxuAZCHW +RUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=tBn7UNp2W1YVZL7sn3Dpsxn7DzXgtjCyjpH6sGAmt80=; b=jOOx+8bkDdg1T6N2DXr3GSOiUAW2U1XA8xr/l+Nnpp9R5/VSMLaX09P1JtM0j4WH7Z aUQnuI7sW90ysPjPD1BnB1zibtIBgM0hVhwwy4AOyr5qSpFEoqrLfi8r58OjFDz6a6mB QxpHnqQYKpAU/Jet27CApX1HG74xLEzT90qsC1GfX1ugVSxO1PGN4fa2rEUzy0KH2nX8 ILqBx+dLMppYP13S4DBzZP/ABqORubFJCwiCgEtLnCbIvCahShCiNpp6NaI5r3irT7os r61swYqZ/TuZz7ASqb3HC5QsDEImOH9Z1Ox0bpb90D1LtvNJiqKrQo8YKSRhpUECebCI 242w== X-Gm-Message-State: AOPr4FVGS9oUED9Wy+HOY1OYNIzH4dHaf5ZCK8urbdd9vR7LVOkj7O1FhGtv93Iyey8Vjw== X-Received: by 10.66.175.110 with SMTP id bz14mr39498313pac.41.1461468432927; Sat, 23 Apr 2016 20:27:12 -0700 (PDT) Received: from [192.168.0.117] (66-189-255-235.dhcp.reno.nv.charter.com. [66.189.255.235]) by smtp.gmail.com with ESMTPSA id g5sm19507336pac.1.2016.04.23.20.27.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Apr 2016 20:27:12 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Sat, 23 Apr 2016 20:27:12 -0700 From: Jeff Tantsura To: "mpls@ietf.org" Message-ID: Thread-Topic: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping References: <571A2101.9050106@pi.nu> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3544288032_517963742" Archived-At: Cc: "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 03:27:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3544288032_517963742 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Yes/support Thanks, Jeff On 4/22/16, 9:02 AM, "Loa Andersson" wrote: >Working Group, > >This is to start a two week poll to see if we have consensus to >adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working >group document. > >Please send your comments (support/not support) to the mpls working >group mailing list (mpls@ietf.org). Please give a technical >motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document. > >There are no IPR disclosures against this document. > >All the authors has stated that they are not aware of any IPRs that >relate to this document. In all but one case this has been done on the >on the mpls wg mailing list, in the last case this has been stated in a >mail to the wg chairs. > >The working group adoption poll ends May 7, 2016. > >/Loa > >MPLS wg co-chair. >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --B_3544288032_517963742 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Yes/support

Thanks,
Jeff


On 4/22/16, 9:02 AM, "Loa Andersson" <loa@pi.= nu> wrote:

>Working Group,
>
>This is to start a two week poll to see if we have consensus to
>adopt draft-kumarkini-mpls-spring-lsp-ping as an MPLS working
>group document.
>
>Please send your comments (support/not support) to the mpls working
= >group mailing list (mpls@ietf.org). = Please give a technical
>motivation for your support/not support, especially if you think that >the document should not be adopted as a working group document.
>
>There are no IPR disclosures against this document.
>
>All the authors has stated that they are not aware of any IPRs that
= >relate to this document. In all but one case this has been done on the<= br> >on the mpls wg mailing list, in the last case this has been stated in a=
>mail to the wg chairs.
>
>The working group adoption poll ends May 7, 2016.
>
>/Loa
>
>MPLS wg co-chair.
>--
>
>
>Loa Andersson                &n= bsp;       email: loa@mail01.huawei.com
>Senior MPLS Expert              &nbs= p;           loa@pi.nu
>Huawei Technologies (consultant)     phone: +46 739 81 21 64

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

--B_3544288032_517963742-- From nobody Sat Apr 23 21:22:35 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D53712D107; Sat, 23 Apr 2016 21:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB1HzSw8tA-u; Sat, 23 Apr 2016 21:22:31 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B975612D0E1; Sat, 23 Apr 2016 21:22:31 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-28-571c49db13a1 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 22.CF.03614.BD94C175; Sun, 24 Apr 2016 06:21:47 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Sun, 24 Apr 2016 00:22:30 -0400 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" Thread-Topic: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJde/7xcsZgmvkiEWHoWbZ1wUJ+YiJKg Date: Sun, 24 Apr 2016 04:22:29 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A5D315@eusaamb103.ericsson.se> References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHW/e2p0y4waXdKhY/V95js/g3dw6z xbrLp9gsbi1dyerA4rFkyU8mj1nT29g8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsf3PL7aCh9wV P25tZW9gXMbZxcjJISFgItE3ZzsbhC0mceHeeiCbi0NI4CijxJRbu1kgnOWMEg8n/WEHqWIT MJJ4sbGHHSQhIvCAUeJE331mkISwQITE3yMTwYpEBCIlHk1ugrKNJO78W8MEYrMIqErsXnWV EcTmFfCVmNW6mQXEFhJQkWjYcg5sDidQzYobX8B6GYFO+n4KopdZQFzi1pP5TBCnCkgs2XOe GcIWlXj5+B8rhK0kMef1NWaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaS lllIWhYwsqxi5CgtLsjJTTcy3MQIjJdjEmyOOxj39noeYhTgYFTi4V2gIRMuxJpYVlyZe4hR goNZSYRX0Q0oxJuSWFmVWpQfX1Sak1p8iFGag0VJnNc78l+YkEB6YklqdmpqQWoRTJaJg1Oq gTFWn+3t8h/XCg+xbDyQcIGxc0ub+EQlRsF2vpnNXue+nps5//zPX0GNPI7TdzHkXF++zjVi ktz7fK6O7eUpyodj/0kHWzhPb/slGNbHEV9ydrWSn9bDubPe/IifEp6vZy6606d9OsODCInE Vo9r13rMnM4tU1rzT/PxrQuX5Zy2uelLFBlNZFFiKc5INNRiLipOBABZ94rMkwIAAA== Archived-At: Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 04:22:34 -0000 Yes, support. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, April 22, 2016 6:03 AM To: mpls@ietf.org; mpls-chairs@ietf.org; draft-kumarkini-mpls-spring-lsp-pi= ng@tools.ietf.org Subject: [mpls] working group adption poll on draft-kumarkini-mpls-spring-l= sp-ping Working Group, This is to start a two week poll to see if we have consensus to adopt draft= -kumarkini-mpls-spring-lsp-ping as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There are no IPR disclosures against this document. All the authors has stated that they are not aware of any IPRs that relate = to this document. In all but one case this has been done on the on the mpls= wg mailing list, in the last case this has been stated in a mail to the wg= chairs. The working group adoption poll ends May 7, 2016. /Loa MPLS wg co-chair. --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Apr 23 23:20:18 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0485812B05B; Sat, 23 Apr 2016 23:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdsSM5sdfw0D; Sat, 23 Apr 2016 23:20:15 -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 8DB5112B02D; Sat, 23 Apr 2016 23:20:14 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id EA23088A6BE20; Sun, 24 Apr 2016 06:20: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 u3O6KBpI002213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 24 Apr 2016 06:20:12 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 u3O6KAIj026005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Apr 2016 08:20:10 +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; Sun, 24 Apr 2016 08:20:10 +0200 From: "Henderickx, Wim (Nokia - BE)" To: EXT Sri , "Nagendra Kumar Nainar (naikumar)" Thread-Topic: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnUhF7Ws0SQf/A0K/SbWy0bWPFZ+YqCOA Date: Sun, 24 Apr 2016 06:20:09 +0000 Message-ID: <33A3FB51-2111-4E51-9410-F4A1021EC651@alcatel-lucent.com> References: <571A2101.9050106@pi.nu> 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_33A3FB5121114E519410F4A1021EC651alcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 06:20:17 -0000 --_000_33A3FB5121114E519410F4A1021EC651alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBjby1hdXRob3INCg0KRnJvbTogbXBscyA8bXBscy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRVhUIFNyaSA8c3Jp Z2FuZXNoa2luaUBnbWFpbC5jb208bWFpbHRvOnNyaWdhbmVzaGtpbmlAZ21haWwuY29tPj4NCkRh dGU6IFNhdHVyZGF5IDIzIEFwcmlsIDIwMTYgYXQgMTI6MDgNClRvOiAiTmFnZW5kcmEgS3VtYXIg TmFpbmFyIChuYWlrdW1hcikiIDxuYWlrdW1hckBjaXNjby5jb208bWFpbHRvOm5haWt1bWFyQGNp c2NvLmNvbT4+DQpDYzogIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+IiA8bXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+LCAiZHJhZnQta3VtYXJraW5pLW1wbHMt c3ByaW5nLWxzcC1waW5nQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1rdW1hcmtpbmktbXBs cy1zcHJpbmctbHNwLXBpbmdAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJhZnQta3VtYXJraW5pLW1wbHMt c3ByaW5nLWxzcC1waW5nQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1rdW1hcmtpbmktbXBs cy1zcHJpbmctbHNwLXBpbmdAdG9vbHMuaWV0Zi5vcmc+PiwgIm1wbHMtY2hhaXJzQGlldGYub3Jn PG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZz4iIDxtcGxzLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFttcGxzXSB3b3JraW5nIGdy b3VwIGFkcHRpb24gcG9sbCBvbiBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmcN Cg0KU3VwcG9ydCBhcyBjby1hdXRob3INCg0KU3JpDQoNCk9uIEZyaSwgQXByIDIyLCAyMDE2IGF0 IDg6MDYgQU0sIE5hZ2VuZHJhIEt1bWFyIE5haW5hciAobmFpa3VtYXIpIDxuYWlrdW1hckBjaXNj by5jb208bWFpbHRvOm5haWt1bWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGksDQoNClN1cHBvcnQg YXMgYSBjby1hdXRob3IuDQoNClJlZ2FyZHMsDQpOYWdlbmRyYQ0KDQpPbiA0LzIyLzE2LCA5OjAy IEFNLCAiTG9hIEFuZGVyc3NvbiIgPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6 DQoNCj5Xb3JraW5nIEdyb3VwLA0KPg0KPlRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xs IHRvIHNlZSBpZiB3ZSBoYXZlIGNvbnNlbnN1cyB0bw0KPmFkb3B0IGRyYWZ0LWt1bWFya2luaS1t cGxzLXNwcmluZy1sc3AtcGluZyBhcyBhbiBNUExTIHdvcmtpbmcNCj5ncm91cCBkb2N1bWVudC4N Cj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0 aGUgbXBscyB3b3JraW5nDQo+Z3JvdXAgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnPG1haWx0 bzptcGxzQGlldGYub3JnPikuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsDQo+bW90aXZhdGlvbiBm b3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0 DQo+dGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZ3JvdXAg ZG9jdW1lbnQuDQo+DQo+VGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMg ZG9jdW1lbnQuDQo+DQo+QWxsIHRoZSBhdXRob3JzIGhhcyBzdGF0ZWQgdGhhdCB0aGV5IGFyZSBu b3QgYXdhcmUgb2YgYW55IElQUnMgdGhhdA0KPnJlbGF0ZSB0byB0aGlzIGRvY3VtZW50LiBJbiBh bGwgYnV0IG9uZSBjYXNlIHRoaXMgaGFzIGJlZW4gZG9uZSBvbiB0aGUNCj5vbiB0aGUgbXBscyB3 ZyBtYWlsaW5nIGxpc3QsIGluIHRoZSBsYXN0IGNhc2UgdGhpcyBoYXMgYmVlbiBzdGF0ZWQgaW4g YQ0KPm1haWwgdG8gdGhlIHdnIGNoYWlycy4NCj4NCj5UaGUgd29ya2luZyBncm91cCBhZG9wdGlv biBwb2xsIGVuZHMgTWF5IDcsIDIwMTYuDQo+DQo+L0xvYQ0KPg0KPk1QTFMgd2cgY28tY2hhaXIu DQo+LS0NCj4NCj4NCj5Mb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6 IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KPlNl bmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0 bzpsb2FAcGkubnU+DQo+SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25l OiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGlu ZyBsaXN0DQptcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_000_33A3FB5121114E519410F4A1021EC651alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <80B1B0E1211FF749B1CDCB007D3B35F3@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlN1cHBvcnQgYXMgY28tYXV0aG9yPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExP T0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+bXBscyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRm Lm9yZyI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEVYVCBTcmkg Jmx0OzxhIGhyZWY9Im1haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbSI+c3JpZ2FuZXNoa2lu aUBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E YXRlOiA8L3NwYW4+U2F0dXJkYXkgMjMgQXByaWwgMjAxNiBhdCAxMjowODxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90O05hZ2VuZHJhIEt1bWFyIE5h aW5hciAobmFpa3VtYXIpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmFpa3VtYXJAY2lzY28u Y29tIj5uYWlrdW1hckBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3Jn Ij5tcGxzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5v cmciPm1wbHNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWt1 bWFya2luaS1tcGxzLXNwcmluZy1sc3AtcGluZ0B0b29scy5pZXRmLm9yZyI+ZHJhZnQta3VtYXJr aW5pLW1wbHMtc3ByaW5nLWxzcC1waW5nQHRvb2xzLmlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8 YSBocmVmPSJtYWlsdG86ZHJhZnQta3VtYXJraW5pLW1wbHMtc3ByaW5nLWxzcC1waW5nQHRvb2xz LmlldGYub3JnIj5kcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmdAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3Jn Ij5tcGxzLWNoYWlyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptcGxz LWNoYWlyc0BpZXRmLm9yZyI+bXBscy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFttcGxzXSB3b3Jr aW5nIGdyb3VwIGFkcHRpb24gcG9sbCBvbiBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNw LXBpbmc8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg ZGlyPSJsdHIiPlN1cHBvcnQgYXMgY28tYXV0aG9yDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5T cmk8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEFwciAyMiwgMjAxNiBhdCA4OjA2IEFNLCBOYWdlbmRy YSBLdW1hciBOYWluYXIgKG5haWt1bWFyKQ0KPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86bmFpa3VtYXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bmFpa3VtYXJAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KSGksPGJyPg0KPGJyPg0KU3VwcG9ydCBhcyBhIGNvLWF1dGhv ci48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCk5hZ2VuZHJhPGJyPg0KPGRpdj4NCjxkaXYgY2xh c3M9Img1Ij48YnI+DQpPbiA0LzIyLzE2LCA5OjAyIEFNLCAmcXVvdDtMb2EgQW5kZXJzc29uJnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQomZ3Q7V29ya2luZyBHcm91cCw8YnI+DQomZ3Q7PGJyPg0KJmd0O1RoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIGNvbnNlbnN1cyB0 bzxicj4NCiZndDthZG9wdCBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmcgYXMg YW4gTVBMUyB3b3JraW5nPGJyPg0KJmd0O2dyb3VwIGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQom Z3Q7UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhl IG1wbHMgd29ya2luZzxicj4NCiZndDtncm91cCBtYWlsaW5nIGxpc3QgKDxhIGhyZWY9Im1haWx0 bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPikuIFBsZWFzZSBnaXZlIGEgdGVjaG5p Y2FsPGJyPg0KJmd0O21vdGl2YXRpb24gZm9yIHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNw ZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdDxicj4NCiZndDt0aGUgZG9jdW1lbnQgc2hvdWxkIG5v dCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC48YnI+DQomZ3Q7PGJyPg0K Jmd0O1RoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Ljxi cj4NCiZndDs8YnI+DQomZ3Q7QWxsIHRoZSBhdXRob3JzIGhhcyBzdGF0ZWQgdGhhdCB0aGV5IGFy ZSBub3QgYXdhcmUgb2YgYW55IElQUnMgdGhhdDxicj4NCiZndDtyZWxhdGUgdG8gdGhpcyBkb2N1 bWVudC4gSW4gYWxsIGJ1dCBvbmUgY2FzZSB0aGlzIGhhcyBiZWVuIGRvbmUgb24gdGhlPGJyPg0K Jmd0O29uIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlzdCwgaW4gdGhlIGxhc3QgY2FzZSB0aGlzIGhh cyBiZWVuIHN0YXRlZCBpbiBhPGJyPg0KJmd0O21haWwgdG8gdGhlIHdnIGNoYWlycy48YnI+DQom Z3Q7PGJyPg0KJmd0O1RoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIHBvbGwgZW5kcyBNYXkgNywg MjAxNi48YnI+DQomZ3Q7PGJyPg0KJmd0Oy9Mb2E8YnI+DQomZ3Q7PGJyPg0KJmd0O01QTFMgd2cg Y28tY2hhaXIuPGJyPg0KJmd0Oy0tPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7TG9hIEFu ZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86 bG9hQG1haWwwMS5odWF3ZWkuY29tIj4NCmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvYT48YnI+DQom Z3Q7U2VuaW9yIE1QTFMgRXhwZXJ0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxh IGhyZWY9Im1haWx0bzpsb2FAcGkubnUiPmxvYUBwaS5udTwvYT48YnI+DQomZ3Q7SHVhd2VpIFRl Y2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVm PSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHZhbHVlPSImIzQzOzQ2NzM5ODEyMTY0 Ij4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1wbHMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_33A3FB5121114E519410F4A1021EC651alcatellucentcom_-- From nobody Sun Apr 24 11:25:38 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5E12D0C2; Sun, 24 Apr 2016 11:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6a5XKa6g7Xj; Sun, 24 Apr 2016 11:25:35 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBE812D0BA; Sun, 24 Apr 2016 11:25:34 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-91-571d0f720dc4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B1.28.03614.27F0D175; Sun, 24 Apr 2016 20:24:50 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Sun, 24 Apr 2016 14:25:33 -0400 From: Uma Chunduri To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnTVMRPq2M4BFQ0SZeUQyuvLAtZ+Zcp+Q Date: Sun, 24 Apr 2016 18:25:31 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635809E427@eusaamb106.ericsson.se> References: <571B29F8.1060301@pi.nu> In-Reply-To: <571B29F8.1060301@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonSreIXzbcYO8xfYtz504xWvybO4fZ Yt3lU2wWt5auZHVg8Viy5CeTx6zpbWweXy5/ZgtgjuKySUnNySxLLdK3S+DKmPBrKXPBT86K rcs2MTcwvmPvYuTkkBAwkeg6u4oRwhaTuHBvPVsXIxeHkMBRRomXU18xgSSEBJYzSrx7EgJi swnoSXyc+hOsWUTATmLjq3+MIA3MAosYJe5PPwY2SVggVGLVzmaoojCJaTtOs0HYRhL/P3WA DWURUJU4cvMRC4jNK+ArsW/jIhaIZSoSN6ZOAevlBKq5/28y2ExGoOu+n1oD1sssIC5x68l8 JoirBSSW7DnPDGGLSrx8/I8VwlaS+Ph7PjtEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEax WUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbmIERtExCTbHHYx7ez0PMQpwMCrx8C7glA0X Yk0sK67MPcQowcGsJML7jhsoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNc78l+YkEB6Yklqdmpq QWoRTJaJg1OqgVH4uOmhKqv1+3x94vde9hMU2zn5dN/S/WxfEmf77PHnv/Nk3bwId/4DG/wN l9+9vnGekRBvTwV3i2eZS9rZ7cqNVb/0Pr77VP6/oNFxwam4E87tN8rbAqRM5NhSgs4wskws 2hmy4YKGbu+GvxO8Zvu1Fc+foinCOvH4YsGXBzIexAYyfRBJalBiKc5INNRiLipOBACWbTJX ngIAAA== Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 18:25:36 -0000 We have implemented this and have few minor comments (shall post soon). I support adoption. -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 23, 2016 12:53 AM To: mpls@ietf.org Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls-chairs@ietf.o= rg Subject: [mpls] working group last call on draft-ietf-mpls-spring-entropy-l= abel Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-s= pring-entropy-label. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors and contributors (with one exception) have stated on the wo= rking group mailing list that they are not aware of any other IPRs that rel= ates to this draft. This working group last call ends May 12, 2016. /Loa for the MPLS wg chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sun Apr 24 11:32:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2218212B036; Sun, 24 Apr 2016 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, 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 YWmbI9MOHcLT; Sun, 24 Apr 2016 11:32:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B90012B015; Sun, 24 Apr 2016 11:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8642; q=dns/txt; s=iport; t=1461522725; x=1462732325; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=saVenmfxgeMK5Ee5DpM3xTHYLS0Cgw+VYvTOLMeITps=; b=CJaoFkiUCk3LkV7xjB+G8q0BylcSKaFuU45EUvlK/YV9xxbe6IaNpn+J 7zISFpjQr8QSPhoASXOuga9kx1el2lglJ9xPNG/v/m8T+icMX+t5ZTpL6 DdWkTNOHJsZxa1zoLJ3kbCTVeCGLg9FAU7hwuulDz8VbGtzONOylSu4lG M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAgAGEB1X/5FdJa1egmxMU30GtHmEc?= =?us-ascii?q?wENgXWGDgIceTgUAQEBAQEBAWUnhEEBAQEEIwo+AwsOAgIBCBEEAQEoAwICAhk?= =?us-ascii?q?XFAkIAgQBDQUIiCKvWJBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQSKaIQPEQEjE?= =?us-ascii?q?SCCSoJWBZgPAY4NgW2ETYhdjy4BHgEBQoNrbIcxNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,528,1454976000"; d="scan'208,217";a="264699207" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2016 18:32:04 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3OIW4wa002432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 24 Apr 2016 18:32:04 GMT Received: from xch-aln-011.cisco.com (173.36.7.21) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 24 Apr 2016 13:32:03 -0500 Received: from xch-aln-011.cisco.com ([173.36.7.21]) by XCH-ALN-011.cisco.com ([173.36.7.21]) with mapi id 15.00.1104.009; Sun, 24 Apr 2016 13:32:03 -0500 From: "Siva Sivabalan (msiva)" To: Sri , Loa Andersson Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnUf1/a+ulKMG3EqfA/9d5EY/KJ+ZdFDQ Date: Sun, 24 Apr 2016 18:32:03 +0000 Message-ID: <2f8fac4c4c8e426a838b8c1f012b7bed@XCH-ALN-011.cisco.com> References: <571B29F8.1060301@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.254.27] Content-Type: multipart/alternative; boundary="_000_2f8fac4c4c8e426a838b8c1f012b7bedXCHALN011ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 18:32:07 -0000 --_000_2f8fac4c4c8e426a838b8c1f012b7bedXCHALN011ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhcyBhIGNvLWF1dGhvci4NCg0KLVNpdmENCg0KRnJvbTogbXBscyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaQ0KU2VudDogU2F0dXJkYXksIEFw cmlsIDIzLCAyMDE2IDY6MDcgQU0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzogZHJhZnQtaWV0Zi1t cGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBt cGxzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwNCg0KSGksDQoN ClN1cHBvcnQgYXMgY28tYXV0aG9yLg0KDQpTcmkNCg0KT24gU2F0LCBBcHIgMjMsIDIwMTYgYXQg Mjo1MyBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90 ZToNCldvcmtpbmcgR3JvdXAsDQoNClRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxh YmVsLg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcg bGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGVyZSBhcmUg bm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0KQWxsIHRoZSBhdXRo b3JzIGFuZCBjb250cmlidXRvcnMgKHdpdGggb25lIGV4Y2VwdGlvbikgaGF2ZSBzdGF0ZWQgb24N CnRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBv ZiBhbnkgb3RoZXINCklQUnMgdGhhdCByZWxhdGVzIHRvIHRoaXMgZHJhZnQuDQoNClRoaXMgd29y a2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBNYXkgMTIsIDIwMTYuDQoNCg0KL0xvYQ0KZm9yIHRo ZSBNUExTIHdnIGNoYWlycw0KLS0NCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAg ICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3 ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FA cGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQp ICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIw NjQ+DQoNCg== --_000_2f8fac4c4c8e426a838b8c1f012b7bedXCHALN011ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cHBvcnQgYXMgYSBjby1hdXRob3IuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tU2l2YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3JpPGJy Pg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCAyMywgMjAxNiA2OjA3IEFNPGJyPg0KPGI+ VG86PC9iPiBMb2EgQW5kZXJzc29uPGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLW1wbHMtc3By aW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hh aXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbXBsc10gd29ya2luZyBncm91 cCBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXBwb3J0IGFzIGNvLWF1dGhvci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3JpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgQXBy IDIzLCAyMDE2IGF0IDI6NTMgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzps b2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0K VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u PGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsLjxicj4NCjxicj4NClBs ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0ICg8YSBo cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8 L2E+KS48YnI+DQo8YnI+DQpUaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhp cyBkb2N1bWVudC48YnI+DQo8YnI+DQpBbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyAo d2l0aCBvbmUgZXhjZXB0aW9uKSBoYXZlIHN0YXRlZCBvbjxicj4NCnRoZSB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXI8YnI+DQpJ UFJzIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NClRoaXMgd29ya2luZyBn cm91cCBsYXN0IGNhbGwgZW5kcyBNYXkgMTIsIDIwMTYuPGJyPg0KPGJyPg0KPGJyPg0KL0xvYTxi cj4NCmZvciB0aGUgTVBMUyB3ZyBjaGFpcnM8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJy Pg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0gPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxzcGFu IGNsYXNzPSJob2VuemIiPkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBl bWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i aG9lbnpiIj5TZW5pb3IgTVBMUyBFeHBlcnQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQHBpLm51 PC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5IdWF3ZWkgVGVjaG5vbG9naWVz IChjb25zdWx0YW50KSZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6IDxhIGhyZWY9InRlbDolMkI0 NiUyMDczOSUyMDgxJTIwMjElMjA2NCIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0Mzs0NiA3MzkgODEg MjEgNjQ8L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_2f8fac4c4c8e426a838b8c1f012b7bedXCHALN011ciscocom_-- From nobody Mon Apr 25 01:06:45 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B49012D51A for ; Mon, 25 Apr 2016 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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] 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 RBgia1vaFyDu for ; Mon, 25 Apr 2016 01:06:42 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30BE12D515 for ; Mon, 25 Apr 2016 01:06:40 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Apr 2016 10:06:36 +0200 X-IronPort-AV: E=Sophos;i="5.24,532,1454972400"; d="scan'208";a="444318396" Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 25 Apr 2016 10:06:36 +0200 Received: from HE111642.emea1.cds.t-internal.com ([10.134.93.11]) by he110890 ([10.134.92.131]) with mapi; Mon, 25 Apr 2016 10:06:35 +0200 From: To: Date: Mon, 25 Apr 2016 10:06:34 +0200 Thread-Topic: working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AdGcn3Y/U55n42peSgOovJr9C3iE4ACKOjsw Message-ID: <828773FE19B05B4581311493A046E85E6ECC050731@HE111642.emea1.cds.t-internal.com> References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: mpls@ietf.org Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 08:06:44 -0000 SGkgTG9hLA0KDQpJJ20gbm90IGFjdGl2ZSB3aXRoaW4gdGhlIE1QTFMgV0cuIEkgZWRpdCBkcmFm dC1pZXRmLXNwcmluZy1vYW0tdXNlY2FzZS4NCg0KSSByZWFkIGRyYWZ0LWt1bWFya2luaS1tcGxz LXNwcmluZy1sc3AtcGluZyBhbmQgc3VwcG9ydCBhZG9wdGlvbiBhcyBXRyBkb2Mgd2l0aGluIHRo ZSBNUExTIFdHLg0KDQpSZWdhcmRzLA0KDQpSdWVkaWdlcg0KDQoNCg0KLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51 XSANCkdlc2VuZGV0OiBGcmVpdGFnLCAyMi4gQXByaWwgMjAxNiAxNTowMw0KQW46IG1wbHNAaWV0 Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmct bHNwLXBpbmdAdG9vbHMuaWV0Zi5vcmcNCkJldHJlZmY6IHdvcmtpbmcgZ3JvdXAgYWRwdGlvbiBw b2xsIG9uIGRyYWZ0LWt1bWFya2luaS1tcGxzLXNwcmluZy1sc3AtcGluZw0KDQpXb3JraW5nIEdy b3VwLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCB0byBzZWUgaWYgd2UgaGF2 ZSBjb25zZW5zdXMgdG8gYWRvcHQgZHJhZnQta3VtYXJraW5pLW1wbHMtc3ByaW5nLWxzcC1waW5n IGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KUGxlYXNlIHNlbmQgeW91ciBj b21tZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhIHRlY2huaWNhbCBtb3Rp dmF0aW9uIGZvciB5b3VyIHN1cHBvcnQvbm90IHN1cHBvcnQsIGVzcGVjaWFsbHkgaWYgeW91IHRo aW5rIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRlZCBhcyBhIHdvcmtpbmcg Z3JvdXAgZG9jdW1lbnQuDQoNClRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0 aGlzIGRvY3VtZW50Lg0KDQpBbGwgdGhlIGF1dGhvcnMgaGFzIHN0YXRlZCB0aGF0IHRoZXkgYXJl IG5vdCBhd2FyZSBvZiBhbnkgSVBScyB0aGF0IHJlbGF0ZSB0byB0aGlzIGRvY3VtZW50LiBJbiBh bGwgYnV0IG9uZSBjYXNlIHRoaXMgaGFzIGJlZW4gZG9uZSBvbiB0aGUgb24gdGhlIG1wbHMgd2cg bWFpbGluZyBsaXN0LCBpbiB0aGUgbGFzdCBjYXNlIHRoaXMgaGFzIGJlZW4gc3RhdGVkIGluIGEg bWFpbCB0byB0aGUgd2cgY2hhaXJzLg0KDQpUaGUgd29ya2luZyBncm91cCBhZG9wdGlvbiBwb2xs IGVuZHMgTWF5IDcsIDIwMTYuDQoNCi9Mb2ENCg0KTVBMUyB3ZyBjby1jaGFpci4NCi0tIA0KDQoN CkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5o dWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxv YUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0DQo= From nobody Mon Apr 25 02:57:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CE912D158; Mon, 25 Apr 2016 02:57: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 HbClIE82nU0U; Mon, 25 Apr 2016 02:57: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 6C3BA12D150; Mon, 25 Apr 2016 02:57:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CIK13847; Mon, 25 Apr 2016 09:57:41 +0000 (GMT) Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 25 Apr 2016 10:57:37 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.171]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Mon, 25 Apr 2016 17:57:32 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" Thread-Topic: working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJdekOKGCCQAiEezAzuIvnGPr5+aeHfQ Date: Mon, 25 Apr 2016 09:57:31 +0000 Message-ID: References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.571DEA15.010B, 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: 07d47596785273c70085ffcb3a3421c0 Archived-At: Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 09:57:46 -0000 U3VwcG9ydCBhcyBjby1hdXRob3IuDQoNCkJlc3QgcmVnYXJkcywNCk1hY2ggDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGku bnVdDQo+IFNlbnQ6IEZyaWRheSwgQXByaWwgMjIsIDIwMTYgOTowMyBQTQ0KPiBUbzogbXBsc0Bp ZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWt1bWFya2luaS1tcGxzLXNw cmluZy1sc3AtcGluZ0B0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiB3b3JraW5nIGdyb3VwIGFk cHRpb24gcG9sbCBvbiBkcmFmdC1rdW1hcmtpbmktbXBscy1zcHJpbmctbHNwLXBpbmcNCj4gDQo+ IFdvcmtpbmcgR3JvdXAsDQo+IA0KPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCB0 byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gYWRvcHQNCj4gZHJhZnQta3VtYXJraW5pLW1w bHMtc3ByaW5nLWxzcC1waW5nIGFzIGFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC4NCj4g DQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRo ZSBtcGxzIHdvcmtpbmcgZ3JvdXANCj4gbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnKS4gUGxl YXNlIGdpdmUgYSB0ZWNobmljYWwgbW90aXZhdGlvbiBmb3IgeW91cg0KPiBzdXBwb3J0L25vdCBz dXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0IHRoZSBkb2N1bWVudCBzaG91bGQg bm90IGJlDQo+IGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KPiANCj4gVGhl cmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBB bGwgdGhlIGF1dGhvcnMgaGFzIHN0YXRlZCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkg SVBScyB0aGF0IHJlbGF0ZSB0bw0KPiB0aGlzIGRvY3VtZW50LiBJbiBhbGwgYnV0IG9uZSBjYXNl IHRoaXMgaGFzIGJlZW4gZG9uZSBvbiB0aGUgb24gdGhlIG1wbHMgd2cNCj4gbWFpbGluZyBsaXN0 LCBpbiB0aGUgbGFzdCBjYXNlIHRoaXMgaGFzIGJlZW4gc3RhdGVkIGluIGEgbWFpbCB0byB0aGUg d2cgY2hhaXJzLg0KPiANCj4gVGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9sbCBlbmRzIE1h eSA3LCAyMDE2Lg0KPiANCj4gL0xvYQ0KPiANCj4gTVBMUyB3ZyBjby1jaGFpci4NCj4gLS0NCj4g DQo+IA0KPiBMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBt YWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAg cGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Mon Apr 25 06:58:57 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498112D1A7; Mon, 25 Apr 2016 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBCiQyhY6wE7; Mon, 25 Apr 2016 06:58:55 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 6416012D50D; Mon, 25 Apr 2016 06:58:54 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v188so99352849wme.1; Mon, 25 Apr 2016 06:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WWwiom+dBN6Jx6zbsq0xQhh5KskbJco6b11cn42UJ5E=; b=GLBsfm8cdeQjtktNKBtfoi3CHOfSQehk8Tcb/ASwW1JqIUfeG9VFZfUsq+mxzR2IXC /VS8vmZHtjuOec4iPtyGjAWeLWNuvhbBrsIqgFGEMqHXBDAbD8LJWp0FXa7QDofBum7l rsjDqS9sv+bVdFDhzlcW3yR7uZLItSOihdMc35irAC+4GzqkHCSI+PKias7pMdnslfhd cHLYEFlq7P/G28yWkaCtLPvhX3HMAJ86wgVTc67IZ/z9dPYxyA9o0xTDfoxiIWbUmQ1Y 9bYtAApv4CDNg3Mbhmhs21RfIsQ7lQM6DJXMTbPjhCXZwuJumSSW1eyRC/dIjdTj/ZQz 6vNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WWwiom+dBN6Jx6zbsq0xQhh5KskbJco6b11cn42UJ5E=; b=ARSzthiIcqjnyaO2XKSsUKhD9iroBzBkD+CAKcbAx+ZST3ETI+X3DCsYUHYzkKFsul VK1P4pjYHiffAfAYtZrs12H2nOYh0ssj+hfRLbo928WgW7AU9xyoD6X07yK3BKWBrgr0 TeGJk94daGbmKpUNh2dWEBkq4HB84eKF38gimOe0bXTWmuPkGgxemsUINULMFUSMc+4x u6JCxCRhP1/SkFQ0CRHHONI8WkmRszW6GJLd0TaWCTQLoTjnostMCau5G5sQ3ZEoV204 C/FqZDKKqilx1nOnZBBVoQughV4glvNzRHWBOeVxVBwyNFftXry0s/copUF0Y9LFv5nm USEQ== X-Gm-Message-State: AOPr4FXrmZhfYekvcXjWLtGCvGzB+G/ecn1a9cxaHNVUVwirj99dJcZ5dauIqKQpfQkzIQ== X-Received: by 10.194.96.10 with SMTP id do10mr40441467wjb.113.1461592732936; Mon, 25 Apr 2016 06:58:52 -0700 (PDT) Received: from [192.168.2.134] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c4sm23711396wjm.24.2016.04.25.06.58.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 06:58:51 -0700 (PDT) To: Loa Andersson , "mpls@ietf.org" References: <571B29F8.1060301@pi.nu> From: Stewart Bryant Message-ID: <571E229B.2090405@gmail.com> Date: Mon, 25 Apr 2016 14:58:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571B29F8.1060301@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 13:58:56 -0000 I support this becoming a WG doc and thereby comming under WG control. However I am not sure about the dismissal of the option to reuse the ELI+EL. This clutters the stack less than the proposed option. Also I wonder why this is standards track? Surely any equipment that understands the ELI can do this and thus this is just an informal description of the problem and a solution. Stewart On 23/04/2016 08:53, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs From nobody Mon Apr 25 10:57:32 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA42912D645; Mon, 25 Apr 2016 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJGIQ6GSJeQw; Mon, 25 Apr 2016 10:57:29 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D68B012D631; Mon, 25 Apr 2016 10:57:28 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id v188so107856970wme.1; Mon, 25 Apr 2016 10:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fT/j8Wan99apLkeYmBdTIyP4q7KDchOGA6bwXOoKUPE=; b=PTbJMpVITK7bAFgTlb5TfzxGwkR+qS/RCRM+GUL9PXL+07W+r9Jh8d7kh7Nrkm60Go 4SlxfcUdQ7WcJcq0px9b02YuTMVj1sCxTNDj7idPsj9T2svnCicy1dDiY2OVaJrVUuJO TZTZIAZMXJ/PK3SRAtDuvXL8UM0JAzsCF1Ks1bJCTEY+HL+GZr4/xFMX/tTA464lt40d NSPspQftlUxub/iTYDkxfXKa12Zwo2qY290UKsQaQgSa0SKhAvNzKTQ20iyfnoJ6TB7Z mqmXAW7a15EwgjDX5DCVhDQFVHq+S0u94FayXvxYSdSGDP1EAvcTpG/CTXnKlsazzFkz zSwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fT/j8Wan99apLkeYmBdTIyP4q7KDchOGA6bwXOoKUPE=; b=IxbCpv0KLp/F2/R4FxBg961kc3EIJFraL/Gakcu/avsomg0TQYdPx5s0XwS6f9dkzN ZmdFxNDjOSoC+UYsfIvUU22Zl6De2OKKbxrpVVA7OnZaxbc8EhIftY9sSfp1ZCINlYAA 0SPM0RKaslwR9c0ub51EFexurTIT5A9NBJypRttkM+TdRsbfumxiM0Q7Etx/mvOV0gb0 2aXys8h6dbnD/B6CCYenacP8sKBY1Ywb0Nq6UQFIT704t3y/bFW1Zf4ciGGkz33GcWKn 982nq3+yG67RaJiFBKoXVdgenqdnLLFW4fGr+fhv2+IN8L467YEJkuWb+96Of1JD2+qq WHMg== X-Gm-Message-State: AOPr4FX+Pc2VLrc3/TInasHh36r9ZG7RTFzRRMVCYL1HKpOSx64ZGplAlGfyAEzQ0VAmdld7ewIgTajO0eZIng== MIME-Version: 1.0 X-Received: by 10.194.157.195 with SMTP id wo3mr36165190wjb.155.1461607047437; Mon, 25 Apr 2016 10:57:27 -0700 (PDT) Received: by 10.195.14.3 with HTTP; Mon, 25 Apr 2016 10:57:27 -0700 (PDT) In-Reply-To: <571E229B.2090405@gmail.com> References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> Date: Mon, 25 Apr 2016 13:57:27 -0400 Message-ID: From: George Swallow To: Stewart Bryant Content-Type: multipart/alternative; boundary=089e013c6648dd2419053152e81c Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 17:57:31 -0000 --089e013c6648dd2419053152e81c Content-Type: text/plain; charset=UTF-8 Stewart - On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant wrote: > I support this becoming a WG doc and thereby comming under WG > control. > The document is a WG doc. We are now in WG last call. > However I am not sure about the dismissal of the option to reuse > the ELI+EL. This clutters the stack less than the proposed option. > > Also I wonder why this is standards track? > A reasonable question, particularly since there are no MUSTs, SHALLs or REQUIREDs. Will discuss with my Co-Chairs and ADs. > Surely any equipment that understands the ELI can do this and thus this is > just an informal description of the problem and a solution. > > Stewart > > > On 23/04/2016 08:53, Loa Andersson wrote: > >> Working Group, >> >> This is to initiate a two week working group last call on >> draft-ietf-mpls-spring-entropy-label. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >> There are no IPR disclosures against this document. >> >> All the authors and contributors (with one exception) have stated on >> the working group mailing list that they are not aware of any other >> IPRs that relates to this draft. >> >> This working group last call ends May 12, 2016. >> >> >> /Loa >> for the MPLS wg chairs >> > > --089e013c6648dd2419053152e81c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stewart -

On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <stewa= rt.bryant@gmail.com> wrote:
I support this becoming a WG doc and thereby comming under WG
control.

The document is a WG doc.=C2= =A0=C2=A0 We are now in WG last call.
=C2=A0
However I am not sure about the dismissal of the option to reuse
the ELI+EL. This clutters the stack less than the proposed option.

Also I wonder why this is standards track?

<= div>A reasonable question, particularly since there are no MUSTs, SHALLs or= REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs.
=C2= =A0
Surely any equipment that understands the ELI can do this and thus this is = just an informal description of the problem and a solution.

Stewart


On 23/04/2016 08:53, Loa Andersson wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs


--089e013c6648dd2419053152e81c-- From nobody Mon Apr 25 11:24:42 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B283612B035; Mon, 25 Apr 2016 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4P5KywsyIpB; Mon, 25 Apr 2016 11:24:39 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A016B12B004; Mon, 25 Apr 2016 11:24:38 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id e201so95289567wme.0; Mon, 25 Apr 2016 11:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lCwP/g9rb57eA0mVLTFSGqEuyTPk8u7Y8rEh94zvTR0=; b=obX6U902P8kQSUBGyFcA83ltufmPCfBv38m/2AtKu6DwQL1v/JJqzNxIATHK3eQTfZ RZFb2asO4ktL4e6GTH6wTnWzWqMFeVw7OMtJ2bnstzsnNapZ9VRrIATZxIiFQQh0ataJ 6zGqHspfhanfGj+5pop4is9h/l6fw2vk0zFNTvZyuKpr6ZMbiHqXnCcpb2R3xAlmrxX5 OHmSi5e2A0iMdi8dgGctoa60SoeXZSqh4N7D4Q5vcAsxwIZHdxLHJVAd4yC/F3/v3k0+ +/xaWV5LDcQPE5fyWnR9QEl3G7lk2ZTnCXZz1ggtITT3pMYW0TWJzNgtEH9HtIrPRDjV F+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lCwP/g9rb57eA0mVLTFSGqEuyTPk8u7Y8rEh94zvTR0=; b=d/c8aDgeGNeXuLi48Hb6PkZJWCnFqc8RI8IRWMBpKfGbXNnaCvECqpkKcrzAawHV3f vWmj6KSG+GLLps74vN8o9Dnj+1UrOGq4z/CvkWW+yMXlNv1hlOKnneKbg1BtOTYyBIoV 1ANbE7mPI29w0EV8iomZVRUXETAjUeCqcRtUND380bWzg/4Fo85x+BHnMGZ/OqVJIpLN NerR4Z8vUvP0PWP+823GZ7VDOxP6ctNVTV16MD7Z7S7+RS6UvEY+ik/rMstztpNYnOjO GyZ+LelTMa2umRH67c+tB4EHHc3a0ifwtUk/BcFAdiRJvtUj2y5s4/btwwcMM/4i5hyY O9/Q== X-Gm-Message-State: AOPr4FU78SYE/39+481C0sCmBfjduGx1T7waxQBxbZcMTbQ04a+xEryq95RJKlckFowyGUDjHmUiAb+GA23drQ== MIME-Version: 1.0 X-Received: by 10.28.51.5 with SMTP id z5mr14612756wmz.101.1461608677262; Mon, 25 Apr 2016 11:24:37 -0700 (PDT) Received: by 10.195.14.3 with HTTP; Mon, 25 Apr 2016 11:24:37 -0700 (PDT) In-Reply-To: <571B29F8.1060301@pi.nu> References: <571B29F8.1060301@pi.nu> Date: Mon, 25 Apr 2016 14:24:37 -0400 Message-ID: From: George Swallow To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11441cae024a7e0531534a09 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:24:40 -0000 --001a11441cae024a7e0531534a09 Content-Type: text/plain; charset=UTF-8 I support the document going forward as "Informational" and have the following comments: Section 5.4 para 1 OLD: protocol such as an IGP. For the same Section 3 above, if LSR P1 NEW: protocol such as an IGP. Applying this method to the example in Section 3 above, if LSR P1 Section 5.4 para OLD: A variant of this solution was selected which balances the number of labels that need to be pushed against the requirement for entropy. NEW: Note that as refinement of this solution which balances the number of pushed labels against the desired entropy is the solution described in Section 4. On Sat, Apr 23, 2016 at 3:53 AM, Loa Andersson wrote: > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a11441cae024a7e0531534a09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the document going forward as "In= formational" and have the following comments:

Section 5.4= para 1

OLD:
   protocol such as an IGP.  F=
or the same Section 3 above, if LSR P1

NEW: 
   protocol such as an IGP.
=

<NEW PARAGRAPH>
   App=
lying this method to the example in Section 3 above, if LSR P1

Section 5.4 para 
OLD:

   =
A variant of this solution was selected which balances the number of
   labels that need to be pushed against the requirement for entropy.
NEW:
<move this para above =
para 2>
   Note that as refinement of this solu=
tion which balances the number of
   pushed labels against the desired entropy is the solution described in S=
ection 4.



On Sat, Apr 23, 2016 at 3:53 AM, Loa = Andersson <loa@pi.nu> wrote:
Worki= ng Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a11441cae024a7e0531534a09-- From nobody Mon Apr 25 12:03:27 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C143812D670; Mon, 25 Apr 2016 12:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc7aG28pZA27; Mon, 25 Apr 2016 12:03:25 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5370C12D679; Mon, 25 Apr 2016 12:03:18 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id u206so142626745wme.1; Mon, 25 Apr 2016 12:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ERMuIaqMyS6FUU42yN+MIrBfXvIYz0J0i1HiVTA4lrc=; b=xPrkAfP5te4nBp8umm+JwHwzuIi/Bn0r+oh1W1TD3zJolmJ+S9Y8THzEEL8DR/xYot a+wB5WsCQZRxA43EiVHdDfE53U9fGwxYY5SL3kBpM5MrDPk4cnlLiLiFjMDcmjQW/Aej G8QlD5csLHbzEj4Im6whataYVlM1Ud1FZP372/wnFMmQ7l/zP7pAq1b6g6te4rBrbAo1 +TJIaV0Lr8QYNgVlIkKIWU1YM/fvxssP+CZLdI/gDu7SsSHKoSgk5+fYZZgmk+D06AzD bpwzOPJ0JnIEKIFFmaN+tNwtlpFxz1vsMNvwXg3OvPwpDReriqiD0RLwS7Eaj5CcJzlK H3hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ERMuIaqMyS6FUU42yN+MIrBfXvIYz0J0i1HiVTA4lrc=; b=Xlna3FUuuJ6fmM7+nK4+Qg0WoNuk31aTnzSExliI9LJ20oVwoZbTZKzH6lSBlHUGCF ICPmeH+HIHM+t5vT1CCiu/5xGjSSfOojM22GAdf4gM/n2l1dtcGVVP2W0Eh+s/iqk+oY CvCnOLn/iRDej4JnRbhhY74GYW7UGmc2NtGdNXJzvyD8tTdQHX3xlZLH9RnOrNm6Dt5f 2Aj4SFzWrm+2Uce8t9L9azuPxnZ/w5HiO4R/Zt3mGaUrcPSG6FskGMRj01fEV636vSuG G5WyzO9E9V3RmXGMZ8NSp5/l9+tkqGd6VFAKop0UsDTfeBXxia9P0MSXHYFapbU5gr+w 6MzA== X-Gm-Message-State: AOPr4FUeM87R3FdWLlLX6afhmxidAiquM0al6qvQAZa3KA7N7mFJGh8O8Z0US5H2ULGDEw== X-Received: by 10.28.59.133 with SMTP id i127mr5558366wma.24.1461610996894; Mon, 25 Apr 2016 12:03:16 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id jh2sm24966344wjb.39.2016.04.25.12.03.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 12:03:15 -0700 (PDT) To: George Swallow References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> From: Stewart Bryant Message-ID: <571E69F2.8020506@gmail.com> Date: Mon, 25 Apr 2016 20:03:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000400040602010606000104" Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:03:26 -0000 This is a multi-part message in MIME format. --------------000400040602010606000104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 25/04/2016 18:57, George Swallow wrote: > Stewart - > > On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant > > wrote: > > I support this becoming a WG doc and thereby comming under WG > control. > > > The document is a WG doc. We are now in WG last call. Sorry, I missed that :( I should have read the subject! > However I am not sure about the dismissal of the option to reuse > the ELI+EL. This clutters the stack less than the proposed option. > > Also I wonder why this is standards track? > > > A reasonable question, particularly since there are no MUSTs, SHALLs > or REQUIREDs. Will discuss with my Co-Chairs and ADs. Well that brings me to wonder what needs to be specified, since action when the label stack is pushed is a local matter and as I remember a number of the rejected strategies are just normal MPLS. - Stewart > Surely any equipment that understands the ELI can do this and thus > this is just an informal description of the problem and a solution. > > Stewart > > > On 23/04/2016 08:53, Loa Andersson wrote: > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list > (mpls@ietf.org ). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have > stated on > the working group mailing list that they are not aware of any > other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs > > > --------------000400040602010606000104 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 25/04/2016 18:57, George Swallow wrote:
Stewart -

On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
I support this becoming a WG doc and thereby comming under WG
control.

The document is a WG doc.   We are now in WG last call.

Sorry, I missed that :( I should have read the subject!

 
However I am not sure about the dismissal of the option to reuse
the ELI+EL. This clutters the stack less than the proposed option.

Also I wonder why this is standards track?

A reasonable question, particularly since there are no MUSTs, SHALLs or REQUIREDs.  Will discuss with my Co-Chairs and ADs.

Well that brings me to wonder what needs to be specified, since action when the label stack is pushed is a local matter and as I remember a number of the rejected strategies are just normal MPLS.

- Stewart


 
Surely any equipment that understands the ELI can do this and thus this is just an informal description of the problem and a solution.

Stewart


On 23/04/2016 08:53, Loa Andersson wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this document.

All the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs



--------------000400040602010606000104-- From nobody Mon Apr 25 12:19:20 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AB12D6B9; Mon, 25 Apr 2016 12:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHcpUGW8OtbV; Mon, 25 Apr 2016 12:19:16 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483D112D69E; Mon, 25 Apr 2016 12:19:16 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-2f-571e6d87fccd Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id EB.9D.03614.78D6E175; Mon, 25 Apr 2016 21:18:32 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Mon, 25 Apr 2016 15:19:13 -0400 From: Gregory Mirsky To: George Swallow , Stewart Bryant Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnvqgLrEm8VHuxEKbfrdW+MSR/p+bPPSA///Qq2A= Date: Mon, 25 Apr 2016 19:19:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A5E5C2eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyuXSPn25Hrly4weoVXBbnzp1itFh3+RSb xa2lK1ktTj1ItFg0eRmLA6vHzll32T2WLPnJ5PHl8me2AOYoLpuU1JzMstQifbsEroyZb9rY C7qaGCs+XbvP2sB4pq6LkZNDQsBEYv2XDjYIW0ziwr31QDYXh5DAUUaJObvvsEA4yxklPl3p ZAWpYhMwknixsYcdxBYRiJBYf2wDWJxZ4DCjxLOrViC2sECoxMQtf1kgasIkds6fzQRhW0m8 /fsHrJ5FQFXi/6ptYHN4BXwlGva/YYVY1sEo0fjxGyNIglMgUGLXp4VgRYxA530/tYYJYpm4 xK0n85kgzhaQWLLnPDOELSrx8vE/VghbUWJf/3R2iPp8iS0zIN7kFRCUODnzCcsERtFZSEbN QlI2C0nZLEYOoLimxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFaXJCTm25kuIkRGH/H JNgcdzDu7fU8xCjAwajEw7uAUzZciDWxrLgy9xCjBAezkgjvkhy5cCHelMTKqtSi/Pii0pzU 4kOM0hwsSuK83pH/woQE0hNLUrNTUwtSi2CyTBycUg2MIsHT9/hWP7YNv7b53j/F3zVegi+b 9YW1H7y4Kx0bfk/U69CpwqUz/00429NgUjuPI2z/wq6i4AsBt9dsC/rx/x7Dh95Ln7gPfrog OCnWhXHXDOa9N3Y9OVwb25955rHNh9yqRyq7XvOpm74+YNb8vWaD2qJzh5bbGKlbfn7w6NrP KX5HbC+n8SmxFGckGmoxFxUnAgA5el4guwIAAA== Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 19:19:19 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A5E5C2eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2VvcmdlLCBldC4gYWwsDQpJ4oCZdmUgZm91bmQgc2V2ZXJhbCBvY2N1cnJlbmNlcywgdGhy ZWUgYWN0dWFsbHksIG9mIFNIT1VMRCBiZWluZyB1c2VkIGluIFNlY3Rpb24gNC4NCg0KQW5kIEkg YWdyZWUgd2l0aCBTdGV3YXJ0IHRoYXQgYXBwbGljYXRpb24gb2YgPEVMSSwgRUw+IGlzIHRoZSBs b2NhbCBkZWNpc2lvbiBhbmQsIGF0IG1vc3QsIHRoaXMgd29yayBjYW4gYmUgcHVibGlzaGVkIGFz IEluZm9ybWF0aW9uYWwuDQpPbmUgY29tbWVudCwgc3VnZ2VzdGlvbjoNCg0KwrcgICAgICAgICB0 aGUgc2FtcGxlIGFsZ29yaXRobSBpbiBTZWN0aW9uIDQgc3VnZ2VzdHMgdGhhdCB0aGUgc2FtZSA8 RUxJLEVMPiB0dXBsZSBiZWVuIHVzZWQgbXVsdGlwbGUgdGltZXMgd2hlcmVhcyBpdCBtYXkgYmUg YWR2YW50YWdlb3VzIHRvIGdlbmVyYWxpemUgYW5kIHBvaW50IHRoYXQgdGhlIGRpZmZlcmVudCBl bnRyb3B5IGxhYmVsIHZhbHVlIG1heSBiZSB1c2VkIGJ5IHJlZmVycmluZyB0byB0aGUgdHVwbGUg YXMgPEVMSSwgRUxuPg0KDQpSZWdhcmRzLA0KICAgICAgICBHcmVnDQoNCg0KRnJvbTogbXBscyBb bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdlb3JnZSBTd2FsbG93 DQpTZW50OiBNb25kYXksIEFwcmlsIDI1LCAyMDE2IDEwOjU3IEFNDQpUbzogU3Rld2FydCBCcnlh bnQNCkNjOiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5v cmc7IG1wbHNAaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21w bHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50 cm9weS1sYWJlbA0KDQpTdGV3YXJ0IC0NCg0KT24gTW9uLCBBcHIgMjUsIDIwMTYgYXQgOTo1OCBB TSwgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86c3Rld2Fy dC5icnlhbnRAZ21haWwuY29tPj4gd3JvdGU6DQpJIHN1cHBvcnQgdGhpcyBiZWNvbWluZyBhIFdH IGRvYyBhbmQgdGhlcmVieSBjb21taW5nIHVuZGVyIFdHDQpjb250cm9sLg0KDQpUaGUgZG9jdW1l bnQgaXMgYSBXRyBkb2MuICAgV2UgYXJlIG5vdyBpbiBXRyBsYXN0IGNhbGwuDQoNCkhvd2V2ZXIg SSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZGlzbWlzc2FsIG9mIHRoZSBvcHRpb24gdG8gcmV1c2UN CnRoZSBFTEkrRUwuIFRoaXMgY2x1dHRlcnMgdGhlIHN0YWNrIGxlc3MgdGhhbiB0aGUgcHJvcG9z ZWQgb3B0aW9uLg0KDQpBbHNvIEkgd29uZGVyIHdoeSB0aGlzIGlzIHN0YW5kYXJkcyB0cmFjaz8N Cg0KQSByZWFzb25hYmxlIHF1ZXN0aW9uLCBwYXJ0aWN1bGFybHkgc2luY2UgdGhlcmUgYXJlIG5v IE1VU1RzLCBTSEFMTHMgb3IgUkVRVUlSRURzLiAgV2lsbCBkaXNjdXNzIHdpdGggbXkgQ28tQ2hh aXJzIGFuZCBBRHMuDQoNClN1cmVseSBhbnkgZXF1aXBtZW50IHRoYXQgdW5kZXJzdGFuZHMgdGhl IEVMSSBjYW4gZG8gdGhpcyBhbmQgdGh1cyB0aGlzIGlzIGp1c3QgYW4gaW5mb3JtYWwgZGVzY3Jp cHRpb24gb2YgdGhlIHByb2JsZW0gYW5kIGEgc29sdXRpb24uDQoNClN0ZXdhcnQNCg0KDQpPbiAy My8wNC8yMDE2IDA4OjUzLCBMb2EgQW5kZXJzc29uIHdyb3RlOg0KV29ya2luZyBHcm91cCwNCg0K VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u DQpkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwuDQoNClBsZWFzZSBzZW5kIHlv dXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0IChtcGxzQGlldGYub3JnPG1h aWx0bzptcGxzQGlldGYub3JnPikuDQoNClRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdh aW5zdCB0aGlzIGRvY3VtZW50Lg0KDQpBbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyAo d2l0aCBvbmUgZXhjZXB0aW9uKSBoYXZlIHN0YXRlZCBvbg0KdGhlIHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0IHRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlcg0KSVBScyB0aGF0 IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC4NCg0KVGhpcyB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBl bmRzIE1heSAxMiwgMjAxNi4NCg0KDQovTG9hDQpmb3IgdGhlIE1QTFMgd2cgY2hhaXJzDQoNCg0K --_000_7347100B5761DC41A166AC17F22DF11221A5E5C2eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1u YW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA5ODQwNTk4NDsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk1NTg1NTU3MCA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEdlb3JnZSwgZXQu IGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZdmUgZm91bmQgc2V2ZXJhbCBv Y2N1cnJlbmNlcywgdGhyZWUgYWN0dWFsbHksIG9mIFNIT1VMRCBiZWluZyB1c2VkIGluIFNlY3Rp b24gNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkFuZCBJIGFncmVlIHdpdGggU3Rld2FydCB0aGF0IGFwcGxpY2F0aW9u IG9mICZsdDtFTEksIEVMJmd0OyBpcyB0aGUgbG9jYWwgZGVjaXNpb24gYW5kLCBhdCBtb3N0LCB0 aGlzIHdvcmsgY2FuIGJlIHB1Ymxpc2hlZCBhcyBJbmZvcm1hdGlvbmFsLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5PbmUgY29tbWVudCwgc3VnZ2VzdGlvbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHNhbXBsZSBhbGdvcml0 aG0gaW4gU2VjdGlvbiA0IHN1Z2dlc3RzIHRoYXQgdGhlIHNhbWUgJmx0O0VMSSxFTCZndDsgdHVw bGUgYmVlbiB1c2VkIG11bHRpcGxlIHRpbWVzIHdoZXJlYXMgaXQgbWF5IGJlIGFkdmFudGFnZW91 cyB0byBnZW5lcmFsaXplIGFuZA0KIHBvaW50IHRoYXQgdGhlIGRpZmZlcmVudCBlbnRyb3B5IGxh YmVsIHZhbHVlIG1heSBiZSB1c2VkIGJ5IHJlZmVycmluZyB0byB0aGUgdHVwbGUgYXMgJmx0O0VM SSwgRUxuJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+R2VvcmdlIFN3YWxsb3c8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBcHJp bCAyNSwgMjAxNiAxMDo1NyBBTTxicj4NCjxiPlRvOjwvYj4gU3Rld2FydCBCcnlhbnQ8YnI+DQo8 Yj5DYzo8L2I+IGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbEB0b29scy5pZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1w bHMtc3ByaW5nLWVudHJvcHktbGFiZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdGV3YXJ0IC08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN b24sIEFwciAyNSwgMjAxNiBhdCA5OjU4IEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdhcnQu YnJ5YW50QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoaXMgYmVjb21pbmcgYSBXRyBkb2MgYW5kIHRoZXJlYnkg Y29tbWluZyB1bmRlciBXRzxicj4NCmNvbnRyb2wuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQgaXMgYSBXRyBkb2MuJm5ic3A7Jm5ic3A7 IFdlIGFyZSBub3cgaW4gV0cgbGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyIEkgYW0gbm90IHN1cmUgYWJv dXQgdGhlIGRpc21pc3NhbCBvZiB0aGUgb3B0aW9uIHRvIHJldXNlPGJyPg0KdGhlIEVMSSYjNDM7 RUwuIFRoaXMgY2x1dHRlcnMgdGhlIHN0YWNrIGxlc3MgdGhhbiB0aGUgcHJvcG9zZWQgb3B0aW9u Ljxicj4NCjxicj4NCkFsc28gSSB3b25kZXIgd2h5IHRoaXMgaXMgc3RhbmRhcmRzIHRyYWNrPzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QSByZWFzb25hYmxlIHF1ZXN0aW9uLCBwYXJ0aWN1bGFybHkgc2luY2UgdGhlcmUgYXJlIG5v IE1VU1RzLCBTSEFMTHMgb3IgUkVRVUlSRURzLiZuYnNwOyBXaWxsIGRpc2N1c3Mgd2l0aCBteSBD by1DaGFpcnMgYW5kIEFEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZWx5IGFueSBlcXVpcG1lbnQgdGhhdCB1bmRlcnN0YW5k cyB0aGUgRUxJIGNhbiBkbyB0aGlzIGFuZCB0aHVzIHRoaXMgaXMganVzdCBhbiBpbmZvcm1hbCBk ZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbSBhbmQgYSBzb2x1dGlvbi48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+U3Rld2FydDwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCk9uIDIzLzA0LzIwMTYgMDg6NTMsIExvYSBBbmRlcnNzb24gd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3JraW5nIEdyb3VwLDxicj4N Cjxicj4NClRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbjxicj4NCmRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbC48YnI+DQo8 YnI+DQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlz dCAoPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGll dGYub3JnPC9hPikuPGJyPg0KPGJyPg0KVGhlcmUgYXJlIG5vIElQUiBkaXNjbG9zdXJlcyBhZ2Fp bnN0IHRoaXMgZG9jdW1lbnQuPGJyPg0KPGJyPg0KQWxsIHRoZSBhdXRob3JzIGFuZCBjb250cmli dXRvcnMgKHdpdGggb25lIGV4Y2VwdGlvbikgaGF2ZSBzdGF0ZWQgb248YnI+DQp0aGUgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVy PGJyPg0KSVBScyB0aGF0IHJlbGF0ZXMgdG8gdGhpcyBkcmFmdC48YnI+DQo8YnI+DQpUaGlzIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgTWF5IDEyLCAyMDE2Ljxicj4NCjxicj4NCjxicj4N Ci9Mb2E8YnI+DQpmb3IgdGhlIE1QTFMgd2cgY2hhaXJzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7347100B5761DC41A166AC17F22DF11221A5E5C2eusaamb103erics_-- From nobody Mon Apr 25 22:04:23 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144E512B03D; Mon, 25 Apr 2016 22:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 QnkGkJX0uKO1; Mon, 25 Apr 2016 22:04:20 -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 72E0B12B01B; Mon, 25 Apr 2016 22:04:20 -0700 (PDT) Received: from [192.168.1.2] (unknown [122.53.41.246]) (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 1DC4B18013E4; Tue, 26 Apr 2016 07:04:16 +0200 (CEST) To: Gregory Mirsky , George Swallow , Stewart Bryant References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> From: Loa Andersson Message-ID: <571EF6B9.403@pi.nu> Date: Tue, 26 Apr 2016 13:03:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 05:04:22 -0000 Greg, (talking about the SHOULDs in Section 4 only) I think what George (and Stewart) says is that since the document does not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an Informational RFC. However, it does not work to turn that argument around and say that an Informational RFC can't use the normative language, it was doen for example in RFC 7412. I think we should change it to Informational, but there is no need to do anything to the SHOULDs in section 4. /Loa On 2016-04-26 03:19, Gregory Mirsky wrote: > Hi George, et. al, > > Ive found several occurrences, three actually, of SHOULD being used in > Section 4. > > And I agree with Stewart that application of is the local > decision and, at most, this work can be published as Informational. > > One comment, suggestion: > > the sample algorithm in Section 4 suggests that the same tuple > been used multiple times whereas it may be advantageous to generalize > and point that the different entropy label value may be used by > referring to the tuple as > > Regards, > > Greg > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow > *Sent:* Monday, April 25, 2016 10:57 AM > *To:* Stewart Bryant > *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; > mpls@ietf.org; mpls-chairs@ietf.org > *Subject:* Re: [mpls] working group last call on > draft-ietf-mpls-spring-entropy-label > > Stewart - > > On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant > > wrote: > > I support this becoming a WG doc and thereby comming under WG > control. > > The document is a WG doc. We are now in WG last call. > > However I am not sure about the dismissal of the option to reuse > the ELI+EL. This clutters the stack less than the proposed option. > > Also I wonder why this is standards track? > > A reasonable question, particularly since there are no MUSTs, SHALLs or > REQUIREDs. Will discuss with my Co-Chairs and ADs. > > Surely any equipment that understands the ELI can do this and thus > this is just an informal description of the problem and a solution. > > Stewart > > > > On 23/04/2016 08:53, Loa Andersson wrote: > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org > ). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Mon Apr 25 23:57:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF92D12B044; Mon, 25 Apr 2016 23:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nuzp5vfWj6l; Mon, 25 Apr 2016 23:56:58 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 654B312B042; Mon, 25 Apr 2016 23:56:58 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id u206so17302440wme.1; Mon, 25 Apr 2016 23:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VL6WUVzaTnPT+hE4ns5bR7bYzoroBFiYiToEf/iq/9U=; b=BCOv5LbSVGBwxtdvWerCeO40RluxFIs9n2yxgcmOFMlbw6sve9UPL87DXl/sz8Bris tONt+kBtxmahE4r1YgK1f07zy0ThYu4BTnh5zlIHvghOTvIb2SMK4GnO7qN5i9VGKURW /7IxFYdgni8xxgpDTlwq/zqYEyNX12yX3tymzU9+a7iGoQHJNGfHtX4e+N8a5RVq7uGW 2zDJtOwq0ov6eOKVIG40utv1HHvEZWj7UD11Du5Tv8APiY5vDM1SIFb+iO0OywbQb+WS bYNzuvRlzGl8Cb+m/6kmg3hTsWzeI4Q6oTZEIwHYPKm4Ltqarhj7jW4H1ePT4leTtwl1 Uyng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VL6WUVzaTnPT+hE4ns5bR7bYzoroBFiYiToEf/iq/9U=; b=Gy+SjQ7eqI1TCWsjtjCFa5gd/xdEZOjmJPxpL2GIByW5k1RCkNH1GOOXWKXaQF+p9L Zbh/7W0hWajfshIq6fhKGK6kTOz0J+5w3wVBRcQsqcE/XNe6LsHdP4IjmQpJbrSOUjiX 1y5CI8VBbJvOR8/3XT+lXQGzGC98aHSvl+caPL0kK0uVdePOxJUYsf2kH29/I/0wBedF ycZc82WURF3X3O2+rARu0t2ExyOILGunxBqACRso+Aoza0EHVNReh+Q5+LiniTbWQyC1 aezmrD9OenBLPEjUQ8kf8Wswsui6J4Y77xLc5PHFYNc/mIccTDXhLqrukr1nqd9O6D8P I4Gg== X-Gm-Message-State: AOPr4FUyrgH9vfEzv19PZbETK1VmVubXsF2xfdT8pyReN1UiQ9DLc7y31EjQT4sS1TLN2Q== X-Received: by 10.28.230.69 with SMTP id d66mr16838136wmh.73.1461653816945; Mon, 25 Apr 2016 23:56:56 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b2sm1494732wmb.9.2016.04.25.23.56.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2016 23:56:55 -0700 (PDT) To: Loa Andersson , Gregory Mirsky , George Swallow References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <571EF6B9.403@pi.nu> From: Stewart Bryant Message-ID: <571F1136.1050905@gmail.com> Date: Tue, 26 Apr 2016 07:56:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571EF6B9.403@pi.nu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 06:57:01 -0000 If I look at section 4, the key piece of information is the RLD which is the subject of other drafts. Given the RLD, how it is decided to distribute the ELIs within the stack is purely a local matter. 5.1 is the trivial case of 4 for a large RLD, and for shorter RLD is a matter for the imposing LSR to balance reduction in ECMP against LS size (which may be a limit for that LSR anyway). Either way unless you use some sort of phone a friend scheme* (which you may need as the label stack grows beyond the capability of the edge nodes) this is a local matter. 5.2 is the other trivial case of 4, which again is a local matter. 5.3 and 5.3.1 require hardware changes, but optimises the stack size, which is an oft quoted issue in MPLS systems, particularly PWs. As such it is not a local matter, but if you knew that strategic nodes had that capability it would become a local matter. Incidentally there is a need for something of the form of 5.3 in that an LSR pushing further labels may need to look at the existing stack, retrieve the EL and add its own ELI/ELs. There perhaps ought to be text describing this action, but once you have this capability, surely 5.3 becomes a viable general solution. Also a 5.3 like solution may be needed to overcome the ingress node imposition limitations in cases where phone-a-friend is not available. 5.4 is as the document notes really a version of 4. There is so much that is a local matter that I am not sure the text should go beyond describing the issues and leaving the decision to the imposing LSR s/w team. - Stewart *As I recall that there is IPR on at least one phone-a-friend scheme On 26/04/2016 06:03, Loa Andersson wrote: > Greg, > > (talking about the SHOULDs in Section 4 only) > > I think what George (and Stewart) says is that since the document does > not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an > Informational RFC. > > However, it does not work to turn that argument around and say that an > Informational RFC can't use the normative language, it was doen for > example in RFC 7412. > > I think we should change it to Informational, but there is no need to > do anything to the SHOULDs in section 4. > > /Loa > > On 2016-04-26 03:19, Gregory Mirsky wrote: >> Hi George, et. al, >> >> Ive found several occurrences, three actually, of SHOULD being used in >> Section 4. >> >> And I agree with Stewart that application of is the local >> decision and, at most, this work can be published as Informational. >> >> One comment, suggestion: >> >> the sample algorithm in Section 4 suggests that the same tuple >> been used multiple times whereas it may be advantageous to generalize >> and point that the different entropy label value may be used by >> referring to the tuple as >> >> Regards, >> >> Greg >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow >> *Sent:* Monday, April 25, 2016 10:57 AM >> *To:* Stewart Bryant >> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; >> mpls@ietf.org; mpls-chairs@ietf.org >> *Subject:* Re: [mpls] working group last call on >> draft-ietf-mpls-spring-entropy-label >> >> Stewart - >> >> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant >> > wrote: >> >> I support this becoming a WG doc and thereby comming under WG >> control. >> >> The document is a WG doc. We are now in WG last call. >> >> However I am not sure about the dismissal of the option to reuse >> the ELI+EL. This clutters the stack less than the proposed option. >> >> Also I wonder why this is standards track? >> >> A reasonable question, particularly since there are no MUSTs, SHALLs or >> REQUIREDs. Will discuss with my Co-Chairs and ADs. >> >> Surely any equipment that understands the ELI can do this and thus >> this is just an informal description of the problem and a solution. >> >> Stewart >> >> >> >> On 23/04/2016 08:53, Loa Andersson wrote: >> >> Working Group, >> >> This is to initiate a two week working group last call on >> draft-ietf-mpls-spring-entropy-label. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org >> ). >> >> There are no IPR disclosures against this document. >> >> All the authors and contributors (with one exception) have stated on >> the working group mailing list that they are not aware of any other >> IPRs that relates to this draft. >> >> This working group last call ends May 12, 2016. >> >> >> /Loa >> for the MPLS wg chairs >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> From nobody Tue Apr 26 10:10:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18C12D54A; Tue, 26 Apr 2016 10:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 r-kEPfJIxWiY; Tue, 26 Apr 2016 10:10:04 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E4D12D530; Tue, 26 Apr 2016 10:10:04 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x201so21956296oif.3; Tue, 26 Apr 2016 10:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tesqkdBVfOqlOpFZtLH0vlJX4ojCRwb1/YqMq0EsFGs=; b=Lg/N56SJZR1Ho+EpY1Nc+1vkJT4+ACrZ+TceUxkXWaUqN+t+QVDL9QOnRn5uyg1AW+ j1jqfAFBqW8x/RJorzQbzM6g2d4aWy8PnbC9nTAgmNGZ35fHox7sTCzgxicPN8XzpIch t8nEodvvEpJsJ332OiYSNMVhlRLVFnhRuqw2sdVyPqgSnSKxTTUIz+zKDEqK4iQ0BeOx ic4tKXKZjl/j5tOlVvVt8rIXARgdZXifU8rBflrnAG5iPqHuHeXRUCnNrVLTz5GRum6r eftHlZlx2r3109eeuBzxfBXAcU8XbRr1kDoJ9O6j1LWdZ7lHQJNUeanzYgng2I/DYU0O AAbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tesqkdBVfOqlOpFZtLH0vlJX4ojCRwb1/YqMq0EsFGs=; b=W4h4JlKJFN/5EHKXLeV+XPFBAZOY02V3o5jbsuHEKeHOPoRFMlXiODk1jrNHC+KVLL RUP8gUZ8BzDeasU5uMfcxfbTCgtnsRq+yMD9tqMu3XaP0iKvrgSYK6GkT4a0ZfPiQCJl lLn8QF/tGvZz7czFebNOSoE+eDHtgzO8O1WyFlBsFcn35dZvrBR/h5Frv42AxLlB1LuA 0jU83pjq+O58MsGCyM4C/37YzEHmscqFzZS3gGgA8bAQZdH7s3MMcEufGY8yXiF9r7JP PkdsPl2HAfFOc8tqQviqb5KVa0Cg3x2QplRErFtxd6wclIes3Ay2Z63H/+zI6YXQhV+Z MglQ== X-Gm-Message-State: AOPr4FWR1iF+Pb++sqMhwOmDAWPaV9wgQ52vHVqL9t+jHd1QEOjI2i0dw9aW9nrf+wRwwTsNinXExG4mV3I0+g== X-Received: by 10.202.64.132 with SMTP id n126mr1372539oia.80.1461690603658; Tue, 26 Apr 2016 10:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Tue, 26 Apr 2016 10:09:33 -0700 (PDT) In-Reply-To: References: <571B29F8.1060301@pi.nu> From: Sri Date: Tue, 26 Apr 2016 10:09:33 -0700 Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=001a113d76f433ec1f0531665d77 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:10:06 -0000 --001a113d76f433ec1f0531665d77 Content-Type: text/plain; charset=UTF-8 Thanks Acee for the comments. I accept the comments but pls see inline at Sri> for some clarification. On Sat, Apr 23, 2016 at 10:57 AM, Acee Lindem (acee) wrote: > I support publication of this work. I have the following editorial > comments: > > 208,209c208,209 > < source routed label stacks. Lets L_N-P denote the label to be used > < to reach the node SID of LSR P. Let L_A-Ln denote the label used for > --- > > source routed label stacks. Let L_N-P3 denote the label to be used > > to reach the node SID of LSR P3. Let L_A-Ln denote the label used for > Sri> Changing 'Lets' to 'Let' is fine. Note that we are introducing notation here that can be applied to specific node and adjacency SIDs. So L_N-P is the generic notation for the label used for the SID of the node P, which when applied to the SID for the node P3 becomes the label L_N-P3. So I prefer that the rest of the sentence stay as-is. > 322c322 > < label stack. In the example described in Section 3 it will result in > --- > > label stack. In the example described in Section 3, it will result in > Sri> Accepted > 330c330 > < Section 3 the LSR P1 would poorly load-balance traffic on the > --- > > Section 3, the LSR P1 would poorly load-balance traffic on the > Sri> Accepted > 349c349 > < This option was discounted since there exist a number of hardware > --- > > This option was rejected since there are a number of hardware > Sri> Accepted > 351,352c351,352 > < Choosing this option can lead to a loss of load-balancing using EL in > < a significant part of the network but that is a critical requirement > --- > > Choosing this option can lead to EL load-balancing interruptions in > > a significant part of the network and that is a critical requirement > Sri> Accepted > 377c377 > < This option was discounted due to the existence of hardware > --- > > This option was rejected due to the existence of hardware > Sri> Accepted > 381c381 > < restrict the number of tunnels that can form a LSP and constrain the > --- > > restrict the number of LSRs that can form an LSP and constrain the > Accepted > 419c419 > < This option was discounted due to the significant change in label > --- > > This option was rejected due to the significant change in label > Sri> Accepted > 432c432 > < This option was discounted due to the significant change in label > --- > > This option was rejected due to the significant change in label > Sri> Accepted > > > Thanks, > Acee > > On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson" > wrote: > > >Working Group, > > > >This is to initiate a two week working group last call on > >draft-ietf-mpls-spring-entropy-label. > > > >Please send your comments to the mpls wg mailing list (mpls@ietf.org). > > > >There are no IPR disclosures against this document. > > > >All the authors and contributors (with one exception) have stated on > >the working group mailing list that they are not aware of any other > >IPRs that relates to this draft. > > > >This working group last call ends May 12, 2016. > > > > > >/Loa > >for the MPLS wg chairs > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > >_______________________________________________ > >mpls mailing list > >mpls@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001a113d76f433ec1f0531665d77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Acee for the comments. I accept the comments but pl= s see inline at Sri> for some clarification.
<= br>
On Sat, Apr 23, 2016 at 10:57 AM, Acee Lindem= (acee) <acee@cisco.com> wrote:
I support publication of this work. I have the following editorial
comments:

208,209c208,209
<=C2=A0 =C2=A0 source routed label stacks.=C2=A0 Lets L_N-P denote the l= abel to be used
<=C2=A0 =C2=A0 to reach the node SID of LSR P.=C2=A0 Let L_A-Ln denote t= he label used for
---
>=C2=A0 =C2=A0 source routed label stacks.=C2=A0 Let L_N-P3 denote the l= abel to be used
>=C2=A0 =C2=A0 to reach the node SID of LSR P3.=C2=A0 Let L_A-Ln denote = the label used for

Sri> Changing = 9;Lets' to 'Let' is fine. Note that we are introducing notation= here that can be applied to specific node and adjacency SIDs. So L_N-P is = the generic notation for the label used for the SID of the node P, which wh= en applied to the SID for the node P3 becomes the label L_N-P3.=C2=A0 So I = prefer that the rest of the sentence stay as-is.
=C2=A0
322c322
<=C2=A0 =C2=A0 label stack.=C2=A0 In the example described in Section 3 = it will result in
---
>=C2=A0 =C2=A0 label stack.=C2=A0 In the example described in Section 3,= it will result in

Sri> Accepted
=C2=A0
330c330
<=C2=A0 =C2=A0 Section 3 the LSR P1 would poorly load-balance traffic on= the
---
>=C2=A0 =C2=A0 Section 3, the LSR P1 would poorly load-balance traffic o= n the

Sri> Accepted
=C2=A0=
349c349
<=C2=A0 =C2=A0 This option was discounted since there exist a number of = hardware
---
>=C2=A0 =C2=A0 This option was rejected since there are a number of hard= ware

Sri> Accepted
=C2=A0<= /div>
351,352c351,352
<=C2=A0 =C2=A0 Choosing this option can lead to a loss of load-balancing= using EL in
<=C2=A0 =C2=A0 a significant part of the network but that is a critical = requirement
---
>=C2=A0 =C2=A0 Choosing this option can lead to EL load-balancing interr= uptions in
>=C2=A0 =C2=A0 a significant part of the network and that is a critical = requirement

Sri> Accepted
= =C2=A0
377c377
<=C2=A0 =C2=A0 This option was discounted due to the existence of hardwa= re
---
>=C2=A0 =C2=A0 This option was rejected due to the existence of hardware=

Sri> Accepted
=C2=A0
381c381
<=C2=A0 =C2=A0 restrict the number of tunnels that can form a LSP and co= nstrain the
---
>=C2=A0 =C2=A0 restrict the number of LSRs that can form an LSP and cons= train the

Accepted
=C2=A0
419c419
<=C2=A0 =C2=A0 This option was discounted due to the significant change = in label
---
>=C2=A0 =C2=A0 This option was rejected due to the significant change in= label

Sri> Accepted
=C2= =A0
432c432
<=C2=A0 =C2=A0 This option was discounted due to the significant change = in label
---
>=C2=A0 =C2=A0 This option was rejected due to the significant change in= label

Sri> Accepted
=C2= =A0


Thanks,
Acee

On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson"
<mpls-bo= unces@ietf.org on behalf of loa@pi.nu&= gt; wrote:

>Working Group,
>
>This is to initiate a two week working group last call on
>draft-ietf-mpls-spring-entropy-label.
>
>Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
>There are no IPR disclosures against this document.
>
>All the authors and contributors (with one exception) have stated on >the working group mailing list that they are not aware of any other
>IPRs that relates to this draft.
>
>This working group last call ends May 12, 2016.
>
>
>/Loa
>for the MPLS wg chairs
>--
>
>
>Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
>Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
>Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64<= br> >
>_______________________________________________
>mpls mailing list
>mpls@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls

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

--001a113d76f433ec1f0531665d77-- From nobody Tue Apr 26 10:54:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF1C12D0DA; Tue, 26 Apr 2016 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 qfUBGtnVjpkP; Tue, 26 Apr 2016 10:54:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67AB212B04A; Tue, 26 Apr 2016 10:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20173; q=dns/txt; s=iport; t=1461693274; x=1462902874; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nxe24d40mW2Y1I7p0Nb35DVY/58a/HN/UB7rMOU0b9c=; b=JQTf1cKCNRoauLoV2fKgUx8qu161XbnMiQq1yt2aIIAMuQSFzMgmnaF9 s7Pg/dcj4xavQT7h5f7qdoYpxNxGqmDUOdcdIC5+VZf6UwciHaTb3lRKz BU1uqg+u/jn5Caik4kpkoT5cY2WE7y9jpGgEILdQ1Q6FJINP6CUrc6boM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgDWqh9X/4QNJK1egmxMU30GrhyGa?= =?us-ascii?q?oRzAQ2BdBcBCoVtAhyBITgUAQEBAQEBAWUnhEEBAQEEAQEBCxVCBgMLDgICAQg?= =?us-ascii?q?RAwECKAMCAgIZBgYLFAkIAgQOBYgVAxIOsxeMLw2EYQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAREEBIpogkGBThEBIxEKDYJTglYFh36HCIhZMQGMIIF2gWeETYhdh1G?= =?us-ascii?q?HXgEeAQFCggUbgUtsh3k2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,537,1454976000"; d="scan'208,217";a="101547770" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Apr 2016 17:54:33 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3QHsWNL029200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Apr 2016 17:54:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 13:54:32 -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; Tue, 26 Apr 2016 13:54:32 -0400 From: "Acee Lindem (acee)" To: Sri Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnYml/l4Oy2kisUCFQARxWDWjp5+cxMiA///JgIA= Date: Tue, 26 Apr 2016 17:54:32 +0000 Message-ID: References: <571B29F8.1060301@pi.nu> 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_D34522625CE47aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:54:37 -0000 --_000_D34522625CE47aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3JpLA0KDQpUaGFua3MgLSBzZWUgb25lIGlubGluZS4NCg0KRnJvbTogU3JpIEtpbmkgPHNy aWdhbmVzaGtpbmlAZ21haWwuY29tPG1haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbT4+DQpE YXRlOiBUdWVzZGF5LCBBcHJpbCAyNiwgMjAxNiBhdCAxOjA5IFBNDQpUbzogQWNlZSBMaW5kZW0g PGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpDYzogTG9hIEFuZGVyc3Nv biA8bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+PiwgIm1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+IiA8bXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4+LCAiZHJh ZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc+IiA8ZHJh ZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc+PiwgIm1w bHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0BpZXRmLm9yZz4iIDxtcGxzLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLW1wbHMtc3ByaW5n LWVudHJvcHktbGFiZWwNCg0KVGhhbmtzIEFjZWUgZm9yIHRoZSBjb21tZW50cy4gSSBhY2NlcHQg dGhlIGNvbW1lbnRzIGJ1dCBwbHMgc2VlIGlubGluZSBhdCBTcmk+IGZvciBzb21lIGNsYXJpZmlj YXRpb24uDQoNCk9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDEwOjU3IEFNLCBBY2VlIExpbmRlbSAo YWNlZSkgPGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KSSBz dXBwb3J0IHB1YmxpY2F0aW9uIG9mIHRoaXMgd29yay4gSSBoYXZlIHRoZSBmb2xsb3dpbmcgZWRp dG9yaWFsDQpjb21tZW50czoNCg0KMjA4LDIwOWMyMDgsMjA5DQo8ICAgIHNvdXJjZSByb3V0ZWQg bGFiZWwgc3RhY2tzLiAgTGV0cyBMX04tUCBkZW5vdGUgdGhlIGxhYmVsIHRvIGJlIHVzZWQNCjwg ICAgdG8gcmVhY2ggdGhlIG5vZGUgU0lEIG9mIExTUiBQLiAgTGV0IExfQS1MbiBkZW5vdGUgdGhl IGxhYmVsIHVzZWQgZm9yDQotLS0NCj4gICAgc291cmNlIHJvdXRlZCBsYWJlbCBzdGFja3MuICBM ZXQgTF9OLVAzIGRlbm90ZSB0aGUgbGFiZWwgdG8gYmUgdXNlZA0KPiAgICB0byByZWFjaCB0aGUg bm9kZSBTSUQgb2YgTFNSIFAzLiAgTGV0IExfQS1MbiBkZW5vdGUgdGhlIGxhYmVsIHVzZWQgZm9y DQoNClNyaT4gQ2hhbmdpbmcgJ0xldHMnIHRvICdMZXQnIGlzIGZpbmUuIE5vdGUgdGhhdCB3ZSBh cmUgaW50cm9kdWNpbmcgbm90YXRpb24gaGVyZSB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIHNwZWNp ZmljIG5vZGUgYW5kIGFkamFjZW5jeSBTSURzLiBTbyBMX04tUCBpcyB0aGUgZ2VuZXJpYyBub3Rh dGlvbiBmb3IgdGhlIGxhYmVsIHVzZWQgZm9yIHRoZSBTSUQgb2YgdGhlIG5vZGUgUCwgd2hpY2gg d2hlbiBhcHBsaWVkIHRvIHRoZSBTSUQgZm9yIHRoZSBub2RlIFAzIGJlY29tZXMgdGhlIGxhYmVs IExfTi1QMy4gIFNvIEkgcHJlZmVyIHRoYXQgdGhlIHJlc3Qgb2YgdGhlIHNlbnRlbmNlIHN0YXkg YXMtaXMuDQoNCkl0IGlzIHN0aWxsIHdyb25nIHNpbmNlIHRoZSBvcmlnaW5hbCBzZW50ZW5jZSBz cGVjaWZpY2FsbHkgcmVmZXJlbmNlcyBMU1IgUDMuICBQZXJoYXBzOg0KDQogICAgc291cmNlIHJv dXRlZCBsYWJlbCBzdGFja3MuICBMZXQgTF9OLVB4IGRlbm90ZSB0aGUgbGFiZWwgdG8gYmUgdXNl ZA0KICAgIHRvIHJlYWNoIHRoZSBub2RlIFNJRCBvZiBMU1IgUHguICBMZXQgTF9BLUxuIGRlbm90 ZSB0aGUgbGFiZWwgdXNlZCBmb3INCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCjMyMmMzMjINCjwgICAg bGFiZWwgc3RhY2suICBJbiB0aGUgZXhhbXBsZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzIGl0IHdp bGwgcmVzdWx0IGluDQotLS0NCj4gICAgbGFiZWwgc3RhY2suICBJbiB0aGUgZXhhbXBsZSBkZXNj cmliZWQgaW4gU2VjdGlvbiAzLCBpdCB3aWxsIHJlc3VsdCBpbg0KDQpTcmk+IEFjY2VwdGVkDQoN CjMzMGMzMzANCjwgICAgU2VjdGlvbiAzIHRoZSBMU1IgUDEgd291bGQgcG9vcmx5IGxvYWQtYmFs YW5jZSB0cmFmZmljIG9uIHRoZQ0KLS0tDQo+ICAgIFNlY3Rpb24gMywgdGhlIExTUiBQMSB3b3Vs ZCBwb29ybHkgbG9hZC1iYWxhbmNlIHRyYWZmaWMgb24gdGhlDQoNClNyaT4gQWNjZXB0ZWQNCg0K MzQ5YzM0OQ0KPCAgICBUaGlzIG9wdGlvbiB3YXMgZGlzY291bnRlZCBzaW5jZSB0aGVyZSBleGlz dCBhIG51bWJlciBvZiBoYXJkd2FyZQ0KLS0tDQo+ICAgIFRoaXMgb3B0aW9uIHdhcyByZWplY3Rl ZCBzaW5jZSB0aGVyZSBhcmUgYSBudW1iZXIgb2YgaGFyZHdhcmUNCg0KU3JpPiBBY2NlcHRlZA0K DQozNTEsMzUyYzM1MSwzNTINCjwgICAgQ2hvb3NpbmcgdGhpcyBvcHRpb24gY2FuIGxlYWQgdG8g YSBsb3NzIG9mIGxvYWQtYmFsYW5jaW5nIHVzaW5nIEVMIGluDQo8ICAgIGEgc2lnbmlmaWNhbnQg cGFydCBvZiB0aGUgbmV0d29yayBidXQgdGhhdCBpcyBhIGNyaXRpY2FsIHJlcXVpcmVtZW50DQot LS0NCj4gICAgQ2hvb3NpbmcgdGhpcyBvcHRpb24gY2FuIGxlYWQgdG8gRUwgbG9hZC1iYWxhbmNp bmcgaW50ZXJydXB0aW9ucyBpbg0KPiAgICBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIG5ldHdv cmsgYW5kIHRoYXQgaXMgYSBjcml0aWNhbCByZXF1aXJlbWVudA0KDQpTcmk+IEFjY2VwdGVkDQoN CjM3N2MzNzcNCjwgICAgVGhpcyBvcHRpb24gd2FzIGRpc2NvdW50ZWQgZHVlIHRvIHRoZSBleGlz dGVuY2Ugb2YgaGFyZHdhcmUNCi0tLQ0KPiAgICBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgZHVl IHRvIHRoZSBleGlzdGVuY2Ugb2YgaGFyZHdhcmUNCg0KU3JpPiBBY2NlcHRlZA0KDQozODFjMzgx DQo8ICAgIHJlc3RyaWN0IHRoZSBudW1iZXIgb2YgdHVubmVscyB0aGF0IGNhbiBmb3JtIGEgTFNQ IGFuZCBjb25zdHJhaW4gdGhlDQotLS0NCj4gICAgcmVzdHJpY3QgdGhlIG51bWJlciBvZiBMU1Jz IHRoYXQgY2FuIGZvcm0gYW4gTFNQIGFuZCBjb25zdHJhaW4gdGhlDQoNCkFjY2VwdGVkDQoNCjQx OWM0MTkNCjwgICAgVGhpcyBvcHRpb24gd2FzIGRpc2NvdW50ZWQgZHVlIHRvIHRoZSBzaWduaWZp Y2FudCBjaGFuZ2UgaW4gbGFiZWwNCi0tLQ0KPiAgICBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQg ZHVlIHRvIHRoZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gbGFiZWwNCg0KU3JpPiBBY2NlcHRlZA0K DQo0MzJjNDMyDQo8ICAgIFRoaXMgb3B0aW9uIHdhcyBkaXNjb3VudGVkIGR1ZSB0byB0aGUgc2ln bmlmaWNhbnQgY2hhbmdlIGluIGxhYmVsDQotLS0NCj4gICAgVGhpcyBvcHRpb24gd2FzIHJlamVj dGVkIGR1ZSB0byB0aGUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIGxhYmVsDQoNClNyaT4gQWNjZXB0 ZWQNCg0KDQoNClRoYW5rcywNCkFjZWUNCg0KT24gNC8yMy8xNiwgMzo1MyBBTSwgIm1wbHMgb24g YmVoYWxmIG9mIExvYSBBbmRlcnNzb24iDQo8bXBscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBsb2FAcGkubnU8bWFpbHRvOmxvYUBw aS5udT4+IHdyb3RlOg0KDQo+V29ya2luZyBHcm91cCwNCj4NCj5UaGlzIGlzIHRvIGluaXRpYXRl IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj5kcmFmdC1pZXRmLW1wbHMt c3ByaW5nLWVudHJvcHktbGFiZWwuDQo+DQo+UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0 aGUgbXBscyB3ZyBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5v cmc+KS4NCj4NCj5UaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1 bWVudC4NCj4NCj5BbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyAod2l0aCBvbmUgZXhj ZXB0aW9uKSBoYXZlIHN0YXRlZCBvbg0KPnRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCB0 aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXINCj5JUFJzIHRoYXQgcmVsYXRlcyB0 byB0aGlzIGRyYWZ0Lg0KPg0KPlRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBNYXkg MTIsIDIwMTYuDQo+DQo+DQo+L0xvYQ0KPmZvciB0aGUgTVBMUyB3ZyBjaGFpcnMNCj4tLQ0KPg0K Pg0KPkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWww MS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQo+U2VuaW9yIE1QTFMg RXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5u dT4NCj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3Mzkg ODEgMjEgNjQ8dGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Pg0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QN Cj5tcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFp bHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCg0K --_000_D34522625CE47aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <79F66F5FC32EFC41BD4D3BBFFF2B50F7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBTcmksPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgLSBzZWUgb25lIGlubGluZS4mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRl eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBC T1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG VDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlk OyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+U3JpIEtpbmkgJmx0OzxhIGhyZWY9 Im1haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbSI+c3JpZ2FuZXNoa2luaUBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+ VHVlc2RheSwgQXByaWwgMjYsIDIwMTYgYXQgMTowOSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86 YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5Mb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJt YWlsdG86bG9hQHBpLm51Ij5sb2FAcGkubnU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmlldGYub3Jn Ij5kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc8L2E+ JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJv cHktbGFiZWxAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1s YWJlbEB0b29scy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bXBscy1j aGFpcnNAaWV0Zi5vcmciPm1wbHMtY2hhaXJzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3JnIj5tcGxzLWNoYWlyc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1zcHJp bmctZW50cm9weS1sYWJlbDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVS LUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5UaGFua3MgQWNlZSBmb3IgdGhlIGNvbW1l bnRzLiBJIGFjY2VwdCB0aGUgY29tbWVudHMgYnV0IHBscyBzZWUgaW5saW5lIGF0IFNyaSZndDsg Zm9yIHNvbWUgY2xhcmlmaWNhdGlvbi4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQgMTA6NTcgQU0s IEFjZWUgTGluZGVtIChhY2VlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRv OmFjZWVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQpJIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhpcyB3b3JrLiBJIGhhdmUgdGhlIGZv bGxvd2luZyBlZGl0b3JpYWw8YnI+DQpjb21tZW50czo8YnI+DQo8YnI+DQoyMDgsMjA5YzIwOCwy MDk8YnI+DQombHQ7Jm5ic3A7ICZuYnNwOyBzb3VyY2Ugcm91dGVkIGxhYmVsIHN0YWNrcy4mbmJz cDsgTGV0cyBMX04tUCBkZW5vdGUgdGhlIGxhYmVsIHRvIGJlIHVzZWQ8YnI+DQombHQ7Jm5ic3A7 ICZuYnNwOyB0byByZWFjaCB0aGUgbm9kZSBTSUQgb2YgTFNSIFAuJm5ic3A7IExldCBMX0EtTG4g ZGVub3RlIHRoZSBsYWJlbCB1c2VkIGZvcjxicj4NCi0tLTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 IHNvdXJjZSByb3V0ZWQgbGFiZWwgc3RhY2tzLiZuYnNwOyBMZXQgTF9OLVAzIGRlbm90ZSB0aGUg bGFiZWwgdG8gYmUgdXNlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRvIHJlYWNoIHRoZSBub2Rl IFNJRCBvZiBMU1IgUDMuJm5ic3A7IExldCBMX0EtTG4gZGVub3RlIHRoZSBsYWJlbCB1c2VkIGZv cjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNyaSZndDsgQ2hh bmdpbmcgJ0xldHMnIHRvICdMZXQnIGlzIGZpbmUuIE5vdGUgdGhhdCB3ZSBhcmUgaW50cm9kdWNp bmcgbm90YXRpb24gaGVyZSB0aGF0IGNhbiBiZSBhcHBsaWVkIHRvIHNwZWNpZmljIG5vZGUgYW5k IGFkamFjZW5jeSBTSURzLiBTbyBMX04tUCBpcyB0aGUgZ2VuZXJpYyBub3RhdGlvbiBmb3IgdGhl IGxhYmVsIHVzZWQgZm9yIHRoZSBTSUQgb2YgdGhlIG5vZGUgUCwgd2hpY2ggd2hlbiBhcHBsaWVk IHRvIHRoZSBTSUQgZm9yDQogdGhlIG5vZGUgUDMgYmVjb21lcyB0aGUgbGFiZWwgTF9OLVAzLiZu YnNwOyBTbyBJIHByZWZlciB0aGF0IHRoZSByZXN0IG9mIHRoZSBzZW50ZW5jZSBzdGF5IGFzLWlz LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkl0IGlzIHN0aWxsIHdyb25n IHNpbmNlIHRoZSBvcmlnaW5hbCBzZW50ZW5jZSBzcGVjaWZpY2FsbHkgcmVmZXJlbmNlcyBMU1Ig UDMuICZuYnNwO1BlcmhhcHM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ Jm5ic3A7ICZuYnNwOyBzb3VyY2Ugcm91dGVkIGxhYmVsIHN0YWNrcy4gJm5ic3A7TGV0IExfTi1Q eCBkZW5vdGUgdGhlIGxhYmVsIHRvIGJlIHVzZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyB0 byByZWFjaCB0aGUgbm9kZSBTSUQgb2YgTFNSIFB4LiAmbmJzcDtMZXQgTF9BLUxuIGRlbm90ZSB0 aGUgbGFiZWwgdXNlZCBmb3I8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VU TE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYg NSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjMyMmMzMjI8YnI+DQombHQ7Jm5ic3A7ICZuYnNwOyBs YWJlbCBzdGFjay4mbmJzcDsgSW4gdGhlIGV4YW1wbGUgZGVzY3JpYmVkIGluIFNlY3Rpb24gMyBp dCB3aWxsIHJlc3VsdCBpbjxicj4NCi0tLTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGxhYmVsIHN0 YWNrLiZuYnNwOyBJbiB0aGUgZXhhbXBsZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLCBpdCB3aWxs IHJlc3VsdCBpbjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNy aSZndDsgQWNjZXB0ZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjMzMGMzMzA8YnI+DQombHQ7Jm5ic3A7ICZu YnNwOyBTZWN0aW9uIDMgdGhlIExTUiBQMSB3b3VsZCBwb29ybHkgbG9hZC1iYWxhbmNlIHRyYWZm aWMgb24gdGhlPGJyPg0KLS0tPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgU2VjdGlvbiAzLCB0aGUg TFNSIFAxIHdvdWxkIHBvb3JseSBsb2FkLWJhbGFuY2UgdHJhZmZpYyBvbiB0aGU8YnI+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TcmkmZ3Q7IEFjY2VwdGVkPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQozNDljMzQ5PGJyPg0KJmx0OyZuYnNwOyAmbmJzcDsgVGhpcyBvcHRpb24gd2Fz IGRpc2NvdW50ZWQgc2luY2UgdGhlcmUgZXhpc3QgYSBudW1iZXIgb2YgaGFyZHdhcmU8YnI+DQot LS08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgc2luY2Ug dGhlcmUgYXJlIGEgbnVtYmVyIG9mIGhhcmR3YXJlPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+U3JpJmd0OyBBY2NlcHRlZDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KMzUxLDM1 MmMzNTEsMzUyPGJyPg0KJmx0OyZuYnNwOyAmbmJzcDsgQ2hvb3NpbmcgdGhpcyBvcHRpb24gY2Fu IGxlYWQgdG8gYSBsb3NzIG9mIGxvYWQtYmFsYW5jaW5nIHVzaW5nIEVMIGluPGJyPg0KJmx0OyZu YnNwOyAmbmJzcDsgYSBzaWduaWZpY2FudCBwYXJ0IG9mIHRoZSBuZXR3b3JrIGJ1dCB0aGF0IGlz IGEgY3JpdGljYWwgcmVxdWlyZW1lbnQ8YnI+DQotLS08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBD aG9vc2luZyB0aGlzIG9wdGlvbiBjYW4gbGVhZCB0byBFTCBsb2FkLWJhbGFuY2luZyBpbnRlcnJ1 cHRpb25zIGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgYSBzaWduaWZpY2FudCBwYXJ0IG9mIHRo ZSBuZXR3b3JrIGFuZCB0aGF0IGlzIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQ8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TcmkmZ3Q7IEFjY2VwdGVkPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQozNzdjMzc3PGJyPg0KJmx0OyZuYnNwOyAmbmJzcDsgVGhpcyBvcHRpb24gd2FzIGRp c2NvdW50ZWQgZHVlIHRvIHRoZSBleGlzdGVuY2Ugb2YgaGFyZHdhcmU8YnI+DQotLS08YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgZHVlIHRvIHRoZSBleGlz dGVuY2Ugb2YgaGFyZHdhcmU8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5TcmkmZ3Q7IEFjY2VwdGVkPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQozODFjMzgxPGJyPg0KJmx0OyZu YnNwOyAmbmJzcDsgcmVzdHJpY3QgdGhlIG51bWJlciBvZiB0dW5uZWxzIHRoYXQgY2FuIGZvcm0g YSBMU1AgYW5kIGNvbnN0cmFpbiB0aGU8YnI+DQotLS08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBy ZXN0cmljdCB0aGUgbnVtYmVyIG9mIExTUnMgdGhhdCBjYW4gZm9ybSBhbiBMU1AgYW5kIGNvbnN0 cmFpbiB0aGU8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BY2Nl cHRlZDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KNDE5YzQxOTxicj4NCiZsdDsmbmJzcDsgJm5ic3A7IFRoaXMg b3B0aW9uIHdhcyBkaXNjb3VudGVkIGR1ZSB0byB0aGUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIGxh YmVsPGJyPg0KLS0tPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBvcHRpb24gd2FzIHJlamVj dGVkIGR1ZSB0byB0aGUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIGxhYmVsPGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U3JpJmd0OyBBY2NlcHRlZDwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDox ZXgiPg0KNDMyYzQzMjxicj4NCiZsdDsmbmJzcDsgJm5ic3A7IFRoaXMgb3B0aW9uIHdhcyBkaXNj b3VudGVkIGR1ZSB0byB0aGUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIGxhYmVsPGJyPg0KLS0tPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBvcHRpb24gd2FzIHJlamVjdGVkIGR1ZSB0byB0aGUg c2lnbmlmaWNhbnQgY2hhbmdlIGluIGxhYmVsPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+U3JpJmd0OyBBY2NlcHRlZDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4 O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NCkFjZWU8YnI+DQo8YnI+DQpPbiA0LzIzLzE2LCAzOjUzIEFNLCAmcXVv dDttcGxzIG9uIGJlaGFsZiBvZiBMb2EgQW5kZXJzc29uJnF1b3Q7PGJyPg0KPGRpdj4NCjxkaXYg Y2xhc3M9Img1Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+bXBs cy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpsb2FA cGkubnUiPmxvYUBwaS5udTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDtXb3JraW5nIEdy b3VwLDxicj4NCiZndDs8YnI+DQomZ3Q7VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KJmd0O2RyYWZ0LWlldGYtbXBscy1zcHJpbmct ZW50cm9weS1sYWJlbC48YnI+DQomZ3Q7PGJyPg0KJmd0O1BsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0ICg8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRm Lm9yZyI+bXBsc0BpZXRmLm9yZzwvYT4pLjxicj4NCiZndDs8YnI+DQomZ3Q7VGhlcmUgYXJlIG5v IElQUiBkaXNjbG9zdXJlcyBhZ2FpbnN0IHRoaXMgZG9jdW1lbnQuPGJyPg0KJmd0Ozxicj4NCiZn dDtBbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyAod2l0aCBvbmUgZXhjZXB0aW9uKSBo YXZlIHN0YXRlZCBvbjxicj4NCiZndDt0aGUgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgdGhh dCB0aGV5IGFyZSBub3QgYXdhcmUgb2YgYW55IG90aGVyPGJyPg0KJmd0O0lQUnMgdGhhdCByZWxh dGVzIHRvIHRoaXMgZHJhZnQuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGlzIHdvcmtpbmcgZ3JvdXAg bGFzdCBjYWxsIGVuZHMgTWF5IDEyLCAyMDE2Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Oy9Mb2E8YnI+DQomZ3Q7Zm9yIHRoZSBNUExTIHdnIGNoYWlyczxicj4NCiZndDstLTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0xvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSI+DQpsb2FA bWFpbDAxLmh1YXdlaS5jb208L2E+PGJyPg0KJmd0O1NlbmlvciBNUExTIEV4cGVydCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51Ij5sb2FA cGkubnU8L2E+PGJyPg0KJmd0O0h1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpJm5ic3A7 ICZuYnNwOyAmbmJzcDtwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODElMjAyMSUy MDY0IiB2YWx1ZT0iJiM0Mzs0NjczOTgxMjE2NCI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48 YnI+DQomZ3Q7PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDttcGxzIG1haWxpbmcgbGlzdDxicj4N CiZndDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIj5tcGxzQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tcGxzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D34522625CE47aceeciscocom_-- From nobody Tue Apr 26 11:01:17 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95DF12B069; Tue, 26 Apr 2016 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPoX2DlsioAU; Tue, 26 Apr 2016 11:01:14 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 C952D12B04A; Tue, 26 Apr 2016 11:01:13 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id j9so10793342obd.3; Tue, 26 Apr 2016 11:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aYqyKfAxJXtzGCJUV+f8CV+BYJCiWecoKsdXHGTwhYs=; b=apK5FUQGerYy1P3VerfmdW3IMdlfu/j7KFhjYQNZ6x0sRAa9qN9zLo3EvqtyR1mnec YRrIhqFzeDDi4/CbvTpikztcJ9kHJs6iSY6ioVNydrXBCGNrZlTLQ2uuZ37XPHqAsqil 2U1qwA0Qu7CsxewyTn/YPa+60SrNRHmZpjSD73A37LnEjM76pairBBMkRz11+qjMQo97 LOawEDVwTqGBzZ5KmDm1xFEAk72eSMHues5YxUmicI2micd0DbPZ3B2e7hx1uDz0hibx ip/UQz9CuqhqCGDlaWhl+inJ0vTo1wa+XYQVpTNLXwNz4bnG88P5SbgRyr20INtSy5Nw Y7lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aYqyKfAxJXtzGCJUV+f8CV+BYJCiWecoKsdXHGTwhYs=; b=OsfQnkg2ad3AaZs/c1QLSn/mS1JMQC68zJMBTjZ59IhQwTfPo8bPLm+6ruEyvnM9lB f51w/Wt4KI6HCXcwLSi77Hf+Z8R1j/C4bbjnnXbuxl5mP5LfLHu7VgPLbMuz7ssWOGqX 8mGQEqEUTXpneTqicm2tlFbhAJNVVRzx1EYKgatmrdrxWZrTxyRMLoEbmqggnzybXMn2 YD8CgihLVRZ5Wdak+09effy9N/J1+NOMCtdt1fqnsEuNe5vQM8pWRpv5LcyI+kb3SYbK 8D3wIY/VK2roVJr4qzn2HJy4sCrrr7EWCBc2j3gFolSeVAKbd4T+g5GPFf0zrvlQDepw 7oTQ== X-Gm-Message-State: AOPr4FVQrD3vi0GbP0YQi2lwtI1h4BTCFVMh17viLyzCNBrkpy3BsisATFHS6W6YF4X9VvlSysBCa1fsTPmEWw== X-Received: by 10.60.162.230 with SMTP id yd6mr1630712oeb.4.1461693673068; Tue, 26 Apr 2016 11:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Tue, 26 Apr 2016 11:00:43 -0700 (PDT) In-Reply-To: References: <571B29F8.1060301@pi.nu> From: Sri Date: Tue, 26 Apr 2016 11:00:43 -0700 Message-ID: To: "Acee Lindem (acee)" Content-Type: multipart/alternative; boundary=047d7b5db6fa275f3d05316714f5 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 18:01:15 -0000 --047d7b5db6fa275f3d05316714f5 Content-Type: text/plain; charset=UTF-8 Accepted. Thanks Sri On Tue, Apr 26, 2016 at 10:54 AM, Acee Lindem (acee) wrote: > Hi Sri, > > Thanks - see one inline. > > From: Sri Kini > Date: Tuesday, April 26, 2016 at 1:09 PM > To: Acee Lindem > Cc: Loa Andersson , "mpls@ietf.org" , " > draft-ietf-mpls-spring-entropy-label@tools.ietf.org" < > draft-ietf-mpls-spring-entropy-label@tools.ietf.org>, " > mpls-chairs@ietf.org" > Subject: Re: [mpls] working group last call on > draft-ietf-mpls-spring-entropy-label > > Thanks Acee for the comments. I accept the comments but pls see inline at > Sri> for some clarification. > > On Sat, Apr 23, 2016 at 10:57 AM, Acee Lindem (acee) > wrote: > >> I support publication of this work. I have the following editorial >> comments: >> >> 208,209c208,209 >> < source routed label stacks. Lets L_N-P denote the label to be used >> < to reach the node SID of LSR P. Let L_A-Ln denote the label used for >> --- >> > source routed label stacks. Let L_N-P3 denote the label to be used >> > to reach the node SID of LSR P3. Let L_A-Ln denote the label used >> for >> > > Sri> Changing 'Lets' to 'Let' is fine. Note that we are introducing > notation here that can be applied to specific node and adjacency SIDs. So > L_N-P is the generic notation for the label used for the SID of the node P, > which when applied to the SID for the node P3 becomes the label L_N-P3. So > I prefer that the rest of the sentence stay as-is. > > > It is still wrong since the original sentence specifically references LSR > P3. Perhaps: > > source routed label stacks. Let L_N-Px denote the label to be used > to reach the node SID of LSR Px. Let L_A-Ln denote the label used for > > Thanks, > Acee > > > >> 322c322 >> < label stack. In the example described in Section 3 it will result in >> --- >> > label stack. In the example described in Section 3, it will result >> in >> > > Sri> Accepted > > >> 330c330 >> < Section 3 the LSR P1 would poorly load-balance traffic on the >> --- >> > Section 3, the LSR P1 would poorly load-balance traffic on the >> > > Sri> Accepted > > >> 349c349 >> < This option was discounted since there exist a number of hardware >> --- >> > This option was rejected since there are a number of hardware >> > > Sri> Accepted > > >> 351,352c351,352 >> < Choosing this option can lead to a loss of load-balancing using EL in >> < a significant part of the network but that is a critical requirement >> --- >> > Choosing this option can lead to EL load-balancing interruptions in >> > a significant part of the network and that is a critical requirement >> > > Sri> Accepted > > >> 377c377 >> < This option was discounted due to the existence of hardware >> --- >> > This option was rejected due to the existence of hardware >> > > Sri> Accepted > > >> 381c381 >> < restrict the number of tunnels that can form a LSP and constrain the >> --- >> > restrict the number of LSRs that can form an LSP and constrain the >> > > Accepted > > >> 419c419 >> < This option was discounted due to the significant change in label >> --- >> > This option was rejected due to the significant change in label >> > > Sri> Accepted > > >> 432c432 >> < This option was discounted due to the significant change in label >> --- >> > This option was rejected due to the significant change in label >> > > Sri> Accepted > > >> >> >> Thanks, >> Acee >> >> On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson" >> wrote: >> >> >Working Group, >> > >> >This is to initiate a two week working group last call on >> >draft-ietf-mpls-spring-entropy-label. >> > >> >Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> > >> >There are no IPR disclosures against this document. >> > >> >All the authors and contributors (with one exception) have stated on >> >the working group mailing list that they are not aware of any other >> >IPRs that relates to this draft. >> > >> >This working group last call ends May 12, 2016. >> > >> > >> >/Loa >> >for the MPLS wg chairs >> >-- >> > >> > >> >Loa Andersson email: loa@mail01.huawei.com >> >Senior MPLS Expert loa@pi.nu >> >Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > >> >_______________________________________________ >> >mpls mailing list >> >mpls@ietf.org >> >https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > --047d7b5db6fa275f3d05316714f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Accepted.=C2=A0

Thanks
Sri

On Tue, = Apr 26, 2016 at 10:54 AM, Acee Lindem (acee) <acee@cisco.com> = wrote:
Hi Sri,

Thanks - see one inline.=C2=A0

From: Sri Kini <sriganeshkini@gmail.com>= ;
Date: Tuesday, April 26, 2016 at 1:= 09 PM
To: Acee Lindem <acee@cisco.com>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" <draft-ietf-mpls-spring-entropy-label@tools.ietf.org&= gt;, "mpls-c= hairs@ietf.org" <mpls-chairs@ietf.org>
Subject: Re: [mpls] working group l= ast call on draft-ietf-mpls-spring-entropy-label

Thanks Acee for the comments. I accept the comments but pl= s see inline at Sri> for some clarification.

On Sat, Apr 23, 2016 at 10:57 AM, Acee Lindem (a= cee) <acee@cisco.com&= gt; wrote:
I support publication of this work. I have the following editorial
comments:

208,209c208,209
<=C2=A0 =C2=A0 source routed label stacks.=C2=A0 Lets L_N-P denote the l= abel to be used
<=C2=A0 =C2=A0 to reach the node SID of LSR P.=C2=A0 Let L_A-Ln denote t= he label used for
---
>=C2=A0 =C2=A0 source routed label stacks.=C2=A0 Let L_N-P3 denote the l= abel to be used
>=C2=A0 =C2=A0 to reach the node SID of LSR P3.=C2=A0 Let L_A-Ln denote = the label used for

Sri> Changing 'Lets' to 'Let' is fine. Note that we= are introducing notation here that can be applied to specific node and adj= acency SIDs. So L_N-P is the generic notation for the label used for the SI= D of the node P, which when applied to the SID for the node P3 becomes the label L_N-P3.=C2=A0 So I prefer that the rest of t= he sentence stay as-is.

It is still wrong since the original sentence specifically references = LSR P3.=C2=A0 Perhaps:

=C2=A0 =C2=A0 source routed label stacks.=C2=A0 Let L_N-Px denote the = label to be used
=C2=A0 =C2=A0 to reach the node SID of LSR Px.=C2=A0 Let L_A-Ln denote= the label used for

Thanks,
Acee=C2=A0

=C2=A0
322c322
<=C2=A0 =C2=A0 label stack.=C2=A0 In the example described in Section 3 = it will result in
---
>=C2=A0 =C2=A0 label stack.=C2=A0 In the example described in Section 3,= it will result in

Sri> Accepted
=C2=A0
330c330
<=C2=A0 =C2=A0 Section 3 the LSR P1 would poorly load-balance traffic on= the
---
>=C2=A0 =C2=A0 Section 3, the LSR P1 would poorly load-balance traffic o= n the

Sri> Accepted
=C2=A0
349c349
<=C2=A0 =C2=A0 This option was discounted since there exist a number of = hardware
---
>=C2=A0 =C2=A0 This option was rejected since there are a number of hard= ware

Sri> Accepted
=C2=A0
351,352c351,352
<=C2=A0 =C2=A0 Choosing this option can lead to a loss of load-balancing= using EL in
<=C2=A0 =C2=A0 a significant part of the network but that is a critical = requirement
---
>=C2=A0 =C2=A0 Choosing this option can lead to EL load-balancing interr= uptions in
>=C2=A0 =C2=A0 a significant part of the network and that is a critical = requirement

Sri> Accepted
=C2=A0
377c377
<=C2=A0 =C2=A0 This option was discounted due to the existence of hardwa= re
---
>=C2=A0 =C2=A0 This option was rejected due to the existence of hardware=

Sri> Accepted
=C2=A0
381c381
<=C2=A0 =C2=A0 restrict the number of tunnels that can form a LSP and co= nstrain the
---
>=C2=A0 =C2=A0 restrict the number of LSRs that can form an LSP and cons= train the

Accepted
=C2=A0
419c419
<=C2=A0 =C2=A0 This option was discounted due to the significant change = in label
---
>=C2=A0 =C2=A0 This option was rejected due to the significant change in= label

Sri> Accepted
=C2=A0
432c432
<=C2=A0 =C2=A0 This option was discounted due to the significant change = in label
---
>=C2=A0 =C2=A0 This option was rejected due to the significant change in= label

Sri> Accepted
=C2=A0


Thanks,
Acee

On 4/23/16, 3:53 AM, "mpls on behalf of Loa Andersson"
<mpls-bo= unces@ietf.org on behalf of loa@pi.nu> wrote:

>Working Group,
>
>This is to initiate a two week working group last call on
>draft-ietf-mpls-spring-entropy-label.
>
>Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
>There are no IPR disclosures against this document.
>
>All the authors and contributors (with one exception) have stated on >the working group mailing list that they are not aware of any other
>IPRs that relates to this draft.
>
>This working group last call ends May 12, 2016.
>
>
>/Loa
>for the MPLS wg chairs
>--
>
>
>Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
>Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
>Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls

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

--047d7b5db6fa275f3d05316714f5-- From nobody Tue Apr 26 18:05:07 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA412B016; Tue, 26 Apr 2016 18:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRhO67FjldkD; Tue, 26 Apr 2016 18:05:04 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89AF12B043; Tue, 26 Apr 2016 18:05:04 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-89-572010136078 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 8A.FD.03614.31010275; Wed, 27 Apr 2016 03:04:20 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Tue, 26 Apr 2016 21:05:03 -0400 From: Gregory Mirsky To: Loa Andersson , George Swallow , Stewart Bryant Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnvqgLrEm8VHuxEKbfrdW+MSR/p+bPPSA///Qq2CAAOmIgIABC3XQ Date: Wed, 27 Apr 2016 01:05:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A5F375@eusaamb103.ericsson.se> References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <571EF6B9.403@pi.nu> In-Reply-To: <571EF6B9.403@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPiK6IgEK4wZQZzBbnzp1itPg3dw6z xbrLp9gsbi1dyWpx6kGixaLJy1gc2Dx2zrrL7rFkyU8mj1nT29g8vlz+zBbAEsVlk5Kak1mW WqRvl8CVsbPxLntBs2zFmq5DzA2M98W6GDk5JARMJI7f/8ECYYtJXLi3nq2LkYtDSOAoo8TE fecZQRJCAssZJb4/yQKx2QSMJF5s7GEHsUUEiiWWrOlkArGZBQ4zSjy7agViCwuESkzc8pcF oiZMYuf82UwQtpvEy3mXwGwWAVWJZ0/mgc3nFfCVeDJpMRPE4seMEpseTQZKcHBwCihK7DsU BlLDCHTc91NroHaJS9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwlSQmLT3HClGvI7Fg9yc2CFtb YtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcUFObnpRoabGIHxdUyCzXEH 495ez0OMAhyMSjy8C07LhQuxJpYVV+YeYpTgYFYS4Q3jVwgX4k1JrKxKLcqPLyrNSS0+xCjN waIkzusd+S9MSCA9sSQ1OzW1ILUIJsvEwSnVwLj8JPsJz//dcRdLLFU4z3a9ztPgm3L8qrz4 ybUNLTdP3Fu33zh3x7ng5L3JZc+OicySsdqzZIPueh+lh243meJUL8iVPhBTzYlgivh3xtdG MlXwEIfF0QWCd0o5v/unsiU3/xdLS7ulbCi5932gc9A+9ei+fToMMQuzjS4tm5A659mSmcbb pyixFGckGmoxFxUnAgCz6jR5qwIAAA== Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 01:05:06 -0000 Hi Loa, if the WG decides to publish the document, then the Informational is the ri= ght track. Appreciate authors to consider my comment on generalizing references to an = Entropy Label in the tuple as . Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu]=20 Sent: Monday, April 25, 2016 10:04 PM To: Gregory Mirsky; George Swallow; Stewart Bryant Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; mpl= s-chairs@ietf.org Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entro= py-label Greg, (talking about the SHOULDs in Section 4 only) I think what George (and Stewart) says is that since the document does not = use any MUST, SHALL or REQUIRED, it makes sense to publish it as an Informa= tional RFC. However, it does not work to turn that argument around and say that an Info= rmational RFC can't use the normative language, it was doen for example in = RFC 7412. I think we should change it to Informational, but there is no need to do an= ything to the SHOULDs in section 4. /Loa On 2016-04-26 03:19, Gregory Mirsky wrote: > Hi George, et. al, > > I've found several occurrences, three actually, of SHOULD being used=20 > in Section 4. > > And I agree with Stewart that application of is the local=20 > decision and, at most, this work can be published as Informational. > > One comment, suggestion: > > *the sample algorithm in Section 4 suggests that the same =20 > tuple been used multiple times whereas it may be advantageous to=20 > generalize and point that the different entropy label value may be=20 > used by referring to the tuple as > > Regards, > > Greg > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George=20 > Swallow > *Sent:* Monday, April 25, 2016 10:57 AM > *To:* Stewart Bryant > *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; > mpls@ietf.org; mpls-chairs@ietf.org > *Subject:* Re: [mpls] working group last call on=20 > draft-ietf-mpls-spring-entropy-label > > Stewart - > > On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant=20 > > wrote: > > I support this becoming a WG doc and thereby comming under WG control. > > The document is a WG doc. We are now in WG last call. > > However I am not sure about the dismissal of the option to reuse > the ELI+EL. This clutters the stack less than the proposed option. > > Also I wonder why this is standards track? > > A reasonable question, particularly since there are no MUSTs, SHALLs=20 > or REQUIREDs. Will discuss with my Co-Chairs and ADs. > > Surely any equipment that understands the ELI can do this and thus > this is just an informal description of the problem and a solution. > > Stewart > > > > On 23/04/2016 08:53, Loa Andersson wrote: > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org > ). > > There are no IPR disclosures against this document. > > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. > > This working group last call ends May 12, 2016. > > > /Loa > for the MPLS wg chairs > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Tue Apr 26 21:29:48 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4390A12D5B8; Tue, 26 Apr 2016 21:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, 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 lNhOLKWSCXt7; Tue, 26 Apr 2016 21:29:43 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8288212D096; Tue, 26 Apr 2016 21:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31170; q=dns/txt; s=iport; t=1461731383; x=1462940983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s7rk7Mp5huXdcd740M0QvuF7eqgs5CFbHQI2TlHd9Ro=; b=jIYo8dXu3y2+DJwSou5nWbYxdUd5SN9LryC5NW4dL37dMzskuFSXnXhp wGHnrXLnRSL/nBL04sbVcqbR5UsAuIDgXVx1cBaMJtutqyiCEnU7zqsdo BF3qdgZ+CSk71R7p+0XNjnSrxBrX5wAZEo6Lim0c7s3Uvae5n/7hwgaIr c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AgDoPyBX/4QNJK1egmxMU30GrhmLX?= =?us-ascii?q?Q6BcAQXAQqFbQKBOjgUAQEBAQEBAWUnhEEBAQEDAQEBASBLCwULAgEIEQQBAQE?= =?us-ascii?q?VCwEGAwICIQYLFAkIAgQBDQUODYd6AwoIDrMajDINhGEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQENBASGIYF1glaCQYIyCYJBK4IrBYdwhxaEGYRAMQGDJ4FnhxKBdoF?= =?us-ascii?q?nhE2IXYdRh14BHgFDg2tsiC9/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,540,1454976000"; d="asc'?scan'208,217";a="266436303" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2016 04:29:42 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3R4Tfl4024585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 04:29:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 00:29:40 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 00:29:40 -0400 From: "Carlos Pignataro (cpignata)" To: Gregory Mirsky , Loa Andersson Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnvqiyJTa1iN2rkOldcR5st5EVZ+bPPSAgAAW1wCAAiwhAA== Date: Wed, 27 Apr 2016 04:29:40 +0000 Message-ID: <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com> References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.118.52] Content-Type: multipart/signed; boundary="Apple-Mail=_56D92E74-A986-497B-9A1F-8B80B50673A1"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 04:29:46 -0000 --Apple-Mail=_56D92E74-A986-497B-9A1F-8B80B50673A1 Content-Type: multipart/alternative; boundary="Apple-Mail=_555176CD-D646-4868-99F2-5F8334CDF2FA" --Apple-Mail=_555176CD-D646-4868-99F2-5F8334CDF2FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Loa, I just scanned through draft-ietf-mpls-spring-entropy-label-03 and = wanted to share some observations. Please treat these as WGLC comments. I have a number of concerns. It seems as if this document was not really = reviewed to see if it was ready for WGLC: 1. What is this document specifying? As Greg just mentioned below, there are several SHOULD terms in Section = 4. Those SHOULD are dependent upon the =E2=80=9CRLD". That same section then lists the following: The RLD can be advertised via protocols and those extensions are described in separate documents [I-D.xu-isis-mpls-elc] and [I-D.xu-ospf-mpls-elc]. First, those are expired and should be marked as replaced by wg docs. But the main point is that knowing the RLD is REQUIRED (neither = RECOMMENDED nor OPTIONAL) to be able to follow and comply with the = requirements on where to position the {ELI; EL} and with the pseudocode. 2. OAM? The document says the following: The recommendations above are not expected to bring any additional OAM considerations beyond those described in section 6 of [RFC6790]. However, the OAM requirements and solutions for source routed tunnels formed by label stacking are still under discussion and future revisions of this document will address those if needed. Is this saying that the document still needs to evolve to be ready? What = are really the OAM considerations related to this draft? 3. Intended status: I agree with others in the sense that this is not a Standards Track doc. 4. EL Capability? This is probably the most important comment. The document defines the = ELC acronym, but it does not use it. ELC - Entropy Label Capability =46rom RFC 6790, the egress capability of processing EL needs to be = signaled to the ingress for the ingress to be able to insert an ELI; EL. In this case, the proposed method tries to optimize for position, but it = is not taking into account whether the egress of each segment can = actually process ELI; EL (or if it would otherwise Drop the packet!). = The algorithm does says =E2=80=9Cif EL-capable=E2=80=9D, but how is that = learned? In other words, this seems like a bug. Is the ingress is inserting a = label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for = example) might not understand and would drop? 5. Labels to push? Inserting N * 2 LSEs can have implications on the head-end in terms of = max numbers of labels which can be pushed. A label stack that is pushed = onto a packet, might not be able to be pushed if the stack grows by 2 * = N LSEs. The text says in various portions things like: The LSR that inserts pairs MAY have limitations on the number of such pairs that it can insert and also the depth at which it can insert them. However, is it really the limitation how many labels an ingress can = push? Also, if there is one node in the path which does not advertise the RLD, = then would the RLD be zero and make the algorithm moot? More editorial comments: No reference to draft-ietf-spring-segment-routing-mpls? Source routed tunnels with label stacking is a technique that can be leveraged to provide a method to steer a packet through a controlled set of segments. Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D (SRTLS?) = and not Segment Routing with MPLS data plane? OAM - Operation, Administration and Maintenance Should be "OAM - Operation, Administration, and Maintenance" [I-D.xu-isis-mpls-elc] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability Using IS- IS", draft-xu-isis-mpls-elc-02 (work in progress), April 2015. [I-D.xu-ospf-mpls-elc] Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. Litkowski, "Signaling Entropy Label Capability Using OSPF", draft-xu-ospf-mpls-elc-01 (work in progress), October 2014. These are expired and replaced by other documents. They should be marked = as Replaced-by in the Tracker. Thanks! =E2=80=94 Carlos. > On Apr 25, 2016, at 3:19 PM, Gregory Mirsky = wrote: >=20 > Hi George, et. al, > I=E2=80=99ve found several occurrences, three actually, of SHOULD = being used in Section 4. >=20 > And I agree with Stewart that application of is the local = decision and, at most, this work can be published as Informational. > One comment, suggestion: > =C2=B7 the sample algorithm in Section 4 suggests that the = same tuple been used multiple times whereas it may be = advantageous to generalize and point that the different entropy label = value may be used by referring to the tuple as >=20 > Regards, > Greg >=20 >=20 > From: mpls [mailto:mpls-bounces@ietf.org = ] On Behalf Of George Swallow > Sent: Monday, April 25, 2016 10:57 AM > To: Stewart Bryant > Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org = ; = mpls@ietf.org ; mpls-chairs@ietf.org = > Subject: Re: [mpls] working group last call on = draft-ietf-mpls-spring-entropy-label >=20 > Stewart - >=20 > On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant = > wrote: > I support this becoming a WG doc and thereby comming under WG > control. >=20 > The document is a WG doc. We are now in WG last call. >=20 > However I am not sure about the dismissal of the option to reuse > the ELI+EL. This clutters the stack less than the proposed option. >=20 > Also I wonder why this is standards track? >=20 > A reasonable question, particularly since there are no MUSTs, SHALLs = or REQUIREDs. Will discuss with my Co-Chairs and ADs. >=20 > Surely any equipment that understands the ELI can do this and thus = this is just an informal description of the problem and a solution. >=20 > Stewart >=20 >=20 > On 23/04/2016 08:53, Loa Andersson wrote: > Working Group, >=20 > This is to initiate a two week working group last call on > draft-ietf-mpls-spring-entropy-label. >=20 > Please send your comments to the mpls wg mailing list (mpls@ietf.org = ). >=20 > There are no IPR disclosures against this document. >=20 > All the authors and contributors (with one exception) have stated on > the working group mailing list that they are not aware of any other > IPRs that relates to this draft. >=20 > This working group last call ends May 12, 2016. >=20 >=20 > /Loa > for the MPLS wg chairs >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls = --Apple-Mail=_555176CD-D646-4868-99F2-5F8334CDF2FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Loa,

I = just scanned through draft-ietf-mpls-spring-entropy-label-03 and = wanted to share some observations. Please treat these as WGLC = comments.

I = have a number of concerns. It seems as if this document was not really = reviewed to see if it was ready for WGLC:

1. What is this document = specifying?

As = Greg just mentioned below, there are several SHOULD terms in Section 4. = Those SHOULD are dependent upon the =E2=80=9CRLD".

That same section then = lists the following:

   The RLD can be advertised via = protocols and those extensions are
  =  described in separate documents [I-D.xu-isis-mpls-elc] = and
  =  [I-D.xu-ospf-mpls-elc].

First, those are expired and should be = marked as replaced by wg docs.

But the main point is that knowing the = RLD is REQUIRED (neither RECOMMENDED nor OPTIONAL) to be able to follow = and comply with the requirements on where to position the {ELI; EL} and = with the pseudocode.


2. OAM?

The document says the = following:

   The recommendations above are not expected to = bring any additional
   OAM = considerations beyond those described in section 6 of = [RFC6790].
   However, the OAM = requirements and solutions for source routed tunnels
   formed by label stacking are still under = discussion and future
   revisions of = this document will address those if needed.
Is this saying that the document still = needs to evolve to be ready? What are really the OAM considerations = related to this draft?


3. Intended = status:

I = agree with others in the sense that this is not a Standards Track = doc.


4. EL Capability?

This is probably the = most important comment. The document defines the ELC acronym, but it = does not use it.

      ELC - Entropy Label Capability

=46rom RFC 6790, the = egress capability of processing EL needs to be signaled to the ingress = for the ingress to be able to insert an ELI; EL. 

In this case, the = proposed method tries to optimize for position, but it is not taking = into account whether the egress of each segment can actually process = ELI; EL (or if it would otherwise Drop the packet!). The algorithm does = says =E2=80=9Cif EL-capable=E2=80=9D, but how is that = learned? 

In other words, this seems like a bug. Is the ingress is = inserting a label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node = segment for example) might not understand and would drop?


5. Labels to push?

Inserting N * 2 LSEs can have = implications on the head-end in terms of max numbers of labels which can = be pushed. A label stack that is pushed onto a packet, might not be able = to be pushed if the stack grows by 2 * N LSEs. 

The text says in various = portions things like:

   The LSR that inserts <ELI, = EL> pairs MAY have limitations
   on = the number of such pairs that it can insert and also the depth = at
   which it can insert them. =  

However, is it really the limitation how many labels an = ingress can push?

Also, if there is one node in the path which does not = advertise the RLD, then would the RLD be zero and make the algorithm = moot?


More editorial comments:

No = reference = to draft-ietf-spring-segment-routing-mpls?


   Source routed tunnels with label = stacking is a technique that can be
  =  leveraged to provide a method to steer a packet through a = controlled
   set of = segments.

Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D= (SRTLS?) and not Segment Routing with MPLS data plane?

      OAM = - Operation, Administration and Maintenance

Should be "OAM - Operation, = Administration, and Maintenance"


   [I-D.xu-isis-mpls-elc]
  =             Xu, X., Kini, S., Sivabalan, = S., Filsfils, C., and S.
      =         Litkowski, "Signaling Entropy Label = Capability Using IS-
        =       IS", draft-xu-isis-mpls-elc-02 (work in progress), = April
            =   2015.

   [I-D.xu-ospf-mpls-elc]
 =             Xu, X., Kini, S., Sivabalan, = S., Filsfils, C., and S.
      =         Litkowski, "Signaling Entropy Label = Capability Using
          =     OSPF", draft-xu-ospf-mpls-elc-01 (work in = progress),
          =     October 2014.


These are expired and replaced by other documents. They = should be marked as Replaced-by in the Tracker.

Thanks!

=E2=80=94 Carlos.

On Apr 25, 2016, at 3:19 PM, = Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi George, et. al,
I=E2=80=99ve found several occurrences, = three actually, of SHOULD being used in Section 4.
 
And I agree with = Stewart that application of <ELI, EL> is the local decision and, = at most, this work can be published as Informational.
One comment, suggestion:
=C2=B7         the sample algorithm in Section 4 suggests = that the same <ELI,EL> tuple been used multiple times whereas it = may be advantageous to generalize and point that the different entropy = label value may be used by referring to the tuple as <ELI, = ELn>
 
Regards,
        Greg
 
 
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf = Of George = Swallow
Sent: Monday, April 25, 2016 = 10:57 AM
To: Stewart Bryant
Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org
Subject: Re: [mpls] working group = last call on draft-ietf-mpls-spring-entropy-label
 
Stewart -
 
On Mon, Apr 25, 2016 = at 9:58 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
I = support this becoming a WG doc and thereby comming under WG
control.
 
The document is a WG doc.   We are now in = WG last call.
 
However I am not sure about the dismissal of the option to = reuse
the ELI+EL. This clutters the stack less than the = proposed option.

Also I wonder why this is = standards track?
 
A reasonable question, particularly since there are = no MUSTs, SHALLs or REQUIREDs.  Will discuss with my Co-Chairs and = ADs.
 
Surely= any equipment that understands the ELI can do this and thus this is = just an informal description of the problem and a solution.

Stewart


On = 23/04/2016 08:53, Loa Andersson wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this = document.

All the authors and contributors = (with one exception) have stated on
the working group = mailing list that they are not aware of any other
IPRs = that relates to this draft.

This working = group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs
 
 
_______________________________________________
mpls mailing = list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

= --Apple-Mail=_555176CD-D646-4868-99F2-5F8334CDF2FA-- --Apple-Mail=_56D92E74-A986-497B-9A1F-8B80B50673A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXIEA0AAoJEIXgpQGOZny9W7oP/3tss1VHDC05DiBPWz1J0buJ IWT6ySdNq2goDmmAaYwUh/H80mE6tcU0XGkzGmOSuW1wZS7ylnz+xHFTP0krx9wZ wzu+VqlJXMbjJuqV0idZFNaFEKtvt36TUZLXfCKxni/0/jdUYn+TQ9TrtMLmeNbg lLqaHxufmnuMMQhLTkA0fOfoS5xz7RJovNB4gJ6KQ9Aqsvf4eoGCw3qoeVFY9G+V pL4ublLss578qVje2KMw8+r6Halicg0t/uwScc2hP+J6qqAc7kGPYFJq0V5gQ1ne BgxcoQWQqrORotcdHKiCHmPmXvnG6L/+N3sFz3iQUCwsWSfQB3mwb+TBrsSrts/S 8kAkktn/toe/Dbx2I0PwOwp+qnyUFZoxVlFHGfiZM4Zr30j34F7l9V+bMEedTcDw CUQ/9e6taK2yQNr96M0OXqIBCzmkk4fz3mM7DOO6CdtuGRfM08z1Yqm6yywG/PbH 77dGVP3RzwosBv8MJLD22520ElHI/RL+Bip3iUGSSS0oaey6Znh6OGJsCd+L/6Da A/T/l7BNx/cd2t54wnDsOn8m5dPPsyP/DpyCvv2MwJzHM5IlsA1Bw4psEMQICIEF 4LUkGCFOPYngM81fmEzaVleD/b5v9erbmS+heCFTjevvZcJ76M75EjrqOH8dMkqB zalqBBK3nldBIg4oYzPd =3VWM -----END PGP SIGNATURE----- --Apple-Mail=_56D92E74-A986-497B-9A1F-8B80B50673A1-- From nobody Wed Apr 27 04:07:44 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9612B037; Wed, 27 Apr 2016 04:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkJ2rtPBraNL; Wed, 27 Apr 2016 04:07:40 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 C2F8712B01A; Wed, 27 Apr 2016 04:07:38 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id e201so33513731wme.0; Wed, 27 Apr 2016 04:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=w+GqXE4spSFtfyWmWnJeArGL2n+CPcKXmxoEXHxqmAU=; b=aaaHrii9gm8WR2PuEsr+c6nKvv2FxYwzS1nMeBuDpp6kcU3A0FBZeZgxwDtBlp40j1 Z5VnCACb0VnfUA/KZ9Yl0sRniNnpb5w9XPizz6XFPe04EFwDW1fi/Tc4cRpsrtRUh0UR PhGs9bKEHubbg5TnGk+2K47pbS1cTyFm0KhQhH31q2GNIWfJSJx3LL+EsM3pJmh/uoUl 9ZOTvXlQvpQVm5S3ZppYJ/YUVaJpR50d4qDD97KnHYqOnqxiLus6pGCnonIR+PR7HBuh XQP0kwkiLotEkHVNjdwtR3EkMrK97r+rgwpUWTPJHPXvVa1q3F7kUV9YBenDT2atYP2v 3nqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=w+GqXE4spSFtfyWmWnJeArGL2n+CPcKXmxoEXHxqmAU=; b=c53A7AYIMiGl8OqYvPcUaWsr82Q6mQesyXTT604u97vK0oQp46DoCTXkAFx6xPn/Fq 2xNl94uhnSwdtkRX3EfLMVhuBNvbfsTqzCCQKyaUepvqcCYIxC7XqeyFNpqQX1MVqDEd TJz8YB1lTQJADJh1rTY9KBcfWhf3nMvp7GrrRTROx4BxFfp7pozDv3ibfeiWOpzS4xGb IqBntZdlnRnbAQlUnMqAevy9TQzuSTBXfPpUb0qZEjatkPqo2KN0dSeRmkHQV2Irt3rQ LKB4H7zAKPV2t61iSYduAE3I/0K8pUgB62LqTwBSQWMKOki0JU1/FOKMifXBTcFMtuEl 2FFw== X-Gm-Message-State: AOPr4FV5fNf5PQDNazFK5s4DHFVFwEQnxqJGhQ3/R5bMoeMhqj6nXZ4v8lxOtcfSZlxg+w== X-Received: by 10.194.100.129 with SMTP id ey1mr8654823wjb.26.1461755257300; Wed, 27 Apr 2016 04:07:37 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id a127sm7909353wmc.17.2016.04.27.04.07.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 04:07:35 -0700 (PDT) To: "Carlos Pignataro (cpignata)" , Gregory Mirsky , Loa Andersson References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com> From: Stewart Bryant Message-ID: <57209D76.3050805@gmail.com> Date: Wed, 27 Apr 2016 12:07:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 11:07:43 -0000 On 27/04/2016 05:29, Carlos Pignataro (cpignata) wrote: > Why “source router tunnels with label stacking” (SRTLS?) and not > Segment Routing with MPLS data plane? You are right, although source routing is really the generic name for this technology. Stewart From nobody Wed Apr 27 06:19:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FBD12D18D; Wed, 27 Apr 2016 06:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 U36X0eh2Rd9M; Wed, 27 Apr 2016 06:19:52 -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 7D7C112D191; Wed, 27 Apr 2016 06:19:52 -0700 (PDT) Received: from [192.168.1.6] (unknown [122.53.41.246]) (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 6E2F318013CB; Wed, 27 Apr 2016 15:19:49 +0200 (CEST) From: Loa Andersson To: "mpls@ietf.org" , "pals@ietf.org" Message-ID: <5720BC5A.2040008@pi.nu> Date: Wed, 27 Apr 2016 21:19:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: 8bit Archived-At: Cc: "pals-chairs@ietf.org" , "mpls-chairs@ietf.org" Subject: [mpls] Proposed response to ITU-T SG15 on "LS on work on MPLS-TP protection" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:19:55 -0000 Working groups, We had a liaison from ITU-T SG15 on "LS on work on MPLS-TP protection", please find the proposed response below. Please send comments to the mpls wg mailing list (mpls@ietf.org) on May 3rd the latest. -------------------- proposed response --------------------------- The MPLS and PALS Working Groups are pleased to hear about the continued progress on the MPLS Transport Profile and continued alignment with IETF RFCs. We confirm that "MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology” (https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection) is progressing in the MPLS WG, and invite comments on this draft to the MPLS WG mailing list (mpls@ietf.org). In addition, we are also progressing a draft on "Resilient MPLS Rings" (https://datatracker.ietf.org/doc/draft-ietf-mpls-rmr). The PALS WG currently has two drafts in progress that are relevant to MPLS-TP pseudowire linear protection: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-coordination https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-protection These drafts provide a fast protection mechanism for MPLS-TP PWs to protect dual-homed CEs against failures of their attachment circuits or PE routers. The drafts are ongoing work and were very recently updated. We hope to complete work on these drafts by the upcoming IETF meeting in Berlin on July 17-22, 2016, and would very much appreciate SG15’s review and comments to the pals@ietf.org email list. We are also pleased to hear about the second amendment to Recommendation ITU-T G.8131/Y.1382, "Linear protection switching for MPLS transport profile." In addition to maintaining communication with liaisons, please engage on the MPLS WG mailing list (mpls@ietf.org) and PALS WG mailing list (pals@ietf.org) which provide a more timely view of the state of the work. MPLS and PALS wg co-chairs ------------------------- end of proposed response ------------------ /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Apr 27 10:05:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8A12D9F3; Wed, 27 Apr 2016 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 gi7lTXzrcmKr; Wed, 27 Apr 2016 10:05:02 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE0912D9EF; Wed, 27 Apr 2016 10:05:01 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-f1-5720ea026bc0 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 24.0C.09012.20AE0275; Wed, 27 Apr 2016 18:34:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 13:05:00 -0400 From: Gregory Mirsky To: "Jim Guichard (jguichar)" , "sfc@ietf.org" , "mpls@ietf.org" , "pals@ietf.org" Thread-Topic: draft-ietf-sfc-nsh "first nibble" issue Thread-Index: AQHRoHv5jA1HvFPCM0yMnvW+PmvYjp+eC04w Date: Wed, 27 Apr 2016 17:04:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A60FA3@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHT5fplUK4wembMhZL56lb3Fq6ktVi zb91TBZPHmxld2DxmPJ7I6vHkiU/mQKYorhsUlJzMstSi/TtErgyVi4OLjgcVrF7z3vWBsav Xl2MnBwSAiYSu272sELYYhIX7q1n62Lk4hASOMoosalzHxtIQkhgOaPE3ZO2IDabgJHEi409 7CBFIgLTGSWWrdvMApIQBpr0/+E5ZhBbRMBUovvuFCCbA8g2ktjUbQVisgioSrz4zwJi8gr4 Srw/VAgxXV9i15sV7CA2p4CBRPeCE2DnMAKd8/3UGiYQm1lAXOLWk/lMEGcKSCzZc54ZwhaV ePn4H9T5ihL7+qezQ9TnSzxp3gdWzysgKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxt iWULXzPD2GcOPGZCFl/AyL6KkaO0uCAnN93IYBMjMJKOSbDp7mC8P93zEKMAB6MSD6+CrEK4 EGtiWXFl7iFGCQ5mJRHe6W+AQrwpiZVVqUX58UWlOanFhxilOViUxHkbg/+FCQmkJ5akZqem FqQWwWSZODilGhgVFVyUXjWf8zGqttz19erq+3fCDu5+mC+V+HPKbhupM/8SE/jXcovad1tu mRTF+lu50Y3befor3TR+AQs++8UJi8x3njtv8Xi5Qq71Iil551ev/N84SjnX5gU5WMnOWxio NKH5xKSZppltr1+WhmTciX774kaDoEwq7+OPW18t7gue7Lr1AYcSS3FGoqEWc1FxIgBdF7zS oAIAAA== Archived-At: Subject: Re: [mpls] draft-ietf-sfc-nsh "first nibble" issue X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:05:07 -0000 --_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, as this issue is related to MPLS and MPLS PWs shall we extend the audience = and invite MPLS and PALS WGs to the discussion? Personally, I prefer solution that avoids not only 0x04 and 0x06 in the fir= st nibble but 0x00 and 0x01 as well by using Non-of-the-Above value, e.g. 0= x05 as in BIER over MPLS encapsulation. Regards, Greg From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, April 27, 2016 4:58 AM To: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue Dear WG: The infamous "MPLS first nibble" issue was raised as part of the WGLC for d= raft-ietf-sfc-nsh-04. While this issue has been known for some time, and wo= rk has been done by the community to try and mitigate (for example RFC4928)= or remove it (for example RFC6790), given the widespread implementation of= existing hardware that uses the first nibble for ECMP decision processing,= it seems prudent for us as a WG to address it in terms of how it affects o= ur SFC protocol and make it clear within the draft the conclusion of the WG= . While it is true that we could rearrange our encapsulation header such that= it avoids this issue (by simply making the first nibble correspond to a va= lue that is neither 0x4 or 0x6), given multiple industry and open source im= plementations of the SFC encapsulation header, that is not a desired outcom= e, especially as multiple other transport encapsulations do not exhibit thi= s behavior when coupled with the SFC encapsulation. If we consider the current definition of the SFC encapsulation base header,= we can see that the first two bits are used as a version field. This means= that if we ever produce a version 01 for NSH it could result in a value of= 0x4 or 0x6 being present within the first nibble. To avoid such a result t= he simplest solution would be to reserve within the SFC encapsulation speci= fication version 01 and make it clear within the text that this is reserved= and should not be used in future versions of the protocol. If we ever chan= ge the version, which incidentally should be a rare thing, we would therefo= re jump from version=3D00 to version=3D02 (i.e. making version 1 'reserved'= ) thereby avoiding any clash in the first nibble. IMHO this seems like a reasonable approach to the problem but I would like = to hear opinions from the WG as to whether this is an acceptable solution a= nd if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add = text to reflect it. Jim --_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,=

as this issue is related = to MPLS and MPLS PWs shall we extend the audience and invite MPLS and PALS = WGs to the discussion?

Personally, I prefer solu= tion that avoids not only 0x04 and 0x06 in the first nibble but 0x00 and 0x= 01 as well by using Non-of-the-Above value, e.g. 0x05 as in BIER over MPLS encapsulation.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 4:58 AM
To: sfc@ietf.org
Subject: [sfc] draft-ietf-sfc-nsh "first nibble" issue

 

Dear WG:<= /p>

 

The infamous “MPLS fi= rst nibble” issue was raised as part of the WGLC for draft-ietf-sfc-n= sh-04. While this issue has been known for some time, and work has been done by the community to try and mitigate (for example RFC4928) or remove = it (for example RFC6790), given the widespread implementation of existing h= ardware that uses the first nibble for ECMP decision processing, it seems p= rudent for us as a WG to address it in terms of how it affects our SFC protocol and make it clear within th= e draft the conclusion of the WG.

 

While it is true that we co= uld rearrange our encapsulation header such that it avoids this issue (by s= imply making the first nibble correspond to a value that is neither 0x4 or 0x6), given multiple industry and open source implementa= tions of the SFC encapsulation header, that is not a desired outcome, espec= ially as multiple other transport encapsulations do not exhibit this behavi= or when coupled with the SFC encapsulation.

 

If we consider the current = definition of the SFC encapsulation base header, we can see that the first = two bits are used as a version field. This means that if we ever produce a version 01 for NSH it could result in a value of 0x4 or = 0x6 being present within the first nibble. To avoid such a result the simpl= est solution would be to reserve within the SFC encapsulation specification= version 01 and make it clear within the text that this is reserved and should not be used in future versions o= f the protocol. If we ever change the version, which incidentally should be= a rare thing, we would therefore jump from version=3D00 to version=3D02 (i= .e. making version 1 ‘reserved’) thereby avoiding any clash in the first nibble. 

 

IMHO this seems like a reas= onable approach to the problem but I would like to hear opinions from the W= G as to whether this is an acceptable solution and if we can reach consensus, ask the editors of draft-ietf-sfc-nsh to add text to = reflect it.

 

Jim

--_000_7347100B5761DC41A166AC17F22DF11221A60FA3eusaamb103erics_-- From nobody Thu Apr 28 12:34:02 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19812D942; Thu, 28 Apr 2016 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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, 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 o2pMGBs_tBfJ; Thu, 28 Apr 2016 12:33:58 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B9E12D946; Thu, 28 Apr 2016 12:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7434; q=dns/txt; s=iport; t=1461872038; x=1463081638; h=from:to:cc:subject:date:message-id:mime-version; bh=yJquQEkv6eij7dam+d28qATlQbNFjk9MtWjvoyRdF1c=; b=GUGqJ54Q2N26DY8cH+RVBWmUJs9iPJDmXwaQNayxDfE8PpNyNrEJgABW 7p0LDskCSAI7c5GPh8zsZFBDN3gNmyUZ6382kpLnytl4B7sT5eqsSTX8K R9UA36fWKZbHxTSBNMzqJwZFGdx7qB7sXqJH6YwjXCzS5UOjDLr2HQr5R Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgAKZSJX/4MNJK1egmxMU30GtGeEc?= =?us-ascii?q?wENgXYkhWsegRA4FAEBAQEBAQFlHAuESCNWEgFKAgQwJwQOIIgPDrJTkR0BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQERBIYhgXUIigsrgisFjVSKPAGBLYROiBuPEY8vA?= =?us-ascii?q?R4BAUKDa2wBhislGH8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,548,1454976000"; d="scan'208,217";a="267261753" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 19:33:57 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3SJXu7j021540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 19:33:57 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 15:33:55 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 15:33:55 -0400 From: "Tarek Saad (tsaad)" To: "draft-ietf-netmod-schema-mount@ietf.org" Thread-Topic: Use of schema mounts for common model Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLng== Date: Thu, 28 Apr 2016 19:33:55 +0000 Message-ID: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.243.62] Content-Type: multipart/alternative; boundary="_000_4A05DD100885435C9D139634388B9F4Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" Subject: [mpls] Use of schema mounts for common model X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 19:34:00 -0000 --_000_4A05DD100885435C9D139634388B9F4Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycy9XRywNCg0KSW4gZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUsIHdlIGFyZSBkcml2 aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFORyBtb2RlbCB0aGF0IGNhbi9t YXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRh dGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwgV0RNLCBldGMuKS4NClJldmll d2luZyB0aGUgc2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluIGRyYWZ0LWlldGYtbmV0bW9k LXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXMgdXNlZnVsIGFu ZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZSBw bGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBwZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjoN CuKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQri gKYvb3RuL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nDQoNCldl IGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBmZWVk YmFjay4NCg0KVGhlIGdlbmVyaWMgVEUgbW9kZWwgY3VycmVudGx5IHJlZmVyZW5jZXMgZGF0YSBu b2RlcyBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gZnJvbSB0aGUgaWV0Zi1pbnRlcmZhY2VzIG1v ZGVsIHRvIGRlZmluZSBhZGRpdGlvbmFsIFRFIHByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRoIGEg c3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91ciB1bmRlcnN0YW5kaW5nIGFmdGVyIHJlYWRp bmcgc2VjdGlvbiAzLjEgb2YgeW91ciBkcmFmdCBpcyB0aGUgbW91bnRlZCBtb2RlbCBjYW4gKm5v dCogcmVmZXJlbmNlIGFueSBkYXRhIG5vZGVzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBtb3Vu dC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4gVGhpcyBw b3NlcyBhIGxpbWl0YXRpb24gZm9yIHVzLCBkbyB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gZm9yIHRo aXMgcHJvYmxlbT8NCg0KT25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRv IHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMg KGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUuZy4gdGhlIGludGVy ZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRlZmluZWQgaW4gdGhl IFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUgKGUuZy4gdGhl IGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9u IHRoaXMgb3IgYmV0dGVyIHN1Z2dlc3Rpb25zPw0KDQpSZWdhcmRzLA0KVGFyZWsNCg0KRXhjZXJw dCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudA0KDQozLjE8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9u LTMuMT4uICBBdWdtZW50IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KDQoNCiAgIEFs bCBwYXRocyAoaW4gbGVhZnJlZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNz aW9ucywgYW5kDQogICB0YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVs cyBtb3VudGVkIGF0IGEgbW91bnQgcG9pbnQNCiAgIGFyZSBpbnRlcnByZXRlZCB3aXRoIHRoZSBt b3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlDQogICBtb3VudGVkIGRhdGEgbm9k ZXMgYXMgaXRzIGNoaWxkcmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgIG1v dW50ZWQgc3VidHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3Vi dHJlZS4NCg0KDQoNCg0K --_000_4A05DD100885435C9D139634388B9F4Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4EDE293CDAFCF7409F0D9A213A08AA69@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBhdXRob3Jz L1dHLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gZHJhZnQtaWV0Zi10ZWFzLXlh bmctdGUsIHdlIGFyZSBkcml2aW5nIHRoZSBkZWZpbml0aW9uIGZvciBhIGdlbmVyaWMgVEUgWUFO RyBtb2RlbCB0aGF0IGNhbi9tYXkgYmUgdXNlZCAoYW5kIGV4dGVuZGVkIHdoZW4gbmVjZXNzYXJ5 KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChlLmcuIE1QTFMsIE9UTiwg V0RNLCBldGMuKS48L2Rpdj4NCjxkaXY+UmV2aWV3aW5nIHRoZSBzY2hlbWEgbW91bnQgaWRlYSBw cmVzZW50ZWQgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUgdGhpbmtp bmcgdGhpcyBwcm9wb3NhbCBpcyB1c2VmdWwgYW5kIGNhbiBmYWNpbGl0YXRlIHRoZSByZXVzZSBv ZiB0aGUgb3VyIG1vZGVsIGluIG11bHRpcGxlIHBsYWNlcyBpbiB0aGUgWUFORyB0cmVlIChvbmNl IHBlciBlYWNoIHRlY2hub2xvZ3kpLCBlLmcuOjwvZGl2Pg0KPGRpdj7igKYvbXBscy9tb3VudC1w b2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPGRpdj7igKYvb3Ru L21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1bGU9aWV0Zi10ZS55YW5nPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5XZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24g YW5kIHdlIHZhbHVlIHlvdXIgZmVlZGJhY2suJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5UaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNlcyBkYXRhIG5v ZGVzIGluIHRoZSBnbG9iYWwgdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMgbW9k ZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUgcHJvcGVydGllcyBhc3NvY2lhdGVkIHdpdGggYSBz cGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyIHVuZGVyc3RhbmRpbmcgYWZ0ZXIgcmVhZGlu ZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZQ0KIG1vdW50ZWQgbW9kZWwgY2FuICo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5ub3Q8L3NwYW4+KiByZWZlcmVuY2UgYW55 IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIG1vdW50LXBvaW50IChlLmcuIGds b2JhbCBkYXRhIG5vZGVzIGluIHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGEgbGltaXRhdGlv biBmb3IgdXMsIGRvIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25lIHBvc3NpYmxlIHNvbHV0aW9uIHdlIHRob3Vn aHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcyBwb2ludGluZyB0byB0aGUgZ2xvYmFs IGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQgbmFtZXMgKGUu Zy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVjb3VwbGVzIHRoZSBkYXRhLW5vZGVzIGRl ZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwgZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsDQog dHJlZSAoZS5nLiB0aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBB bnkgZmVlZGJhY2sgb24gdGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5UYXJlazwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+RXhjZXJwdCBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1t b3VudDwvZGl2Pg0KPGRpdj4NCjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6 IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJl Zm9yZTogYWx3YXlzOyI+PHNwYW4gY2xhc3M9ImgzIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDBwdDsg ZGlzcGxheTogaW5saW5lOyBmb250LXNpemU6IDFlbTsgZm9udC13ZWlnaHQ6IGJvbGQ7Ij48aDMg c3R5bGU9ImxpbmUtaGVpZ2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1zaXplOiAxZW07 Ij48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMy4xIiBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rp b24tMy4xIiBzdHlsZT0iY29sb3I6IGJsYWNrOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4zLjE8 L2E+LiAgQXVnbWVudCBhbmQgVmFsaWRhdGlvbiBpbiBNb3VudGVkIERhdGE8L2gzPjwvc3Bhbj4N Cg0KICAgQWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQYXRo IGV4cHJlc3Npb25zLCBhbmQNCiAgIHRhcmdldCBub2RlcyBvZiBhdWdtZW50cykgaW4gdGhlIGRh dGEgbW9kZWxzIG1vdW50ZWQgYXQgYSBtb3VudCBwb2ludA0KICAgYXJlIGludGVycHJldGVkIHdp dGggdGhlIG1vdW50IHBvaW50IGFzIHRoZSByb290IG5vZGUsIGFuZCB0aGUNCiAgIG1vdW50ZWQg ZGF0YSBub2RlcyBhcyBpdHMgY2hpbGRyZW4uICA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAwKTsiPlRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQogICBt b3VudGVkIHN1YnRyZWUgY2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1 YnRyZWUuPC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4A05DD100885435C9D139634388B9F4Bciscocom_-- From nobody Thu Apr 28 13:47:18 2016 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0CA12B04A; Thu, 28 Apr 2016 13:47: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: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2016 13:47:15 -0700 Archived-At: Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:47:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-08.txt Pages : 27 Date : 2016-04-28 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 28 13:53:41 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1110312D584; Thu, 28 Apr 2016 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTASIWNtQNcn; Thu, 28 Apr 2016 13:53:38 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03C812D573; Thu, 28 Apr 2016 13:53:37 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-a4-57227824be8e Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 3A.5C.03614.42872275; Thu, 28 Apr 2016 22:52:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 28 Apr 2016 16:53:36 -0400 From: Gregory Mirsky To: Loa Andersson , "lberger@labn.net" , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt Thread-Index: AQHRoY8q390nPF0LtUuImRWKzDmMap+f3AJw Date: Thu, 28 Apr 2016 20:53:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> In-Reply-To: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyuXRPlK5KhVK4weML+haT385jtpi69QOz xZy7zhYdzW9ZLP7NncNscWvpSlaLUw8SLVp/7GCx+Nvcw+7A6THl90ZWj03/jjN67Jx1l91j yZKfTB7Xm66ye3zY1MzmMWt6G1sAexSXTUpqTmZZapG+XQJXxvZZsQVvBCse/7zP2MC4j7eL kZNDQsBEYsuOvcwQtpjEhXvr2boYuTiEBI4ySlzoOs4E4SxnlOj6+I8NpIpNwEjixcYedpCE iMB9RonJ7S8ZQRxmgX1MEmsW3GQHqRIWcJWY1r0SrENEwE1ib9tcKNtI4u6F7SwgNouAqsTR p2dZQWxeAV+J1nVLmUBsIQEHif5fE8BsTgFHiavr94LNZAS67/upNWBxZgFxiVtP5jNB3C0g sWTPeagfRCVePv7HCmErSUxaeo4Vol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGDlKiwtyctONDDcxAqPzmASb4w7Gvb2ehxgFOBiVeHgX5CmGC7EmlhVX 5h5ilOBgVhLhDSlWChfiTUmsrEotyo8vKs1JLT7EKM3BoiTOq/8SqFogPbEkNTs1tSC1CCbL xMEp1cA4Y2nf9MPsLjOXt7DWmui2ObdL5km+y20Q+rP0ndR5Y+mD0gE+AsvYmjct3sqoJaqj 21OwZafa4W/7o5jke5d9adzzUtq34uXEzFVi/UJvG2buWyaufkvurIm1wDIzzqKfTgwh82Un XXP12F/IZ2zQEn/4oq/fDPWD6w62hXnciGdPv3HSyVaJpTgj0VCLuag4EQB1z8gsygIAAA== Archived-At: Cc: Stefano Ruffini Subject: [mpls] FW: I-D Action: draft-ietf-mpls-residence-time-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:53:40 -0000 Dear All, updates in the new version clarify use of the I flag in the RTM_SET TLV. Authors believe that all comments we've received from Acee and Lou now have= been addressed. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, April 28, 2016 1:47 PM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching of the IETF. Title : Residence Time Measurement in MPLS network Authors : Greg Mirsky Stefano Ruffini Eric Gray John Drake Stewart Bryant Alexander Vainshtein Filename : draft-ietf-mpls-residence-time-08.txt Pages : 27 Date : 2016-04-28 Abstract: This document specifies G-ACh based Residence Time Measurement and how it can be used by time synchronization protocols being transported over MPLS domain. Residence time is the variable part of propagation delay of timing and synchronization messages and knowing what this delay is for each message allows for a more accurate determination of the delay to be taken into account in applying the value included in a PTP event message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-residence-time-08 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Apr 28 13:58:51 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F012D567 for ; Thu, 28 Apr 2016 13:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 rTI5vxewiWlj for ; Thu, 28 Apr 2016 13:58:37 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 14EAC12B00F for ; Thu, 28 Apr 2016 13:58:37 -0700 (PDT) Received: (qmail 12816 invoked by uid 0); 28 Apr 2016 20:58:33 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 28 Apr 2016 20:58:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id nwyP1s00w2SSUrH01wySWl; Thu, 28 Apr 2016 14:58:33 -0600 X-Authority-Analysis: v=2.1 cv=aJ5j99Nm c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=pe07b3NTbGBt4aplo2YA:9 a=Sfpe1sfZ2QWo5lbg:21 a=hDdnFZzf8-CIZ_vu:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=l18ld1uSMTpKLkCALn1iAN7V0uv25dsTD7p695NGAGs=; b=I3i8ZgBosflmXA4jAVd/zJodGo LOjXj2AGV+G5Hw1U5IyaHaYQ975za0bNrpQlzF8lejhGGrsoyyjtjWJGnoDERxyiaktkzlaXCyCV3 e06QmHYMfJwVC1vyYUvTGAd3F; Received: from box313.bluehost.com ([69.89.31.113]:53441 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1avt0x-0007If-Mj; Thu, 28 Apr 2016 14:58:23 -0600 To: Gregory Mirsky , Loa Andersson , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> From: Lou Berger Message-ID: <5722795D.1030008@labn.net> Date: Thu, 28 Apr 2016 16:58:05 -0400 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: <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Stefano Ruffini Subject: Re: [mpls] [Teas] FW: I-D Action: draft-ietf-mpls-residence-time-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:58:49 -0000 I agree. There is one minor typo: s/could been/could be/ This can be picked up in the next rev, i.e., no need to spin a rev now to fix this minor typo. Thanks for all the good work. Lou On 4/28/2016 4:53 PM, Gregory Mirsky wrote: > Dear All, > updates in the new version clarify use of the I flag in the RTM_SET TLV. > Authors believe that all comments we've received from Acee and Lou now have been addressed. > > Regards, > Greg > > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, April 28, 2016 1:47 PM > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching of the IETF. > > Title : Residence Time Measurement in MPLS network > Authors : Greg Mirsky > Stefano Ruffini > Eric Gray > John Drake > Stewart Bryant > Alexander Vainshtein > Filename : draft-ietf-mpls-residence-time-08.txt > Pages : 27 > Date : 2016-04-28 > > Abstract: > This document specifies G-ACh based Residence Time Measurement and > how it can be used by time synchronization protocols being > transported over MPLS domain. > > Residence time is the variable part of propagation delay of timing > and synchronization messages and knowing what this delay is for each > message allows for a more accurate determination of the delay to be > taken into account in applying the value included in a PTP event > message. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-08 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 28 17:55:39 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF0C12B006; Thu, 28 Apr 2016 17:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 UrOmdNuAX4BV; Thu, 28 Apr 2016 17:55:34 -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 2D0C312D509; Thu, 28 Apr 2016 17:55:33 -0700 (PDT) Received: from [192.168.1.6] (unknown [122.53.41.246]) (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 5F97F1802AB9; Fri, 29 Apr 2016 02:55:27 +0200 (CEST) To: Lou Berger , Gregory Mirsky , "mpls@ietf.org" , TEAS WG , "tictoc@ietf.org" , "Acee Lindem (acee) (acee@cisco.com)" References: <20160428204715.5490.96999.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF11221A626CE@eusaamb103.ericsson.se> <5722795D.1030008@labn.net> From: Loa Andersson Message-ID: <5722B0FC.7020609@pi.nu> Date: Fri, 29 Apr 2016 08:55:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5722795D.1030008@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Stefano Ruffini Subject: Re: [mpls] [Teas] FW: I-D Action: draft-ietf-mpls-residence-time-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 00:55:38 -0000 Authors, reviewers, et.al., Thanks for all the work in getting this draft ready for wglc, I will start the procedures later today, beginning with an IPR poll and follow up with the wglc as soon as tht has concluded. /Loa On 2016-04-29 04:58, Lou Berger wrote: > I agree. > > There is one minor typo: s/could been/could be/ > > This can be picked up in the next rev, i.e., no need to spin a rev now > to fix this minor typo. > > Thanks for all the good work. > Lou > > On 4/28/2016 4:53 PM, Gregory Mirsky wrote: >> Dear All, >> updates in the new version clarify use of the I flag in the RTM_SET TLV. >> Authors believe that all comments we've received from Acee and Lou now have been addressed. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >> Sent: Thursday, April 28, 2016 1:47 PM >> To: i-d-announce@ietf.org >> Cc: mpls@ietf.org >> Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-08.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multiprotocol Label Switching of the IETF. >> >> Title : Residence Time Measurement in MPLS network >> Authors : Greg Mirsky >> Stefano Ruffini >> Eric Gray >> John Drake >> Stewart Bryant >> Alexander Vainshtein >> Filename : draft-ietf-mpls-residence-time-08.txt >> Pages : 27 >> Date : 2016-04-28 >> >> Abstract: >> This document specifies G-ACh based Residence Time Measurement and >> how it can be used by time synchronization protocols being >> transported over MPLS domain. >> >> Residence time is the variable part of propagation delay of timing >> and synchronization messages and knowing what this delay is for each >> message allows for a more accurate determination of the delay to be >> taken into account in applying the value included in a PTP event >> message. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mpls-residence-time-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-08 >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Apr 28 19:20:54 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144C512D10A; Thu, 28 Apr 2016 19:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 s2qg64N0VOw0; Thu, 28 Apr 2016 19:20:51 -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 98D4112D11A; Thu, 28 Apr 2016 19:20:48 -0700 (PDT) Received: from [192.168.1.6] (unknown [122.53.41.246]) (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 E65491802AB9; Fri, 29 Apr 2016 04:20:45 +0200 (CEST) To: "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" , "mpls-chairs@ietf.org" From: Loa Andersson Message-ID: <5722C4FA.5000802@pi.nu> Date: Fri, 29 Apr 2016 10:20:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: [mpls] draft-ietf-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 02:20:53 -0000 Working Group, The authors of draft-ietf-mpls-residence-time has told us that the document is ready to be considered for working group last call. We will do an IPR poll prior to the start of the wg last call. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-residence-time? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR disclosure filed against the document that was replaced by the current draft. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 28 19:23:10 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4212D0F6; Thu, 28 Apr 2016 19:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 HhyBTG-1ASpk; Thu, 28 Apr 2016 19:23:08 -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 40E4012B068; Thu, 28 Apr 2016 19:23:08 -0700 (PDT) Received: from [192.168.1.6] (unknown [122.53.41.246]) (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 38A201802AB9; Fri, 29 Apr 2016 04:23:04 +0200 (CEST) To: "mpls-chairs@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" From: Loa Andersson Message-ID: <5722C586.1020705@pi.nu> Date: Fri, 29 Apr 2016 10:23:02 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; 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: [mpls] IPR poll on draft-ietf-mpls-residence-time X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 02:23:09 -0000 Working Group, The authors of draft-ietf-mpls-residence-time has told us that the document is ready to be considered for working group last call. We will do an IPR poll prior to the start of the wg last call. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-residence-time? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). There is one IPR disclosure filed against the document that was replaced by the current draft. If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but 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. /Loa mpls wg co-chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Apr 28 19:33:09 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E2712B040; Thu, 28 Apr 2016 19:33:08 -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_H4=-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 9xPxo-9UOWN9; Thu, 28 Apr 2016 19:33:07 -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 327B812B02B; Thu, 28 Apr 2016 19:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1461897186; x=1463106786; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OB4VUxwtuUGP2UCZW5u2HC7K9ZSHRQlP6LR5CtzUrXU=; b=Q29IhgCEpYgUB9xiZItc8ZQCMAgT9BE7iP674to4LIO4w7TxmF7V1jm7 RLRmuJ2tlj34gUBROASTIpfKM2vm4QZX6LY2u0zgAJnmWAR4avITpyrzK cl14UOF9C1AX8Mr1JqzlXch9QQyRfWrvbIUJlF2yYXjwBCH1Ca0wjuNwS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgD+xiJX/4gNJK1egziBUAa5ZAENg?= =?us-ascii?q?XaGDwIcgQs4FAEBAQEBAQFlJ4RCAQEEIxE3AxkCAgEIGgImAgICGRcVEAIEARK?= =?us-ascii?q?IKrISkSYBAQEBAQEBAQEBAQEBAQEBAQEBFwR4hSWBdYJWhA8QAgEbF4JpK4IrB?= =?us-ascii?q?ZgRAY4WgWeETYhdjy8BHgEBQoNrbIZpfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,549,1454976000"; d="scan'208";a="265674493" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 02:33:05 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3T2X5em009573 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 02:33:05 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 22:33:04 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 22:33:04 -0400 From: "Tarek Saad (tsaad)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" Thread-Topic: working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJduGoSTVqYTy0W2LX3oTKJeqZ+gRbmA Date: Fri, 29 Apr 2016 02:33:04 +0000 Message-ID: <3944F7D7-C118-4CAE-BED0-E33210AF4811@cisco.com> References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.139] Content-Type: text/plain; charset="utf-8" Content-ID: <1018C10048F2A54687DA18EFA039D293@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 02:33:08 -0000 WWVzLCBzdXBwb3J0IHRoaXMgd29yayBhcyBiYXNpcyBmb3IgdGhlIHVzZWZ1bCB0b29scyBMU1Ag cGluZy90cmFjZXJvdXRlIGZvciBTUiBNUExTIGRhdGEgcGxhbmUgTFNQcy4NCg0KUmVnYXJkcywN ClRhcmVrDQoNCg0KDQoNCk9uIDIwMTYtMDQtMjIsIDk6MDIgQU0sICJMb2EgQW5kZXJzc29uIiA8 bG9hQHBpLm51PiB3cm90ZToNCg0KPldvcmtpbmcgR3JvdXAsDQo+DQo+VGhpcyBpcyB0byBzdGFy dCBhIHR3byB3ZWVrIHBvbGwgdG8gc2VlIGlmIHdlIGhhdmUgY29uc2Vuc3VzIHRvDQo+YWRvcHQg ZHJhZnQta3VtYXJraW5pLW1wbHMtc3ByaW5nLWxzcC1waW5nIGFzIGFuIE1QTFMgd29ya2luZw0K Pmdyb3VwIGRvY3VtZW50Lg0KPg0KPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQv bm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcNCj5ncm91cCBtYWlsaW5nIGxpc3QgKG1w bHNAaWV0Zi5vcmcpLiBQbGVhc2UgZ2l2ZSBhIHRlY2huaWNhbA0KPm1vdGl2YXRpb24gZm9yIHlv dXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdA0KPnRo ZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50Lg0KPg0KPlRoZXJlIGFyZSBubyBJUFIgZGlzY2xvc3VyZXMgYWdhaW5zdCB0aGlzIGRvY3Vt ZW50Lg0KPg0KPkFsbCB0aGUgYXV0aG9ycyBoYXMgc3RhdGVkIHRoYXQgdGhleSBhcmUgbm90IGF3 YXJlIG9mIGFueSBJUFJzIHRoYXQNCj5yZWxhdGUgdG8gdGhpcyBkb2N1bWVudC4gSW4gYWxsIGJ1 dCBvbmUgY2FzZSB0aGlzIGhhcyBiZWVuIGRvbmUgb24gdGhlDQo+b24gdGhlIG1wbHMgd2cgbWFp bGluZyBsaXN0LCBpbiB0aGUgbGFzdCBjYXNlIHRoaXMgaGFzIGJlZW4gc3RhdGVkIGluIGENCj5t YWlsIHRvIHRoZSB3ZyBjaGFpcnMuDQo+DQo+VGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gcG9s bCBlbmRzIE1heSA3LCAyMDE2Lg0KPg0KPi9Mb2ENCj4NCj5NUExTIHdnIGNvLWNoYWlyLg0KPi0t IA0KPg0KPg0KPkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tDQo+U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAg ICAgICAgICBsb2FAcGkubnUNCj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAg cGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCg== From nobody Thu Apr 28 19:36:41 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19ADF12D0AD; Thu, 28 Apr 2016 19:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6k-HonlCh-s; Thu, 28 Apr 2016 19:36:37 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 AB60E12B068; Thu, 28 Apr 2016 19:36:37 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x201so104871590oif.3; Thu, 28 Apr 2016 19:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5sB6Ua4S2ZroPLV1TCiu3vdjNC9YA6nxp/9cJ1131k4=; b=JWjhrm3S0n14dKS0/ESCzoX0063GEy/05yi/mt36+9e7B8rnCRku3eIsRk+ztyplo8 Mz163EZuM2UGJzhSpy9Pmk2d1cI3lYXMXSP/ladB51ul3h68Z2dtgnM0EcD4rsVdJe1K n9HuV/b0MTYHH7nwCUTIIo7l/Bhk/TBxRJX40kA7YLBESxiOGQbaaPYQgfVnkXWBoRQA r1eFab+WT3nrIev9LFyoJF5VEkzs0xZWfBq/D5eFbrDdfcgC9jrGXJyv7fUqZZECu1r4 VoNBNseoriPTSXH97kelAdyG/syOQ3hPmrY7AttgoFZJQ6DsuSygGh8RznbvfatsNYK9 KVJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5sB6Ua4S2ZroPLV1TCiu3vdjNC9YA6nxp/9cJ1131k4=; b=EJ40CNBoo4nWXduL2JgPLi43O+6wcGaHEEHStLLQBP1wixgv8BY9m8NrZzDdkvR+jw ZasIABRDW4X0F8Qtle2jilJoXcbgydxtcf+O3Iyfd/sWA0EELczPHu2+NhtBt1PsIMOH 7n9BxJj4dAa3IFu6kBH0SUxJgzzcC+Nr/OguiqmRaGrwwQ5ZYqDNPrJX6AxOJIysCDnX A1D52Y+i9tfLLc+Hu0BdKc5sAaxQwqSUvx2mlV+UY6DveHQ6+wPYoeI6vR2qMTaXxHuo /Ef9Dq1PrX7laq6s5QHSjkEs33rGi7G4YeUYFVPKc1R3+FMMrnKAIWl2QOk4TOP/IPfA 9dmA== X-Gm-Message-State: AOPr4FUoMQebJD2rIpnJCr/SJaT4Q/gLYTnJOA0Khra4qWSUVS8IZxMdCMlFnhgdfWbzRtMrjjdln3oB4loHkQ== X-Received: by 10.202.64.132 with SMTP id n126mr7482581oia.80.1461897397122; Thu, 28 Apr 2016 19:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Thu, 28 Apr 2016 19:36:07 -0700 (PDT) In-Reply-To: <571EF6B9.403@pi.nu> References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com> <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <571EF6B9.403@pi.nu> From: Sri Date: Thu, 28 Apr 2016 19:36:07 -0700 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a113d76f40dbf760531968351 Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 02:36:40 -0000 --001a113d76f40dbf760531968351 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Loa, I agree that changing it to informational while retaining the SHOULDs is the right way. That should address similar comments by Stewart, George, Greg and Carlos. Thanks Sri On Mon, Apr 25, 2016 at 10:03 PM, Loa Andersson wrote: > Greg, > > (talking about the SHOULDs in Section 4 only) > > I think what George (and Stewart) says is that since the document does > not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an > Informational RFC. > > However, it does not work to turn that argument around and say that an > Informational RFC can't use the normative language, it was doen for > example in RFC 7412. > > I think we should change it to Informational, but there is no need to > do anything to the SHOULDs in section 4. > > /Loa > > On 2016-04-26 03:19, Gregory Mirsky wrote: > >> Hi George, et. al, >> >> I=E2=80=99ve found several occurrences, three actually, of SHOULD being = used in >> Section 4. >> >> And I agree with Stewart that application of is the local >> decision and, at most, this work can be published as Informational. >> >> One comment, suggestion: >> >> =C2=B7the sample algorithm in Section 4 suggests that the same = tuple >> been used multiple times whereas it may be advantageous to generalize >> and point that the different entropy label value may be used by >> referring to the tuple as >> >> Regards, >> >> Greg >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow >> *Sent:* Monday, April 25, 2016 10:57 AM >> *To:* Stewart Bryant >> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; >> mpls@ietf.org; mpls-chairs@ietf.org >> *Subject:* Re: [mpls] working group last call on >> draft-ietf-mpls-spring-entropy-label >> >> Stewart - >> >> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant >> > wrote: >> >> I support this becoming a WG doc and thereby comming under WG >> control. >> >> The document is a WG doc. We are now in WG last call. >> >> However I am not sure about the dismissal of the option to reuse >> the ELI+EL. This clutters the stack less than the proposed option. >> >> Also I wonder why this is standards track? >> >> A reasonable question, particularly since there are no MUSTs, SHALLs or >> REQUIREDs. Will discuss with my Co-Chairs and ADs. >> >> Surely any equipment that understands the ELI can do this and thus >> this is just an informal description of the problem and a solution. >> >> Stewart >> >> >> >> On 23/04/2016 08:53, Loa Andersson wrote: >> >> Working Group, >> >> This is to initiate a two week working group last call on >> draft-ietf-mpls-spring-entropy-label. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org >> ). >> >> There are no IPR disclosures against this document. >> >> All the authors and contributors (with one exception) have stated on >> the working group mailing list that they are not aware of any other >> IPRs that relates to this draft. >> >> This working group last call ends May 12, 2016. >> >> >> /Loa >> for the MPLS wg chairs >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> --001a113d76f40dbf760531968351 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa, I agree that changing it to informational while re= taining the SHOULDs is the right way. That should address similar comments = by Stewart, George, Greg and Carlos.

Thanks
Sr= i

On M= on, Apr 25, 2016 at 10:03 PM, Loa Andersson <loa@pi.nu> wrote:
=
Greg,

(talking about the SHOULDs in Section 4 only)

I think what George (and Stewart) says is that since the document does
not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an
Informational RFC.

However, it does not work to turn that argument around and say that an
Informational RFC can't use the normative language, it was doen for exa= mple in RFC 7412.

I think we should change it to Informational, but there is no need to
do anything to the SHOULDs in section 4.

/Loa

On 2016-04-26 03:19, Gregory Mirsky wrote:
Hi George, et. al,

I=E2=80=99ve found several occurrences, three actually, of SHOULD being use= d in
Section 4.

And I agree with Stewart that application of <ELI, EL> is the local decision and, at most, this work can be published as Informational.

One comment, suggestion:

=C2=B7the sample algorithm in Section 4 suggests that the same <ELI,EL&g= t; tuple
been used multiple times whereas it may be advantageous to generalize
and point that the different entropy label value may be used by
referring to the tuple as <ELI, ELn>

Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg

 *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow
*Sent:* Monday, April 25, 2016 10:57 AM
*To:* Stewart Bryant
*Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org= ;
mpls@ietf.org; mpls-chairs@ietf.org
*Subject:* Re: [mpls] working group last call on
draft-ietf-mpls-spring-entropy-label

Stewart -

On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant
 <stewart.b= ryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:

I support this becoming a WG doc and thereby comming under WG
control.

The document is a WG doc.=C2=A0 =C2=A0We are now in WG last call.

=C2=A0 =C2=A0 However I am not sure about the dismissal of the option to re= use
=C2=A0 =C2=A0 the ELI+EL. This clutters the stack less than the proposed op= tion.

=C2=A0 =C2=A0 Also I wonder why this is standards track?

A reasonable question, particularly since there are no MUSTs, SHALLs or
REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs.

=C2=A0 =C2=A0 Surely any equipment that understands the ELI can do this and= thus
=C2=A0 =C2=A0 this is just an informal description of the problem and a sol= ution.

=C2=A0 =C2=A0 Stewart



=C2=A0 =C2=A0 On 23/04/2016 08:53, Loa Andersson wrote:

=C2=A0 =C2=A0 Working Group,

=C2=A0 =C2=A0 This is to initiate a two week working group last call on
=C2=A0 =C2=A0 draft-ietf-mpls-spring-entropy-label.

=C2=A0 =C2=A0 Please send your comments to the mpls wg mailing list (mpls@ietf.org
=C2=A0 =C2=A0 <mailto:mpls@ietf.org>).

=C2=A0 =C2=A0 There are no IPR disclosures against this document.

=C2=A0 =C2=A0 All the authors and contributors (with one exception) have st= ated on
=C2=A0 =C2=A0 the working group mailing list that they are not aware of any= other
=C2=A0 =C2=A0 IPRs that relates to this draft.

=C2=A0 =C2=A0 This working group last call ends May 12, 2016.


=C2=A0 =C2=A0 /Loa
=C2=A0 =C2=A0 for the MPLS wg chairs



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


--001a113d76f40dbf760531968351-- From nobody Thu Apr 28 19:41:59 2016 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94212B068; Thu, 28 Apr 2016 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr6NtVwEYedw; Thu, 28 Apr 2016 19:41:55 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 6454912B040; Thu, 28 Apr 2016 19:41:55 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x201so104962524oif.3; Thu, 28 Apr 2016 19:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OYy5uVn/28DzZPi2TSapvqUnIQQKxFwhxeaaugRcisQ=; b=VOZkDwdx14+gRgCgM+IiQWCVIPHIyncrT6vdyFcArWTf9aw7y7VTn9Y5B39L9RRLQ8 yODkT/OYkNYgXLFno1DbGIuigJHuT94oRd82kkE5dTNPgsgucuzeeDtrzS5eea+ZNCj6 ba3/t7M1RXAQLuaj7LuUd0gTj71T4BeQT2+Y4WCjbmSF8/NAybj8+tgt4P7+nyP7f6Re rUQzEe/tyKRShzPPVd62qb1Qg6SqJmstU5HZfZQukig5+j/J5V5YS/Qb7jgfx4e+pFYk NwBpGKLnmlk+QPwK45aFxyO4dajCK4V7uNwW9jDgb8cz5/Te+yycFXRMZemp/ZC+Pjn3 SvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OYy5uVn/28DzZPi2TSapvqUnIQQKxFwhxeaaugRcisQ=; b=hyUmLYRDW8n7LNjlW9oV5JmsAvMdCZQrFyCQpNshpgsXDoEhwzB7NlXS/eGw4X1nsF 9Y+IeUkdvGRzzYgllC2RtOMqPFpkLsjtqcBzSbJqr9TAVcdaZqVk9BtHP3NdUQhUVNLP IzA2keLuYgpMWuIKVn/FFpzPWDdDDfagAbsrOwVZz1XRTzTbq3SQjGqlHAWVyoBDn8Jw k4TxoQ4QAvvgPyYGTDbJ1m270Oj5nNsEQq+V5ed89n2x/Gp4+EBIkP5hrglGbQhHsfM7 hhTE+Y4XKlFo9h9yGSdj9PP5lD0btsLEnaRApcoLyP901fkf8dD8Qmm6dfJuHcts9yPN CHfA== X-Gm-Message-State: AOPr4FWkVATS7tfFQqQLA96gryjBnRzCd/aLS3miygPQKLFo1Msm28JwEOCR+i8toMDZcSDlwWDI+H2Y/FX+Aw== X-Received: by 10.157.37.98 with SMTP id j31mr8931248otd.3.1461897714749; Thu, 28 Apr 2016 19:41:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.223.213 with HTTP; Thu, 28 Apr 2016 19:41:25 -0700 (PDT) In-Reply-To: References: <571B29F8.1060301@pi.nu> From: Sri Date: Thu, 28 Apr 2016 19:41:25 -0700 Message-ID: To: George Swallow Content-Type: multipart/alternative; boundary=001a113cd9d4fc5af8053196953a Archived-At: Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 02:41:58 -0000 --001a113cd9d4fc5af8053196953a Content-Type: text/plain; charset=UTF-8 Hi George, Thanks for the review comments. I accept the comments, but see inline. On Mon, Apr 25, 2016 at 11:24 AM, George Swallow wrote: > I support the document going forward as "Informational" and have the > following comments: > Sri> Accepted > > Section 5.4 para 1 > > OLD: > > protocol such as an IGP. For the same Section 3 above, if LSR P1 > > NEW: > > protocol such as an IGP. > > > > Applying this method to the example in Section 3 above, if LSR P1 > > Sri> Accepted > Section 5.4 para > > OLD: > > A variant of this solution was selected which balances the number of > labels that need to be pushed against the requirement for entropy. > > NEW: > > > > Note that as refinement of this solution which balances the number of > pushed labels against the desired entropy is the solution described in Section 4. > > > Sri> Accepted. I think the "as refinement" was a typo and it should be "a refinement". If it is not pls let me know. > > > On Sat, Apr 23, 2016 at 3:53 AM, Loa Andersson wrote: > >> Working Group, >> >> This is to initiate a two week working group last call on >> draft-ietf-mpls-spring-entropy-label. >> >> Please send your comments to the mpls wg mailing list (mpls@ietf.org). >> >> There are no IPR disclosures against this document. >> >> All the authors and contributors (with one exception) have stated on >> the working group mailing list that they are not aware of any other >> IPRs that relates to this draft. >> >> This working group last call ends May 12, 2016. >> >> >> /Loa >> for the MPLS wg chairs >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Thanks Sri --001a113cd9d4fc5af8053196953a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi George,

Thanks for the review commen= ts. I accept the comments, but see inline.
=
On Mon, Apr 25, 2016 at 11:24 AM, George Swa= llow <swallow.ietf@gmail.com> wrote:
I support the document going for= ward as "Informational" and have the following comments:

Sri> Accepted
= =C2=A0

<= /div>Section 5.4 para 1

OLD:
   protocol such as an IG=
P.  For the same Section 3 above, if L=
SR P1

NEW:  
   protocol such as an IGP.
<NEW PARAGRAPH>
   Applying this method to =
the example in Section 3 above, if LSR P1

<= div>
Sri> Accepted
=C2=A0
Section 5.4 para 
<=
pre>OLD:

   A variant of this solution was selected which balances t=
he number of
   labels that need to be pushed against the requirement for entropy.
NEW:
<move this para above para 2>
   Note that as refinement of this solution which balances the number of
   pushed labels against the desired entropy is the solution described in S=
ection 4.

Sri> Accepted.=
 I think the "as refinement" was a typo and it should be "a =
refinement". If it is not pls let me know.
=C2=A0

=


On Sat, Apr 23, 2016 at 3:53 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,



This is to initiate a two week working group last call on

draft-ietf-mpls-spring-entropy-label.



Please send your comments to the mpls wg mailing list (mpls@ietf.org).



There are no IPR disclosures against this document.



All the authors and contributors (with one exception) have stated on

the working group mailing list that they are not aware of any other

IPRs that relates to this draft.



This working group last call ends May 12, 2016.





/Loa

for the MPLS wg chairs

-- 





Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu

Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739=
 81 21 64






_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls



Thanks
Sri


--001a113cd9d4fc5af8053196953a--


From nobody Thu Apr 28 22:16:30 2016
Return-Path: 
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59512D0A9; Thu, 28 Apr 2016 22:16:27 -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: <20160429051627.23551.81912.idtracker@ietfa.amsl.com>
Date: Thu, 28 Apr 2016 22:16:27 -0700
Archived-At: 
Cc: mpls@ietf.org
Subject: [mpls] I-D Action: draft-ietf-mpls-residence-time-09.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 05:16:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Residence Time Measurement in MPLS network
        Authors         : Greg Mirsky
                          Stefano Ruffini
                          Eric Gray
                          John Drake
                          Stewart Bryant
                          Alexander Vainshtein
	Filename        : draft-ietf-mpls-residence-time-09.txt
	Pages           : 27
	Date            : 2016-04-28

Abstract:
   This document specifies G-ACh based Residence Time Measurement and
   how it can be used by time synchronization protocols being
   transported over MPLS domain.

   Residence time is the variable part of propagation delay of timing
   and synchronization messages and knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a PTP event
   message.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-residence-time-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Apr 28 22:28:02 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3312D0AD; Thu, 28 Apr 2016 22:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 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, 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 2SDcL7SaB0qY; Thu, 28 Apr 2016 22:27:58 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD3612B01F; Thu, 28 Apr 2016 22:27:58 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-c3-5722e990a852
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AE.8B.09012.099E2275; Fri, 29 Apr 2016 06:56:48 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Fri, 29 Apr 2016 01:27:57 -0400
From: Gregory Mirsky 
To: Loa Andersson , "mpls-chairs@ietf.org" ,  "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" 
Thread-Topic: IPR poll on draft-ietf-mpls-residence-time
Thread-Index: AQHRob4YNm044eoTq0asLv0JLoPafJ+gazkQ
Date: Fri, 29 Apr 2016 05:27:48 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A62E65@eusaamb103.ericsson.se>
References: <5722C586.1020705@pi.nu>
In-Reply-To: <5722C586.1020705@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPlO6El0rhBgdXaFrc+3yb0eLf3DnM Fusun2KzuLV0JasDi8eSJT+ZPGZNb2Pz+HL5M1sAcxSXTUpqTmZZapG+XQJXRsv/i6wFP4Qq +r+fZ25g3CHUxcjJISFgInGzbzY7hC0mceHeerYuRi4OIYGjjBIt71rZIZzljBJbzp9nBali EzCSeLGxBywhInCFUaL3xDywhLCAucS+g2+YQWwRAQuJtt0d7BC2kcTJ46fZQGwWAVWJZ63T WUBsXgFfiT3n14P1CgmoSGzduRPM5gSqubn2GlgNI9BJ30+tYQKxmQXEJW49mc8EcaqAxJI9 55khbFGJl4//sULYShIff88H2ssBVK8psX6XPkSrosSU7ofsEGsFJU7OfMIygVF0FpKpsxA6 ZiHpmIWkYwEjyypGjtLigpzcdCODTYzAWDkmwaa7g/H+dM9DjAIcjEo8vAvyFMOFWBPLiitz DzFKcDArifBue6sULsSbklhZlVqUH19UmpNafIhRmoNFSZxX7BFQtUB6YklqdmpqQWoRTJaJ g1OqgdHqZObXJMM5VVd1WOQW2ZWdevPksxbPpH3v1ZnOZ0y0TZq9r4PN5ziPesyssz8i8nK5 3+RfLjjYHSEXOkH12HSxpXvPzNl16fL/2aqLPiQ9eDS9vaE5KvXE9B08G6rPqqxZw2JVs9Mo v7wo3t/FydjAxKl7W37+8kvhNztZ1QL+LBAoElhz7q8SS3FGoqEWc1FxIgCdTDT8kQIAAA==
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 05:28:01 -0000

SGkgTG9hLCBldC4gYWwsDQpJIGtub3cgb2YgdGhlIElQUiBkaXNjbG9zdXJlIGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI2MjYvIHRoYXQgaXMgcmVsYXRlZCB0byB0aGUgZHJhZnQt
bWlyc2t5LW1wbHMtcmVzaWRlbmNlLXRpbWUgIGFuZCB3YXMgc3VibWl0dGVkIG9uIEp1bHkgMTAs
IDIwMTUuDQoNCglSZWdhcmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBpLm51XSANClNlbnQ6IFRodXJzZGF5
LCBBcHJpbCAyOCwgMjAxNiA3OjIzIFBNDQpUbzogbXBscy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNA
aWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZUB0b29scy5pZXRmLm9yZw0K
U3ViamVjdDogSVBSIHBvbGwgb24gZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lDQoNCldv
cmtpbmcgR3JvdXAsDQoNClRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2Ut
dGltZSBoYXMgdG9sZCB1cyB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRl
cmVkIGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4NCg0KV2Ugd2lsbCBkbyBhbiBJUFIgcG9s
bCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHdnIGxhc3QgY2FsbC4NCg0KVGhpcyBtYWlsIHN0
YXJ0cyB0aGUgSVBSIHBvbGwuDQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxp
ZXMgdG8gZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10aW1lPw0KDQpJZiBzbywgaGFzIHRoaXMg
SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl
IFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0KVGhl
cmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGFnYWluc3QgdGhlIGRvY3VtZW50IHRoYXQg
d2FzIHJlcGxhY2VkIGJ5IHRoZSBjdXJyZW50IGRyYWZ0Lg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBh
cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlz
IGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkg
cmVsZXZhbnQgSVBSLiAqVGhlIHJlc3BvbnNlIG5lZWRzIHRvIGJlIHNlbnQgdG8gdGhlIE1QTFMg
d2cgbWFpbGluZyBsaXN0LiogVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l
eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0
aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0aGUgTVBMUyBXRyBlbWFpbCBs
aXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4g
cGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQ
UiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVU
RiBydWxlcy4NCg0KDQovTG9hDQptcGxzIHdnIGNvLWNoYWlyDQotLSANCg0KDQpMb2EgQW5kZXJz
c29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0K
U2VuaW9yIE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1
YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2
NA0K


From nobody Fri Apr 29 02:35:05 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4331B12D788; Fri, 29 Apr 2016 02:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqXVg23zQxaS; Fri, 29 Apr 2016 02:35:02 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 5837C12D77B; Fri, 29 Apr 2016 02:35:02 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id g17so26484354wme.1; Fri, 29 Apr 2016 02:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=hbBX1ilHs7TS3yV5rkVASy735jcZVBVQ0ulKzQoTj8s=; b=KlbWufjJN3jU7IFebJlHTmbaE9FopSmHYM5ZLIA1UMLPaD7lk8c8Xq79Edc3AJHwp2 4aZmflPGuXH6eZLnM+A4HBqmmLIoEcXvIFi2fc8KdK4Rd0b6U7gws0/L7C/lfgwMotlI h92MWekauW9O2S4hxqp0bENg41MeKlG6qsfz617fD+//TBaAZrcatyT9oaS6T+bmc7s1 MoXXKu5t2gM1r8FNFGxdXXC5OSZRACyma+WZMOhwpay1fTKQ0jaRLOsN5pRjn0xrCqU9 zb542Td0g4VMaQ0bBAHtCsWbiSYItUR7q1DNIBcAkxmlIVI/NNCLFPayCggl81dszaF8 /alA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hbBX1ilHs7TS3yV5rkVASy735jcZVBVQ0ulKzQoTj8s=; b=GxdMDP27o2XkuDcUqyyqrbS1pjUSMtLSn4vs6Jle1P2vKOoAd8lsiol9Xm5soH1BUf U+/0i+KlORVbEmguIgRaF5eG7+za6CZ7q+wLrjVSs9FnCAs+7+Bzzf/7tQzMfQ2TWHNh s6JAysYn2cdqRSyOcrLqfdljj8cOgWUewVrHYhUzMu5x+fvsrqC5cV+/eq1t61hOpPyf m8ZJp8DT56F+YACpAeL77VCbniyus2t0p8eNMERgeUvYgSbnOLhrzjWEKoLdq9wdAbGe W3R9vjrUR+gPbLx7/mrEsNe4xioRT78yIL0iFLYP9MtMqhSha2i3mPXqK6120CIO+egX L8Ww==
X-Gm-Message-State: AOPr4FXzOvLaHhfllybFkmxbC1IqpzzIV7nGe6byev+VHCphL3FIL6ydHLY1h8kLi5StaA==
X-Received: by 10.194.172.228 with SMTP id bf4mr20525515wjc.123.1461922500981;  Fri, 29 Apr 2016 02:35:00 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c16sm2393926wme.16.2016.04.29.02.34.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 02:35:00 -0700 (PDT)
To: Loa Andersson , "mpls-chairs@ietf.org" ,  "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" 
References: <5722C586.1020705@pi.nu>
From: Stewart Bryant 
Message-ID: <57232AC2.7000906@gmail.com>
Date: Fri, 29 Apr 2016 10:34:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5722C586.1020705@pi.nu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 09:35:04 -0000

I am not aware of any IPR related to this draft other than that already 
declared.

Stewart

On 29/04/2016 03:23, Loa Andersson wrote:
> Working Group,
>
> The authors of draft-ietf-mpls-residence-time has told us that
> the document is ready to be considered for working group last call.
>
> We will do an IPR poll prior to the start of the wg last call.
>
> This mail starts the IPR poll.
>
> Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> There is one IPR disclosure filed against the document that was
> replaced by the current draft.
>
> If you are listed as a document author or contributor please respond to
> this email regardless of whether or not you are aware of any relevant
> IPR. *The response needs to be sent to the MPLS wg mailing list.* The
> document will not advance to the next stage until a response has been
> received from each author and contributor.
>
> If you are on the MPLS WG email list but 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.
>
>
> /Loa
> mpls wg co-chair


From nobody Fri Apr 29 03:29:55 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB512D5F8; Fri, 29 Apr 2016 03:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level: 
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IX3Y4pAm4TXT; Fri, 29 Apr 2016 03:29:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0F64E12D5ED; Fri, 29 Apr 2016 03:29:45 -0700 (PDT)
Received: from localhost (h-186-70.a165.priv.bahnhof.se [109.228.186.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 7A1F31AE0119; Fri, 29 Apr 2016 12:29:43 +0200 (CEST)
Date: Fri, 29 Apr 2016 12:29:43 +0200 (CEST)
Message-Id: <20160429.122943.1926404425708749601.mbj@tail-f.com>
To: tsaad@cisco.com
From: Martin Bjorklund 
In-Reply-To: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com>
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [mpls] [netmod] Use of schema mounts for common model
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 10:29:53 -0000

IlRhcmVrIFNhYWQgKHRzYWFkKSIgPHRzYWFkQGNpc2NvLmNvbT4gd3JvdGU6DQo+IEhpIGF1dGhv
cnMvV0csDQo+IA0KPiBJbiBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZSwgd2UgYXJlIGRyaXZpbmcg
dGhlIGRlZmluaXRpb24gZm9yIGENCj4gZ2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21h
eSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQgd2hlbg0KPiBuZWNlc3NhcnkpIGZvciBkaWZmZXJlbnQg
ZGF0YSBwbGFuZSB0ZWNobm9sb2dpZXMgKGUuZy4gTVBMUywgT1ROLCBXRE0sDQo+IGV0Yy4pLg0K
PiBSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBpZGVhIHByZXNlbnRlZCBpbg0KPiBkcmFmdC1p
ZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQsIHdlIGFyZSB0aGlua2luZyB0aGlzIHByb3Bvc2FsIGlz
DQo+IHVzZWZ1bCBhbmQgY2FuIGZhY2lsaXRhdGUgdGhlIHJldXNlIG9mIHRoZSBvdXIgbW9kZWwg
aW4gbXVsdGlwbGUNCj4gcGxhY2VzIGluIHRoZSBZQU5HIHRyZWUgKG9uY2UgcGVyIGVhY2ggdGVj
aG5vbG9neSksIGUuZy46DQo+IOKApi9tcGxzL21vdW50LXBvaW50cy9tb3VudC1wb2ludC9tb2R1
bGU9aWV0Zi10ZS55YW5nDQo+IOKApi9vdG4vbW91bnQtcG9pbnRzL21vdW50LXBvaW50L21vZHVs
ZT1pZXRmLXRlLnlhbmcNCg0KU2NoZW1hIG1vdW50IGlzIHByb2JhYmx5IG5vdCB0aGUgcmlnaHQg
c29sdXRpb24gdG8geW91ciBwcm9ibGVtLiAgSQ0KdGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4g
eW91ciBjYXNlIGlzIHRvIGRlZmluZSBncm91cGluZ3MuDQpHcm91cGluZ3MgYXJlIGRlc2lnbmVk
IHRvIGJlIHJlLXVzZWQgYXQgZGlmZmVyZW50IHBsYWNlcyBpbiB0aGUNCmhpZXJhcmNoeS4NCg0K
PiBXZSBoYXZlIGEgY29tbWVudC9jb25jZXJuL3N1Z2dlc3Rpb24gYW5kIHdlIHZhbHVlIHlvdXIg
ZmVlZGJhY2suDQo+IA0KPiBUaGUgZ2VuZXJpYyBURSBtb2RlbCBjdXJyZW50bHkgcmVmZXJlbmNl
cyBkYXRhIG5vZGVzIGluIHRoZSBnbG9iYWwNCj4gdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWlu
dGVyZmFjZXMgbW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCj4gcHJvcGVydGllcyBhc3Nv
Y2lhdGVkIHdpdGggYSBzcGVjaWZpYyBkZXZpY2UgaW50ZXJmYWNlKS4gT3VyDQo+IHVuZGVyc3Rh
bmRpbmcgYWZ0ZXIgcmVhZGluZyBzZWN0aW9uIDMuMSBvZiB5b3VyIGRyYWZ0IGlzIHRoZSBtb3Vu
dGVkDQo+IG1vZGVsIGNhbiAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0
aGUgc2NvcGUgb2YgdGhlDQo+IG1vdW50LXBvaW50IChlLmcuIGdsb2JhbCBkYXRhIG5vZGVzIGlu
IHRoZSB5YW5nIHRyZWUpLiBUaGlzIHBvc2VzIGENCj4gbGltaXRhdGlvbiBmb3IgdXMsIGRvIHlv
dSBoYXZlIGEgc3VnZ2VzdGlvbiBmb3IgdGhpcyBwcm9ibGVtPw0KPiANCj4gT25lIHBvc3NpYmxl
IHNvbHV0aW9uIHdlIHRob3VnaHQgb2Ygd2FzIHRvIHJlcGxhY2UgdGhlIGxlYWYtcmVmcw0KPiBw
b2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEgbm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3
aXRoIGNvbnRleHQNCj4gbmFtZXMgKGUuZy4gdGhlIGludGVyZmFjZSBuYW1lKS4uIFRoaXMgZGVj
b3VwbGVzIHRoZSBkYXRhLW5vZGVzDQo+IGRlZmluZWQgaW4gdGhlIFRFIGdlbmVyaWMgbW9kZWwg
ZnJvbSB0aG9zZSBpbiB0aGUgZ2xvYmFsIHRyZWUNCj4gKGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZh
Y2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZlZWRiYWNrIG9uDQo+IHRoaXMgb3IgYmV0
dGVyIHN1Z2dlc3Rpb25zPw0KDQpJZiB5b3UgdXNlIGdyb3VwaW5ncyBpbnN0ZWFkLCB5b3UgY2Fu
IHN0aWxsIHVzZSBwcm9wZXIgbGVhZnJlZnMuDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gUmVn
YXJkcywNCj4gVGFyZWsNCj4gDQo+IEV4Y2VycHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hl
bWEtbW91bnQNCj4gDQo+IDMuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xPi4NCj4gQXVnbWVudCBhbmQgVmFs
aWRhdGlvbiBpbiBNb3VudGVkIERhdGENCj4gDQo+IA0KPiAgICBBbGwgcGF0aHMgKGluIGxlYWZy
ZWZzLCBpbnN0YW5jZS1pZGVudGlmaWVycywgWFBhdGggZXhwcmVzc2lvbnMsIGFuZA0KPiAgICB0
YXJnZXQgbm9kZXMgb2YgYXVnbWVudHMpIGluIHRoZSBkYXRhIG1vZGVscyBtb3VudGVkIGF0IGEg
bW91bnQgcG9pbnQNCj4gICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFz
IHRoZSByb290IG5vZGUsIGFuZCB0aGUNCj4gICAgbW91bnRlZCBkYXRhIG5vZGVzIGFzIGl0cyBj
aGlsZHJlbi4gIFRoaXMgbWVhbnMgdGhhdCBkYXRhIHdpdGhpbiBhDQo+ICAgIG1vdW50ZWQgc3Vi
dHJlZSBjYW4gbmV2ZXIgcmVmZXIgdG8gZGF0YSBvdXRzaWRlIG9mIHRoaXMgc3VidHJlZS4NCj4g
DQo+IA0KPiANCj4gDQo=


From nobody Fri Apr 29 05:11:36 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605A312D127; Fri, 29 Apr 2016 05:11:35 -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 gH7wG1LGqrul; Fri, 29 Apr 2016 05:11:28 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EA6312D1E9; Fri, 29 Apr 2016 05:11:27 -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=TxHvyHuqy1hhT1RmTXAfEdKYp5tQJWkx/5OdFufowlQ=; b=cwQ7c+6hfR/BkdWbYQ3JyJw2gaO31GfqrLI3jQk/2WwVROOxKh1tXzkdDoZV2kIKcvIvRbmcnP3gSEFVWYYWaklTWj+v0HZCtlSCyl0LG81r7g+h0F3gVwulBLI3AhgnW4p0FFFZkROj7v7Iv4qS2io1HcxIwqg+GAMBZ8PRcls=
Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1710.namprd05.prod.outlook.com (10.163.130.156) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 29 Apr 2016 12:11:08 +0000
Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0477.014; Fri, 29 Apr 2016 12:11:07 +0000
From: John E Drake 
To: Loa Andersson , "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" , "mpls-chairs@ietf.org" 
Thread-Topic: draft-ietf-mpls-residence-time
Thread-Index: AQHRob3D37dmQz/4w0OWmQFxCjJGn5+g3L5g
Date: Fri, 29 Apr 2016 12:11:07 +0000
Message-ID: 
References: <5722C4FA.5000802@pi.nu>
In-Reply-To: <5722C4FA.5000802@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 794dbee2-cbf3-4765-18d0-08d370275877
x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1710; 5:Ks1DoV57+dvY+mi652PMf4BS2iVqX9kyKGrPmSFn2oEk9gMB8wh5LyHX5McZV+XPSKd4l8d1SyIk/oSJgh7TluQdPduwQlxPquLrp0QOZSBBUb6YYYihn5WA5s34EJ7H6B8Y8Zoov9ZTH8N9ccMhsw==; 24:MGlQ6rzqmM0j0qlV25GcIdwsJkpDKNh6+MY3VBksMRGE2sCPOfyNdxosu/lpsPvrDTjvlXze37Tko+htLuwvwSPzuY8UIMc6SCc3hz98Lrc=; 7:AlqBonhGZGCV8DhXI/4kr+2fBDt8S8x9vEC83moCqjGVcb5QNPJ0W3zupMOyK77ProRBbdvBxpOUEUt3tBwHnuF7vvqHHhpAnuAotzt2pA54fWwSPBfDXvZsqwIpUV+ddyW61LqZmJM+uwqF7D3S2aEHA+IiawKAcGCvuzCuQzFHHZha260vdNDuRHT3TiXT
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1710;
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:SN1PR0501MB1710; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1710; 
x-forefront-prvs: 0927AA37C7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(252514010)(66066001)(10400500002)(87936001)(586003)(107886002)(77096005)(102836003)(6116002)(2906002)(3846002)(230783001)(54356999)(86362001)(2900100001)(2950100001)(76176999)(5001770100001)(5003600100002)(50986999)(2201001)(189998001)(3660700001)(3280700002)(1096002)(1220700001)(19580405001)(92566002)(122556002)(2501003)(19580395003)(99286002)(81166005)(106116001)(33656002)(9686002)(5004730100002)(5002640100001)(74316001)(5008740100001)(76576001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1710; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 12:11:07.7888 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1710
Archived-At: 
Subject: Re: [mpls] draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:11:35 -0000

SSdtIG5vdCBhd2FyZSBvZiBhbnkgdW5kaXNjbG9zZWQgSVBSLg0KDQpZb3VycyBJcnJlc3BlY3Rp
dmVseSwNCg0KSm9obg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExv
YSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAy
OCwgMjAxNiAxMDoyMSBQTQ0KPiBUbzogbXBsc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tcGxzLXJl
c2lkZW5jZS10aW1lQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJq
ZWN0OiBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUNCj4gDQo+IFdvcmtpbmcgR3JvdXAs
DQo+IA0KPiBUaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUgaGFz
IHRvbGQgdXMgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUNCj4gY29uc2lkZXJlZCBm
b3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwuDQo+IA0KPiBXZSB3aWxsIGRvIGFuIElQUiBwb2xs
IHByaW9yIHRvIHRoZSBzdGFydCBvZiB0aGUgd2cgbGFzdCBjYWxsLg0KPiANCj4gVGhpcyBtYWls
IHN0YXJ0cyB0aGUgSVBSIHBvbGwuDQo+IA0KPiBBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhh
dCBhcHBsaWVzIHRvIGRyYWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZT8NCj4gDQo+IElmIHNv
LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS
IHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5DQo+IGFuZCA1Mzc4IGZvciBtb3JlIGRl
dGFpbHMpLg0KPiANCj4gVGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGFnYWluc3Qg
dGhlIGRvY3VtZW50IHRoYXQgd2FzIHJlcGxhY2VkIGJ5IHRoZSBjdXJyZW50DQo+IGRyYWZ0Lg0K
PiANCj4gSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0
b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzDQo+IG9mIHdoZXRoZXIg
b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBu
ZWVkcyB0byBiZSBzZW50IHRvDQo+IHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1
bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UN
Cj4gaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQo+
IA0KPiBJZiB5b3UgYXJlIG9uIHRoZSBNUExTIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlz
dGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbg0KPiBwbGVhc2UgZXhwbGljaXRs
eSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5
ZXQgYmVlbiBkaXNjbG9zZWQgaW4NCj4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPiAN
Cj4gDQo+IC9Mb2ENCj4gbXBscyB3ZyBjby1jaGFpcg0KPiAtLQ0KPiANCj4gDQo+IExvYSBBbmRl
cnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29t
DQo+IFNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAgICAgICAgICAgICAgbG9hQHBpLm51
DQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4
MSAyMSA2NA0K


From nobody Fri Apr 29 05:17:03 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F6F12D139; Fri, 29 Apr 2016 05:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 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, 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 jwg0nSHNRQhk; Fri, 29 Apr 2016 05:16:59 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5238012D114; Fri, 29 Apr 2016 05:16:59 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-52-572350b98e81
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.BB.12516.9B053275; Fri, 29 Apr 2016 14:16:57 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.65]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Fri, 29 Apr 2016 14:16:57 +0200
From: Stefano Ruffini 
To: Stewart Bryant , Loa Andersson , "mpls-chairs@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" 
Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-residence-time
Thread-Index: AQHRob4WYvpAAaJQY06+RU3SDdDeW5+gj8YAgABObIA=
Date: Fri, 29 Apr 2016 12:16:56 +0000
Message-ID: <1B5CAFEB4D81154AA0F020783784C31516131798@ESESSMB301.ericsson.se>
References: <5722C586.1020705@pi.nu> <57232AC2.7000906@gmail.com>
In-Reply-To: <57232AC2.7000906@gmail.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7n+7OAOVwg87Fuhb3Pt9mtPg3dw6z xbrLp9gsbi1dyWpx6kGiA6vHzll32T2WLPnJ5DFrehubx5fLn9kCWKK4bFJSczLLUov07RK4 Mu4fWc1Y8Iu3Yu23k4wNjBO5uxg5OSQETCSmvu1ihrDFJC7cW8/WxcjFISRwhFFi3noYZzGj xIXz/WwgVWxAHc8Xr2YCSYgI/GeUmH6rhRUkISxgJ/H1wEYwW0TAXmLy6hZGCNtKYsbb6WA2 i4CqxKTz08DW8Qr4Skx5OosJxBYScJToXvUVzOYU0JTYcGMH2BxGAVmJCbsXgfUyC4hL3Hoy nwniVAGJJXvOQ50tKvHy8T9WCFtRYufZdmaIej2JG1OnsEHY2hLLFr6G2isocXLmE5YJjKKz kIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjK2DW37r7mBc/drx EKMAB6MSD2/CD6VwIdbEsuLK3EOMEhzMSiK8uu7K4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5 /V8qhgsJpCeWpGanphakFsFkmTg4pRoY5bz599lv+X/Ub8oxrtdarMvYC90iGllq/tycYJa9 IfNWzfzUbO6lH+2WKO5MObnuzyPP4lKT5JMrmouiY3zdzbs7va9Vvz96O/wmi+hS4xWe2iV/ TyXcs/A8mrTe7YnHc9u1B4MW1nArir6OcM+XsWnbslhuUraY2juBCMdfZyomqvd6nehTYinO SDTUYi4qTgQAYxoGlKkCAAA=
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:17:01 -0000

Hi,

same for me, I am not aware of any IPR related to this draft other than tha=
t already declared.

Best regards
stefano

-----Original Message-----
From: Stewart Bryant [mailto:stewart.bryant@gmail.com]=20
Sent: venerd=EC 29 aprile 2016 11:35
To: Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org; draft-ietf-mpls-res=
idence-time@tools.ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time

I am not aware of any IPR related to this draft other than that already dec=
lared.

Stewart

On 29/04/2016 03:23, Loa Andersson wrote:
> Working Group,
>
> The authors of draft-ietf-mpls-residence-time has told us that the=20
> document is ready to be considered for working group last call.
>
> We will do an IPR poll prior to the start of the wg last call.
>
> This mail starts the IPR poll.
>
> Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules=20
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> There is one IPR disclosure filed against the document that was=20
> replaced by the current draft.
>
> If you are listed as a document author or contributor please respond=20
> to this email regardless of whether or not you are aware of any=20
> relevant IPR. *The response needs to be sent to the MPLS wg mailing=20
> list.* The document will not advance to the next stage until a=20
> response has been received from each author and contributor.
>
> If you are on the MPLS WG email list but are not listed as an author=20
> or contributor, then please explicitly respond only if you are aware=20
> of any IPR that has not yet been disclosed in conformance with IETF rules=
.
>
>
> /Loa
> mpls wg co-chair


From nobody Fri Apr 29 05:47:31 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2CB12D663; Fri, 29 Apr 2016 05:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.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 cJculVK9sjTJ; Fri, 29 Apr 2016 05:47:28 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0105.outbound.protection.outlook.com [104.47.2.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E2212D12B; Fri, 29 Apr 2016 05:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ocr0pQpgggVzC99GhSXLyKc/veWp+46en7ym1MRvrtc=; b=LYFIhlgN83MIN/jLwSR+Qfs/uk+telWBDa2gCqoTxZNrruaGbosj639P5BbQLk16auLJw/YVktzLxjuM6qKAJ/QidOvwuOqe14DRF6B04R/Oq9SDUwnxoXYvNmuiSMwPwiXAL4pa9ppti5Py3kI41P4OY9f2WcJQ/dxcE9n8qF8=
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0778.eurprd03.prod.outlook.com (10.161.54.28) with Microsoft SMTP Server (TLS) id 15.1.466.19; Fri, 29 Apr 2016 12:47:24 +0000
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0466.028; Fri, 29 Apr 2016 12:47:24 +0000
From: Alexander Vainshtein 
To: Stefano Ruffini , Stewart Bryant , Loa Andersson , "mpls-chairs@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" 
Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-residence-time
Thread-Index: AQHRob4YXCOBOlVqhkOSjwiD9Gpdtp+gsU0AgAAtQQCAAAiErg==
Date: Fri, 29 Apr 2016 12:47:24 +0000
Message-ID: 
References: <5722C586.1020705@pi.nu> <57232AC2.7000906@gmail.com>, <1B5CAFEB4D81154AA0F020783784C31516131798@ESESSMB301.ericsson.se>
In-Reply-To: <1B5CAFEB4D81154AA0F020783784C31516131798@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ecitele.com;
x-originating-ip: [79.176.34.95]
x-ms-office365-filtering-correlation-id: 016aaffd-f2d9-42bd-04db-08d3702c69ce
x-microsoft-exchange-diagnostics: 1; DB3PR03MB0778; 5:a6UvDqtJs0VbDhvglLI8A8krBx7UVAl/XQlyo/eaMjjdp8n3s7qpZIX0qVbFJXYdvmgyoMfpoyX7rAlMW1u3h3KjNGQ36qe+Gnfouc8ndJ/FwUX0X/Cpw2TgVhDTka9gnK8N3r+0uFD1pmWJqJ7UMjcBQL9gnvBlY6PEfq79uwD3mPo5XnUyZgyDwJmVvcJh; 24:bX6K/5pO5AS8sXENeplBddeogM3vOzAemJjb68cJCi9cNKinJWh2hKnLqAWrrgObSGEikQllf2BZYnE31zTu1JQ1tk1Kp0oTtlaiHc6afJ0=; 7:+nKTbJV1imonfMxRvhhm2Xj0D0j3ZF0sw6mCN/epgR9OaEvI3S3aBbk1YmWZL5M31Jc6Vzr9ipMUtoPxDiJvNWaAToJA3B6DI3pKzEubQIl0k7FTMfB+iF60ysx/PnmRcyMC2+TPq/HBKgpOLhrHVYYJ231VP2IZE/k92ZRKZd8wWqlfU3RfDDUzRUJzZBDpR4k0SOwh8WFr6Rgp7Mh2djuYRgSC3qJlHp7+f5mydcM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0778;
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:DB3PR03MB0778; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0778; 
x-forefront-prvs: 0927AA37C7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(377454003)(24454002)(13464003)(5001770100001)(9686002)(95246002)(5002640100001)(586003)(3280700002)(107886002)(2501003)(3660700001)(5008740100001)(81166005)(5004730100002)(33646002)(122556002)(66066001)(10400500002)(1096002)(15975445007)(189998001)(2950100001)(2900100001)(77096005)(2906002)(106116001)(1220700001)(2201001)(86362001)(87936001)(63666004)(102836003)(6116002)(19580395003)(3846002)(11100500001)(50986999)(230783001)(76176999)(92566002)(54356999)(19580405001)(51650200001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0778; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 12:47:24.3634 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0778
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:47:30 -0000

Hi all,
Me too.
I am not aware of any IPR related to this draft other than that already dec=
lared.

Regards,
Sasha

-------- Original Message --------
From: Stefano Ruffini 
Date: Fri, April 29, 2016 3:17 PM +0300
To: Stewart Bryant , Loa Andersson , m=
pls-chairs@ietf.org, mpls@ietf.org, draft-ietf-mpls-residence-time@tools.ie=
tf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time


Hi,

same for me, I am not aware of any IPR related to this draft other than tha=
t already declared.

Best regards
stefano

-----Original Message-----
From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: venerd=EC 29 aprile 2016 11:35
To: Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org; draft-ietf-mpls-res=
idence-time@tools.ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time

I am not aware of any IPR related to this draft other than that already dec=
lared.

Stewart

On 29/04/2016 03:23, Loa Andersson wrote:
> Working Group,
>
> The authors of draft-ietf-mpls-residence-time has told us that the
> document is ready to be considered for working group last call.
>
> We will do an IPR poll prior to the start of the wg last call.
>
> This mail starts the IPR poll.
>
> Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> There is one IPR disclosure filed against the document that was
> replaced by the current draft.
>
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the MPLS wg mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
>
> If you are on the MPLS WG email list but 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=
.
>
>
> /Loa
> mpls wg co-chair

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


From nobody Fri Apr 29 05:58:17 2016
Return-Path: 
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 724A112B05C; Fri, 29 Apr 2016 05:58:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160429125816.12469.65250.idtracker@ietfa.amsl.com>
Date: Fri, 29 Apr 2016 05:58:16 -0700
Archived-At: 
Cc: mpls@ietf.org
Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 12:58:16 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
        Authors         : Kireeti Kompella
                          Carlos Pignataro
                          Nagendra Kumar
                          Sam Aldrin
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-mpls-rfc4379bis-03.txt
	Pages           : 55
	Date            : 2016-04-29

Abstract:
   This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in Multi-Protocol Label Switching
   (MPLS) Label Switched Paths (LSPs).  There are two parts to this
   document: information carried in an MPLS "echo request" and "echo
   reply" for the purposes of fault detection and isolation, and
   mechanisms for reliably sending the echo reply.

   This document obsoletes RFCs 4379 and 6829.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc4379bis-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 Fri Apr 29 09:17:39 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEE12D15E; Fri, 29 Apr 2016 09:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 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, 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 SxWDaSXYfjfe; Fri, 29 Apr 2016 09:17:21 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD3F12D147; Fri, 29 Apr 2016 09:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17876; q=dns/txt; s=iport; t=1461946640; x=1463156240; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DN2yQSt7utfpvgKgcKeFzJifVbBYp876IsrpWKjxu9Y=; b=CAh5SmprREyPbPtq4al1SIljgQWoKY4ogW2D14izHMCvoLjTlgZp166d VagvgNC+jXXw2IUl6lFo0GUBvKZYQsFw8rvC6yD6Af8MFvFtyR58VzDa8 ZGO+gm1YF1ZAwHgLIDWiAxxib/fTP7hQ9ORVtjlliS1JlI/BrXTFSwPUg o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAgDkhyNX/5hdJa1dgmxMU30GtHeEc?= =?us-ascii?q?wENgXYkhWwCHIEOOBQBAQEBAQEBZSeEQgEBBCNWEAIBCA4xAwICAjAUEQIEDgU?= =?us-ascii?q?biA8OszWRIgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdoJWhFSCaSuCKwWNV?= =?us-ascii?q?oVMhHEBhXuIG4FnhE2IXYYkiQsBHgEBQoIFG4FLbAGHRCUYAX4BAQE?=
X-IronPort-AV: E=Sophos; i="5.24,552,1454976000"; d="scan'208,217"; a="97431017"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 16:17:19 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3TGHJtj025505 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 16:17:19 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 12:17:17 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 12:17:18 -0400
From: "Tarek Saad (tsaad)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] Use of schema mounts for common model
Thread-Index: AQHRoYTn8Q7ybSBq9EC0qN+9tgYLnp+hBBqAgAAeDQA=
Date: Fri, 29 Apr 2016 16:17:18 +0000
Message-ID: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com>
In-Reply-To: <20160429.122943.1926404425708749601.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.213.64]
Content-Type: multipart/alternative; boundary="_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "netmod@ietf.org" , "teas@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" 
Subject: Re: [mpls] [netmod] Use of schema mounts for common model
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 16:17:24 -0000

--_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIE1hcnRpbiwgcGxlYXNlIHNlZSBpbmxpbmUuLg0KDQoNCk9uIDIwMTYtMDQtMjksIDY6
MjkgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWls
LWYuY29tPj4gd3JvdGU6DQoNCiJUYXJlayBTYWFkICh0c2FhZCkiIDx0c2FhZEBjaXNjby5jb208
bWFpbHRvOnRzYWFkQGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgYXV0aG9ycy9XRywNCkluIGRyYWZ0
LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJpdmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYQ0K
Z2VuZXJpYyBURSBZQU5HIG1vZGVsIHRoYXQgY2FuL21heSBiZSB1c2VkIChhbmQgZXh0ZW5kZWQg
d2hlbg0KbmVjZXNzYXJ5KSBmb3IgZGlmZmVyZW50IGRhdGEgcGxhbmUgdGVjaG5vbG9naWVzIChl
LmcuIE1QTFMsIE9UTiwgV0RNLA0KZXRjLikuDQpSZXZpZXdpbmcgdGhlIHNjaGVtYSBtb3VudCBp
ZGVhIHByZXNlbnRlZCBpbg0KZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LCB3ZSBhcmUg
dGhpbmtpbmcgdGhpcyBwcm9wb3NhbCBpcw0KdXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUg
cmV1c2Ugb2YgdGhlIG91ciBtb2RlbCBpbiBtdWx0aXBsZQ0KcGxhY2VzIGluIHRoZSBZQU5HIHRy
ZWUgKG9uY2UgcGVyIGVhY2ggdGVjaG5vbG9neSksIGUuZy46DQrigKYvbXBscy9tb3VudC1wb2lu
dHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0K4oCmL290bi9tb3VudC1wb2ludHMv
bW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZw0KDQpTY2hlbWEgbW91bnQgaXMgcHJvYmFi
bHkgbm90IHRoZSByaWdodCBzb2x1dGlvbiB0byB5b3VyIHByb2JsZW0uICBJDQp0aGluayBhIGJl
dHRlciBzb2x1dGlvbiBpbiB5b3VyIGNhc2UgaXMgdG8gZGVmaW5lIGdyb3VwaW5ncy4NCkdyb3Vw
aW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUtdXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRo
ZQ0KaGllcmFyY2h5Lg0KDQpXZSB0aG91Z2h0IG9mIHRoaXMgZWFybGllciwgYW5kIGZvdW5kIGdy
b3VwaW5ncyBwb3NlIHRoZWlyIG93biBzZXQgb2YgY2hhbGxlbmdlcyB0b28uLiBTcGVjaWZpY2Fs
bHk6DQotIGEgZ3JvdXBpbmdzIHdpdGggbGVhZnJlZnMgY291bGQgbm90IHJlZmVyZW5jZSBkYXRh
IG5vZGVzIHRoYXQgcmVzaWRlIGluIGFub3RoZXIgZ3JvdXBpbmcNCi0gYSBncm91cGluZyB3aXRo
IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp
dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmcNCi0gdGhl
IGF1Z21lbnRhdGlvbiBvZiB0aGUgZ3JvdXBpbmcgYnkgb3RoZXIgbW9kdWxlcyBpcyBub3QgYXMg
c3RyYWlnaHRmb3J3YXJkDQoNClRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1z
IHRvDQoNCm9uZSBjb3VsZCBhbHNvIHRoaW5rIHRoYXQgd2l0aCBncm91cGluZ3Mgb25lIGNvdWxk
IGFkZHJlc3MgcmV1c2Ugb2YgdGhlIGEgbW9kZWwgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSBmb3Ig
bG9naWNhbCBkZXZpY2VzIG9yIFZNIChzZWUgYmVsb3cpLiBJbiBmYWN0LCBpbiB5b3VyIGRyYWZ0
IChzZWN0aW9uIDIpIHlvdSBleHBsaWNpdGx5IGRpc2NvdXJhZ2UgdGhpcyBhcHByb2FjaCBhcyBu
b3Qgc2NhbGFibGUgc29sdXRpb24NCg0KDQogICBXaXRoIHRoZSAidXNlcyIgYXBwcm9hY2gsIGll
dGYtaW50ZXJmYWNlcyB3b3VsZCBoYXZlIHRvIGRlZmluZSBhDQogICBncm91cGluZyB3aXRoIGFs
bCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXMNCiAgIHdv
dWxkIGhhdmUgdG8gdXNlIHRoaXMgZ3JvdXBpbmcuICBUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUg
c29sdXRpb24sDQogICBzaW5jZSBldmVyeSB0aW1lIHRoZXJlIGlzIGEgbmV3IG1vZGVsIGRlZmlu
ZWQsIHdlIHdvdWxkIGhhdmUgdG8NCiAgIHVwZGF0ZSBvdXIgbW9kZWwgZm9yIGxvZ2ljYWwgZGV2
aWNlcyB0byB1c2UgYSBncm91cGluZyBmcm9tIHRoZSBuZXcNCiAgIG1vZGVsLiAgQW5vdGhlciBw
cm9ibGVtIGlzIHRoYXQgdGhpcyBhcHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci0NCg0KDQoN
CldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUgeW91ciBm
ZWVkYmFjay4NClRoZSBnZW5lcmljIFRFIG1vZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEg
bm9kZXMgaW4gdGhlIGdsb2JhbA0KdHJlZSAoZS5nLiBmcm9tIHRoZSBpZXRmLWludGVyZmFjZXMg
bW9kZWwgdG8gZGVmaW5lIGFkZGl0aW9uYWwgVEUNCnByb3BlcnRpZXMgYXNzb2NpYXRlZCB3aXRo
IGEgc3BlY2lmaWMgZGV2aWNlIGludGVyZmFjZSkuIE91cg0KdW5kZXJzdGFuZGluZyBhZnRlciBy
ZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQNCm1vZGVsIGNh
biAqbm90KiByZWZlcmVuY2UgYW55IGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhl
DQptb3VudC1wb2ludCAoZS5nLiBnbG9iYWwgZGF0YSBub2RlcyBpbiB0aGUgeWFuZyB0cmVlKS4g
VGhpcyBwb3NlcyBhDQpsaW1pdGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9u
IGZvciB0aGlzIHByb2JsZW0/DQpPbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdodCBvZiB3
YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzDQpwb2ludGluZyB0byB0aGUgZ2xvYmFsIGRhdGEg
bm9kZXMgKGUuZy4gSWV0Zi1pbnRlcmZhY2VzKSB3aXRoIGNvbnRleHQNCm5hbWVzIChlLmcuIHRo
ZSBpbnRlcmZhY2UgbmFtZSkuLiBUaGlzIGRlY291cGxlcyB0aGUgZGF0YS1ub2Rlcw0KZGVmaW5l
ZCBpbiB0aGUgVEUgZ2VuZXJpYyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZQ0K
KGUuZy4gdGhlIGFjdHVhbCBpbnRlcmZhY2UgaWV0Zi1pbnRlcmZhY2VzIG1vZGVsKS4gQW55IGZl
ZWRiYWNrIG9uDQp0aGlzIG9yIGJldHRlciBzdWdnZXN0aW9ucz8NCg0KSWYgeW91IHVzZSBncm91
cGluZ3MgaW5zdGVhZCwgeW91IGNhbiBzdGlsbCB1c2UgcHJvcGVyIGxlYWZyZWZzLg0KDQpOb3Qg
aW4gYWxsIGNhc2VzIOKAlCBhcyBkZXNjcmliZWQgYWJvdmUuDQoNClJlZ2FyZHMsDQpUYXJlaw0K
DQoNCg0KL21hcnRpbg0KDQoNCg0KUmVnYXJkcywNClRhcmVrDQpFeGNlcnB0IGZyb20gZHJhZnQt
aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50DQozLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtbmV0bW9kLXNjaGVtYS1tb3VudC0wMSNzZWN0aW9uLTMuMT4uDQpBdWdtZW50
IGFuZCBWYWxpZGF0aW9uIGluIE1vdW50ZWQgRGF0YQ0KICAgIEFsbCBwYXRocyAoaW4gbGVhZnJl
ZnMsIGluc3RhbmNlLWlkZW50aWZpZXJzLCBYUGF0aCBleHByZXNzaW9ucywgYW5kDQogICAgdGFy
Z2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBhIG1v
dW50IHBvaW50DQogICAgYXJlIGludGVycHJldGVkIHdpdGggdGhlIG1vdW50IHBvaW50IGFzIHRo
ZSByb290IG5vZGUsIGFuZCB0aGUNCiAgICBtb3VudGVkIGRhdGEgbm9kZXMgYXMgaXRzIGNoaWxk
cmVuLiAgVGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGENCiAgICBtb3VudGVkIHN1YnRyZWUg
Y2FuIG5ldmVyIHJlZmVyIHRvIGRhdGEgb3V0c2lkZSBvZiB0aGlzIHN1YnRyZWUuDQoNCg==

--_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6B980E3C296CC94681706D4E9526FA79@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9u
dC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij4NCjxkaXY+VGhhbmtzIE1hcnRpbiwgcGxl
YXNlIHNlZSBpbmxpbmUuLjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B
VFVSRSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz
dHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsi
Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTog
Q29uc29sYXMsIG1vbm9zcGFjZTsiPk9uIDIwMTYtMDQtMjksIDY6MjkgQU0sICZxdW90O01hcnRp
biBCam9ya2x1bmQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJq
QHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTog
MTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48YnI+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i
Zm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVy
LWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsg
Ym9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdp
bjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2PiZxdW90O1RhcmVrIFNhYWQgKHRzYWFkKSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzYWFkQGNpc2NvLmNvbSI+dHNhYWRAY2lzY28uY29tPC9h
PiZndDsgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ
T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ
Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+SGkgYXV0aG9ycy9XRyw8L2Rpdj4N
CjxkaXY+PC9kaXY+DQo8ZGl2PkluIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLCB3ZSBhcmUgZHJp
dmluZyB0aGUgZGVmaW5pdGlvbiBmb3IgYTwvZGl2Pg0KPGRpdj5nZW5lcmljIFRFIFlBTkcgbW9k
ZWwgdGhhdCBjYW4vbWF5IGJlIHVzZWQgKGFuZCBleHRlbmRlZCB3aGVuPC9kaXY+DQo8ZGl2Pm5l
Y2Vzc2FyeSkgZm9yIGRpZmZlcmVudCBkYXRhIHBsYW5lIHRlY2hub2xvZ2llcyAoZS5nLiBNUExT
LCBPVE4sIFdETSw8L2Rpdj4NCjxkaXY+ZXRjLikuPC9kaXY+DQo8ZGl2PlJldmlld2luZyB0aGUg
c2NoZW1hIG1vdW50IGlkZWEgcHJlc2VudGVkIGluPC9kaXY+DQo8ZGl2PmRyYWZ0LWlldGYtbmV0
bW9kLXNjaGVtYS1tb3VudCwgd2UgYXJlIHRoaW5raW5nIHRoaXMgcHJvcG9zYWwgaXM8L2Rpdj4N
CjxkaXY+dXNlZnVsIGFuZCBjYW4gZmFjaWxpdGF0ZSB0aGUgcmV1c2Ugb2YgdGhlIG91ciBtb2Rl
bCBpbiBtdWx0aXBsZTwvZGl2Pg0KPGRpdj5wbGFjZXMgaW4gdGhlIFlBTkcgdHJlZSAob25jZSBw
ZXIgZWFjaCB0ZWNobm9sb2d5KSwgZS5nLjo8L2Rpdj4NCjxkaXY+4oCmL21wbHMvbW91bnQtcG9p
bnRzL21vdW50LXBvaW50L21vZHVsZT1pZXRmLXRlLnlhbmc8L2Rpdj4NCjxkaXY+4oCmL290bi9t
b3VudC1wb2ludHMvbW91bnQtcG9pbnQvbW9kdWxlPWlldGYtdGUueWFuZzwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2NoZW1hIG1vdW50IGlzIHByb2JhYmx5
IG5vdCB0aGUgcmlnaHQgc29sdXRpb24gdG8geW91ciBwcm9ibGVtLiZuYnNwOyZuYnNwO0k8L2Rp
dj4NCjxkaXY+dGhpbmsgYSBiZXR0ZXIgc29sdXRpb24gaW4geW91ciBjYXNlIGlzIHRvIGRlZmlu
ZSBncm91cGluZ3MuPC9kaXY+DQo8ZGl2Pkdyb3VwaW5ncyBhcmUgZGVzaWduZWQgdG8gYmUgcmUt
dXNlZCBhdCBkaWZmZXJlbnQgcGxhY2VzIGluIHRoZTwvZGl2Pg0KPGRpdj5oaWVyYXJjaHkuPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt
aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250
LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+V2UgdGhvdWdo
dCBvZiB0aGlzIGVhcmxpZXIsIGFuZCBmb3VuZCBncm91cGluZ3MgcG9zZSB0aGVpciBvd24gc2V0
IG9mIGNoYWxsZW5nZXMgdG9vLi4gU3BlY2lmaWNhbGx5OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91
cGluZ3Mgd2l0aCBsZWFmcmVmcyBjb3VsZCBub3QgcmVmZXJlbmNlIGRhdGEgbm9kZXMgdGhhdCBy
ZXNpZGUgaW4gYW5vdGhlciBncm91cGluZzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAx
MnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPi0gYSBncm91cGluZyB3aXRo
IGxlYWZyZWZzIG9mIHJlbGF0aXZlIHBhdGggd2VyZSBjaGFsbGVuZ2Ugd2hlbiB0aGUgcmVsYXRp
dmUgcGF0aCByZWZlcmVuY2VzIGRhdGEgbm9kZXMgb3V0c2lkZSB0aGUgZ3JvdXBpbmc8L2Rpdj4N
CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v
c3BhY2U7Ij4tIHRoZSBhdWdtZW50YXRpb24gb2YgdGhlIGdyb3VwaW5nIGJ5IG90aGVyIG1vZHVs
ZXMgaXMgbm90IGFzIHN0cmFpZ2h0Zm9yd2FyZDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXpl
OiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxicj4NCjwvZGl2Pg0K
PGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9z
cGFjZTsiPlRoYXQgc2FpZCwgdGhlIGdyb3VwaW5nIHByb3Bvc2FsIHNlZW1zIHRvJm5ic3A7PC9k
aXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywg
bW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZv
bnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+b25lIGNvdWxkIGFsc28gdGhpbmsgdGhh
dCB3aXRoIGdyb3VwaW5ncyBvbmUgY291bGQgYWRkcmVzcyByZXVzZSBvZiB0aGUgYSBtb2RlbCAo
ZS5nLiBJZXRmLWludGVyZmFjZXMpIGZvciBsb2dpY2FsIGRldmljZXMgb3IgVk0gKHNlZSBiZWxv
dykuIEluIGZhY3QsIGluIHlvdXIgZHJhZnQgKHNlY3Rpb24gMikgeW91IGV4cGxpY2l0bHkgZGlz
Y291cmFnZQ0KIHRoaXMgYXBwcm9hY2ggYXMgbm90IHNjYWxhYmxlIHNvbHV0aW9uPC9kaXY+DQo8
ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3Nw
YWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7IGZvbnQtZmFt
aWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9u
dCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tn
cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7V2l0aCB0aGUgJnF1
b3Q7dXNlcyZxdW90OyBhcHByb2FjaCwgaWV0Zi1pbnRlcmZhY2VzIHdvdWxkIGhhdmUgdG8gZGVm
aW5lIGE8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvbnNvbGFzLG1vbm9zcGFjZSIg
c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAw
KTsiPiZuYnNwOyAmbmJzcDtncm91cGluZyB3aXRoIGFsbCBpdHMgbm9kZXMsIGFuZCB0aGUgbmV3
IG1vZGVsIGZvciBsb2dpY2FsIGRldmljZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9
IkNvbnNvbGFzLG1vbm9zcGFjZSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI1NSwgMjU1LCAwKTsiPiZuYnNwOyAmbmJzcDt3b3VsZCBoYXZlIHRvIHVzZSB0
aGlzIGdyb3VwaW5nLiAmbmJzcDtUaGlzIGlzIGEgbm90IGEgc2NhbGFibGUgc29sdXRpb24sPC9m
b250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxtb25vc3BhY2UiIHN0eWxlPSJm
b250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJz
cDsgJm5ic3A7c2luY2UgZXZlcnkgdGltZSB0aGVyZSBpcyBhIG5ldyBtb2RlbCBkZWZpbmVkLCB3
ZSB3b3VsZCBoYXZlIHRvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyxt
b25vc3BhY2UiIHN0eWxlPSJmb250LXNpemU6IDEycHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NTUsIDI1NSwgMCk7Ij4mbmJzcDsgJm5ic3A7dXBkYXRlIG91ciBtb2RlbCBmb3IgbG9naWNhbCBk
ZXZpY2VzIHRvIHVzZSBhIGdyb3VwaW5nIGZyb20gdGhlIG5ldzwvZm9udD48L2Rpdj4NCjxkaXY+
PGZvbnQgZmFjZT0iQ29uc29sYXMsbW9ub3NwYWNlIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+
PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMCk7Ij4mbmJzcDsg
Jm5ic3A7bW9kZWwuDQo8L3NwYW4+Jm5ic3A7QW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgdGhpcyBh
cHByb2FjaCBjYW5ub3QgaGFuZGxlIHZlbmRvci08L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgbW9ub3NwYWNlOyI+PGJyPg0KPC9kaXY+DQo8
ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i
TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBD
b25zb2xhcywgbW9ub3NwYWNlOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMp
OyBib3JkZXItbGVmdC13aWR0aDogNXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRp
bmc6IDBweCAwcHggMHB4IDVweDsgbWFyZ2luOiAwcHggMHB4IDBweCA1cHg7Ij4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR
VU9URSIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEs
IDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNv
bGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+
DQo8ZGl2PldlIGhhdmUgYSBjb21tZW50L2NvbmNlcm4vc3VnZ2VzdGlvbiBhbmQgd2UgdmFsdWUg
eW91ciBmZWVkYmFjay48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PlRoZSBnZW5lcmljIFRFIG1v
ZGVsIGN1cnJlbnRseSByZWZlcmVuY2VzIGRhdGEgbm9kZXMgaW4gdGhlIGdsb2JhbDwvZGl2Pg0K
PGRpdj50cmVlIChlLmcuIGZyb20gdGhlIGlldGYtaW50ZXJmYWNlcyBtb2RlbCB0byBkZWZpbmUg
YWRkaXRpb25hbCBURTwvZGl2Pg0KPGRpdj5wcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0aCBhIHNw
ZWNpZmljIGRldmljZSBpbnRlcmZhY2UpLiBPdXI8L2Rpdj4NCjxkaXY+dW5kZXJzdGFuZGluZyBh
ZnRlciByZWFkaW5nIHNlY3Rpb24gMy4xIG9mIHlvdXIgZHJhZnQgaXMgdGhlIG1vdW50ZWQ8L2Rp
dj4NCjxkaXY+bW9kZWwgY2FuICpub3QqIHJlZmVyZW5jZSBhbnkgZGF0YSBub2RlcyBvdXRzaWRl
IHRoZSBzY29wZSBvZiB0aGU8L2Rpdj4NCjxkaXY+bW91bnQtcG9pbnQgKGUuZy4gZ2xvYmFsIGRh
dGEgbm9kZXMgaW4gdGhlIHlhbmcgdHJlZSkuIFRoaXMgcG9zZXMgYTwvZGl2Pg0KPGRpdj5saW1p
dGF0aW9uIGZvciB1cywgZG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIGZvciB0aGlzIHByb2JsZW0/
PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj5PbmUgcG9zc2libGUgc29sdXRpb24gd2UgdGhvdWdo
dCBvZiB3YXMgdG8gcmVwbGFjZSB0aGUgbGVhZi1yZWZzPC9kaXY+DQo8ZGl2PnBvaW50aW5nIHRv
IHRoZSBnbG9iYWwgZGF0YSBub2RlcyAoZS5nLiBJZXRmLWludGVyZmFjZXMpIHdpdGggY29udGV4
dDwvZGl2Pg0KPGRpdj5uYW1lcyAoZS5nLiB0aGUgaW50ZXJmYWNlIG5hbWUpLi4gVGhpcyBkZWNv
dXBsZXMgdGhlIGRhdGEtbm9kZXM8L2Rpdj4NCjxkaXY+ZGVmaW5lZCBpbiB0aGUgVEUgZ2VuZXJp
YyBtb2RlbCBmcm9tIHRob3NlIGluIHRoZSBnbG9iYWwgdHJlZTwvZGl2Pg0KPGRpdj4oZS5nLiB0
aGUgYWN0dWFsIGludGVyZmFjZSBpZXRmLWludGVyZmFjZXMgbW9kZWwpLiBBbnkgZmVlZGJhY2sg
b248L2Rpdj4NCjxkaXY+dGhpcyBvciBiZXR0ZXIgc3VnZ2VzdGlvbnM/PC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPklmIHlvdSB1c2UgZ3JvdXBpbmdzIGluc3RlYWQsIHlv
dSBjYW4gc3RpbGwgdXNlIHByb3BlciBsZWFmcmVmcy48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdCBpbiBhbGwgY2FzZXMg4oCUIGFzIGRlc2NyaWJlZCBh
Ym92ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6IENvbnNvbGFzLCBtb25vc3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4
OyI+UmVnYXJkcyw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29s
YXMsIG1vbm9zcGFjZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UYXJlazwvc3Bh
bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCBtb25v
c3BhY2U7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFuPjwvZGl2
Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0
eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsIG1vbm9zcGFjZTsgYm9yZGVyLWxlZnQtY29sb3I6
IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQt
c3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAw
cHggNXB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rpdj4NCjxk
aXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1zaXplOiAxMnB4OyI+L21hcnRpbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4
OyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJmb250LXNp
emU6IDEycHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRlci1s
ZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4IDBw
eCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdj48L2Rpdj4NCjxkaXY+
UmVnYXJkcyw8L2Rpdj4NCjxkaXY+VGFyZWs8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkV4Y2Vy
cHQgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1zY2hlbWEtbW91bnQ8L2Rpdj4NCjxkaXY+PC9kaXY+
DQo8ZGl2PjMuMSZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4xIj5odHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50LTAxI3NlY3Rpb24tMy4x
PC9hPiZndDsuPC9kaXY+DQo8ZGl2PkF1Z21lbnQgYW5kIFZhbGlkYXRpb24gaW4gTW91bnRlZCBE
YXRhPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7QWxsIHBhdGhzIChpbiBsZWFmcmVmcywgaW5zdGFuY2UtaWRlbnRpZmllcnMsIFhQ
YXRoIGV4cHJlc3Npb25zLCBhbmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
dGFyZ2V0IG5vZGVzIG9mIGF1Z21lbnRzKSBpbiB0aGUgZGF0YSBtb2RlbHMgbW91bnRlZCBhdCBh
IG1vdW50IHBvaW50PC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FyZSBpbnRl
cnByZXRlZCB3aXRoIHRoZSBtb3VudCBwb2ludCBhcyB0aGUgcm9vdCBub2RlLCBhbmQgdGhlPC9k
aXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21vdW50ZWQgZGF0YSBub2RlcyBhcyBp
dHMgY2hpbGRyZW4uJm5ic3A7Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGRhdGEgd2l0aGluIGE8L2Rp
dj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW91bnRlZCBzdWJ0cmVlIGNhbiBuZXZl
ciByZWZlciB0byBkYXRhIG91dHNpZGUgb2YgdGhpcyBzdWJ0cmVlLjwvZGl2Pg0KPGRpdj48L2Rp
dj4NCjxkaXY+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_50BEAA4EC6454DCEA99244B14B4EFC43ciscocom_--


From nobody Fri Apr 29 10:05:06 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4B12D13E; Fri, 29 Apr 2016 10:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level: 
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj6_jr2mAGHN; Fri, 29 Apr 2016 10:04:57 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FEE12D12B; Fri, 29 Apr 2016 10:04:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F12602411E5; Fri, 29 Apr 2016 10:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1461949496; bh=hwMPH6/7VVfwrOtHc55Mnx3pXmddpW5sg6hBTRTyMXQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cq9qLddIDAStd89DKnNU5e6CfzqtjwRl3eO7JZ2KGG0X9oJdCHKZyr9gmIwHocdW7 K1jWayh+nU0z0X8AzEUBSvpFYPptXFhmLUq0FON9RdstjCfWvVOapDfZNB56tJKZq0 R+ZtaN354zYa/hikw8RmuippPSTNRCSt6Gv+fIR0=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 040EC240E6E; Fri, 29 Apr 2016 10:04:55 -0700 (PDT)
To: "Tarek Saad (tsaad)" , Martin Bjorklund 
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
From: "Joel M. Halpern" 
Message-ID: 
Date: Fri, 29 Apr 2016 13:04:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "draft-ietf-teas-yang-te@ietf.org" , "mpls@ietf.org" , "teas@ietf.org" , "netmod@ietf.org" , "draft-ietf-netmod-schema-mount@ietf.org" 
Subject: Re: [mpls] [netmod] Use of schema mounts for common model
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 17:04:59 -0000

With regard to leafrefs trying to point into groupings, would 
instance-identifiers work for your use case?

Yours,
Joel

On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:
> Thanks Martin, please see inline..
>
>
> On 2016-04-29, 6:29 AM, "Martin Bjorklund"  > wrote:
>
>     "Tarek Saad (tsaad)" > wrote:
>
>         Hi authors/WG,
>         In draft-ietf-teas-yang-te, we are driving the definition for a
>         generic TE YANG model that can/may be used (and extended when
>         necessary) for different data plane technologies (e.g. MPLS,
>         OTN, WDM,
>         etc.).
>         Reviewing the schema mount idea presented in
>         draft-ietf-netmod-schema-mount, we are thinking this proposal is
>         useful and can facilitate the reuse of the our model in multiple
>         places in the YANG tree (once per each technology), e.g.:
>         /mpls/mount-points/mount-point/module=ietf-te.yang
>         /otn/mount-points/mount-point/module=ietf-te.yang
>
>
>     Schema mount is probably not the right solution to your problem.  I
>     think a better solution in your case is to define groupings.
>     Groupings are designed to be re-used at different places in the
>     hierarchy.
>
>
> We thought of this earlier, and found groupings pose their own set of
> challenges too.. Specifically:
> - a groupings with leafrefs could not reference data nodes that reside
> in another grouping
> - a grouping with leafrefs of relative path were challenge when the
> relative path references data nodes outside the grouping
> - the augmentation of the grouping by other modules is not as
> straightforward
>
> That said, the grouping proposal seems to
>
> one could also think that with groupings one could address reuse of the
> a model (e.g. Ietf-interfaces) for logical devices or VM (see below). In
> fact, in your draft (section 2) you explicitly discourage this approach
> as not scalable solution
>
>
>    With the "uses" approach, ietf-interfaces would have to define a
>    grouping with all its nodes, and the new model for logical devices
>    would have to use this grouping.  This is a not a scalable solution,
>    since every time there is a new model defined, we would have to
>    update our model for logical devices to use a grouping from the new
>    model.  Another problem is that this approach cannot handle vendor-
>
>
>
>         We have a comment/concern/suggestion and we value your feedback.
>         The generic TE model currently references data nodes in the global
>         tree (e.g. from the ietf-interfaces model to define additional TE
>         properties associated with a specific device interface). Our
>         understanding after reading section 3.1 of your draft is the mounted
>         model can *not* reference any data nodes outside the scope of the
>         mount-point (e.g. global data nodes in the yang tree). This poses a
>         limitation for us, do you have a suggestion for this problem?
>         One possible solution we thought of was to replace the leaf-refs
>         pointing to the global data nodes (e.g. Ietf-interfaces) with
>         context
>         names (e.g. the interface name).. This decouples the data-nodes
>         defined in the TE generic model from those in the global tree
>         (e.g. the actual interface ietf-interfaces model). Any feedback on
>         this or better suggestions?
>
>
>     If you use groupings instead, you can still use proper leafrefs.
>
>
> Not in all cases  as described above.
>
> Regards,
> Tarek
>
>
>
>     /martin
>
>
>
>         Regards,
>         Tarek
>         Excerpt from draft-ietf-netmod-schema-mount
>         3.1.
>         Augment and Validation in Mounted Data
>             All paths (in leafrefs, instance-identifiers, XPath
>         expressions, and
>             target nodes of augments) in the data models mounted at a
>         mount point
>             are interpreted with the mount point as the root node, and the
>             mounted data nodes as its children.  This means that data
>         within a
>             mounted subtree can never refer to data outside of this subtree.
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Fri Apr 29 10:45:18 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8412D6A1 for ; Fri, 29 Apr 2016 10:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 oYSRopXaqmdP for ; Fri, 29 Apr 2016 10:34:24 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 7E1A712D1F0 for ; Fri, 29 Apr 2016 10:34:24 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id j74so178599200ywg.1 for ; Fri, 29 Apr 2016 10:34:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=G21EUFcqQrungyFP4w0RiF+k0WDUVv8bRqQD8pzJVYg=; b=Ucz7+E9q7/UAayVWira+gyflMQSsu/Kp0nLlzBYiWgn+8u/khtldGDa6CelUUUVgz0 esEd6nmyY6l6FyKvJ/RNo56696eLExjbktSCcH2FHZLBfIWilrnrmbLafZU34nZZnhhu ayKc1cOMpqP6PibEb3s0c16bVglXxf374rOHA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=G21EUFcqQrungyFP4w0RiF+k0WDUVv8bRqQD8pzJVYg=; b=iMKDm/XqrJbPh2nJDbrPrTmufeKl2Xd+p+5CyRWj+eAOgOlWj/Gfk3MpsxsfvhNxb2 2fxh2QpsJYXwkA4TOKkamG37Gw28zSoRnJKg0eWpE1ZkuiIqdYc2eKenspj5925OZn+L hIsi7/rLt2MGf0Lux7dcKUWnumY72g2WuTFtn2BiF3EgjvOf32O6wqNGEFIUfGk3AY5b u6pRlZnPgfrnWIlyIo2WdGn6B3xlLv7qT2TLw97XY1987KKznK5ATMEVJMW/J2/ng5RZ Jn8sI/1zc9/MbERooH+XbCZaD70OG1L3fFBo4cbkkz+s6HiIG19OElZRHBt8uHw7/m88 iQBA==
X-Gm-Message-State: AOPr4FU0B2sdJw8KWJlvDwvgCyl3ylbOAaY82tKYT3ESnmmmwYcAUFAh3flYkmA2MlM5/iypUsyotYguWD0z9wD3
X-Received: by 10.37.2.86 with SMTP id 83mr2259350ybc.159.1461951263331; Fri, 29 Apr 2016 10:34:23 -0700 (PDT)
From: Shahram Davari 
References: <5722C586.1020705@pi.nu> <7347100B5761DC41A166AC17F22DF11221A62E65@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A62E65@eusaamb103.ericsson.se>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE6Y8rADs6RpL3UqyXu63dSWo/3LQJmd43woLx/J2A=
Date: Fri, 29 Apr 2016 10:34:19 -0700
Message-ID: <6cae9d8672236bd9fe12c774d9c7e4bd@mail.gmail.com>
To: Gregory Mirsky , Loa Andersson , mpls-chairs@ietf.org,  mpls@ietf.org, draft-ietf-mpls-residence-time@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
X-Mailman-Approved-At: Fri, 29 Apr 2016 10:45:17 -0700
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 17:34:27 -0000

Unfortunately the Patent Number doesn't seem to be valid. Can you provide
the correct Us patent number or a link to it?

Thx
Shahram

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, April 28, 2016 10:28 PM
To: Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time

Hi Loa, et. al,
I know of the IPR disclosure https://datatracker.ietf.org/ipr/2626/ that
is related to the draft-mirsky-mpls-residence-time  and was submitted on
July 10, 2015.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Thursday, April 28, 2016 7:23 PM
To: mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: IPR poll on draft-ietf-mpls-residence-time

Working Group,

The authors of draft-ietf-mpls-residence-time has told us that the
document is ready to be considered for working group last call.

We will do an IPR poll prior to the start of the wg last call.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see
RFCs 3979, 4879, 3669 and 5378 for more details).

There is one IPR disclosure filed against the document that was replaced
by the current draft.

If you are listed as a document author or contributor please respond to
this email regardless of whether or not you are aware of any relevant IPR.
*The response needs to be sent to the MPLS wg mailing list.* The document
will not advance to the next stage until a response has been received from
each author and contributor.

If you are on the MPLS WG email list but 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.


/Loa
mpls wg co-chair
-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


From nobody Fri Apr 29 11:54:54 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E955C12D6F8; Fri, 29 Apr 2016 11:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEvqUj3HBCkk; Fri, 29 Apr 2016 11:54:51 -0700 (PDT)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6F612D6E8; Fri, 29 Apr 2016 11:54:50 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-87-5723adcc17c6
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id F8.36.03614.CCDA3275; Fri, 29 Apr 2016 20:54:05 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 29 Apr 2016 14:54:49 -0400
From: Gregory Mirsky 
To: Shahram Davari , Loa Andersson , "mpls-chairs@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-residence-time@tools.ietf.org" 
Thread-Topic: [mpls] IPR poll on draft-ietf-mpls-residence-time
Thread-Index: AQHRob4YNm044eoTq0asLv0JLoPafJ+gazkQgAEPEID//9J30A==
Date: Fri, 29 Apr 2016 18:54:48 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A638E7@eusaamb103.ericsson.se>
References: <5722C586.1020705@pi.nu> <7347100B5761DC41A166AC17F22DF11221A62E65@eusaamb103.ericsson.se> <6cae9d8672236bd9fe12c774d9c7e4bd@mail.gmail.com>
In-Reply-To: <6cae9d8672236bd9fe12c774d9c7e4bd@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonXPfsWuVwg/OvmSzufb7NaPFv7hxm i3WXT7FZ3Fq6ktVi06Jb7A6sHrPun2XzWLLkJ5PHrOltbB5fLn9mC2CJ4rJJSc3JLEst0rdL 4MrY3fOZreCIfMW8dy9YGhjvyHUxcnJICJhITNtwkwnCFpO4cG89WxcjF4eQwFFGiZcdt1hB EkICyxkllr1JBLHZBIwkXmzsYQcpEhFoYpLovbYCrFtYwE7i64GNYA0iAvYSk1e3MELYThJv d88Bs1kEVCU6Ts5hB7F5BXwlHj6ayQKxbQ6jxKSpn8ASnECDPl34DWYzAp30/dQasAXMAuIS t57MhzpVQGLJnvPMELaoxMvH/1ghbCWJSUvPAdkcQPWaEut36UO0KkpM6X4ItVdQ4uTMJywT GEVnIZk6C6FjFpKOWUg6FjCyrGLkKC0uyMlNNzLcxAiMn2MSbI47GPf2eh5iFOBgVOLhTfih FC7EmlhWXJl7iFGCg1lJhHfbMuVwId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz6LxXDhQTSE0tS s1NTC1KLYLJMHJxSDYxG8jdCLoUa+7OLvPmw9u/BK12OWvVrk7ZarXrwwEzESP/rii+1hssU 511ePn/6eu+ytlKpCdwWdv0O8senLF/mcSin2VQw+kjxOYb0/l3h/Lyfz0/fc0Bf9djxGZc3 3XzAOD1u6kOdo5ujOU7WrIh7MlXsbIrqHMbTGzTf13W8dRLuynPIZe5UYinOSDTUYi4qTgQA SFiSe5sCAAA=
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 18:54:53 -0000

SGkgU2hhaHJhbSwNCnRoZSBudW1iZXIgbGlzdGVkIGluIHRoZSBkaXNjbG9zdXJlIHJlZmVycyB0
byB0aGUgVS5TLiBQcm92aXNpb25hbCBhcHBsaWNhdGlvbiwgbm90IHRoZSBQQ1QuIEkgd2FzIHRv
bGQgdGhhdCB0aGUgcHVibGljYXRpb24gc3VwcG9zZWQgdG8gaGFwcGVuIDE4IG1vbnRocyBhZnRl
ciB0aGUgZmlsaW5nIGFuZCBpcyBleHBlY3RlZCBvbiBvciBhZnRlciBNYXkgNSwgMjAxNi4gV2ls
bCBtb25pdG9yIHRoYXQgYW5kIHVwZGF0ZSBhY2NvcmRpbmdseS4NCg0KCVJlZ2FyZHMsDQoJCUdy
ZWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNoYWhyYW0gRGF2YXJpIFtt
YWlsdG86c2hhaHJhbS5kYXZhcmlAYnJvYWRjb20uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwg
MjksIDIwMTYgMTA6MzQgQU0NClRvOiBHcmVnb3J5IE1pcnNreTsgTG9hIEFuZGVyc3NvbjsgbXBs
cy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVu
Y2UtdGltZUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxzXSBJUFIgcG9sbCBvbiBk
cmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWUNCg0KVW5mb3J0dW5hdGVseSB0aGUgUGF0ZW50
IE51bWJlciBkb2Vzbid0IHNlZW0gdG8gYmUgdmFsaWQuIENhbiB5b3UgcHJvdmlkZSB0aGUgY29y
cmVjdCBVcyBwYXRlbnQgbnVtYmVyIG9yIGEgbGluayB0byBpdD8NCg0KVGh4DQpTaGFocmFtDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR3JlZ29yeSBNaXJza3kNClNlbnQ6IFRodXJzZGF5
LCBBcHJpbCAyOCwgMjAxNiAxMDoyOCBQTQ0KVG86IExvYSBBbmRlcnNzb247IG1wbHMtY2hhaXJz
QGlldGYub3JnOyBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtcmVzaWRlbmNlLXRpbWVA
dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXBsc10gSVBSIHBvbGwgb24gZHJhZnQtaWV0
Zi1tcGxzLXJlc2lkZW5jZS10aW1lDQoNCkhpIExvYSwgZXQuIGFsLA0KSSBrbm93IG9mIHRoZSBJ
UFIgZGlzY2xvc3VyZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yNjI2LyB0aGF0
IGlzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0LW1pcnNreS1tcGxzLXJlc2lkZW5jZS10aW1lICBhbmQg
d2FzIHN1Ym1pdHRlZCBvbiBKdWx5IDEwLCAyMDE1Lg0KDQoJUmVnYXJkcywNCgkJR3JlZw0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxv
YUBwaS5udV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyOCwgMjAxNiA3OjIzIFBNDQpUbzogbXBs
cy1jaGFpcnNAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbXBscy1yZXNpZGVu
Y2UtdGltZUB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogSVBSIHBvbGwgb24gZHJhZnQtaWV0Zi1t
cGxzLXJlc2lkZW5jZS10aW1lDQoNCldvcmtpbmcgR3JvdXAsDQoNClRoZSBhdXRob3JzIG9mIGRy
YWZ0LWlldGYtbXBscy1yZXNpZGVuY2UtdGltZSBoYXMgdG9sZCB1cyB0aGF0IHRoZSBkb2N1bWVu
dCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbC4N
Cg0KV2Ugd2lsbCBkbyBhbiBJUFIgcG9sbCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHdnIGxh
c3QgY2FsbC4NCg0KVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwuDQoNCkFyZSB5b3UgYXdh
cmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0Zi1tcGxzLXJlc2lkZW5jZS10
aW1lPw0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug
d2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm
b3IgbW9yZSBkZXRhaWxzKS4NCg0KVGhlcmUgaXMgb25lIElQUiBkaXNjbG9zdXJlIGZpbGVkIGFn
YWluc3QgdGhlIGRvY3VtZW50IHRoYXQgd2FzIHJlcGxhY2VkIGJ5IHRoZSBjdXJyZW50IGRyYWZ0
Lg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRv
ciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBu
b3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLg0KKlRoZSByZXNwb25zZSBuZWVk
cyB0byBiZSBzZW50IHRvIHRoZSBNUExTIHdnIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVudCB3
aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJl
ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQoNCklmIHlvdSBh
cmUgb24gdGhlIE1QTFMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0
aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp
ZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl
ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNCg0KL0xvYQ0KbXBscyB3ZyBjby1j
aGFpcg0KLS0gDQoNCg0KTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWls
OiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAgICAgICAg
ICAgICAgICAgICAgbG9hQHBpLm51DQpIdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAg
ICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo=


From nobody Fri Apr 29 13:39:10 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F177512D51A; Fri, 29 Apr 2016 13:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZZTs40aRj02; Fri, 29 Apr 2016 13:39:07 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 8A87C12B037; Fri, 29 Apr 2016 13:39:07 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id k142so131932212oib.1; Fri, 29 Apr 2016 13:39:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KTkoiuC6tq1S1Uz/KwCWq12UFibr2Envo4AvuetSRWU=; b=MjDR5Tl0+IVyFgPq5ln53tn5yD33cNNZcIU1PGsKWZef/zgb8c3zNkQ8N952A4MUME Hzbjd0fckgkCG6FfyqDZh74RWeP0dScKkx4FHyivlCfLKyzz33QiAwA16U725Y1dhFRO xV464oKqypbuSgIKphl9Q6CNVfthzv7x/vhoX+258DmcInLjHySvFrP+S+ADmGBoGRKG BrbkQSLg2myi2KyaLqYumpzzgkgvotUWcW9otTlpBhy69Kqdue/BpJZdre9u/6A+oLnf o10mMjM7qpP5oRsrGlW5nzT61CiPXCxLyYWhTLGp/9pmJfQzNqaL52nCpVsJQLY+6goF IjpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KTkoiuC6tq1S1Uz/KwCWq12UFibr2Envo4AvuetSRWU=; b=VhwFVoqzUgzF9i+WgXMug5iwCcF20/e3Zcp1WHUgmaJpxJJjbJ8+9YDIlI/qK5XN7H SBDIqpf1SmCSv4Pa/4x8wexp/o/qO+l9T/wt4LtSSuUZ7U9L39t2mEQp2c/H87+RLT5f 5bM+YgY2KupUBHmqk3oD5uiNja2Ie1HXMTAoYaLgeDKqMJcaZxa2qM3dtd5qgLAzHBxo ETGdSN1LrD/RrGpkbz/TORpSVMMT1GmkXk/qFGYGxg9MNNGgK/bdfo3TB98amqwuKyww ONw9lFfP3BoyOfA8Omv6uCXfbgSg9RKZtHtkxOtcVCWZ/e54e908QjakJ+woG9XOObEv hYxg==
X-Gm-Message-State: AOPr4FWgJVwbu5qvH6ga5yJGDPT8pqnipBE6bm52zvLAfo0sppyJhliaDwPICkVkeP/+3GVx0ePeA1zZX4KGvA==
X-Received: by 10.157.41.162 with SMTP id n31mr10760156otb.62.1461962346958; Fri, 29 Apr 2016 13:39:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 13:38:37 -0700 (PDT)
In-Reply-To: <571E229B.2090405@gmail.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>
From: Sri 
Date: Fri, 29 Apr 2016 13:38:37 -0700
Message-ID: 
To: Stewart Bryant 
Content-Type: multipart/alternative; boundary=001a113df6c25d95540531a5a2f3
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 20:39:10 -0000

--001a113df6c25d95540531a5a2f3
Content-Type: text/plain; charset=UTF-8

Hi Stewart,

Thanks for your comments. Pls see inline

On Mon, Apr 25, 2016 at 6:58 AM, Stewart Bryant 
wrote:

> I support this becoming a WG doc and thereby comming under WG
> control.
>

Sri> As pointed out by George, this draft is going through WGLC.


> However I am not sure about the dismissal of the option to reuse
> the ELI+EL. This clutters the stack less than the proposed option.
>

Sri> This option was not considered since it changes the label swap
operations and would need hardware changes.


>
> Also I wonder why this is standards track?
>
>
Sri> As per the response to Loa's suggestion, this draft will be changed to
Informational.


> Surely any equipment that understands the ELI can do this and thus this is
> just an informal description of the problem and a solution.


Sri> Since there are different ways to do this and some ways are better
than others, this draft lists the different options and recommends one
solution.


>
>
> Stewart
>
> On 23/04/2016 08:53, Loa Andersson wrote:
>
>> Working Group,
>>
>> This is to initiate a two week working group last call on
>> draft-ietf-mpls-spring-entropy-label.
>>
>> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>>
>> There are no IPR disclosures against this document.
>>
>> All the authors and contributors (with one exception) have stated on
>> the working group mailing list that they are not aware of any other
>> IPRs that relates to this draft.
>>
>> This working group last call ends May 12, 2016.
>>
>>
>> /Loa
>> for the MPLS wg chairs
>>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--001a113df6c25d95540531a5a2f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stewart,

Thanks for your comments. P=
ls see inline

On Mon, Apr 25, 2016 at 6:58 AM, Stewart Bryant <stewart.bryant@g=
mail.com> wrote:
I suppor=
t this becoming a WG doc and thereby comming under WG

control.

Sri> As pointed out by Geor=
ge, this draft is going through WGLC.=C2=A0




However I am not sure about the dismissal of the option to reuse

the ELI+EL. This clutters the stack less than the proposed option.

Sri> This option was not considered since it=
 changes the label swap operations and would need hardware changes.
=C2=A0



Also I wonder why this is standards track?



Sri> As per the response to Loa'=
;s suggestion, this draft will be changed to Informational.
=C2=
=A0

Surely any equipment that understands the ELI can do this and thus this is =
just an informal description of the problem and a solution.

Sri> Since there are different ways to do this and some=
 ways are better than others, this draft lists the different options and re=
commends one solution.
=C2=A0




Stewart



On 23/04/2016 08:53, Loa Andersson wrote:



Working Group,



This is to initiate a two week working group last call on

draft-ietf-mpls-spring-entropy-label.



Please send your comments to the mpls wg mailing list (mpls@ietf.org).



There are no IPR disclosures against this document.



All the authors and contributors (with one exception) have stated on

the working group mailing list that they are not aware of any other

IPRs that relates to this draft.



This working group last call ends May 12, 2016.





/Loa

for the MPLS wg chairs





_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls





--001a113df6c25d95540531a5a2f3--


From nobody Fri Apr 29 13:41:51 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F107B12D54B; Fri, 29 Apr 2016 13:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuUTU7WzncgG; Fri, 29 Apr 2016 13:41:48 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 CAE8312D51A; Fri, 29 Apr 2016 13:41:47 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id k142so132003581oib.1; Fri, 29 Apr 2016 13:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gq46MYXaUIoHE+JF8BDaL2evzmY/3Lv7Kgruozrc5Vg=; b=x9ITxaGH003yDPejNvRKfccKX4R7qyYk/uz3BLugfS2EDEKOQVnHJtqcjWK7PzfkdC PFb+9bAZmXhsLWrOrnFXWHouvZW5jU87VpL+bIQ8CoYqUM1qrBMMo9EX+pHKxsOxNTdg K7sReclLLXQdsUwgoFSx9U0uM59Y0y/UGjFptbMBFefIZpmbbgSsUsud+ldi9vcbLPEZ zZLp628wwAqD4Uksu8B0jC4ro3zjzB22hBxydj0yv5S2jeX3rIvHtBt3UbFajE0CT/tX JMv+IgZvoAcZq2q6ptH7BPH80GR8QqI/BWaGPCnih9N3ooebw7+1/6G5f0tUAGq7lnPg As9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gq46MYXaUIoHE+JF8BDaL2evzmY/3Lv7Kgruozrc5Vg=; b=liNukv8bQLaeWuA+TU/SvFgRw6CJ04L2rLjUZbEdCb6TSwdWXgsZ8YVsuVAwg0cZPm a7vTh4/3s1j4CxPmQt4DMD+TkOKoeBzGTRJxtbftQ1qfedqpUXgL3J9A/tfmu3hna/Ro EFmYGIazNz6bUEKXmPLXALZiQ+d+jZ2qks7hSWyIx3z09V1IUEA1mkyhntdMfjiDg9fb GfgQN9fz0TAPasehJvw9I/dc1PbHllOjs7biWHkVv+V3VCRpNjHeNxTBn08nNfArEYcA bEGCx2oYDIxUqs0YnZ4n1Z0UAiVzaUoIhgS4ySVMV4FLU6GPMX1Nf90nehtF1i2IFkLr cVIQ==
X-Gm-Message-State: AOPr4FUL5SvK/Plx+iQhjhYhflkU6xcjNyEH7CElqXPo0SdvZ/WRlBMBDDZtDxcUDpCQfigDdZVFSgeyDsWhpg==
X-Received: by 10.157.41.162 with SMTP id n31mr10764603otb.62.1461962507264; Fri, 29 Apr 2016 13:41:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 13:41:17 -0700 (PDT)
In-Reply-To: <571E69F2.8020506@gmail.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <571E69F2.8020506@gmail.com>
From: Sri 
Date: Fri, 29 Apr 2016 13:41:17 -0700
Message-ID: 
To: Stewart Bryant 
Content-Type: multipart/alternative; boundary=001a113df6c2ebaa120531a5abe3
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 20:41:50 -0000

--001a113df6c2ebaa120531a5abe3
Content-Type: text/plain; charset=UTF-8

Hi Stewart,

Pls see inline.



On Mon, Apr 25, 2016 at 12:03 PM, Stewart Bryant 
wrote:

>
>
> On 25/04/2016 18:57, George Swallow wrote:
>
> Stewart -
>
> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <
> stewart.bryant@gmail.com> wrote:
>
>> I support this becoming a WG doc and thereby comming under WG
>> control.
>>
>
> The document is a WG doc.   We are now in WG last call.
>
>
> Sorry, I missed that :( I should have read the subject!
>
>
>
>> However I am not sure about the dismissal of the option to reuse
>> the ELI+EL. This clutters the stack less than the proposed option.
>>
>> Also I wonder why this is standards track?
>>
>
> A reasonable question, particularly since there are no MUSTs, SHALLs or
> REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>
>
> Well that brings me to wonder what needs to be specified, since action
> when the label stack is pushed is a local matter and as I remember a number
> of the rejected strategies are just normal MPLS.
>

Sri> Just re-iterating a response to a similar point in an earlier email -
 "Since there are different ways to do this and some ways are better than
others, this draft lists the different options and recommends one solution."


> - Stewart
>
>
Thanks
Sri


>
>
>
>> Surely any equipment that understands the ELI can do this and thus this
>> is just an informal description of the problem and a solution.
>>
>> Stewart
>>
>>
>> On 23/04/2016 08:53, Loa Andersson wrote:
>>
>>> Working Group,
>>>
>>> This is to initiate a two week working group last call on
>>> draft-ietf-mpls-spring-entropy-label.
>>>
>>> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>>>
>>> There are no IPR disclosures against this document.
>>>
>>> All the authors and contributors (with one exception) have stated on
>>> the working group mailing list that they are not aware of any other
>>> IPRs that relates to this draft.
>>>
>>> This working group last call ends May 12, 2016.
>>>
>>>
>>> /Loa
>>> for the MPLS wg chairs
>>>
>>
>>
>
>

--001a113df6c2ebaa120531a5abe3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stewart,

Pls see inline.
<=
br>


On Mon, Apr 25, 2016 at 12:03 PM, Stewart Bryant &=
lt;stewart.br=
yant@gmail.com> wrote:

 =20
   =20
 =20
  

    

    

    
On 25/04/2016 18:57, George Swallow
      wrote:

    

    

      
Stewart -

        


          
On Mon, Apr 25, 2016 at 9:58 AM,
            Stewart Bryant <stewart.bryant@gmail.com>
            wrote:

            
I
              support this becoming a WG doc and thereby comming under
              WG

              control.

            

            


            

            
The document is a WG doc.=C2=A0=C2=A0 We are now in WG las=
t call.

            

          

        

      

    

    

    Sorry, I missed that :( I should have read the subject!

    

    

      

        

          

            
=C2=A0

            

              However I am not sure about the dismissal of the option to
              reuse

              the ELI+EL. This clutters the stack less than the proposed
              option.

              

              Also I wonder why this is standards track?

            

            


            

            
A reasonable question, particularly since there are no
              MUSTs, SHALLs or REQUIREDs.=C2=A0 Will discuss with my
              Co-Chairs and ADs.

            

          

        

      

    

    

    Well that brings me to wonder what needs to be specified, since
    action when the label stack is pushed is a local matter and as I
    remember a number of the rejected strategies are just normal MPLS. 
=


Sri> Just re-iterating a response=
 to a similar point in an earlier email - =C2=A0"Since there are different ways to do this and some ways are bet=
ter than others, this draft lists the different options and recommends one =
solution."


    

    - Stewart

    

Thanks
Sri<=
/div>
=C2=A0

    

    

      

        

          

            
=C2=A0

            

              Surely any equipment that understands the ELI can do this
              and thus this is just an informal description of the
              problem and a solution.

                  

                  Stewart
              

                


                  

                  On 23/04/2016 08:53, Loa Andersson wrote:

                  

                    Working Group,

                    

                    This is to initiate a two week working group last
                    call on

                    draft-ietf-mpls-spring-entropy-label.

                    

                    Please send your comments to the mpls wg mailing
                    list (mpls@ietf.org).

                    

                    There are no IPR disclosures against this document.

                    

                    All the authors and contributors (with one
                    exception) have stated on

                    the working group mailing list that they are not
                    aware of any other

                    IPRs that relates to this draft.

                    

                    This working group last call ends May 12, 2016.

                    

                    

                    /Loa

                    for the MPLS wg chairs

                  

                  

                

              

            

          

          

        

      

    

    

  






--001a113df6c2ebaa120531a5abe3--


From nobody Fri Apr 29 13:43:51 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3643A12D53E for ; Fri, 29 Apr 2016 13:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 w2kkZ_7bz_S2 for ; Fri, 29 Apr 2016 13:43:47 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 279D712D54B for ; Fri, 29 Apr 2016 13:43:47 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id t10so209475261ywa.0 for ; Fri, 29 Apr 2016 13:43:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=U0Irejmvm9NjwL20mIzrWdgMnJyB8YoTfeux9ysbXNM=; b=YK5YPx/UPUeSoF0ufuhjH/BIqQFh8cZgXMD7QeRhAdNFKGlOSHwoFglDPXCBufIbJ2 IhvpibcdXqGhlTC99/4lXq7l35b21xnGDfQKDcMKNI1l2SsSqRjc9to2ZNMq39lX4Axb dNJZ+47RAqhlOsJm9dih/zebE+sTTxGJQxIv8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=U0Irejmvm9NjwL20mIzrWdgMnJyB8YoTfeux9ysbXNM=; b=QDpLhx5IwbCEQ18KuZcfyWmfkBbeR7tc8sKMXyYF/jdD1z7zKrMbiUWK67AoWgJYBV AfZ5kZmTEZCsV1FRh9eFXYqY3mDDhygkkSavr8AcOdDCQ7O+Hg/QgZkh9xbcfi1GJ0r3 xtV8l7AO08G1L4htK0KeyfV5xYlxoFzj8PRKLLnwl8QZmQWKDDBWB6xvPacT+caRSuTE 2OMQhhD5cDvfUMUgZKderqybttVoZRDX8lwkvYyKc7mBQaAtGlnTMXwYj7HpP8D6kP3E K7UBicKoE4DeQpWh8kMdNS/A4k4/qxADXh6tL8skz/z5NHhkTAqz4oN2VQd9nb7b0cLC 46eA==
X-Gm-Message-State: AOPr4FXMREvIQo54hfDvB/4KWrKQ/cneecvTedWGuCZlU0sS6StigMUTr5tlGDG2zhE2KLnCPQa7pa6PL0T+8MPo
X-Received: by 10.13.224.69 with SMTP id j66mr12451091ywe.117.1461962626278; Fri, 29 Apr 2016 13:43:46 -0700 (PDT)
From: Shahram Davari 
References: <5722C586.1020705@pi.nu> <7347100B5761DC41A166AC17F22DF11221A62E65@eusaamb103.ericsson.se> <6cae9d8672236bd9fe12c774d9c7e4bd@mail.gmail.com> <7347100B5761DC41A166AC17F22DF11221A638E7@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A638E7@eusaamb103.ericsson.se>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE6Y8rADs6RpL3UqyXu63dSWo/3LQJmd43wAZ1FMrUBrul2xKCiUrmA
Date: Fri, 29 Apr 2016 13:43:42 -0700
Message-ID: 
To: Gregory Mirsky , Loa Andersson , mpls-chairs@ietf.org,  mpls@ietf.org, draft-ietf-mpls-residence-time@tools.ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 20:43:51 -0000

Ok. Thanks.

-----Original Message-----
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, April 29, 2016 11:55 AM
To: Shahram Davari; Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: RE: [mpls] IPR poll on draft-ietf-mpls-residence-time

Hi Shahram,
the number listed in the disclosure refers to the U.S. Provisional
application, not the PCT. I was told that the publication supposed to happen
18 months after the filing and is expected on or after May 5, 2016. Will
monitor that and update accordingly.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:shahram.davari@broadcom.com]
Sent: Friday, April 29, 2016 10:34 AM
To: Gregory Mirsky; Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: RE: [mpls] IPR poll on draft-ietf-mpls-residence-time

Unfortunately the Patent Number doesn't seem to be valid. Can you provide
the correct Us patent number or a link to it?

Thx
Shahram

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Thursday, April 28, 2016 10:28 PM
To: Loa Andersson; mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: Re: [mpls] IPR poll on draft-ietf-mpls-residence-time

Hi Loa, et. al,
I know of the IPR disclosure https://datatracker.ietf.org/ipr/2626/ that is
related to the draft-mirsky-mpls-residence-time  and was submitted on July
10, 2015.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Thursday, April 28, 2016 7:23 PM
To: mpls-chairs@ietf.org; mpls@ietf.org;
draft-ietf-mpls-residence-time@tools.ietf.org
Subject: IPR poll on draft-ietf-mpls-residence-time

Working Group,

The authors of draft-ietf-mpls-residence-time has told us that the document
is ready to be considered for working group last call.

We will do an IPR poll prior to the start of the wg last call.

This mail starts the IPR poll.

Are you aware of any IPR that applies to draft-ietf-mpls-residence-time?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see
RFCs 3979, 4879, 3669 and 5378 for more details).

There is one IPR disclosure filed against the document that was replaced by
the current draft.

If you are listed as a document author or contributor please respond to this
email regardless of whether or not you are aware of any relevant IPR.
*The response needs to be sent to the MPLS wg mailing list.* The document
will not advance to the next stage until a response has been received from
each author and contributor.

If you are on the MPLS WG email list but 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.


/Loa
mpls wg co-chair
-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


From nobody Fri Apr 29 13:55:30 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8412D641; Fri, 29 Apr 2016 13:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSLMbzhwXJbw; Fri, 29 Apr 2016 13:55:24 -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 676C812D111; Fri, 29 Apr 2016 13:55:24 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id u64so131348083lff.3; Fri, 29 Apr 2016 13:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=VT0jvFRNSClUTgwavrJtjlcMiE6hL98YSpgVv53DYXB4Yweei9sDAalzUGfsqcuzWw Ap7vYJgrXHjuJmb80qwNUS9PTCU1XL72C5gicktpJrFRgxR7MMRSKOUzmZ8OJGUcIJtN x0vZviVEJUlRjKk+2wKzPsSyMNY5nv9Rwkew43KLNKqgayBJrUTVLSz3n9y+CA/R3BY3 MdxxkiE8i6f9iJZElc99kurIJ0IF0kzppUu5A6Kw7LyMosFh+meiQ5/B0sWcd6gP9L4l WkF6vTNLKCIXIOxdXOuo+yT9FTcJGwvrgtna7K9yzMrljfO5IQyDiVVVUArR4HZM7FNq LiNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=D+B60/l0XDvP2psF5UjcpH/C9sEXnKLumgVNbGJUCYY=; b=OdS6ozzuvCzVfMU/jWPIbGxXtTEI0BftGYgaHnG5EfjIoFTPxjDKQzetR0dQk1f75Y RdaeHiYmUUF+g0OASadbKIeOmsCs7xJo4aLAC7fOIJ7E7hRMCTFqJPrx148BJD8PGpbI Q9lOj8DG4QQXNtif1uB+3grOpJucxDyGtWvC7Xvp6zY56qis0nolOzx8Emcg/AEGbnZT XAheppD8jHRL9mEmZRX7PMHNfqv6v8N9ZreG5AvAXj65THFbrzZVTjeNXBAGR7FVSDLR BpLeCQ3r3ICLxXUr3rIMIOwCTEo9yHUhQt5V42w+SVh8QX8Yf8o3ouXcvEPngp+ihCSw TvXw==
X-Gm-Message-State: AOPr4FWDZjTHu+LW7jbfZ3JoKsGli250VTzPPFmPl1olrKXO6a8+u0jI+bJVxeVcP/u0TA==
X-Received: by 10.25.18.215 with SMTP id 84mr9656770lfs.154.1461963322598; Fri, 29 Apr 2016 13:55:22 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id s4sm2581040lbr.34.2016.04.29.13.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Apr 2016 13:55:21 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Joel M. Halpern'" , "'Tarek Saad \(tsaad\)'" , "'Martin Bjorklund'" 
References: <4A05DD10-0885-435C-9D13-9634388B9F4B@cisco.com> <20160429.122943.1926404425708749601.mbj@tail-f.com> <50BEAA4E-C645-4DCE-A992-44B14B4EFC43@cisco.com> 
In-Reply-To: 
Date: Fri, 29 Apr 2016 16:55:18 -0400
Message-ID: <01fc01d1a259$71cfae00$556f0a00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHWgJx6jSrWpXJ0ftSLGH1x1joEWQIIa3FCAl1chQsCIJL6KJ9jcbMA
Content-Language: en-us
Archived-At: 
Cc: draft-ietf-teas-yang-te@ietf.org, mpls@ietf.org, netmod@ietf.org, teas@ietf.org, draft-ietf-netmod-schema-mount@ietf.org
Subject: Re: [mpls] [Teas] [netmod] Use of schema mounts for common model
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 20:55:27 -0000

We still hope that schema mount can handle cross-referencing across mounted
modules. It is also needed when ietf-interfaces model is mounted to
logical-network-element  and network-instance models.

More comments for this case below in-line.

Thanks,

- Xufeng

> -----Original Message-----
> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, April 29, 2016 1:05 PM
> To: Tarek Saad (tsaad) ; Martin Bjorklund

> Cc: draft-ietf-teas-yang-te@ietf.org; mpls@ietf.org; teas@ietf.org;
> netmod@ietf.org; draft-ietf-netmod-schema-mount@ietf.org
> Subject: Re: [Teas] [netmod] Use of schema mounts for common model
> 
> With regard to leafrefs trying to point into groupings, would
instance-identifiers
> work for your use case?
> 

In this case, it would be hard to specify the must conditions for these
instance-identifiers to make them always applicable when the groupings are
used in various situations. If we are willing to re-structure everything,
the method used in draft-halpern-supa-generic-policy-data-model could be an
option to explore. 

> Yours,
> Joel
> 
> On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote:
> > Thanks Martin, please see inline..
> >
> >
> > On 2016-04-29, 6:29 AM, "Martin Bjorklund"  > > wrote:
> >
> >     "Tarek Saad (tsaad)" >
wrote:
> >
> >         Hi authors/WG,
> >         In draft-ietf-teas-yang-te, we are driving the definition for a
> >         generic TE YANG model that can/may be used (and extended when
> >         necessary) for different data plane technologies (e.g. MPLS,
> >         OTN, WDM,
> >         etc.).
> >         Reviewing the schema mount idea presented in
> >         draft-ietf-netmod-schema-mount, we are thinking this proposal is
> >         useful and can facilitate the reuse of the our model in multiple
> >         places in the YANG tree (once per each technology), e.g.:
> >         ./mpls/mount-points/mount-point/module=ietf-te.yang
> >         ./otn/mount-points/mount-point/module=ietf-te.yang
> >
> >
> >     Schema mount is probably not the right solution to your problem.  I
> >     think a better solution in your case is to define groupings.
> >     Groupings are designed to be re-used at different places in the
> >     hierarchy.
> >
> >
> > We thought of this earlier, and found groupings pose their own set of
> > challenges too.. Specifically:
> > - a groupings with leafrefs could not reference data nodes that reside
> > in another grouping
> > - a grouping with leafrefs of relative path were challenge when the
> > relative path references data nodes outside the grouping
> > - the augmentation of the grouping by other modules is not as
> > straightforward
> >
> > That said, the grouping proposal seems to
> >
> > one could also think that with groupings one could address reuse of
> > the a model (e.g. Ietf-interfaces) for logical devices or VM (see
> > below). In fact, in your draft (section 2) you explicitly discourage
> > this approach as not scalable solution
> >
> >
> >    With the "uses" approach, ietf-interfaces would have to define a
> >    grouping with all its nodes, and the new model for logical devices
> >    would have to use this grouping.  This is a not a scalable solution,
> >    since every time there is a new model defined, we would have to
> >    update our model for logical devices to use a grouping from the new
> >    model.  Another problem is that this approach cannot handle vendor-
> >
> >
> >
> >         We have a comment/concern/suggestion and we value your feedback.
> >         The generic TE model currently references data nodes in the
global
> >         tree (e.g. from the ietf-interfaces model to define additional
TE
> >         properties associated with a specific device interface). Our
> >         understanding after reading section 3.1 of your draft is the
mounted
> >         model can *not* reference any data nodes outside the scope of
the
> >         mount-point (e.g. global data nodes in the yang tree). This
poses a
> >         limitation for us, do you have a suggestion for this problem?
> >         One possible solution we thought of was to replace the leaf-refs
> >         pointing to the global data nodes (e.g. Ietf-interfaces) with
> >         context
> >         names (e.g. the interface name).. This decouples the data-nodes
> >         defined in the TE generic model from those in the global tree
> >         (e.g. the actual interface ietf-interfaces model). Any feedback
on
> >         this or better suggestions?
> >
In this case, there are multiple augmentations to ietf-te.yang, such as
ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the
augmentations before ietf-te is used. Using the grouping would be very
awkward when ietf-te is used. We would have to make the same many
augmentations at that time. Even worse, there could be future augmentations,
we cannot specify these augmentations now because they are not defined yet.

> >
> >     If you use groupings instead, you can still use proper leafrefs.
> >
> >
> > Not in all cases - as described above.
> >
> > Regards,
> > Tarek
> >
> >
> >
> >     /martin
> >
> >
> >
> >         Regards,
> >         Tarek
> >         Excerpt from draft-ietf-netmod-schema-mount
> >         3.1 01#section-3.1>.
> >         Augment and Validation in Mounted Data
> >             All paths (in leafrefs, instance-identifiers, XPath
> >         expressions, and
> >             target nodes of augments) in the data models mounted at a
> >         mount point
> >             are interpreted with the mount point as the root node, and
the
> >             mounted data nodes as its children.  This means that data
> >         within a
> >             mounted subtree can never refer to data outside of this
subtree.
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas


From nobody Fri Apr 29 14:00:03 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4312D6B3; Fri, 29 Apr 2016 14:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug8mQmNbwVFH; Fri, 29 Apr 2016 14:00:00 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 CAC6012D68F; Fri, 29 Apr 2016 13:59:59 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id k142so132482667oib.1; Fri, 29 Apr 2016 13:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k+HQm1z4mHgxtqs+fN4DHWZTJDOMwp59uKy+fyWiPC0=; b=LokxzezUhXUi55mebdpHpARSzhM2K4Nq3wgyPuWhI7EJM5Akw/B51wmnF5SmrUcvdj MtEHBuy2jxdGZh0QpeY0UpvE6psqkAIysyVAGxBWX9DxqBxR9HV2YvzVoC14aZpxZqlT WQaUTLn0q+7SFdLBraPdDZnmiy6i6r/MQfK7K0Y2jBX6REohYDzAk2frvYqvCPlYV/op M409sCeAv1mkBh8Yc05KEIkimfdHG/8qbUyrSIHgHkVsb1s0H+pd0MNHv+/URbDDtn+V 7Wm+AHq18cu7BOhpi6wnuqM8g9D6J2rd7HZvZV/w+AzhcBy+KTwcBCAkcD6XguTTKztk snGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+HQm1z4mHgxtqs+fN4DHWZTJDOMwp59uKy+fyWiPC0=; b=MyhPwvm8KtJ/LL2nQwaKqjl/agNsvN+7XjN6gEWzpx1eLLuF3KCCGsPrM+EVaKBjb+ 2bsWgJM9PebqaHFLEglhu2euUj4MOC6TifQtZHY/v7aG4G3Ur6rkQ7tx5BelRvXJWLW6 GPkMUre+ErqMU1yF79yT+cjROAwAzlBVf6lTQ7COVnYGRazpJm+gP/ol9q+ZPzocjg/W kd9b1aeOdJgQGBFadvfrsCQdVQBzUKl0yOO1Wng4iH9xmsVQ728J7l3dQNyrxg5/FObG g0kTkq4sPji/6u0K6wKXoN2IIzH1xWTXVDaXGEtWprhhXaYL/ya2+q7U1mrBZLVbtd2P dAJQ==
X-Gm-Message-State: AOPr4FW51rXSIsD5blV965XZhhpyuq1wHaHjC5dtN1jbijj4oVViNwqEw41qF61vLYdTD6s81o+Es/+J6pDVYQ==
X-Received: by 10.157.41.162 with SMTP id n31mr10795824otb.62.1461963599236; Fri, 29 Apr 2016 13:59:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 13:59:29 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se>
From: Sri 
Date: Fri, 29 Apr 2016 13:59:29 -0700
Message-ID: 
To: Gregory Mirsky 
Content-Type: multipart/alternative; boundary=001a113df6c201d5360531a5edda
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:00:02 -0000

--001a113df6c201d5360531a5edda
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Greg,

Thanks for your comments. Pls see inline.

On Mon, Apr 25, 2016 at 12:19 PM, Gregory Mirsky <
gregory.mirsky@ericsson.com> wrote:

> Hi George, et. al,
>
> I=E2=80=99ve found several occurrences, three actually, of SHOULD being u=
sed in
> Section 4.
>
>
>
> And I agree with Stewart that application of  is the local
> decision and, at most, this work can be published as Informational.
>

Sri> As per my response to Loa's suggestion, the draft will be changed to
informational with all the SHOULDs retained.


> One comment, suggestion:
>
> =C2=B7         the sample algorithm in Section 4 suggests that the same
>  tuple been used multiple times whereas it may be advantageous to
> generalize and point that the different entropy label value may be used b=
y
> referring to the tuple as 
>

Sri> We had shown that ELs may be different in the example in an earlier
version of the draft. Instead of referring to ELn, I would suggest that a
second sentence be added in the third para in sec 4 as follows "The ELs
among multiple  pairs inserted in the stack may be same or
different".


>
>
> Regards,
>
>         Greg
>
>
>
>
>

Thanks
Sri


> *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow
> *Sent:* Monday, April 25, 2016 10:57 AM
> *To:* Stewart Bryant
> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org;
> mpls-chairs@ietf.org
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
>
>
> Stewart -
>
>
>
> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant 
> wrote:
>
> I support this becoming a WG doc and thereby comming under WG
> control.
>
>
>
> The document is a WG doc.   We are now in WG last call.
>
>
>
> However I am not sure about the dismissal of the option to reuse
> the ELI+EL. This clutters the stack less than the proposed option.
>
> Also I wonder why this is standards track?
>
>
>
> A reasonable question, particularly since there are no MUSTs, SHALLs or
> REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>
>
>
> Surely any equipment that understands the ELI can do this and thus this i=
s
> just an informal description of the problem and a solution.
>
> Stewart
>
>
>
> On 23/04/2016 08:53, Loa Andersson wrote:
>
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-ietf-mpls-spring-entropy-label.
>
> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
> There are no IPR disclosures against this document.
>
> All the authors and contributors (with one exception) have stated on
> the working group mailing list that they are not aware of any other
> IPRs that relates to this draft.
>
> This working group last call ends May 12, 2016.
>
>
> /Loa
> for the MPLS wg chairs
>
>
>
>
>

--001a113df6c201d5360531a5edda
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Greg,

Thanks for your comments. Pls =
see inline.

=
On Mon, Apr 25, 2016 at 12:19 PM, Gregory Mirsky <gregory.mirsky=
@ericsson.com> wrote:











Hi George, et. al,=



I=E2=80=99ve found severa=
l occurrences, three actually, of SHOULD being used in Section 4.=



=C2=A0


And I agree with Stewart =
that application of <ELI, EL> is the local decision and, at most, thi=
s work can be published as Informational.

Sri> As per my response to Loa's suggestion, t=
he draft will be changed to informational with all the SHOULDs retained.
=C2=A0


One comment, suggestion:<=
u>


=C2=B7=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
the sample algorithm=
 in Section 4 suggests that the same <ELI,EL> tuple been used multipl=
e times whereas it may be advantageous to generalize and
 point that the different entropy label value may be used by referring to t=
he tuple as <ELI, ELn>

Sri> We had shown that ELs may be different in the example in a=
n earlier version of the draft. Instead of referring to ELn, I would sugges=
t that a second sentence be added in the third para in sec 4 as follows &qu=
ot;The ELs among multiple <ELI, EL> pairs inserted in the stack may b=
e same or different".
=C2=A0


=C2=A0


Regards,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg


=C2=A0


=C2=A0
<=
/div>

Thanks
Sri
=
=C2=A0
<=
u>


From: mpls [ma=
ilto:mpls-bounce=
s@ietf.org]
On Behalf Of George Swallow

Sent: Monday, April 25, 2016 10:57 AM

To: Stewart Bryant

Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.or=
g; mpls@ietf.org=
; mpls-chairs@iet=
f.org

Subject: Re: [mpls] working group last call on draft-ietf-mpls-sprin=
g-entropy-label


=C2=A0




Stewart -




=C2=A0




On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <=
stewart.bryan=
t@gmail.com> wrote:


I support this becoming a WG doc and thereby comming=
 under WG

control.




=C2=A0






The document is a WG doc.=C2=A0=C2=A0 We are now in =
WG last call.






=C2=A0






However I am not sure about the dismissal of the opt=
ion to reuse

the ELI+EL. This clutters the stack less than the proposed option.



Also I wonder why this is standards track?






=C2=A0






A reasonable question, particularly since there are =
no MUSTs, SHALLs or REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs=
.






=C2=A0






Surely any equipment that understands the ELI can do=
 this and thus this is just an informal description of the problem and a so=
lution.



Stewart










On 23/04/2016 08:53, Loa Andersson wrote:


Working Group,



This is to initiate a two week working group last call on

draft-ietf-mpls-spring-entropy-label.



Please send your comments to the mpls wg mailing list (mpls@ietf.org).



There are no IPR disclosures against this document.



All the authors and contributors (with one exception) have stated on

the working group mailing list that they are not aware of any other

IPRs that relates to this draft.



This working group last call ends May 12, 2016.





/Loa

for the MPLS wg chairs


=C2=A0










=C2=A0














--001a113df6c201d5360531a5edda--


From nobody Fri Apr 29 14:01:43 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A02712D63A; Fri, 29 Apr 2016 14:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmpAuy-E1W-b; Fri, 29 Apr 2016 14:01:40 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 20E4712D096; Fri, 29 Apr 2016 14:01:40 -0700 (PDT)
Received: by mail-ob0-x231.google.com with SMTP id n10so54171877obb.2; Fri, 29 Apr 2016 14:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RPb7afSBJ6QWS2IFT5RR9TUn9f0nZRhz4wBWwAjnt74=; b=pFMsepvdVDEQ6fAcRfFJ4jJtQ+NC2xV8BgbnaLABV8X+FLe1pcga6KflRyGUMOe8EV 2dfrzv7xaKcdPXkMPr+e9b8XQMbdyMMd+sx9MsEXxMQX6z3Wo3bdrPQht39jyQHzhwKe WqGOw4DkHtt/c+FeJYlFYIqTNuhX0+L8uQR0nI8N/YgUKnKDB7Z7Ju472J7iwtdqVHGm AvEXa8yqYDcqhn9M7218M29iy5Nl1BcnEIhq+lNtM3xNRuSvrflD9yIzL4RRyppWD/bN My79sBY+DBuZEfBAmmHtoW/jH0jx+mvIRhdzS0zjsp04LlqvwC+LnwzkOkoQtfHBIk/u 1ZNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RPb7afSBJ6QWS2IFT5RR9TUn9f0nZRhz4wBWwAjnt74=; b=iUnptkdlM9TakXl7RDyniniLtjSS/MW37Re3/tl+U/KtZRLYL4aqXRw7J3ZelzQNC/ YSMhjTAINX+0UvKYH/2Xx+fKwSaUlU5DaYtZhGwYVZG960y0Ln4hXql9D54+eOSIxUHE tgYTtiYnADicPdUzuCfwN9F/PtX/xLeEvIaucpZZpmNbIJVwnyS2/5T7951rscg/eDm3 h4n13VrDZalD8IJ5lzoK7KEVngy+QehdRPQDMXi0BZrzwNgBslKW8bx3w1MPoL5JzrLC Bnw1OYKWWtrY5dn3ztMjDAawkgKIZbSvjrrBjQUqzS0Fpi3PVXvC+y2/oA3wIRgoX/2P vgmA==
X-Gm-Message-State: AOPr4FUy+LDYXP5po2+zt7b29qwdJSISd2JG8KJqARzi/GRp00FdIEj8dHHKgHOL6SJ8g/cSuArQN+JbmDMECw==
X-Received: by 10.60.162.230 with SMTP id yd6mr10361729oeb.4.1461963699401; Fri, 29 Apr 2016 14:01:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 14:01:09 -0700 (PDT)
In-Reply-To: <7347100B5761DC41A166AC17F22DF11221A5F375@eusaamb103.ericsson.se>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <571EF6B9.403@pi.nu> <7347100B5761DC41A166AC17F22DF11221A5F375@eusaamb103.ericsson.se>
From: Sri 
Date: Fri, 29 Apr 2016 14:01:09 -0700
Message-ID: 
To: Gregory Mirsky 
Content-Type: multipart/alternative; boundary=047d7b5db6fafa3aa50531a5f2e2
Archived-At: 
Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:01:42 -0000

--047d7b5db6fafa3aa50531a5f2e2
Content-Type: text/plain; charset=UTF-8

A response to an earlier email from Greg, addresses all comments in this
email.

On Tue, Apr 26, 2016 at 6:05 PM, Gregory Mirsky  wrote:

> Hi Loa,
> if the WG decides to publish the document, then the Informational is the
> right track.
>
> Appreciate authors to consider my comment on generalizing references to an
> Entropy Label in the tuple as .
>
>         Regards,
>                 Greg
>
> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Monday, April 25, 2016 10:04 PM
> To: Gregory Mirsky; George Swallow; Stewart Bryant
> Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org;
> mpls-chairs@ietf.org
> Subject: Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
> Greg,
>
> (talking about the SHOULDs in Section 4 only)
>
> I think what George (and Stewart) says is that since the document does not
> use any MUST, SHALL or REQUIRED, it makes sense to publish it as an
> Informational RFC.
>
> However, it does not work to turn that argument around and say that an
> Informational RFC can't use the normative language, it was doen for example
> in RFC 7412.
>
> I think we should change it to Informational, but there is no need to do
> anything to the SHOULDs in section 4.
>
> /Loa
>
> On 2016-04-26 03:19, Gregory Mirsky wrote:
> > Hi George, et. al,
> >
> > I've found several occurrences, three actually, of SHOULD being used
> > in Section 4.
> >
> > And I agree with Stewart that application of  is the local
> > decision and, at most, this work can be published as Informational.
> >
> > One comment, suggestion:
> >
> > *the sample algorithm in Section 4 suggests that the same 
> > tuple been used multiple times whereas it may be advantageous to
> > generalize and point that the different entropy label value may be
> > used by referring to the tuple as 
> >
> > Regards,
> >
> >          Greg
> >
> > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George
> > Swallow
> > *Sent:* Monday, April 25, 2016 10:57 AM
> > *To:* Stewart Bryant
> > *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org;
> > mpls@ietf.org; mpls-chairs@ietf.org
> > *Subject:* Re: [mpls] working group last call on
> > draft-ietf-mpls-spring-entropy-label
> >
> > Stewart -
> >
> > On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant
> > > wrote:
> >
> > I support this becoming a WG doc and thereby comming under WG control.
> >
> > The document is a WG doc.   We are now in WG last call.
> >
> >     However I am not sure about the dismissal of the option to reuse
> >     the ELI+EL. This clutters the stack less than the proposed option.
> >
> >     Also I wonder why this is standards track?
> >
> > A reasonable question, particularly since there are no MUSTs, SHALLs
> > or REQUIREDs.  Will discuss with my Co-Chairs and ADs.
> >
> >     Surely any equipment that understands the ELI can do this and thus
> >     this is just an informal description of the problem and a solution.
> >
> >     Stewart
> >
> >
> >
> >     On 23/04/2016 08:53, Loa Andersson wrote:
> >
> >     Working Group,
> >
> >     This is to initiate a two week working group last call on
> >     draft-ietf-mpls-spring-entropy-label.
> >
> >     Please send your comments to the mpls wg mailing list (mpls@ietf.org
> >     ).
> >
> >     There are no IPR disclosures against this document.
> >
> >     All the authors and contributors (with one exception) have stated on
> >     the working group mailing list that they are not aware of any other
> >     IPRs that relates to this draft.
> >
> >     This working group last call ends May 12, 2016.
> >
> >
> >     /Loa
> >     for the MPLS wg chairs
> >
> >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--047d7b5db6fafa3aa50531a5f2e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


A response to an earlier email from Greg, addresses all co=
mments in this email.

On Tue, Apr 26, 2016 at 6:05 PM, Gregory Mirsky <grego=
ry.mirsky@ericsson.com> wrote:
Hi Loa,

if the WG decides to publish the document, then the Informational is the ri=
ght track.



Appreciate authors to consider my comment on generalizing references to an =
Entropy Label in the tuple as <ELI, ELn>.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg



-----Original Message-----

From: Loa Andersson [mailto:loa@pi.nu]

Sent: Monday, April 25, 2016 10:04 PM

To: Gregory Mirsky; George Swallow; Stewart Bryant

Cc: =
draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; m=
pls-chairs@ietf.org

Subject: Re: [mpls] working group last call on draf=
t-ietf-mpls-spring-entropy-label



Greg,



(talking about the SHOULDs in Section 4 only)



I think what George (and Stewart) says is that since the document does not =
use any MUST, SHALL or REQUIRED, it makes sense to publish it as an Informa=
tional RFC.



However, it does not work to turn that argument around and say that an Info=
rmational RFC can't use the normative language, it was doen for example=
 in RFC 7412.



I think we should change it to Informational, but there is no need to do an=
ything to the SHOULDs in section 4.



/Loa



On 2016-04-26 03:19, Gregory Mirsky wrote:

> Hi George, et. al,

>

> I've found several occurrences, three actually, of SHOULD being us=
ed

> in Section 4.

>

> And I agree with Stewart that application of <ELI, EL> is the lo=
cal

> decision and, at most, this work can be published as Informational.
>

> One comment, suggestion:

>

> *the sample algorithm in Section 4 suggests that the same <E=
LI,EL>


> tuple been used multiple times=
 whereas it may be advantageous to

> generalize and point that the different entropy label value may be

> used by referring to the tuple as <ELI, ELn>

>

> Regards,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg

>

> *From:*mpls [mailto:mpls-boun=
ces@ietf.org] *On Behalf Of *George

> Swallow

> *Sent:* Monday, April 25, 2016 10:57 AM

> *To:* Stewart Bryant

> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org;

> mpls@ietf.org; mpls-chairs@ietf.org

> *Subject:* Re: [mpls] working group last call on

> draft-ietf-mpls-spring-entropy-label

>

> Stewart -

>

> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant

> <stewart.bryant@gmail.c=
om <mailto:stewart.bryan=
t@gmail.com>> wrote:

>

> I support this becoming a WG doc and thereby comming under WG control.=


>

> The document is a WG doc.=C2=A0 =C2=A0We are now in WG last call.

>

>=C2=A0 =C2=A0 =C2=A0However I am not sure about the dismissal of the op=
tion to reuse

>=C2=A0 =C2=A0 =C2=A0the ELI+EL. This clutters the stack less than the p=
roposed option.

>

>=C2=A0 =C2=A0 =C2=A0Also I wonder why this is standards track?

>

> A reasonable question, particularly since there are no MUSTs, SHALLs
> or REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs.

>

>=C2=A0 =C2=A0 =C2=A0Surely any equipment that understands the ELI can d=
o this and thus

>=C2=A0 =C2=A0 =C2=A0this is just an informal description of the problem=
 and a solution.

>

>=C2=A0 =C2=A0 =C2=A0Stewart

>

>

>

>=C2=A0 =C2=A0 =C2=A0On 23/04/2016 08:53, Loa Andersson wrote:

>

>=C2=A0 =C2=A0 =C2=A0Working Group,

>

>=C2=A0 =C2=A0 =C2=A0This is to initiate a two week working group last c=
all on

>=C2=A0 =C2=A0 =C2=A0draft-ietf-mpls-spring-entropy-label.

>

>=C2=A0 =C2=A0 =C2=A0Please send your comments to the mpls wg mailing li=
st (mpls@ietf.org

>=C2=A0 =C2=A0 =C2=A0<mailto:mpls@ie=
tf.org>).

>

>=C2=A0 =C2=A0 =C2=A0There are no IPR disclosures against this document.=


>

>=C2=A0 =C2=A0 =C2=A0All the authors and contributors (with one exceptio=
n) have stated on

>=C2=A0 =C2=A0 =C2=A0the working group mailing list that they are not aw=
are of any other

>=C2=A0 =C2=A0 =C2=A0IPRs that relates to this draft.

>

>=C2=A0 =C2=A0 =C2=A0This working group last call ends May 12, 2016.

>

>

>=C2=A0 =C2=A0 =C2=A0/Loa

>=C2=A0 =C2=A0 =C2=A0for the MPLS wg chairs

>

>

>

> _______________________________________________

> mpls mailing list

> mpls@ietf.org

> https://www.ietf.org/mailman/listinfo/mpls

>



_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls





--047d7b5db6fafa3aa50531a5f2e2--


From nobody Fri Apr 29 14:13:13 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B1212D564; Fri, 29 Apr 2016 14:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 hgNeiUVQtwr8; Fri, 29 Apr 2016 14:13:09 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F4C12B069; Fri, 29 Apr 2016 14:13:08 -0700 (PDT)
X-AuditID: c618062d-f79886d000002334-11-5723c70e6fb3
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 30.20.09012.E07C3275; Fri, 29 Apr 2016 22:41:50 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 29 Apr 2016 17:13:07 -0400
From: Gregory Mirsky 
To: Sri 
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHRnvqgLrEm8VHuxEKbfrdW+MSR/p+bPPSA///Qq2CABquEgP//wITA
Date: Fri, 29 Apr 2016 21:13:06 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF11221A63A62@eusaamb103.ericsson.se>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221A63A62eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyuXRPuC7fceVwg/5d5hbnzp1itFh3+RSb xa2lK1kt7i86xmhx6kGixaLJy1gc2Dx2zrrL7rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVw Zby82ctY8GgnY8Xm+U4NjG+2MHYxcnJICJhIrJz9hQXCFpO4cG89WxcjF4eQwFFGie+3L0M5 yxkluje8ZwKpYhMwknixsYcdxBYRUJRYPu8hC0gRs8BsJomfxx6BjRIWCJWYuOUvC0RRmMTO +bOZIGw3ibb+C6wgNouAqsTBFdvA4rwCvhJrV3xkgtg2mUni+/89bCAJToFAifU/ToMNYgS6 7/upNWANzALiEreezGeCuFtAYsme88wQtqjEy8f/WCFsRYl9/dOBLuUAqs+XePO8FGKXoMTJ mU9YJjCKzkIyaRZC1SwkVRBhTYn1u/QhqhUlpnQ/ZIewNSRa58xlRxZfwMi+ipGjtLggJzfd yGATIzAOj0mw6e5gvD/d8xCjAAejEg9vwg+lcCHWxLLiytxDjBIczEoivKdPKYcL8aYkVlal FuXHF5XmpBYfYpTmYFES5xV7pBguJJCeWJKanZpakFoEk2Xi4JRqYEzQ+rpQ4Vz0qgb7P1fF 9y60OLQh+KHkB1XFoLVvipQOMtct/XScTc3Blu/ovuqw+jexe1JTCtapJGbk3vIznvqPeaFu 2Sv/g3uu+z4JsdxT8ezOB6bQ3a+vB37ft2TDar/Nbj4lm4/WarMX2fc4WfCfnHhFO3FK3dfX F32Er93OUJJMD9poelqJpTgj0VCLuag4EQBM7uNBvwIAAA==
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls-chairs@ietf.org" , "mpls@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:13:12 -0000

--_000_7347100B5761DC41A166AC17F22DF11221A63A62eusaamb103erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgU3JpLA0KSSBhZ3JlZSB3aXRoIHRoZSB3YXkgeW91IHBsYW4gdG8gYWRkcmVzcyBteSBjb21t
ZW50ICMyLg0KDQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBTcmkgW21haWx0bzpzcmlnYW5lc2hraW5pQGdtYWls
LmNvbV0NClNlbnQ6IEZyaWRheSwgQXByaWwgMjksIDIwMTYgMTo1OSBQTQ0KVG86IEdyZWdvcnkg
TWlyc2t5DQpDYzogR2VvcmdlIFN3YWxsb3c7IFN0ZXdhcnQgQnJ5YW50OyBkcmFmdC1pZXRmLW1w
bHMtc3ByaW5nLWVudHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmc7IG1w
bHMtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFz
dCBjYWxsIG9uIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbA0KDQpIaSBHcmVn
LA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBscyBzZWUgaW5saW5lLg0KDQpPbiBNb24s
IEFwciAyNSwgMjAxNiBhdCAxMjoxOSBQTSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5
QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6
DQpIaSBHZW9yZ2UsIGV0LiBhbCwNCknigJl2ZSBmb3VuZCBzZXZlcmFsIG9jY3VycmVuY2VzLCB0
aHJlZSBhY3R1YWxseSwgb2YgU0hPVUxEIGJlaW5nIHVzZWQgaW4gU2VjdGlvbiA0Lg0KDQpBbmQg
SSBhZ3JlZSB3aXRoIFN0ZXdhcnQgdGhhdCBhcHBsaWNhdGlvbiBvZiA8RUxJLCBFTD4gaXMgdGhl
IGxvY2FsIGRlY2lzaW9uIGFuZCwgYXQgbW9zdCwgdGhpcyB3b3JrIGNhbiBiZSBwdWJsaXNoZWQg
YXMgSW5mb3JtYXRpb25hbC4NCg0KU3JpPiBBcyBwZXIgbXkgcmVzcG9uc2UgdG8gTG9hJ3Mgc3Vn
Z2VzdGlvbiwgdGhlIGRyYWZ0IHdpbGwgYmUgY2hhbmdlZCB0byBpbmZvcm1hdGlvbmFsIHdpdGgg
YWxsIHRoZSBTSE9VTERzIHJldGFpbmVkLg0KDQpPbmUgY29tbWVudCwgc3VnZ2VzdGlvbjoNCg0K
4oCiICAgICAgICAgdGhlIHNhbXBsZSBhbGdvcml0aG0gaW4gU2VjdGlvbiA0IHN1Z2dlc3RzIHRo
YXQgdGhlIHNhbWUgPEVMSSxFTD4gdHVwbGUgYmVlbiB1c2VkIG11bHRpcGxlIHRpbWVzIHdoZXJl
YXMgaXQgbWF5IGJlIGFkdmFudGFnZW91cyB0byBnZW5lcmFsaXplIGFuZCBwb2ludCB0aGF0IHRo
ZSBkaWZmZXJlbnQgZW50cm9weSBsYWJlbCB2YWx1ZSBtYXkgYmUgdXNlZCBieSByZWZlcnJpbmcg
dG8gdGhlIHR1cGxlIGFzIDxFTEksIEVMbj4NCg0KU3JpPiBXZSBoYWQgc2hvd24gdGhhdCBFTHMg
bWF5IGJlIGRpZmZlcmVudCBpbiB0aGUgZXhhbXBsZSBpbiBhbiBlYXJsaWVyIHZlcnNpb24gb2Yg
dGhlIGRyYWZ0LiBJbnN0ZWFkIG9mIHJlZmVycmluZyB0byBFTG4sIEkgd291bGQgc3VnZ2VzdCB0
aGF0IGEgc2Vjb25kIHNlbnRlbmNlIGJlIGFkZGVkIGluIHRoZSB0aGlyZCBwYXJhIGluIHNlYyA0
IGFzIGZvbGxvd3MgIlRoZSBFTHMgYW1vbmcgbXVsdGlwbGUgPEVMSSwgRUw+IHBhaXJzIGluc2Vy
dGVkIGluIHRoZSBzdGFjayBtYXkgYmUgc2FtZSBvciBkaWZmZXJlbnQiLg0KDQoNClJlZ2FyZHMs
DQogICAgICAgIEdyZWcNCg0KDQoNClRoYW5rcw0KU3JpDQoNCkZyb206IG1wbHMgW21haWx0bzpt
cGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl
aGFsZiBPZiBHZW9yZ2UgU3dhbGxvdw0KU2VudDogTW9uZGF5LCBBcHJpbCAyNSwgMjAxNiAxMDo1
NyBBTQ0KVG86IFN0ZXdhcnQgQnJ5YW50DQpDYzogZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRy
b3B5LWxhYmVsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVu
dHJvcHktbGFiZWxAdG9vbHMuaWV0Zi5vcmc+OyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGll
dGYub3JnPjsgbXBscy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtY2hhaXJzQGlldGYub3Jn
Pg0KU3ViamVjdDogUmU6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1p
ZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwNCg0KU3Rld2FydCAtDQoNCk9uIE1vbiwgQXBy
IDI1LCAyMDE2IGF0IDk6NTggQU0sIFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFp
bC5jb208bWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4+IHdyb3RlOg0KSSBzdXBwb3J0
IHRoaXMgYmVjb21pbmcgYSBXRyBkb2MgYW5kIHRoZXJlYnkgY29tbWluZyB1bmRlciBXRw0KY29u
dHJvbC4NCg0KVGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jLiAgIFdlIGFyZSBub3cgaW4gV0cgbGFz
dCBjYWxsLg0KDQpIb3dldmVyIEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGRpc21pc3NhbCBvZiB0
aGUgb3B0aW9uIHRvIHJldXNlDQp0aGUgRUxJK0VMLiBUaGlzIGNsdXR0ZXJzIHRoZSBzdGFjayBs
ZXNzIHRoYW4gdGhlIHByb3Bvc2VkIG9wdGlvbi4NCg0KQWxzbyBJIHdvbmRlciB3aHkgdGhpcyBp
cyBzdGFuZGFyZHMgdHJhY2s/DQoNCkEgcmVhc29uYWJsZSBxdWVzdGlvbiwgcGFydGljdWxhcmx5
IHNpbmNlIHRoZXJlIGFyZSBubyBNVVNUcywgU0hBTExzIG9yIFJFUVVJUkVEcy4gIFdpbGwgZGlz
Y3VzcyB3aXRoIG15IENvLUNoYWlycyBhbmQgQURzLg0KDQpTdXJlbHkgYW55IGVxdWlwbWVudCB0
aGF0IHVuZGVyc3RhbmRzIHRoZSBFTEkgY2FuIGRvIHRoaXMgYW5kIHRodXMgdGhpcyBpcyBqdXN0
IGFuIGluZm9ybWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIGFuZCBhIHNvbHV0aW9uLg0K
DQpTdGV3YXJ0DQoNCg0KT24gMjMvMDQvMjAxNiAwODo1MywgTG9hIEFuZGVyc3NvbiB3cm90ZToN
CldvcmtpbmcgR3JvdXAsDQoNClRoaXMgaXMgdG8gaW5pdGlhdGUgYSB0d28gd2VlayB3b3JraW5n
IGdyb3VwIGxhc3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVs
Lg0KDQpQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdnIG1haWxpbmcgbGlz
dCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLg0KDQpUaGVyZSBhcmUgbm8g
SVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCg0KQWxsIHRoZSBhdXRob3Jz
IGFuZCBjb250cmlidXRvcnMgKHdpdGggb25lIGV4Y2VwdGlvbikgaGF2ZSBzdGF0ZWQgb24NCnRo
ZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBh
bnkgb3RoZXINCklQUnMgdGhhdCByZWxhdGVzIHRvIHRoaXMgZHJhZnQuDQoNClRoaXMgd29ya2lu
ZyBncm91cCBsYXN0IGNhbGwgZW5kcyBNYXkgMTIsIDIwMTYuDQoNCg0KL0xvYQ0KZm9yIHRoZSBN
UExTIHdnIGNoYWlycw0KDQoNCg0K

--_000_7347100B5761DC41A166AC17F22DF11221A63A62eusaamb103erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl
dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h
bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0
eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy
aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4
PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8
bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i
MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5
IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgU3JpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij5JIGFncmVlIHdpdGggdGhlIHdheSB5b3UgcGxhbiB0byBhZGRyZXNzIG15IGNvbW1lbnQgIzIu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFNyaSBbbWFpbHRvOnNyaWdhbmVzaGtp
bmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXByaWwgMjksIDIwMTYg
MTo1OSBQTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IEdl
b3JnZSBTd2FsbG93OyBTdGV3YXJ0IEJyeWFudDsgZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRy
b3B5LWxhYmVsQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnOyBtcGxzLWNoYWlyc0BpZXRm
Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBj
YWxsIG9uIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEdyZWcsPG86cD48L286cD48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBscyBzZWUg
aW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g
TW9uLCBBcHIgMjUsIDIwMTYgYXQgMTI6MTkgUE0sIEdyZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVm
PSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3Jl
Z29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEdlb3JnZSwgZXQuIGFsLDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPknigJl2ZSBmb3VuZCBzZXZlcmFsIG9jY3VycmVuY2VzLCB0aHJlZSBh
Y3R1YWxseSwgb2YgU0hPVUxEIGJlaW5nIHVzZWQgaW4gU2VjdGlvbiA0Ljwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkFuZCBJIGFncmVlIHdpdGggU3Rld2FydCB0aGF0IGFwcGxpY2F0aW9uIG9mICZsdDtFTEksIEVM
Jmd0OyBpcyB0aGUgbG9jYWwgZGVjaXNpb24gYW5kLCBhdCBtb3N0LCB0aGlzIHdvcmsNCiBjYW4g
YmUgcHVibGlzaGVkIGFzIEluZm9ybWF0aW9uYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNyaSZndDsgQXMgcGVy
IG15IHJlc3BvbnNlIHRvIExvYSdzIHN1Z2dlc3Rpb24sIHRoZSBkcmFmdCB3aWxsIGJlIGNoYW5n
ZWQgdG8gaW5mb3JtYXRpb25hbCB3aXRoIGFsbCB0aGUgU0hPVUxEcyByZXRhaW5lZC48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5P
bmUgY29tbWVudCwgc3VnZ2VzdGlvbjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+
wrc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhlIHNhbXBsZSBhbGdvcml0
aG0gaW4gU2VjdGlvbiA0IHN1Z2dlc3RzIHRoYXQgdGhlIHNhbWUgJmx0O0VMSSxFTCZndDsgdHVw
bGUgYmVlbiB1c2VkIG11bHRpcGxlIHRpbWVzIHdoZXJlYXMgaXQgbWF5IGJlIGFkdmFudGFnZW91
cyB0byBnZW5lcmFsaXplIGFuZCBwb2ludCB0aGF0IHRoZSBkaWZmZXJlbnQNCiBlbnRyb3B5IGxh
YmVsIHZhbHVlIG1heSBiZSB1c2VkIGJ5IHJlZmVycmluZyB0byB0aGUgdHVwbGUgYXMgJmx0O0VM
SSwgRUxuJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcmkmZ3Q7IFdlIGhhZCBzaG93
biB0aGF0IEVMcyBtYXkgYmUgZGlmZmVyZW50IGluIHRoZSBleGFtcGxlIGluIGFuIGVhcmxpZXIg
dmVyc2lvbiBvZiB0aGUgZHJhZnQuIEluc3RlYWQgb2YgcmVmZXJyaW5nIHRvIEVMbiwgSSB3b3Vs
ZCBzdWdnZXN0IHRoYXQgYSBzZWNvbmQgc2VudGVuY2UgYmUgYWRkZWQgaW4gdGhlIHRoaXJkIHBh
cmEgaW4gc2VjIDQgYXMgZm9sbG93cyAmcXVvdDtUaGUgRUxzIGFtb25nIG11bHRpcGxlICZsdDtF
TEksDQogRUwmZ3Q7IHBhaXJzIGluc2VydGVkIGluIHRoZSBzdGFjayBtYXkgYmUgc2FtZSBvciBk
aWZmZXJlbnQmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IEdyZWc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5Tcmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtcGxz
IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkdl
b3JnZSBTd2FsbG93PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMjUsIDIwMTYgMTA6
NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IFN0ZXdhcnQgQnJ5YW50PGJyPg0KPGI+Q2M6PC9iPiA8YSBo
cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsQHRvb2xzLmll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHkt
bGFiZWxAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiPg0KbXBsc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzptcGxz
LWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtY2hhaXJzQGlldGYub3JnPC9h
Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs
IG9uIGRyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0ZXdhcnQgLTxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBNb24sIEFwciAyNSwgMjAxNiBh
dCA5OjU4IEFNLCBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5
YW50QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHN1
cHBvcnQgdGhpcyBiZWNvbWluZyBhIFdHIGRvYyBhbmQgdGhlcmVieSBjb21taW5nIHVuZGVyIFdH
PGJyPg0KY29udHJvbC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj5UaGUgZG9jdW1lbnQgaXMgYSBXRyBkb2MuJm5ic3A7Jm5ic3A7IFdlIGFyZSBub3cg
aW4gV0cgbGFzdCBjYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPkhvd2V2ZXIgSSBhbSBub3Qgc3VyZSBhYm91dCB0aGUgZGlzbWlzc2FsIG9mIHRoZSBvcHRp
b24gdG8gcmV1c2U8YnI+DQp0aGUgRUxJJiM0MztFTC4gVGhpcyBjbHV0dGVycyB0aGUgc3RhY2sg
bGVzcyB0aGFuIHRoZSBwcm9wb3NlZCBvcHRpb24uPGJyPg0KPGJyPg0KQWxzbyBJIHdvbmRlciB3
aHkgdGhpcyBpcyBzdGFuZGFyZHMgdHJhY2s/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSByZWFzb25hYmxlIHF1ZXN0aW9u
LCBwYXJ0aWN1bGFybHkgc2luY2UgdGhlcmUgYXJlIG5vIE1VU1RzLCBTSEFMTHMgb3IgUkVRVUlS
RURzLiZuYnNwOyBXaWxsIGRpc2N1c3Mgd2l0aCBteSBDby1DaGFpcnMgYW5kIEFEcy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdXJlbHkgYW55IGVxdWlwbWVu
dCB0aGF0IHVuZGVyc3RhbmRzIHRoZSBFTEkgY2FuIGRvIHRoaXMgYW5kIHRodXMgdGhpcyBpcyBq
dXN0IGFuIGluZm9ybWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtIGFuZCBhIHNvbHV0aW9u
LjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQpTdGV3YXJ0PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N
Cjxicj4NCk9uIDIzLzA0LzIwMTYgMDg6NTMsIExvYSBBbmRlcnNzb24gd3JvdGU6PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvcmtpbmcgR3JvdXAsPGJyPg0KPGJyPg0K
VGhpcyBpcyB0byBpbml0aWF0ZSBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9u
PGJyPg0KZHJhZnQtaWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsLjxicj4NCjxicj4NClBs
ZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG1wbHMgd2cgbWFpbGluZyBsaXN0ICg8YSBo
cmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8
L2E+KS48YnI+DQo8YnI+DQpUaGVyZSBhcmUgbm8gSVBSIGRpc2Nsb3N1cmVzIGFnYWluc3QgdGhp
cyBkb2N1bWVudC48YnI+DQo8YnI+DQpBbGwgdGhlIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyAo
d2l0aCBvbmUgZXhjZXB0aW9uKSBoYXZlIHN0YXRlZCBvbjxicj4NCnRoZSB3b3JraW5nIGdyb3Vw
IG1haWxpbmcgbGlzdCB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBhbnkgb3RoZXI8YnI+DQpJ
UFJzIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NClRoaXMgd29ya2luZyBn
cm91cCBsYXN0IGNhbGwgZW5kcyBNYXkgMTIsIDIwMTYuPGJyPg0KPGJyPg0KPGJyPg0KL0xvYTxi
cj4NCmZvciB0aGUgTVBMUyB3ZyBjaGFpcnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7347100B5761DC41A166AC17F22DF11221A63A62eusaamb103erics_--


From nobody Fri Apr 29 14:15:42 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DBA12D734; Fri, 29 Apr 2016 14:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLvvBL-0Rf04; Fri, 29 Apr 2016 14:15:40 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 073DE12D6F2; Fri, 29 Apr 2016 14:15:40 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id e201so42192992wme.0; Fri, 29 Apr 2016 14:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ioKf1Al0HJNwBcHQOlwGxdDD/CT9PieWTOzbE/+C+34=; b=iiULthyA8a4+bRfguTeCLPo9duljDNdyGhQ75eGiLFmOpEWt5aYfKHvLtK0o5jslmx aW1v0r+IEAc72qENEc+QugNiTbkbL1WMaIq5p+2rFdpWV5CStnsDI1n74swRhxrA01Nc c7QKLXowKQhjHJVjTNsLyKjxuZSnvAysU7H7Y7SmpTw/0vZ+vGxuA7Yl7zzY1xP9SQjk SOhhw3p6Xy/Rbe23w/MJolIdnkURkYr2JcNJ22IYB/DEAy8gF/KvsrAWKPtp+VvJtRIX Z97TFAenVc6sm4O10s7OYSyp9tfc6pIx/8dj2M5pu33z2tKi8FImSojoR0uVY8Q2P/mF teig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ioKf1Al0HJNwBcHQOlwGxdDD/CT9PieWTOzbE/+C+34=; b=Sn17ahs0MkzpqyHTIp05r+ADiDr1szp5NzKeNug7OWJ75Mt0iskJyL0SV9DAbjwasN z0H1ell7O1ZpDEAVmnzOscdD18Mx8jcERHeTEUHSdYPhaWgoUZrO8RJfHSO3OlbfpSLA CFxLbhEcOjxitCK34sQZuTuMNshW46SSS97Oon9Dq9AzBmpFqegJrQTLfruBCpSfzxb0 bqMTpTsg5ity6HXeF8G1NlZRdea/BHmySGDp9QT0k/Z6KxC/0L3expyXL74uin3lIWKj hvM81/4gSPqILo8Wf575f0KMZzCQ8LApXwTyj1sHTcJi6q3lNs0RCJUIYujxXlianq6j fjBA==
X-Gm-Message-State: AOPr4FXzDB+fmf1zqPOSBwTzH7xydK5JKTiiT1Y9BjderidOcwJq/f51TL+uf7JshWgxYQ==
X-Received: by 10.194.134.73 with SMTP id pi9mr23416707wjb.156.1461964538596;  Fri, 29 Apr 2016 14:15:38 -0700 (PDT)
Received: from [192.168.2.133] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id p67sm5085844wmp.17.2016.04.29.14.15.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 14:15:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-7368EA22-6FD2-4E2E-977C-DB04A9272F9B
Mime-Version: 1.0 (1.0)
From: Stewart Bryant 
X-Mailer: iPhone Mail (13E238)
In-Reply-To: 
Date: Fri, 29 Apr 2016 22:15:36 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <571E69F2.8020506@gmail.com> 
To: Sri 
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:15:41 -0000

--Apple-Mail-7368EA22-6FD2-4E2E-977C-DB04A9272F9B
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable



> On 29 Apr 2016, at 21:41, Sri  wrote:
>=20
> Sri> Just re-iterating a response to a similar point in an earlier email -=
  "Since there are different ways to do this and some ways are better than o=
thers, this draft lists the different options and recommends one solution."

Hi Sri

We don't normally make a formal recommendation on a local matter such as thi=
s.

Stewart=20=

--Apple-Mail-7368EA22-6FD2-4E2E-977C-DB04A9272F9B
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit




On 29 Apr 2016, at 21:41, Sri <sriganeshkini@gmail.com> wrote:

Sri> Just re-iterating a response to a similar point in an earlier email -  "Since there are different ways to do this and some ways are better than others, this draft lists the different options and recommends one solution."

Hi Sri

We don't normally make a formal recommendation on a local matter such as this.

Stewart 

--Apple-Mail-7368EA22-6FD2-4E2E-977C-DB04A9272F9B--


From nobody Fri Apr 29 14:38:11 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0292412D769; Fri, 29 Apr 2016 14:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSa43gxqCUbJ; Fri, 29 Apr 2016 14:37:43 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 84B7C12B04A; Fri, 29 Apr 2016 14:37:42 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id k142so133416400oib.1; Fri, 29 Apr 2016 14:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GOgRIpdf91ypp6SXXk28hMFuc0RN/P96RhTyzi9TCTU=; b=k+SpWn+z19YkbGibrQtxFcGq6d3CS4qDyq9j8yIbgB5JhyQZ8Fvo1EFZ9IDxqsdmAO jWGY8Mrwk2/SSFULMoOZ3jJLPQPxnAUE8TkABfq/CTDG05N/cmlTqUFkh7gQ13xP1G9q /fm+fJRHBn7y8atHO8ZzV1TTnGjROR3dW+jZUHYC81ldx4mNrNF2Layi7NViBH+qihVQ ZfJbwDl2JgGffAtajY8QBNo74fs1b9WU79bEH+ZS0qHUc21/vNQEQy5Ncz677jfOulXK xjpGvW/JlBukU0rmyGBi4vtCDjoH4/WV8jfXqA1OsFyUPSFlxhWRYfFF69umxYb6jYDh He6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GOgRIpdf91ypp6SXXk28hMFuc0RN/P96RhTyzi9TCTU=; b=WZGodAOrK2oDu1ef5XcPzn+T+R2y3DRHKLGOpANcux8OS/7WK8gFRD/7buXaDsedVm 0cQMvz4BrWnYY8cbnePtF22BsSVefaEVykIAVd+UNuo3WxD5leGJuX2O4GwbBE8Q+3li +Nz+AjzeqO/QDdvtRylFEEtB28ISDB88a5v0z7NYc87xZ2r7OTQfJCJYsB46TzFzY//T rs3cl41g+5eDa6rTRP5cxxkkRQ1UYrHUqhroCEmDEGA7iCCpvE1lH3CHWHqVXyIAxOzC I10Ow/klogUXh9RiB2vrJ0bxuGYglXJK9mzDnr5vZQHWI9yv7xHNcPE3TgZZBgUzDUg+ 6aFA==
X-Gm-Message-State: AOPr4FXxcxDznZUQGeeaoRqg+98Pk/0upICtfDApxGbmpoycuw/ELZvQ3hvp0nvFPWNPUvwNkP8ekYXEpkgzUA==
X-Received: by 10.202.108.19 with SMTP id h19mr4910465oic.69.1461965861901; Fri, 29 Apr 2016 14:37:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 14:37:12 -0700 (PDT)
In-Reply-To: <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com>
From: Sri 
Date: Fri, 29 Apr 2016 14:37:12 -0700
Message-ID: 
To: "Carlos Pignataro (cpignata)" 
Content-Type: multipart/alternative; boundary=001a1142e14adf66c60531a673ee
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:37:53 -0000

--001a1142e14adf66c60531a673ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Carlos,

Thanks for your comments. Pls see inline.

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Loa,
>
> I just scanned through draft-ietf-mpls-spring-entropy-label-03 and wanted
> to share some observations. Please treat these as WGLC comments.
>
> I have a number of concerns. It seems as if this document was not really
> reviewed to see if it was ready for WGLC:
>
> 1. What is this document specifying?
>
> As Greg just mentioned below, there are several SHOULD terms in Section 4=
.
> Those SHOULD are dependent upon the =E2=80=9CRLD".
>
>
Sri> As per my response to Loa's suggestion, this draft would be changed to
Informational with all the SHOULDs retained.


> That same section then lists the following:
>
>    The RLD can be advertised via protocols and those extensions are
>    described in separate documents [I-D.xu-isis-mpls-elc] and
>    [I-D.xu-ospf-mpls-elc].
>
> First, those are expired and should be marked as replaced by wg docs.
>

Sri> Accepted. These references would be updated.


>
> But the main point is that knowing the RLD is REQUIRED (neither
> RECOMMENDED nor OPTIONAL) to be able to follow and comply with the
> requirements on where to position the {ELI; EL} and with the pseudocode.
>

Sri> The RLD is required to follow the recommended solution in the draft.
What exactly is the comment?


>
>
> 2. OAM?
>
> The document says the following:
>
>    The recommendations above are not expected to bring any additional
>    OAM considerations beyond those described in section 6 of [RFC6790].
>    However, the OAM requirements and solutions for source routed tunnels
>    formed by label stacking are still under discussion and future
>    revisions of this document will address those if needed.
>
> Is this saying that the document still needs to evolve to be ready? What
> are really the OAM considerations related to this draft?
>

Sri> There are no new OAM consideration related to the recommendations in
this draft. Having said that, the SPRING OAM drafts are not RFCs yet. Hence
the wording.


>
>
> 3. Intended status:
>
> I agree with others in the sense that this is not a Standards Track doc.
>

Sri> As per an earlier response to Loa's suggestion, the draft will be
changed to Informational.


>
>
> 4. EL Capability?
>
> This is probably the most important comment. The document defines the ELC
> acronym, but it does not use it.
>

Sri> ELC is not defined in this draft. It is taken from RFC6790


>
>       ELC - Entropy Label Capability
>
> From RFC 6790, the egress capability of processing EL needs to be signale=
d
> to the ingress for the ingress to be able to insert an ELI; EL.
>
> In this case, the proposed method tries to optimize for position, but it
> is not taking into account whether the egress of each segment can actuall=
y
> process ELI; EL (or if it would otherwise Drop the packet!). The algorith=
m
> does says =E2=80=9Cif EL-capable=E2=80=9D, but how is that learned?
>

Sri> RFC6790 defined procedures to signal ELC, but did not do so for
OSPF/ISIS and these are defined in the documents referenced -
draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed to
the WG draft versions).


>
> In other words, this seems like a bug. Is the ingress is inserting a labe=
l
> (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for example) =
might not
> understand and would drop?
>

Sri> No. The recommended solution takes ELC into account and the
advertisement of ELC is as per the referenced drafts/RFCs.


>
> 5. Labels to push?
>
> Inserting N * 2 LSEs can have implications on the head-end in terms of ma=
x
> numbers of labels which can be pushed. A label stack that is pushed onto =
a
> packet, might not be able to be pushed if the stack grows by 2 * N LSEs.
>
> The text says in various portions things like:
>
>    The LSR that inserts  pairs MAY have limitations
>    on the number of such pairs that it can insert and also the depth at
>    which it can insert them.
>
> However, is it really the limitation how many labels an ingress can push?
>

Sri> How about re-wording it as "The LSR that inserts  pairs MAY
have limitations on the number of labels that can be pushed and this can
limit the number of  pairs that it can insert and also the depth
at which it can insert them".


> Also, if there is one node in the path which does not advertise the RLD,
> then would the RLD be zero and make the algorithm moot?
>

Sri> If the RLD of a node is not available at the headend, then it is a
local matter on how to treat it.


>
>
> More editorial comments:
>
> No reference to draft-ietf-spring-segment-routing-mpls?
>

Sri> Accepted. Will add it.


>
>
>    Source routed tunnels with label stacking is a technique that can be
>    leveraged to provide a method to steer a packet through a controlled
>    set of segments.
>
> Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D (SRTLS?) =
and not Segment
> Routing with MPLS data plane?
>

Sri> Because Segment Routing is based on Source Routing.


>
>       OAM - Operation, Administration and Maintenance
>
> Should be "OAM - Operation, Administration, and Maintenance"
>

Sri> Accepted


>
>
>    [I-D.xu-isis-mpls-elc]
>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>               Litkowski, "Signaling Entropy Label Capability Using IS-
>               IS", draft-xu-isis-mpls-elc-02 (work in progress), April
>               2015.
>
>    [I-D.xu-ospf-mpls-elc]
>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>               Litkowski, "Signaling Entropy Label Capability Using
>               OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
>               October 2014.
>
>
> These are expired and replaced by other documents. They should be marked
> as Replaced-by in the Tracker.
>

Sri> Accepted


>
> Thanks!
>
> =E2=80=94 Carlos.
>
> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky 
> wrote:
>
> Hi George, et. al,
> I=E2=80=99ve found several occurrences, three actually, of SHOULD being u=
sed in
> Section 4.
>
> And I agree with Stewart that application of  is the local
> decision and, at most, this work can be published as Informational.
> One comment, suggestion:
> =C2=B7         the sample algorithm in Section 4 suggests that the same
>  tuple been used multiple times whereas it may be advantageous to
> generalize and point that the different entropy label value may be used b=
y
> referring to the tuple as 
>
> Regards,
>         Greg
>
>
> *From:* mpls [mailto:mpls-bounces@ietf.org ] *On
> Behalf Of *George Swallow
> *Sent:* Monday, April 25, 2016 10:57 AM
> *To:* Stewart Bryant
> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org;
> mpls-chairs@ietf.org
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
> Stewart -
>
> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant 
> wrote:
> I support this becoming a WG doc and thereby comming under WG
> control.
>
> The document is a WG doc.   We are now in WG last call.
>
>
> However I am not sure about the dismissal of the option to reuse
> the ELI+EL. This clutters the stack less than the proposed option.
>
> Also I wonder why this is standards track?
>
>
> A reasonable question, particularly since there are no MUSTs, SHALLs or
> REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>
>
> Surely any equipment that understands the ELI can do this and thus this i=
s
> just an informal description of the problem and a solution.
>
> Stewart
>
>
> On 23/04/2016 08:53, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-ietf-mpls-spring-entropy-label.
>
> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>
> There are no IPR disclosures against this document.
>
> All the authors and contributors (with one exception) have stated on
> the working group mailing list that they are not aware of any other
> IPRs that relates to this draft.
>
> This working group last call ends May 12, 2016.
>
>
> /Loa
> for the MPLS wg chairs
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>

--001a1142e14adf66c60531a673ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Carlos,

Thanks for your comments. Pl=
s see inline.

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <cpignata@=
cisco.com> wrote:
Loa,

I just scanned through=
=C2=A0draft-ietf-mpls-spring-entropy-label-03 and wanted to share some obse=
rvations. Please treat these as WGLC comments.

I h=
ave a number of concerns. It seems as if this document was not really revie=
wed to see if it was ready for WGLC:

1. What is th=
is document specifying?

As Greg just mentioned bel=
ow, there are several SHOULD terms in Section 4. Those SHOULD are dependent=
 upon the =E2=80=9CRLD".

<=
br>
Sri> As per my response to Loa's suggestion, this draf=
t would be changed to Informational with all the SHOULDs retained.
=C2=A0
That same section then lists the following:

=C2=A0 =C2=A0The RLD can be advertised via protocols a=
nd those extensions are
=C2=A0 =C2=A0described in separate docume=
nts [I-D.xu-isis-mpls-elc] and
=C2=A0 =C2=A0[I-D.xu-ospf-mpls-elc=
].

First, those are expired and should be ma=
rked as replaced by wg docs.

Sr=
i> Accepted. These references would be updated.
=C2=A0

<=
/div>
But the main point is that knowing the RLD is REQUIRED (neither R=
ECOMMENDED nor OPTIONAL) to be able to follow and comply with the requireme=
nts on where to position the {ELI; EL} and with the pseudocode.
=


Sri> The RLD is required to follow the =
recommended solution in the draft. What exactly is the comment?
=
=C2=A0


2. OAM?

The=
 document says the following:

=C2=A0 =C2=A0Th=
e recommendations above are not expected to bring any additional
=
=C2=A0 =C2=A0OAM considerations beyond those described in section 6 of [RFC=
6790].
=C2=A0 =C2=A0However, the OAM requirements and solutions f=
or source routed tunnels
=C2=A0 =C2=A0formed by label stacking ar=
e still under discussion and future
=C2=A0 =C2=A0revisions of thi=
s document will address those if needed.

Is =
this saying that the document still needs to evolve to be ready? What are r=
eally the OAM considerations related to this draft?

Sri> There are no new OAM consideration related to =
the recommendations in this draft. Having said that, the SPRING OAM drafts =
are not RFCs yet. Hence the wording.
=C2=A0


=

3. Intended status:

I agree with others=
 in the sense that this is not a Standards Track doc.

Sri> As per an earlier response to Loa's sugg=
estion, the draft will be changed to Informational.
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

=


4. EL Capability?

This i=
s probably the most important comment. The document defines the ELC acronym=
, but it does not use it.

Sri&g=
t; ELC is not defined in this draft. It is taken from RFC6790
=C2=
=A0

=C2=A0 =C2=A0 =C2=A0 ELC - Entropy Label Capability

From RFC 6790, the egress capability of processing E=
L needs to be signaled to the ingress for the ingress to be able to insert =
an ELI; EL.=C2=A0

In this case, the proposed metho=
d tries to optimize for position, but it is not taking into account whether=
 the egress of each segment can actually process ELI; EL (or if it would ot=
herwise Drop the packet!). The algorithm does says =E2=80=9Cif EL-capable=
=E2=80=9D, but how is that learned?=C2=A0

=

Sri> RFC6790 defined procedures to signal ELC, but did not do=
 so for OSPF/ISIS and these are defined in the documents referenced - draft=
-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed to the =
WG draft versions).
=C2=A0

In other words, this =
seems like a bug. Is the ingress is inserting a label (ELI) which the =E2=
=80=9Cegress=E2=80=9D (each Node segment for example) might not understand =
and would drop?

Sri> No. The=
 recommended solution takes ELC into account and the advertisement of ELC i=
s as per the referenced drafts/RFCs.=C2=A0


=

5. Labels to push?

Inserting N * 2 =
LSEs can have implications on the head-end in terms of max numbers of label=
s which can be pushed. A label stack that is pushed onto a packet, might no=
t be able to be pushed if the stack grows by 2 * N LSEs.=C2=A0
The text says in various portions things like:

<=
/div>
=C2=A0 =C2=A0The LSR that inserts <ELI, EL> pairs MAY =
have limitations
=C2=A0 =C2=A0on the number of such pairs that it=
 can insert and also the depth at
=C2=A0 =C2=A0which it can inser=
t them. =C2=A0

However, is it really the lim=
itation how many labels an ingress can push?
<=
br>
Sri> How about re-wording it as "The LSR that inserts=
 <ELI, EL> pairs MAY have limitations on the number of labels that ca=
n be pushed and this can limit the number of <ELI, EL> pairs that it =
can insert and also the depth at which it can insert them".
=


Also, if there is one node in the path which does not=
 advertise the RLD, then would the RLD be zero and make the algorithm moot?=


Sri> If the RLD of a node i=
s not available at the headend, then it is a local matter on how to treat i=
t.
=C2=A0


More editorial comments=
:

No reference to=C2=A0draft-ietf-spring-segm=
ent-routing-mpls?

Sri>=
 Accepted. Will add it.
=C2=A0


=C2=A0 =C2=A0Source routed tunnels with label stacking is a technique th=
at can be
=C2=A0 =C2=A0leveraged to provide a method to steer a p=
acket through a controlled
=C2=A0 =C2=A0set of segments.

Why =E2=80=9Csource router tunnels with label stacki=
ng=E2=80=9D (SRTLS?) and not Segment Routing with MPLS data plane?

Sri> Because Segment Routing is base=
d on Source Routing.
=C2=A0
<=
div style=3D"word-wrap:break-word">

=C2=A0 =C2=A0 =C2=A0=
 OAM - Operation, Administration and Maintenance

S=
hould be "OAM - Operation, Administration, and Maintenance"
=


Sri> Accepted
=C2=A0
=


=C2=A0 =C2=A0[I-D.xu-isis-mpls-elc]
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Xu, X., Kini, S., Sivabalan, =
S., Filsfils, C., and S.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Litkowski, "Signaling Entropy Label Capability Using IS-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IS", draft-xu=
-isis-mpls-elc-02 (work in progress), April
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015.

=C2=A0 =C2=A0[I-=
D.xu-ospf-mpls-elc]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Litkowski, "Signaling Entrop=
y Label Capability Using
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
<=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2014.


These are expired and replaced by oth=
er documents. They should be marked as Replaced-by in the Tracker.

Sri> Accepted
=C2=A0
=

Thanks!

=E2=80=94 Carlos.

<=
div>
On Apr 25, 2016, =
at 3:19 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi George, et. al,
I=E2=80=99ve found several occ=
urrences, three actually, of SHOULD being used in Section 4.<=
/span>
=C2=A0
And I agree with Stewart that application o=
f <ELI, EL> is the local decision and, at most, this work can be publ=
ished as Informational.
One comment, suggestion:
=C2=B7=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
the sample algorithm in Section 4 suggests that the same <=
;ELI,EL> tuple been used multiple times whereas it may be advantageous t=
o generalize and point that the different entropy label value may be used b=
y referring to the tuple as <ELI, ELn>
=C2=A0
Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg=

=C2=A0
=C2=A0
From:=C2=A0mpls [mailt=
o:mpls-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0<=
/span>George Swallow
Sent:=C2=A0Monday, April 25=
, 2016 10:57 AM
To:=C2=A0Stewart Bryant
Cc:=C2=A0draft-ietf-mpls-spring-entropy-label@tools.ietf.org;=C2=
=A0mpls@ietf.org;=C2=A0mpls-chairs@ietf.org
Subject:=C2=A0Re: [mpls] working group last call on draft-ietf-mpls-sprin=
g-entropy-label
=C2=
=A0
Stewart -
=C2=A0
On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
I support this becoming a WG doc and thereby commi=
ng under WG
control.
<=
/u>=C2=A0
The document is a W=
G doc.=C2=A0=C2=A0 We are now in WG last call.
=C2=A0
However I am not sure about the dismissal of th=
e option to reuse
the ELI+EL. This clutters the stack less than the prop=
osed option.

Also I wonder why this is standards track?
=C2=A0
<=
/div>
A reasonable question, particularly since =
there are no MUSTs, SHALLs or REQUIREDs.=C2=A0 Will discuss with my Co-Chai=
rs and ADs.
=C2=A0<=
/u>
Surely a=
ny equipment that understands the ELI can do this and thus this is just an =
informal description of the problem and a solution.

Stewart
=



On 23/04/2016 08:53, Loa Andersson wrot=
e:
Working Group,

This is =
to initiate a two week working group last call on
draft-ietf-mpls-spring=
-entropy-label.

Please send your comments to the mpls wg mailing lis=
t (mpls@ietf.org).

There are no IPR dis=
closures against this document.

All the authors and contributors (wi=
th one exception) have stated on
the working group mailing list that the=
y are not aware of any other
IPRs that relates to this draft.

Thi=
s working group last call ends May 12, 2016.


/Loa
for the MPL=
S wg chairs
=C2=A0<=
/div>
=C2=A0=

______=
_________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
<=
/blockquote>


_____________________________________=
__________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls





--001a1142e14adf66c60531a673ee--


From nobody Fri Apr 29 14:39:19 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D112D743; Fri, 29 Apr 2016 14:39:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_cJnX5dww7q; Fri, 29 Apr 2016 14:39:16 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 4AA0D12B04A; Fri, 29 Apr 2016 14:39:16 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id x201so133429810oif.3; Fri, 29 Apr 2016 14:39:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k2mJJViSnKTpjiF2vFlxX3sU0vo2NmlOtW0KUaPDeY8=; b=WKuCBRJtOMcwsWVA6e4zPas0WxzBk0OH3+sb80MQDnqG1r4Ngg+T8/wZFYNAgZVzwZ wK+MMaDnSVQ9U8gs4R8S1KZn7rAyemyFQ9CLVqQiV99Bd+jqqEQNhgVwAzv1DD0t/1Vx 4J1610G5rCn5gkZH238/A/VGhI/iAsgBXUT1wi589R8viIOFOjai7gVu9PFBuIAiV8bA 6VLIgBsQS33eTHlO1gh5gsowZZiFYZ8eI23CqKmnCx1i05uTpW2cqIGAi9kdC73Mileu SbztjsCY1iZolyU6wVb3WTE0SrzepWjpio+tyF8tydt+lhosoGnh1/P25FSkCVQ82Ttc ZeRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k2mJJViSnKTpjiF2vFlxX3sU0vo2NmlOtW0KUaPDeY8=; b=PG4DiZzQWwQ+g1QD5BR+lGZ7jfFWVuaBJS1rVuxHar9eB+CQ3CE4zNuHgxdcIcysNo RJd1sEC9caQ60i4ZgCBLlGL9BSjUoxkc5WA29sPKKGlN2EvSSfUmomdwDpdI3G9YBff5 i6SwPQKtmW8CwHnBflgxw6WQSChF2TrJ1IuECGdcZRyCgmk+6Plp8IGa44pvujHIZwax c28ffSvTLmzz7XwFm/VMm/5VaeZV+QyNP77vNnpV/v8tMVp0oNfaqpdJjUMPTBC0i7VY ETongoVk9Btm90xsjtH6O72wP6WOVu5ORHfnYQIUrGwWpoyLfyMvqyyIH5kQYUGfxd1R XZOQ==
X-Gm-Message-State: AOPr4FWluqxxOa+33OFJipeT6ZhUv62bEAMgHUFxjJvIa62oKsay5Y6Y2FAWAb+/+PlDX3BrnXZ5DTLPlSR/OA==
X-Received: by 10.202.2.79 with SMTP id 76mr10694981oic.108.1461965955755; Fri, 29 Apr 2016 14:39:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 14:38:46 -0700 (PDT)
In-Reply-To: 
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <571E69F2.8020506@gmail.com>  
From: Sri 
Date: Fri, 29 Apr 2016 14:38:46 -0700
Message-ID: 
To: Stewart Bryant 
Content-Type: multipart/alternative; boundary=001a1137bac87779f30531a67947
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 21:39:18 -0000

--001a1137bac87779f30531a67947
Content-Type: text/plain; charset=UTF-8

Hi Stewart,

Since this will be an Informational draft shouldn't it be okay?

Sri

On Fri, Apr 29, 2016 at 2:15 PM, Stewart Bryant 
wrote:

>
>
> On 29 Apr 2016, at 21:41, Sri  wrote:
>
> Sri> Just re-iterating a response to a similar point in an earlier email -
>  "Since there are different ways to do this and some ways are better than
> others, this draft lists the different options and recommends one solution."
>
>
> Hi Sri
>
> We don't normally make a formal recommendation on a local matter such as
> this.
>
> Stewart
>

--001a1137bac87779f30531a67947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stewart,

Since this will be an Infor=
mational draft shouldn't it be okay?

Sri
=


On Fri, Apr=
 29, 2016 at 2:15 PM, Stewart Bryant <stewart.bryant@gmail.com&=
gt; wrote:


On 29 Apr 2016, at 21:41, Sr=
i <sriganes=
hkini@gmail.com> wrote:

Sri&g=
t; Just re-iterating a response to a similar point in an earlier email - =
=C2=A0"Since there are different ways=
 to do this and some ways are better than others, this draft lists the diff=
erent options and recommends one solution."

Hi Sri

We don't normally make a forma=
l recommendation on a local matter such as this.

Stewart=C2=A0



--001a1137bac87779f30531a67947--


From nobody Fri Apr 29 15:03:55 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86812D1D1; Fri, 29 Apr 2016 15:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfey8WdKd70d; Fri, 29 Apr 2016 15:03:51 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 5DF1612B045; Fri, 29 Apr 2016 15:03:51 -0700 (PDT)
Received: by mail-ob0-x22c.google.com with SMTP id x1so39015046obt.0; Fri, 29 Apr 2016 15:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZlIapp9zgXAiL8Zw50mV9b9R72CXlQmIX7T2izPOnEg=; b=nonpEE394K0qokYwuVcVBYjiE08sixPJmZfIuVgFU/BFrF/6ij1xXa8tvY+cwja7f2 q8qHH9wn/WGwo//VkpFU560kpPOEFRFWqn3INMYKbZF4ufk+hdhpfAy7xMzgUDMzDKnv igOrqJCtLjEncDceY42/Zc4AO22UQz6n6XJDzW94nbtmmIlwiCTJ3pQFtYkCH+hS9Tgy AIAThFgStzlq0kV+T5gNTMF7rxDJTIs7KFumTxoyxYtRWOg94E+c/1eKWiN351k9Y7Dl 4yWsCy6gPay+hl9NgGOKIIcRIKnIX3nu6AGnwn0COT3y/Wpy2HLZ4JA1+ViCdUZZr+uv rKGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZlIapp9zgXAiL8Zw50mV9b9R72CXlQmIX7T2izPOnEg=; b=efnQnlEchJ1mPhXrbSzkZnmFMtWF0lXcS0BCP2MhR3nUrQHiXUlGxyN/E9VCTQHhwy XDIQJWFWHanXOWTnBwtNR028wOe7b8Hi3S3Y+LA3hiT5qHwU8a4KvWejF1bJRi1ZLN4L +1aZw5GN9nFTLBg9Eb5HSzjD40NMWNTkcwjC/SYuYjsmVu6CrJ2+591RIVJjGpLQQ/CW I2vgHG5PRjVYV6dy/FGv9TjVNRcMX8xzsp3N916liR6hzJmcnR9rtPPgH0XSK4q5fikF P9L51CzNO1a5sW41DKxr3ADA3ypz102BG65zuuTDF5SHdddN8baTQ/nbfBJKyDmujFKH kbLQ==
X-Gm-Message-State: AOPr4FV2/UdUaytOr8j9Y73zJqM78f3g1ZrdMb7+/a0abDrck8LzswV9gQjCkNvgk66oK1Vb+DDGX//6hOFPCg==
X-Received: by 10.60.63.132 with SMTP id g4mr10973163oes.49.1461967430592; Fri, 29 Apr 2016 15:03:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 15:03:20 -0700 (PDT)
In-Reply-To: <571F1136.1050905@gmail.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <571EF6B9.403@pi.nu> <571F1136.1050905@gmail.com>
From: Sri 
Date: Fri, 29 Apr 2016 15:03:20 -0700
Message-ID: 
To: Stewart Bryant 
Content-Type: multipart/alternative; boundary=047d7b5d2e8c5fae860531a6d1dd
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 22:03:54 -0000

--047d7b5d2e8c5fae860531a6d1dd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Stewart,

If even after changing the Status to Informational, any of these comments
still need to be addressed pls let me know.

Thanks
Sri

On Mon, Apr 25, 2016 at 11:56 PM, Stewart Bryant 
wrote:

>
> If I look at section 4, the key piece of information is the RLD which
> is the subject of other drafts. Given the RLD, how it is decided
> to distribute the ELIs within the stack is purely a local matter.
>
> 5.1 is the trivial case of 4 for a large RLD, and for shorter RLD
> is a matter for the imposing LSR to balance reduction in
> ECMP against LS size (which may be a limit for that LSR anyway).
> Either way unless you use some sort of phone a friend scheme*
> (which you may need as the label stack grows beyond the capability of
> the edge nodes) this is a local matter.
>
> 5.2 is the other trivial case of 4, which again is a local matter.
>
> 5.3 and 5.3.1 require hardware changes, but optimises the stack
> size, which is an oft quoted issue in MPLS systems, particularly
> PWs. As such it is not a local matter, but if you knew that strategic
> nodes had that capability it would become a local matter.
>
> Incidentally there is a need for something of the form of 5.3
> in that an LSR pushing further labels may need to look at the existing
> stack, retrieve the EL and add its own ELI/ELs. There perhaps
> ought to be text describing this action, but once you have this
> capability, surely 5.3 becomes a viable general solution.
>
> Also a 5.3 like solution may be needed to overcome the
> ingress node imposition limitations in cases where phone-a-friend
> is not available.
>
> 5.4 is as the document notes really a version of 4.
>
> There is so much that is a local matter that I am not sure the text
> should go beyond describing the issues and leaving the decision
> to the imposing LSR s/w team.
>
> - Stewart
>
> *As I recall that there is IPR on at least one phone-a-friend scheme
>
>
> On 26/04/2016 06:03, Loa Andersson wrote:
>
>> Greg,
>>
>> (talking about the SHOULDs in Section 4 only)
>>
>> I think what George (and Stewart) says is that since the document does
>> not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an
>> Informational RFC.
>>
>> However, it does not work to turn that argument around and say that an
>> Informational RFC can't use the normative language, it was doen for
>> example in RFC 7412.
>>
>> I think we should change it to Informational, but there is no need to
>> do anything to the SHOULDs in section 4.
>>
>> /Loa
>>
>> On 2016-04-26 03:19, Gregory Mirsky wrote:
>>
>>> Hi George, et. al,
>>>
>>> I=E2=80=99ve found several occurrences, three actually, of SHOULD being=
 used in
>>> Section 4.
>>>
>>> And I agree with Stewart that application of  is the local
>>> decision and, at most, this work can be published as Informational.
>>>
>>> One comment, suggestion:
>>>
>>> =C2=B7the sample algorithm in Section 4 suggests that the same =
 tuple
>>> been used multiple times whereas it may be advantageous to generalize
>>> and point that the different entropy label value may be used by
>>> referring to the tuple as 
>>>
>>> Regards,
>>>
>>>          Greg
>>>
>>> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallo=
w
>>> *Sent:* Monday, April 25, 2016 10:57 AM
>>> *To:* Stewart Bryant
>>> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org;
>>> mpls@ietf.org; mpls-chairs@ietf.org
>>> *Subject:* Re: [mpls] working group last call on
>>> draft-ietf-mpls-spring-entropy-label
>>>
>>> Stewart -
>>>
>>> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant
>>> > wrote:
>>>
>>> I support this becoming a WG doc and thereby comming under WG
>>> control.
>>>
>>> The document is a WG doc.   We are now in WG last call.
>>>
>>>     However I am not sure about the dismissal of the option to reuse
>>>     the ELI+EL. This clutters the stack less than the proposed option.
>>>
>>>     Also I wonder why this is standards track?
>>>
>>> A reasonable question, particularly since there are no MUSTs, SHALLs or
>>> REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>>>
>>>     Surely any equipment that understands the ELI can do this and thus
>>>     this is just an informal description of the problem and a solution.
>>>
>>>     Stewart
>>>
>>>
>>>
>>>     On 23/04/2016 08:53, Loa Andersson wrote:
>>>
>>>     Working Group,
>>>
>>>     This is to initiate a two week working group last call on
>>>     draft-ietf-mpls-spring-entropy-label.
>>>
>>>     Please send your comments to the mpls wg mailing list (mpls@ietf.or=
g
>>>     ).
>>>
>>>     There are no IPR disclosures against this document.
>>>
>>>     All the authors and contributors (with one exception) have stated o=
n
>>>     the working group mailing list that they are not aware of any other
>>>     IPRs that relates to this draft.
>>>
>>>     This working group last call ends May 12, 2016.
>>>
>>>
>>>     /Loa
>>>     for the MPLS wg chairs
>>>
>>>
>>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>

--047d7b5d2e8c5fae860531a6d1dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stewart,

If even after changing the =
Status to Informational, any of these comments still need to be addressed p=
ls let me know.

Thanks
Sri

On Mon, Apr 25, 201=
6 at 11:56 PM, Stewart Bryant <stewart.bryant@gmail.com> wrote:


If I look at section 4, the key piece of information is the RLD which

is the subject of other drafts. Given the RLD, how it is decided

to distribute the ELIs within the stack is purely a local matter.



5.1 is the trivial case of 4 for a large RLD, and for shorter RLD

is a matter for the imposing LSR to balance reduction in

ECMP against LS size (which may be a limit for that LSR anyway).

Either way unless you use some sort of phone a friend scheme*

(which you may need as the label stack grows beyond the capability of

the edge nodes) this is a local matter.



5.2 is the other trivial case of 4, which again is a local matter.



5.3 and 5.3.1 require hardware changes, but optimises the stack

size, which is an oft quoted issue in MPLS systems, particularly

PWs. As such it is not a local matter, but if you knew that strategic

nodes had that capability it would become a local matter.



Incidentally there is a need for something of the form of 5.3

in that an LSR pushing further labels may need to look at the existing

stack, retrieve the EL and add its own ELI/ELs. There perhaps

ought to be text describing this action, but once you have this

capability, surely 5.3 becomes a viable general solution.



Also a 5.3 like solution may be needed to overcome the

ingress node imposition limitations in cases where phone-a-friend

is not available.



5.4 is as the document notes really a version of 4.



There is so much that is a local matter that I am not sure the text

should go beyond describing the issues and leaving the decision

to the imposing LSR s/w team.



- Stewart



*As I recall that there is IPR on at least one phone-a-friend scheme




On 26/04/2016 06:03, Loa Andersson wrote:



Greg,



(talking about the SHOULDs in Section 4 only)



I think what George (and Stewart) says is that since the document does

not use any MUST, SHALL or REQUIRED, it makes sense to publish it as an

Informational RFC.



However, it does not work to turn that argument around and say that an

Informational RFC can't use the normative language, it was doen for exa=
mple in RFC 7412.



I think we should change it to Informational, but there is no need to

do anything to the SHOULDs in section 4.



/Loa



On 2016-04-26 03:19, Gregory Mirsky wrote:



Hi George, et. al,



I=E2=80=99ve found several occurrences, three actually, of SHOULD being use=
d in

Section 4.



And I agree with Stewart that application of <ELI, EL> is the local
decision and, at most, this work can be published as Informational.



One comment, suggestion:



=C2=B7the sample algorithm in Section 4 suggests that the same <ELI,EL&g=
t; tuple

been used multiple times whereas it may be advantageous to generalize

and point that the different entropy label value may be used by

referring to the tuple as <ELI, ELn>



Regards,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg



*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *George Swallow

*Sent:* Monday, April 25, 2016 10:57 AM

*To:* Stewart Bryant

*Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org=
;

mpls@ietf.org; mpls-chairs@ietf.org

*Subject:* Re: [mpls] working group last call on

draft-ietf-mpls-spring-entropy-label



Stewart -



On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant

<stewart.b=
ryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:



I support this becoming a WG doc and thereby comming under WG

control.



The document is a WG doc.=C2=A0 =C2=A0We are now in WG last call.



=C2=A0 =C2=A0 However I am not sure about the dismissal of the option to re=
use

=C2=A0 =C2=A0 the ELI+EL. This clutters the stack less than the proposed op=
tion.



=C2=A0 =C2=A0 Also I wonder why this is standards track?



A reasonable question, particularly since there are no MUSTs, SHALLs or

REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs.



=C2=A0 =C2=A0 Surely any equipment that understands the ELI can do this and=
 thus

=C2=A0 =C2=A0 this is just an informal description of the problem and a sol=
ution.



=C2=A0 =C2=A0 Stewart







=C2=A0 =C2=A0 On 23/04/2016 08:53, Loa Andersson wrote:



=C2=A0 =C2=A0 Working Group,



=C2=A0 =C2=A0 This is to initiate a two week working group last call on

=C2=A0 =C2=A0 draft-ietf-mpls-spring-entropy-label.



=C2=A0 =C2=A0 Please send your comments to the mpls wg mailing list (mpls@ietf.org

=C2=A0 =C2=A0 <mailto:mpls@ietf.org>).



=C2=A0 =C2=A0 There are no IPR disclosures against this document.



=C2=A0 =C2=A0 All the authors and contributors (with one exception) have st=
ated on

=C2=A0 =C2=A0 the working group mailing list that they are not aware of any=
 other

=C2=A0 =C2=A0 IPRs that relates to this draft.



=C2=A0 =C2=A0 This working group last call ends May 12, 2016.





=C2=A0 =C2=A0 /Loa

=C2=A0 =C2=A0 for the MPLS wg chairs







_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls







_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls





--047d7b5d2e8c5fae860531a6d1dd--


From nobody Fri Apr 29 15:09:21 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A8812B02F; Fri, 29 Apr 2016 15:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 xphNBkiL-bpm; Fri, 29 Apr 2016 15:09:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8816312D747; Fri, 29 Apr 2016 15:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46574; q=dns/txt; s=iport; t=1461967756; x=1463177356; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yA2ra264V0yqfZp+YALL7XfhL762J0MfiXHJvHLdOAM=; b=XbJMv7giT8ZaqrAyONh9EXeIb+sNv3XKGzThElQQRdzwoA68bR0q0Cpl izTX6obMKruZktaScAsZL7I8ylc0kL3zz0VbcL4P1RfAdAQn/elYU7YrU APMaIy773thVpElcQl5K7wlPWaAOyjanMSv1m6FWtvNsQSUX8XNxH69wi o=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAwAP2yNX/5BdJa1egmxMU30GrgyLY?= =?us-ascii?q?A6BcgQXAQqFbgKBLjgUAQEBAQEBAWUnhEEBAQEDAQEBASBLCwULAgEIEQQBAQE?= =?us-ascii?q?VCwEGAwICIQYLFAkIAgQOBQ4Nh3oDCggOsmqMOw2ETgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ0EBIYhgXaCVoJBgVlZCYJBK4IrBYdyhxaEGoRAMQGDJ4FnhxKBdoF?= =?us-ascii?q?nhE2IXYdRh14BHgFDggUbgUtsh0Q+fwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,553,1454976000";  d="asc'?scan'208,217";a="99307062"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 22:08:51 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3TM8pSn014216 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 22:08:51 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 18:08:50 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 18:08:50 -0400
From: "Carlos Pignataro (cpignata)" 
To: Sri 
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHRnvqiyJTa1iN2rkOldcR5st5EVZ+bPPSAgAAW1wCAAiwhAIAEQ8EAgAAI04A=
Date: Fri, 29 Apr 2016 22:08:50 +0000
Message-ID: <0DA662F9-7A98-4BAB-8BAB-61E69DE4F612@cisco.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.244.115]
Content-Type: multipart/signed; boundary="Apple-Mail=_012A14F3-4DA0-41BF-B577-17F2AA6309F7"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 22:09:20 -0000

--Apple-Mail=_012A14F3-4DA0-41BF-B577-17F2AA6309F7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A03CB97A-4708-46E1-838D-B5E2325C9C1C"


--Apple-Mail=_A03CB97A-4708-46E1-838D-B5E2325C9C1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Sri,

Thanks for the response =E2=80=94 please see inline.

> On Apr 29, 2016, at 5:37 PM, Sri  wrote:
>=20
> Hi Carlos,
>=20
> Thanks for your comments. Pls see inline.
>=20
> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) =
> wrote:
> Loa,
>=20
> I just scanned through draft-ietf-mpls-spring-entropy-label-03 and =
wanted to share some observations. Please treat these as WGLC comments.
>=20
> I have a number of concerns. It seems as if this document was not =
really reviewed to see if it was ready for WGLC:
>=20
> 1. What is this document specifying?
>=20
> As Greg just mentioned below, there are several SHOULD terms in =
Section 4. Those SHOULD are dependent upon the =E2=80=9CRLD".
>=20
>=20
> Sri> As per my response to Loa's suggestion, this draft would be =
changed to Informational with all the SHOULDs retained.
>=20

Sorry I still do not understand. My comment is not about the intended =
status of the document.

Those SHOULDs depend on the RLD. So it is a protocol specification. =
However, the RLD is defined in other docs, and loosely integrated. How =
does the solution work without RLD (i.e., if the SHOULD is not =
followed)? And how is this whole thing specified without the ELC as a =
mandatory field?

> That same section then lists the following:
>=20
>    The RLD can be advertised via protocols and those extensions are
>    described in separate documents [I-D.xu-isis-mpls-elc] and
>    [I-D.xu-ospf-mpls-elc].
>=20
> First, those are expired and should be marked as replaced by wg docs.
>=20
> Sri> Accepted. These references would be updated.
>=20

OK.

>=20
> But the main point is that knowing the RLD is REQUIRED (neither =
RECOMMENDED nor OPTIONAL) to be able to follow and comply with the =
requirements on where to position the {ELI; EL} and with the pseudocode.
>=20
> Sri> The RLD is required to follow the recommended solution in the =
draft. What exactly is the comment?
>=20

The comment is, quoting from above, that =E2=80=9C the RLD is REQUIRED =
(neither RECOMMENDED nor OPTIONAL) to be able to follow and comply with =
the requirements=E2=80=9D. Why SHOULD? And how is the RLD learned, used, =
calculated, etc?

>=20
>=20
> 2. OAM?
>=20
> The document says the following:
>=20
>    The recommendations above are not expected to bring any additional
>    OAM considerations beyond those described in section 6 of =
[RFC6790].
>    However, the OAM requirements and solutions for source routed =
tunnels
>    formed by label stacking are still under discussion and future
>    revisions of this document will address those if needed.
>=20
> Is this saying that the document still needs to evolve to be ready? =
What are really the OAM considerations related to this draft?
>=20
> Sri> There are no new OAM consideration related to the recommendations =
in this draft. Having said that, the SPRING OAM drafts are not RFCs yet. =
Hence the wording.
>=20

If the wording of =E2=80=9Cand future revisions of this document will =
address those if needed=E2=80=9D is intended, is a WGLC premature?

>=20
>=20
> 3. Intended status:
>=20
> I agree with others in the sense that this is not a Standards Track =
doc.
>=20
> Sri> As per an earlier response to Loa's suggestion, the draft will be =
changed to Informational.
>=20
>=20
>=20
> 4. EL Capability?
>=20
> This is probably the most important comment. The document defines the =
ELC acronym, but it does not use it.
>=20
> Sri> ELC is not defined in this draft. It is taken from RFC6790
>=20

I know, but it is not used.

Moreover, RFC 6790 defines the ELC, and explains how to signal it =
(Section 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 obsoleted the =
BGP use. However, this document does not use LDP or RSVP-TE.

If the ELC is not considered, then you can end up with pushing ELI/EL to =
a node that does not understand it.

>=20
>       ELC - Entropy Label Capability
>=20
> =46rom RFC 6790, the egress capability of processing EL needs to be =
signaled to the ingress for the ingress to be able to insert an ELI; EL.
>=20
> In this case, the proposed method tries to optimize for position, but =
it is not taking into account whether the egress of each segment can =
actually process ELI; EL (or if it would otherwise Drop the packet!). =
The algorithm does says =E2=80=9Cif EL-capable=E2=80=9D, but how is that =
learned?
>=20
> Sri> RFC6790 defined procedures to signal ELC, but did not do so for =
OSPF/ISIS and these are defined in the documents referenced - =
draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed =
to the WG draft versions).

Yes. However, this document is not using the ELC =E2=80=94 that=E2=80=99s =
my point.

>=20
>=20
> In other words, this seems like a bug. Is the ingress is inserting a =
label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for =
example) might not understand and would drop?
>=20
> Sri> No. The recommended solution takes ELC into account and the =
advertisement of ELC is as per the referenced drafts/RFCs.
>=20

How does the solution take into account the ELC? Can you please =
copy/paste text from the draft?

Currently the draft says:

   The RLD can be advertised via protocols and those extensions are
   described in separate documents [I-D.xu-isis-mpls-elc] and
   [I-D.xu-ospf-mpls-elc].

So it is talking about the advertisement of RLD, but not the ELC, and =
not the use (after advertisement).

>=20
>=20
> 5. Labels to push?
>=20
> Inserting N * 2 LSEs can have implications on the head-end in terms of =
max numbers of labels which can be pushed. A label stack that is pushed =
onto a packet, might not be able to be pushed if the stack grows by 2 * =
N LSEs.
>=20
> The text says in various portions things like:
>=20
>    The LSR that inserts  pairs MAY have limitations
>    on the number of such pairs that it can insert and also the depth =
at
>    which it can insert them.
>=20
> However, is it really the limitation how many labels an ingress can =
push?
>=20
> Sri> How about re-wording it as "The LSR that inserts  pairs =
MAY have limitations on the number of labels that can be pushed and this =
can limit the number of  pairs that it can insert and also the =
depth at which it can insert them".
>=20

To me, that is not a =E2=80=9CMAY=E2=80=9D. It may (not MAY) have =
limitations. But, the more important piece is missing =E2=80=94 how do =
these limitations impact the solution in this doc?

>=20
> Also, if there is one node in the path which does not advertise the =
RLD, then would the RLD be zero and make the algorithm moot?
>=20
> Sri> If the RLD of a node is not available at the headend, then it is =
a local matter on how to treat it.
>=20

I believe this is incorrect. It=E2=80=99s part of the calculation, not a =
local matter.

>=20
>=20
> More editorial comments:
>=20
> No reference to draft-ietf-spring-segment-routing-mpls?
>=20
> Sri> Accepted. Will add it.
>=20
>=20
>=20
>    Source routed tunnels with label stacking is a technique that can =
be
>    leveraged to provide a method to steer a packet through a =
controlled
>    set of segments.
>=20
> Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D =
(SRTLS?) and not Segment Routing with MPLS data plane?
>=20
> Sri> Because Segment Routing is based on Source Routing.
>=20
>=20
>       OAM - Operation, Administration and Maintenance
>=20
> Should be "OAM - Operation, Administration, and Maintenance"
>=20
> Sri> Accepted
>=20
>=20
>=20
>    [I-D.xu-isis-mpls-elc]
>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>               Litkowski, "Signaling Entropy Label Capability Using IS-
>               IS", draft-xu-isis-mpls-elc-02 (work in progress), April
>               2015.
>=20
>    [I-D.xu-ospf-mpls-elc]
>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>               Litkowski, "Signaling Entropy Label Capability Using
>               OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
>               October 2014.
>=20
>=20
> These are expired and replaced by other documents. They should be =
marked as Replaced-by in the Tracker.
>=20
> Sri> Accepted
>=20

Thanks,

=E2=80=94 Carlos.

>=20
> Thanks!
>=20
> =E2=80=94 Carlos.
>=20
>> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky =
> =
wrote:
>>=20
>> Hi George, et. al,
>> I=E2=80=99ve found several occurrences, three actually, of SHOULD =
being used in Section 4.
>>=20
>> And I agree with Stewart that application of  is the local =
decision and, at most, this work can be published as Informational.
>> One comment, suggestion:
>> =C2=B7         the sample algorithm in Section 4 suggests that the =
same  tuple been used multiple times whereas it may be =
advantageous to generalize and point that the different entropy label =
value may be used by referring to the tuple as 
>>=20
>> Regards,
>>         Greg
>>=20
>>=20
>> From: mpls [mailto:mpls-bounces@ietf.org =
] On Behalf Of George Swallow
>> Sent: Monday, April 25, 2016 10:57 AM
>> To: Stewart Bryant
>> Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org =
; =
mpls@ietf.org ; mpls-chairs@ietf.org =

>> Subject: Re: [mpls] working group last call on =
draft-ietf-mpls-spring-entropy-label
>>=20
>> Stewart -
>>=20
>> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant =
> wrote:
>> I support this becoming a WG doc and thereby comming under WG
>> control.
>>=20
>> The document is a WG doc.   We are now in WG last call.
>>=20
>> However I am not sure about the dismissal of the option to reuse
>> the ELI+EL. This clutters the stack less than the proposed option.
>>=20
>> Also I wonder why this is standards track?
>>=20
>> A reasonable question, particularly since there are no MUSTs, SHALLs =
or REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>>=20
>> Surely any equipment that understands the ELI can do this and thus =
this is just an informal description of the problem and a solution.
>>=20
>> Stewart
>>=20
>>=20
>> On 23/04/2016 08:53, Loa Andersson wrote:
>> Working Group,
>>=20
>> This is to initiate a two week working group last call on
>> draft-ietf-mpls-spring-entropy-label.
>>=20
>> Please send your comments to the mpls wg mailing list (mpls@ietf.org =
).
>>=20
>> There are no IPR disclosures against this document.
>>=20
>> All the authors and contributors (with one exception) have stated on
>> the working group mailing list that they are not aware of any other
>> IPRs that relates to this draft.
>>=20
>> This working group last call ends May 12, 2016.
>>=20
>>=20
>> /Loa
>> for the MPLS wg chairs
>>=20
>>=20
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org 
>> https://www.ietf.org/mailman/listinfo/mpls =

>=20
> _______________________________________________
> mpls mailing list
> mpls@ietf.org 
> https://www.ietf.org/mailman/listinfo/mpls =

>=20
>=20


--Apple-Mail=_A03CB97A-4708-46E1-838D-B5E2325C9C1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, Sri,

Thanks for the response =E2=80=94 please see =
inline.

=

--Apple-Mail=_A03CB97A-4708-46E1-838D-B5E2325C9C1C--

--Apple-Mail=_012A14F3-4DA0-41BF-B577-17F2AA6309F7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJXI9tuAAoJEIXgpQGOZny9O5cP/jn0j94x1kBbLinAn5nkP1dQ
EAh20zt5PV2GyLcGpnnoPl9RjzbizXOo0FpJ6U69qzyaJ2wV2r2ooPaSlWY2ndri
PhVJBlNg1y6/fSrWGE/zMbgIbD0Xli8pf0t5iOTrrUTYbhUetry+MIa/ZbXL4lmA
nKVBMNYONk/qrj8JMiXBKQ+RY2jdhKGYffXBQjELnwdxnr/0bRP+E9CugyMatmEl
KK3bprPln9kmZHVm/0UL+teD+7WP88AuXYxqeSr28nSguVRH/Icpfm+29Llf4yMZ
GDLaMq3f3akjpAGB8QY54yELGxkXSZvOKtcHg/zbv5eqcUqOqozN2c/8cR5Mb87b
Qqy3PpHUnsmAtCTV/eK1JliMCmNeWiIyXsLsPtz3ovXaWDD7w8GsjC4AB+uyHsRL
bXneXotbx1/xnC5PLRDT86Qwm1+ua4JMySZhMJaJcH8JKrE+Gwb+CmdnRn6QKJ/O
R/M6qFJOtp5BoEZs/YGQNo62khhjnvV4egekdeHFhgK6DUwpYtaAohOs6O73McyL
OKwoQLgH2R8zC1ghUX8Tk6kspfKuEjNbr1iJ+nn6LaWsIz4OdvZ6IeFpyP3kS45z
o8zyETA804rvdFvwpSCpPY8kmgyhu6sedwewmC9lOyjtJvSnqFvRbxgKUtuK9oco
r6r4nnoyfQFuPkivCv7o
=Jnth
-----END PGP SIGNATURE-----

--Apple-Mail=_012A14F3-4DA0-41BF-B577-17F2AA6309F7--


From nobody Fri Apr 29 15:52:18 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7106612D75B; Fri, 29 Apr 2016 15:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh5-Pt5LF9TX; Fri, 29 Apr 2016 15:52:14 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 3F9D912D739; Fri, 29 Apr 2016 15:52:14 -0700 (PDT)
Received: by mail-oi0-x234.google.com with SMTP id x201so134978394oif.3; Fri, 29 Apr 2016 15:52:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T0S8viSvpDXT8QQd6j0QxWtrh2r5wwbve8AjsebWTJo=; b=znUP4pVJsuYT/jIMvVqyn+38PYZNMJ2jegEGtrF7JfzRXAMv+Z1XdcJ2NNoiLfZ5hi f+1ofVPKesXjKvWoJYjKT0yAbbt91Oj2XzkYQHB6wF9VAcie1O4wDrA27hLAbNWAaVHH O5oJ4XEDb/p9BlMAKZ8BEcgMyUzIaRI6a8w5NgPdON0nj2osNCtJ0Re/+rXFqiPrGsAJ cMtAU6r0Ab7yfbb4H7A8uWMgIs8xsvkBvddVmxhdoMs7EPTdQ0l1DSWudyllvZjoOwJm 4iYlE68HWX2xxqCdqEJ0pRCwvvXomiVZIEOagU8IOaYmlgx7ScS/qw/YtCrW40n8nndu rXSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T0S8viSvpDXT8QQd6j0QxWtrh2r5wwbve8AjsebWTJo=; b=CUoVAZyA/IrtqQAdgPEaxFvMjh4s4tXXOzW4CB1kIyHUUpSNxDXs9I0w6Y+cVzWNT3 Ee3y/X8KxxAsZLdkt5aeBfFNtsRMhrcXdAP20qR72dllM/k2GJ7PTdtY0GCtNNfQvFtd 800CP1nnBoTYImOV3qKbYoY/0BH5lrsVsCW4B15GW0XNFuhcbheRQS/BiR4i052eXyM2 4+Ms1ZZVpKFsaaIhp5EYXRGeQP39npvhMqoBGhJH20VlvF5bmysItZTs9bNP22JwKx42 QieBpkLrIwMlddXhr8ZProHo6SdTJ/Jn2gVmyS+BdN/9piLxPS4VH4FfNJmVW9T2rBJ8 UFhw==
X-Gm-Message-State: AOPr4FXJdbOgwi2LqWYS+AOj88zSjvdm8VtzB1UvTXLzGUEPYToKHRaVYp0eMnTAhz6oo13AybrI0l3s6fro4Q==
X-Received: by 10.157.9.100 with SMTP id 91mr10141518otp.142.1461970333610; Fri, 29 Apr 2016 15:52:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.223.213 with HTTP; Fri, 29 Apr 2016 15:51:43 -0700 (PDT)
In-Reply-To: <0DA662F9-7A98-4BAB-8BAB-61E69DE4F612@cisco.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com>  <0DA662F9-7A98-4BAB-8BAB-61E69DE4F612@cisco.com>
From: Sri 
Date: Fri, 29 Apr 2016 15:51:43 -0700
Message-ID: 
To: "Carlos Pignataro (cpignata)" 
Content-Type: multipart/alternative; boundary=94eb2c04f3fc6839b90531a77e12
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Apr 2016 22:52:17 -0000

--94eb2c04f3fc6839b90531a77e12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Carlos, pls see inline.

On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Hi, Sri,
>
> Thanks for the response =E2=80=94 please see inline.
>
> On Apr 29, 2016, at 5:37 PM, Sri  wrote:
>
> Hi Carlos,
>
> Thanks for your comments. Pls see inline.
>
> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
>> Loa,
>>
>> I just scanned through draft-ietf-mpls-spring-entropy-label-03 and wante=
d
>> to share some observations. Please treat these as WGLC comments.
>>
>> I have a number of concerns. It seems as if this document was not really
>> reviewed to see if it was ready for WGLC:
>>
>> 1. What is this document specifying?
>>
>> As Greg just mentioned below, there are several SHOULD terms in Section
>> 4. Those SHOULD are dependent upon the =E2=80=9CRLD".
>>
>>
> Sri> As per my response to Loa's suggestion, this draft would be changed
> to Informational with all the SHOULDs retained.
>
>
>
> Sorry I still do not understand. My comment is not about the intended
> status of the document.
>
> Those SHOULDs depend on the RLD. So it is a protocol specification.
> However, the RLD is defined in other docs, and loosely integrated. How do=
es
> the solution work without RLD (i.e., if the SHOULD is not followed)? And
> how is this whole thing specified without the ELC as a mandatory field?
>

Sri> The SHOULDs are part of the recommended solution. That does not imply
that this draft is a protocol specification. The documents
draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc are the protocol
specifications and those are used in the recommended solution. They ELC is
required anytime EL is used. There is no implication in this doc that ELC
is not required. If it is not clear the the determination in the pseudocode
of whether a label is EL-capable can be done through ELC, I can modify the
first sentence in the second last para of section 4 to read "The RLD and
ELC can be advertised via protocols and ..."


>
> That same section then lists the following:
>>
>>    The RLD can be advertised via protocols and those extensions are
>>    described in separate documents [I-D.xu-isis-mpls-elc] and
>>    [I-D.xu-ospf-mpls-elc].
>>
>> First, those are expired and should be marked as replaced by wg docs.
>>
>
> Sri> Accepted. These references would be updated.
>
>
>
> OK.
>
>
>> But the main point is that knowing the RLD is REQUIRED (neither
>> RECOMMENDED nor OPTIONAL) to be able to follow and comply with the
>> requirements on where to position the {ELI; EL} and with the pseudocode.
>>
>
> Sri> The RLD is required to follow the recommended solution in the draft.
> What exactly is the comment?
>
>
>
> The comment is, quoting from above, that =E2=80=9C the RLD is REQUIRED (n=
either
> RECOMMENDED nor OPTIONAL) to be able to follow and comply with the
> requirements=E2=80=9D. Why SHOULD? And how is the RLD learned, used, calc=
ulated,
> etc?
>

Sri> Note that it is REQUIRED to follow and comply with the recommendation
(not requirements). RLD is advertised (learned) via the extensions in
draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc, used as described in the
pseudocode and calculated as described in the second para of sec 4 (i.e.
based on the hardware limitations)


>
>
>>
>> 2. OAM?
>>
>> The document says the following:
>>
>>    The recommendations above are not expected to bring any additional
>>    OAM considerations beyond those described in section 6 of [RFC6790].
>>    However, the OAM requirements and solutions for source routed tunnels
>>    formed by label stacking are still under discussion and future
>>    revisions of this document will address those if needed.
>>
>> Is this saying that the document still needs to evolve to be ready? What
>> are really the OAM considerations related to this draft?
>>
>
> Sri> There are no new OAM consideration related to the recommendations in
> this draft. Having said that, the SPRING OAM drafts are not RFCs yet. Hen=
ce
> the wording.
>
>
>
> If the wording of =E2=80=9Cand future revisions of this document will add=
ress
> those if needed=E2=80=9D is intended, is a WGLC premature?
>

Sri> I don't think so. I can remove the second sentence and add a reference
to draft-ietf-spring-sr-oam-requirement and refer to it in the first
sentence right after RFC6790.


>
>
>>
>> 3. Intended status:
>>
>> I agree with others in the sense that this is not a Standards Track doc.
>>
>
> Sri> As per an earlier response to Loa's suggestion, the draft will be
> changed to Informational.
>
>
>>
>>
>> 4. EL Capability?
>>
>> This is probably the most important comment. The document defines the EL=
C
>> acronym, but it does not use it.
>>
>
> Sri> ELC is not defined in this draft. It is taken from RFC6790
>
>
>
> I know, but it is not used.
>
> Moreover, RFC 6790 defines the ELC, and explains how to signal it (Sectio=
n
> 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 obsoleted the BGP use.
> However, this document does not use LDP or RSVP-TE.
>
> If the ELC is not considered, then you can end up with pushing ELI/EL to =
a
> node that does not understand it.
>

Sri> Does the explanation to the earlier comments suffice?


>
>
>>       ELC - Entropy Label Capability
>>
>> From RFC 6790, the egress capability of processing EL needs to be
>> signaled to the ingress for the ingress to be able to insert an ELI; EL.
>>
>> In this case, the proposed method tries to optimize for position, but it
>> is not taking into account whether the egress of each segment can actual=
ly
>> process ELI; EL (or if it would otherwise Drop the packet!). The algorit=
hm
>> does says =E2=80=9Cif EL-capable=E2=80=9D, but how is that learned?
>>
>
> Sri> RFC6790 defined procedures to signal ELC, but did not do so for
> OSPF/ISIS and these are defined in the documents referenced -
> draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed =
to
> the WG draft versions).
>
>
> Yes. However, this document is not using the ELC =E2=80=94 that=E2=80=99s=
 my point.
>

Sri> Does the explanation to the earlier comments suffice?


>
>
>
>>
>> In other words, this seems like a bug. Is the ingress is inserting a
>> label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for ex=
ample) might not
>> understand and would drop?
>>
>
> Sri> No. The recommended solution takes ELC into account and the
> advertisement of ELC is as per the referenced drafts/RFCs.
>
>
> How does the solution take into account the ELC? Can you please copy/past=
e
> text from the draft?
>
> Currently the draft says:
>
>    The RLD can be advertised via protocols and those extensions are
>    described in separate documents [I-D.xu-isis-mpls-elc] and
>    [I-D.xu-ospf-mpls-elc].
>
> So it is talking about the advertisement of RLD, but not the ELC, and not
> the use (after advertisement).
>

Sri> Does the explanation to the earlier comments suffice?


>
>
>>
>> 5. Labels to push?
>>
>> Inserting N * 2 LSEs can have implications on the head-end in terms of
>> max numbers of labels which can be pushed. A label stack that is pushed
>> onto a packet, might not be able to be pushed if the stack grows by 2 * =
N
>> LSEs.
>>
>> The text says in various portions things like:
>>
>>    The LSR that inserts  pairs MAY have limitations
>>    on the number of such pairs that it can insert and also the depth at
>>    which it can insert them.
>>
>> However, is it really the limitation how many labels an ingress can push=
?
>>
>
> Sri> How about re-wording it as "The LSR that inserts  pairs MAY
> have limitations on the number of labels that can be pushed and this can
> limit the number of  pairs that it can insert and also the depth
> at which it can insert them".
>
>
> To me, that is not a =E2=80=9CMAY=E2=80=9D. It may (not MAY) have limitat=
ions. But, the
> more important piece is missing =E2=80=94 how do these limitations impact=
 the
> solution in this doc?
>

Sri> Ok. I can change MAY to may. Does earlier explanation about ELC
suffice?


>
>
>> Also, if there is one node in the path which does not advertise the RLD,
>> then would the RLD be zero and make the algorithm moot?
>>
>
> Sri> If the RLD of a node is not available at the headend, then it is a
> local matter on how to treat it.
>
>
>
> I believe this is incorrect. It=E2=80=99s part of the calculation, not a =
local
> matter.
>

Sri> Yes, it is part of the calculation. But it not being available at the
headend is presumably due to the appropriate protocol extensions not being
implemented in that intermediate node and would suggest that the best
course of action be some kind of default value determined by the headend.


>
>
>>
>> More editorial comments:
>>
>> No reference to draft-ietf-spring-segment-routing-mpls?
>>
>
> Sri> Accepted. Will add it.
>
>
>>
>>
>>    Source routed tunnels with label stacking is a technique that can be
>>    leveraged to provide a method to steer a packet through a controlled
>>    set of segments.
>>
>> Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D (SRTLS?)=
 and not Segment
>> Routing with MPLS data plane?
>>
>
> Sri> Because Segment Routing is based on Source Routing.
>
>
>>
>>       OAM - Operation, Administration and Maintenance
>>
>> Should be "OAM - Operation, Administration, and Maintenance"
>>
>
> Sri> Accepted
>
>
>>
>>
>>    [I-D.xu-isis-mpls-elc]
>>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>>               Litkowski, "Signaling Entropy Label Capability Using IS-
>>               IS", draft-xu-isis-mpls-elc-02 (work in progress), April
>>               2015.
>>
>>    [I-D.xu-ospf-mpls-elc]
>>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>>               Litkowski, "Signaling Entropy Label Capability Using
>>               OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
>>               October 2014.
>>
>>
>> These are expired and replaced by other documents. They should be marked
>> as Replaced-by in the Tracker.
>>
>
> Sri> Accepted
>
>
>
> Thanks,
>
> =E2=80=94 Carlos.
>
>
>> Thanks!
>>
>> =E2=80=94 Carlos.
>>
>> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky 
>> wrote:
>>
>> Hi George, et. al,
>> I=E2=80=99ve found several occurrences, three actually, of SHOULD being =
used in
>> Section 4.
>>
>> And I agree with Stewart that application of  is the local
>> decision and, at most, this work can be published as Informational.
>> One comment, suggestion:
>> =C2=B7         the sample algorithm in Section 4 suggests that the same
>>  tuple been used multiple times whereas it may be advantageous t=
o
>> generalize and point that the different entropy label value may be used =
by
>> referring to the tuple as 
>>
>> Regards,
>>         Greg
>>
>>
>> *From:* mpls [mailto:mpls-bounces@ietf.org ] *On
>> Behalf Of *George Swallow
>> *Sent:* Monday, April 25, 2016 10:57 AM
>> *To:* Stewart Bryant
>> *Cc:* draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org=
;
>>  mpls-chairs@ietf.org
>> *Subject:* Re: [mpls] working group last call on
>> draft-ietf-mpls-spring-entropy-label
>>
>> Stewart -
>>
>> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant 
>> wrote:
>> I support this becoming a WG doc and thereby comming under WG
>> control.
>>
>> The document is a WG doc.   We are now in WG last call.
>>
>>
>> However I am not sure about the dismissal of the option to reuse
>> the ELI+EL. This clutters the stack less than the proposed option.
>>
>> Also I wonder why this is standards track?
>>
>>
>> A reasonable question, particularly since there are no MUSTs, SHALLs or
>> REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>>
>>
>> Surely any equipment that understands the ELI can do this and thus this
>> is just an informal description of the problem and a solution.
>>
>> Stewart
>>
>>
>> On 23/04/2016 08:53, Loa Andersson wrote:
>> Working Group,
>>
>> This is to initiate a two week working group last call on
>> draft-ietf-mpls-spring-entropy-label.
>>
>> Please send your comments to the mpls wg mailing list (mpls@ietf.org).
>>
>> There are no IPR disclosures against this document.
>>
>> All the authors and contributors (with one exception) have stated on
>> the working group mailing list that they are not aware of any other
>> IPRs that relates to this draft.
>>
>> This working group last call ends May 12, 2016.
>>
>>
>> /Loa
>> for the MPLS wg chairs
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>
>

--94eb2c04f3fc6839b90531a77e12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Carlos, pls see inline.

<=
div class=3D"gmail_quote">On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro=
 (cpignata) <cpignata@cisco.com> wrote:
Hi, Sri,

Thanks for=
 the response =E2=80=94 please see inline.

On Apr 29, 2016, at 5:37 PM, Sri <<=
a href=3D"mailto:sriganeshkini@gmail.com" target=3D"_blank">sriganeshkini@g=
mail.com> wrote:

Hi Carlos,

<=
/div>
Thanks for your comments. Pls see inline.

On Tue, Apr 26, 2016 at 9:29 PM, Ca=
rlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Loa,

=
I just scanned through=C2=A0draft-ietf-mpls-spring-entropy-label-03 and wan=
ted to share some observations. Please treat these as WGLC comments.
<=
div>
I have a number of concerns. It seems as if this documen=
t was not really reviewed to see if it was ready for WGLC:

1. What is this document specifying?

As G=
reg just mentioned below, there are several SHOULD terms in Section 4. Thos=
e SHOULD are dependent upon the =E2=80=9CRLD".


Sri> As per my response to Loa's=
 suggestion, this draft would be changed to Informational with all the SHOU=
LDs retained.
=C2=A0

Sorry I still do not understand. My comment is not=
 about the intended status of the document.

Those =
SHOULDs depend on the RLD. So it is a protocol specification. However, the =
RLD is defined in other docs, and loosely integrated. How does the solution=
 work without RLD (i.e., if the SHOULD is not followed)? And how is this wh=
ole thing specified without the ELC as a mandatory field?
=


Sri> The SHOULDs are part of the =
recommended solution. That does not imply that this draft is a protocol spe=
cification. The documents draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc=
 are the protocol specifications and those are used in the recommended solu=
tion. They ELC is required anytime EL is used. There is no implication in t=
his doc that ELC is not required. If it is not clear the the determination =
in the pseudocode of whether a label is EL-capable can be done through ELC,=
 I can modify the first sentence in the second last para of section 4 to re=
ad "The RLD and ELC can be advertised via protocols and ..."
<=
/div>
=C2=A0
=


=

That same section then =
lists the following:

=C2=A0 =C2=A0The RLD can=
 be advertised via protocols and those extensions are
=C2=A0 =C2=
=A0described in separate documents [I-D.xu-isis-mpls-elc] and
=C2=
=A0 =C2=A0[I-D.xu-ospf-mpls-elc].

First, tho=
se are expired and should be marked as replaced by wg docs.

Sri> Accepted. These references would be up=
dated.
=C2=A0

=

OK.

<=
div>
=


Bu=
t the main point is that knowing the RLD is REQUIRED (neither RECOMMENDED n=
or OPTIONAL) to be able to follow and comply with the requirements on where=
 to position the {ELI; EL} and with the pseudocode.

Sri> The RLD is required to follow the recommended =
solution in the draft. What exactly is the comment?
=C2=A0
<=
/div>

The comment =
is, quoting from above, that =E2=80=9C=C2=A0the RLD is REQUIRED (neither RE=
COMMENDED nor OPTIONAL) to be able to follow and comply with the requiremen=
ts=E2=80=9D. Why SHOULD? And how is the RLD learned, used, calculated, etc?=


Sri> Note that =
it is REQUIRED to follow and comply with the recommendation (not requiremen=
ts). RLD is advertised (learned) via the extensions in draft-xu-ospf-mpls-e=
lc and draft-xu-isis-mpls-elc, used as described in the pseudocode and calc=
ulated as described in the second para of sec 4 (i.e. based on the hardware=
 limitations)
=C2=A0



<=
/div>
2. OAM?

The document says the following:=


=C2=A0 =C2=A0The recommendations above are n=
ot expected to bring any additional
=C2=A0 =C2=A0OAM consideratio=
ns beyond those described in section 6 of [RFC6790].
=C2=A0 =C2=
=A0However, the OAM requirements and solutions for source routed tunnels
=C2=A0 =C2=A0formed by label stacking are still under discussion an=
d future
=C2=A0 =C2=A0revisions of this document will address tho=
se if needed.

Is this saying that the docume=
nt still needs to evolve to be ready? What are really the OAM consideration=
s related to this draft?

Sri>=
; There are no new OAM consideration related to the recommendations in this=
 draft. Having said that, the SPRING OAM drafts are not RFCs yet. Hence the=
 wording.
=C2=A0
<=
br>
If the wording of =E2=80=9Cand future revisions of thi=
s document will address those if needed=E2=80=9D is intended, is a WGLC pre=
mature?

Sri> I d=
on't think so. I can remove the second sentence and add a reference to =
draft-ietf-spring-sr-oam-requirement and refer to it in the first sentence =
right after RFC6790.
=C2=A0



3. Intended status:

I agree with =
others in the sense that this is not a Standards Track doc.

Sri> As per an earlier response to Loa'=
s suggestion, the draft will be changed to Informational.
=C2=A0<=
/div>


4. EL Capability?

This is probab=
ly the most important comment. The document defines the ELC acronym, but it=
 does not use it.

Sri> ELC i=
s not defined in this draft. It is taken from RFC6790
=C2=A0

I know, bu=
t it is not used.

Moreover, RFC 6790 defines the E=
LC, and explains how to signal it (Section 5) with LDP, BGP, and RSVP-TE. L=
ater, RFC=C2=A07447 obsoleted the BGP use. However, this document does not =
use LDP or RSVP-TE.=C2=A0

If the ELC is not consid=
ered, then you can end up with pushing ELI/EL to a node that does not under=
stand it.

Sri> D=
oes the explanation to the earlier comments suffice?
=C2=A0
=



=C2=A0 =C2=A0 =C2=A0 ELC - Entropy Label=
 Capability

From RFC 6790, the egress capability o=
f processing EL needs to be signaled to the ingress for the ingress to be a=
ble to insert an ELI; EL.=C2=A0

In this case, the =
proposed method tries to optimize for position, but it is not taking into a=
ccount whether the egress of each segment can actually process ELI; EL (or =
if it would otherwise Drop the packet!). The algorithm does says =E2=80=9Ci=
f EL-capable=E2=80=9D, but how is that learned?=C2=A0

Sri> RFC6790 defined procedures to signal ELC, bu=
t did not do so for OSPF/ISIS and these are defined in the documents refere=
nced - draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be cha=
nged to the WG draft versions).
<=
div>
Yes. However, this document is not using the ELC =
=E2=80=94 that=E2=80=99s my point.

Sri> Does the explanation to the earlier comments suffic=
e?
=C2=A0

=C2=A0<=
/div>

In other words, this seems like a bug. Is the ingress is inserting a lab=
el (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for example)=
 might not understand and would drop?

Sri> No. The recommended solution takes ELC into account and the =
advertisement of ELC is as per the referenced drafts/RFCs.=C2=A0
=


H=
ow does the solution take into account the ELC? Can you please copy/paste t=
ext from the draft?

Currently the=
 draft says:

=C2=A0 =C2=A0The RLD can be adve=
rtised via protocols and those extensions are
=C2=A0 =C2=A0descri=
bed in separate documents [I-D.xu-isis-mpls-elc] and
=C2=A0 =C2=
=A0[I-D.xu-ospf-mpls-elc].

So it is t=
alking about the advertisement of RLD, but not the ELC, and not the use (af=
ter advertisement).

Sri> Does the explanation to the earlier comments suffice?
=
=C2=A0
=



5. Labels to p=
ush?

Inserting N * 2 LSEs can have implications on=
 the head-end in terms of max numbers of labels which can be pushed. A labe=
l stack that is pushed onto a packet, might not be able to be pushed if the=
 stack grows by 2 * N LSEs.=C2=A0

The text says in=
 various portions things like:

=C2=A0 =C2=A0T=
he LSR that inserts <ELI, EL> pairs MAY have limitations
=
=C2=A0 =C2=A0on the number of such pairs that it can insert and also the de=
pth at
=C2=A0 =C2=A0which it can insert them. =C2=A0
<=
div>
However, is it really the limitation how many labels an =
ingress can push?

Sri> How a=
bout re-wording it as "The LSR that inserts <ELI, EL> pairs MAY =
have limitations on the number of labels that can be pushed and this can li=
mit the number of <ELI, EL> pairs that it can insert and also the dep=
th at which it can insert them".


To me, that is not a =E2=80=
=9CMAY=E2=80=9D. It may (not MAY) have limitations. But, the more important=
 piece is missing =E2=80=94 how do these limitations impact the solution in=
 this doc?

Sri> =
Ok. I can change MAY to may. Does earlier explanation about ELC suffice?
=C2=A0

=


Also, if there is o=
ne node in the path which does not advertise the RLD, then would the RLD be=
 zero and make the algorithm moot?

<=
div>Sri> If the RLD of a node is not available at the headend, then it i=
s a local matter on how to treat it.
=C2=A0

I believe this is incorrect=
. It=E2=80=99s part of the calculation, not a local matter.

Sri> Yes, it is part of the cal=
culation. But it not being available at the headend is presumably due to th=
e appropriate protocol extensions not being implemented in that intermediat=
e node and would suggest that the best course of action be some kind of def=
ault value determined by the headend.
=C2=A0

<=
div>

More editorial comments:

No reference to=C2=A0draft-ietf-spring-segment-routing-mpls?<=
/div>

Sri> Accepted. Will ad=
d it.
=C2=A0


=C2=A0 =C2=A0Source routed tu=
nnels with label stacking is a technique that can be
=C2=A0 =C2=
=A0leveraged to provide a method to steer a packet through a controlled
=C2=A0 =C2=A0set of segments.

Why =E2=
=80=9Csource router tunnels with label stacking=E2=80=9D (SRTLS?) and not S=
egment Routing with MPLS data plane?

Sri> Because Segment Routing is based on Source Routing.
=C2=A0

=

=C2=A0 =C2=A0 =C2=A0 OAM - Operation, Administration and Mainten=
ance

Should be "OAM - Operation, Administrati=
on, and Maintenance"

Sri&g=
t; Accepted
=C2=A0


=C2=A0 =C2=A0[I-D.xu-isis-=
mpls-elc]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Xu, X., Kini=
, S., Sivabalan, S., Filsfils, C., and S.
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Litkowski, "Signaling Entropy Label Capabi=
lity Using IS-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I=
S", draft-xu-isis-mpls-elc-02 (work in progress), April
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2015.

=C2=A0 =C2=A0[I-D.xu-ospf-mpls-elc]
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Litkowski, &quo=
t;Signaling Entropy Label Capability Using
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OSPF", draft-xu-ospf-mpls-elc-01 (work in =
progress),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Octob=
er 2014.


These are expired an=
d replaced by other documents. They should be marked as Replaced-by in the =
Tracker.

Sri> Accepted
=

=C2=A0

Thanks,

=E2=80=94 Carlos.


Thanks!

=E2=80=94 Carlos.

On Apr 25, 2016, at =
3:19 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi George, et. al,
I=E2=80=99ve found several occurrences, three =
actually, of SHOULD being used in Section 4.
=C2=A0
And I agree with Stewart that application of <ELI, EL>=
; is the local decision and, at most, this work can be published as Informa=
tional.
One commen=
t, suggestion:
=C2=
=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
the sample algorithm in Section 4 suggests that the same <ELI,EL> tup=
le been used multiple times whereas it may be advantageous to generalize an=
d point that the different entropy label value may be used by referring to =
the tuple as <ELI, ELn>
=C2=A0
=
Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<=
/div>
=C2=A0
=C2=A0
From:=
=C2=A0mpls [mailto:mpls-bounces@=
ietf.org]=C2=A0On Behalf Of=C2=A0Georg=
e Swallow
Sent:=C2=A0Monday, April 25, 2016 10:57 AM=

To:=C2=A0Stewart Bryant
Cc:=C2=A0draft-i=
etf-mpls-spring-entropy-label@tools.ietf.org;=C2=A0mpls@ietf.org;=C2=A0mpls-chairs@ietf.org
Subject:=C2=A0R=
e: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
=C2=A0
<=
div>
Stewart -
=C2=A0
On Mon, Apr =
25, 2016 at 9:58 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
I support this becoming a WG doc and thereby comming under WG
co=
ntrol.
=C2=A0<=
/div>
The document is a WG doc.=C2=A0=C2=
=A0 We are now in WG last call.
=C2=A0
However I am not sure about the dismissal of the option to reu=
se
the ELI+EL. This clutters the stack less than the proposed option.
Also I wonder why this is standards track?
=C2=A0
A reasonable question, particularly since there are no MU=
STs, SHALLs or REQUIREDs.=C2=A0 Will discuss with my Co-Chairs and ADs.<=
/u>
=C2=A0
Surely any equipment th=
at understands the ELI can do this and thus this is just an informal descri=
ption of the problem and a solution.=


Stewart


On 23/04/2016 08:53, Loa Andersson wrote:
Working Group,

This is to initiate a t=
wo week working group last call on
draft-ietf-mpls-spring-entropy-label.=


Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures agains=
t this document.

All the authors and contributors (with one exceptio=
n) have stated on
the working group mailing list that they are not aware=
 of any other
IPRs that relates to this draft.

This working group=
 last call ends May 12, 2016.


/Loa
for the MPLS wg chairs<=
/u>
=C2=A0
=C2=A0
________________________________=
_______________
mpls mailing list
mpls@ietf=
.org
https://www=
.ietf.org/mailman/listinfo/mpls


_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls








--94eb2c04f3fc6839b90531a77e12--


From nobody Sat Apr 30 07:55:13 2016
Return-Path: 
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A44C12D0F8; Sat, 30 Apr 2016 07:55:12 -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: <20160430145512.31080.17020.idtracker@ietfa.amsl.com>
Date: Sat, 30 Apr 2016 07:55:12 -0700
Archived-At: 
Cc: mpls@ietf.org
Subject: [mpls] I-D Action: draft-ietf-mpls-rfc4379bis-04.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Apr 2016 14:55:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching of the IETF.

        Title           : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
        Authors         : Kireeti Kompella
                          Carlos Pignataro
                          Nagendra Kumar
                          Sam Aldrin
                          Mach(Guoyi) Chen
	Filename        : draft-ietf-mpls-rfc4379bis-04.txt
	Pages           : 55
	Date            : 2016-04-30

Abstract:
   This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in Multi-Protocol Label Switching
   (MPLS) Label Switched Paths (LSPs).  There are two parts to this
   document: information carried in an MPLS "echo request" and "echo
   reply" for the purposes of fault detection and isolation, and
   mechanisms for reliably sending the echo reply.

   This document obsoletes RFCs 4379 and 6829.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc4379bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mpls-rfc4379bis-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-rfc4379bis-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sat Apr 30 13:05:51 2016
Return-Path: 
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8988912D1A0; Sat, 30 Apr 2016 13:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level: 
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.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 Iqg8mKdl_gd1; Sat, 30 Apr 2016 13:05:46 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1893F12D199; Sat, 30 Apr 2016 13:05:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67041; q=dns/txt; s=iport; t=1462046745; x=1463256345; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZPJCT5VHHIxxPHV9IcwULXFxx1ADyWwStzYGnVh207s=; b=StEysASmUC1WGgfUeig6ysr4oL1m4yoG4DbrvIukXFOS02mbN5BzheHw 2OqGLsYpkjQPiGLmSJyH0CfbjcqB0FXZVLDZy1uDn0Q+3qg0nqq54t1CI Fc90TUEEaSXqPkI0yI4obN4b7bloPQ9CalGg1SzTvvcNbGbGv+9fo+K1L E=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAwDJDiVX/4oNJK1egmxMU30GrguLY?= =?us-ascii?q?Q6BcgQXAQqFbgKBIjgUAQEBAQEBAWUnhEEBAQEDAQEBARcJSwsFCwIBBgIRBAE?= =?us-ascii?q?BARULAQYDAgIhBgsUCQgCBA4FDg2HegMKCA6Vep0di3MNhE4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQENBASGIYF2glaCQYFYAVkJgkErgisFh3OFZIEyhBqEQDEBgye?= =?us-ascii?q?BZ4cSgXeBZ4RNgymFNIdRh18BHgFDggUbgUtshj8BHx9/AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,557,1454976000";  d="asc'?scan'208,217";a="97398060"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Apr 2016 20:05:43 +0000
Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3UK5hxl014615 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Apr 2016 20:05:43 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 30 Apr 2016 16:05:42 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Sat, 30 Apr 2016 16:05:41 -0400
From: "Carlos Pignataro (cpignata)" 
To: Sri 
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHRnvqiyJTa1iN2rkOldcR5st5EVZ+bPPSAgAAW1wCAAiwhAIAEQ8EAgAAI04CAAAv/gIABY+6A
Date: Sat, 30 Apr 2016 20:05:41 +0000
Message-ID: <2BD9AC4F-88D4-477A-A929-97E5B0C050AF@cisco.com>
References: <571B29F8.1060301@pi.nu> <571E229B.2090405@gmail.com>  <7347100B5761DC41A166AC17F22DF11221A5E5C2@eusaamb103.ericsson.se> <4CE8FDF9-E02E-42AE-AEC3-479057197CF2@cisco.com>  <0DA662F9-7A98-4BAB-8BAB-61E69DE4F612@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.244.244]
Content-Type: multipart/signed; boundary="Apple-Mail=_0C38E7E1-DC89-424F-97A1-0F01BF71EC23"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" , "mpls@ietf.org" , "mpls-chairs@ietf.org" 
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Apr 2016 20:05:49 -0000

--Apple-Mail=_0C38E7E1-DC89-424F-97A1-0F01BF71EC23
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6526DA02-4870-45AD-9AD7-A5917AAA4775"


--Apple-Mail=_6526DA02-4870-45AD-9AD7-A5917AAA4775
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, Sri,

> On Apr 29, 2016, at 6:51 PM, Sri  wrote:
>=20
> Hi Carlos, pls see inline.
>=20
> On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro (cpignata) =
> wrote:
> Hi, Sri,
>=20
> Thanks for the response =E2=80=94 please see inline.
>=20
>> On Apr 29, 2016, at 5:37 PM, Sri > wrote:
>>=20
>> Hi Carlos,
>>=20
>> Thanks for your comments. Pls see inline.
>>=20
>> On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro (cpignata) =
> wrote:
>> Loa,
>>=20
>> I just scanned through draft-ietf-mpls-spring-entropy-label-03 and =
wanted to share some observations. Please treat these as WGLC comments.
>>=20
>> I have a number of concerns. It seems as if this document was not =
really reviewed to see if it was ready for WGLC:
>>=20
>> 1. What is this document specifying?
>>=20
>> As Greg just mentioned below, there are several SHOULD terms in =
Section 4. Those SHOULD are dependent upon the =E2=80=9CRLD".
>>=20
>>=20
>> Sri> As per my response to Loa's suggestion, this draft would be =
changed to Informational with all the SHOULDs retained.
>>=20
>=20
> Sorry I still do not understand. My comment is not about the intended =
status of the document.
>=20
> Those SHOULDs depend on the RLD. So it is a protocol specification. =
However, the RLD is defined in other docs, and loosely integrated. How =
does the solution work without RLD (i.e., if the SHOULD is not =
followed)? And how is this whole thing specified without the ELC as a =
mandatory field?
>=20
> Sri> The SHOULDs are part of the recommended solution. That does not =
imply that this draft is a protocol specification. The documents =
draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc are the protocol =
specifications and those are used in the recommended solution. They ELC =
is required anytime EL is used. There is no implication in this doc that =
ELC is not required. If it is not clear the the determination in the =
pseudocode of whether a label is EL-capable can be done through ELC, I =
can modify the first sentence in the second last para of section 4 to =
read "The RLD and ELC can be advertised via protocols and =E2=80=A6"

I=E2=80=99m still having trouble parsing some of this. The RLD and ELC =
are not global variables. They are per-node (it seems, as defined at =
draft-*-mpls-elc). The ELC is relevant in the context of the node =
popping ELI/EL. This is not clear in the doc or in the pseudocode (esp. =
using a different name for the variable). The RLD relevant to the =
calculation seems to be a characteristic of the path on a segment, =
spanning multiple nodes. Is this the case? Perhaps a topology diagram =
and a stack diagram can clarify. The pseudocode seems to be treating the =
RLD as a constant.

Further, saying "The RLD and ELC can be advertised via protocols and =
=E2=80=A6=E2=80=9D seems to also confuse the context of these, and seems =
to be not enough. It is not as if they can (and cannot) be advertised a =
specific way. It is that are REQUIRED for the calculation.

Also, the algorithm assumes an LSR knows how many ELI/ELs can insert. =
Does an LSR know instead the max number of labels it can push?

Also, looking at the design principles, the first bullet says:

   o  An LSR that is limited in the number of  pairs that it
      can insert SHOULD insert such pairs deeper in the stack.

Why is that? If the top segment traverses 15 LSRs and the next-to-bottom =
segment traverses 1 hop, and the source can only afford a single ELI;EL, =
are we missing a LB opportunity?

Lastly, the algorithm does not consider Node SIDs versus Adjacency SIDs. =
Why would you want to add an ELI/EL in an Adjacency SID?

>=20
>=20
>> That same section then lists the following:
>>=20
>>    The RLD can be advertised via protocols and those extensions are
>>    described in separate documents [I-D.xu-isis-mpls-elc] and
>>    [I-D.xu-ospf-mpls-elc].
>>=20
>> First, those are expired and should be marked as replaced by wg docs.
>>=20
>> Sri> Accepted. These references would be updated.
>>=20
>=20
> OK.
>=20
>>=20
>> But the main point is that knowing the RLD is REQUIRED (neither =
RECOMMENDED nor OPTIONAL) to be able to follow and comply with the =
requirements on where to position the {ELI; EL} and with the pseudocode.
>>=20
>> Sri> The RLD is required to follow the recommended solution in the =
draft. What exactly is the comment?
>>=20
>=20
> The comment is, quoting from above, that =E2=80=9C the RLD is REQUIRED =
(neither RECOMMENDED nor OPTIONAL) to be able to follow and comply with =
the requirements=E2=80=9D. Why SHOULD? And how is the RLD learned, used, =
calculated, etc?
>=20
> Sri> Note that it is REQUIRED to follow and comply with the =
recommendation (not requirements). RLD is advertised (learned) via the =
extensions in draft-xu-ospf-mpls-elc and draft-xu-isis-mpls-elc, used as =
described in the pseudocode and calculated as described in the second =
para of sec 4 (i.e. based on the hardware limitations)
>=20

Are RLDs and ELCs required to use the mechanism in this draft?

Note that the section you point to says =E2=80=9Cwithin the RLD of LSRs =
along the path corresponding to a label stack=E2=80=9D. How are the RLDs =
of LSRs along the path contemplated in the pseudocode?

>=20
>>=20
>>=20
>> 2. OAM?
>>=20
>> The document says the following:
>>=20
>>    The recommendations above are not expected to bring any additional
>>    OAM considerations beyond those described in section 6 of =
[RFC6790].
>>    However, the OAM requirements and solutions for source routed =
tunnels
>>    formed by label stacking are still under discussion and future
>>    revisions of this document will address those if needed.
>>=20
>> Is this saying that the document still needs to evolve to be ready? =
What are really the OAM considerations related to this draft?
>>=20
>> Sri> There are no new OAM consideration related to the =
recommendations in this draft. Having said that, the SPRING OAM drafts =
are not RFCs yet. Hence the wording.
>>=20
>=20
> If the wording of =E2=80=9Cand future revisions of this document will =
address those if needed=E2=80=9D is intended, is a WGLC premature?
>=20
> Sri> I don't think so. I can remove the second sentence and add a =
reference to draft-ietf-spring-sr-oam-requirement and refer to it in the =
first sentence right after RFC6790.
>=20

These two features seem to be quite entangled. Is SR-EL adding =
requirements to SR-OAM, or viceversa? Or both?

>=20
>>=20
>>=20
>> 3. Intended status:
>>=20
>> I agree with others in the sense that this is not a Standards Track =
doc.
>>=20
>> Sri> As per an earlier response to Loa's suggestion, the draft will =
be changed to Informational.
>>=20
>>=20
>>=20
>> 4. EL Capability?
>>=20
>> This is probably the most important comment. The document defines the =
ELC acronym, but it does not use it.
>>=20
>> Sri> ELC is not defined in this draft. It is taken from RFC6790
>>=20
>=20
> I know, but it is not used.
>=20
> Moreover, RFC 6790 defines the ELC, and explains how to signal it =
(Section 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 obsoleted the =
BGP use. However, this document does not use LDP or RSVP-TE.
>=20
> If the ELC is not considered, then you can end up with pushing ELI/EL =
to a node that does not understand it.
>=20
> Sri> Does the explanation to the earlier comments suffice?
>=20

Not to me, sorry.

>=20
>>=20
>>       ELC - Entropy Label Capability
>>=20
>> =46rom RFC 6790, the egress capability of processing EL needs to be =
signaled to the ingress for the ingress to be able to insert an ELI; EL.
>>=20
>> In this case, the proposed method tries to optimize for position, but =
it is not taking into account whether the egress of each segment can =
actually process ELI; EL (or if it would otherwise Drop the packet!). =
The algorithm does says =E2=80=9Cif EL-capable=E2=80=9D, but how is that =
learned?
>>=20
>> Sri> RFC6790 defined procedures to signal ELC, but did not do so for =
OSPF/ISIS and these are defined in the documents referenced - =
draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc (which will be changed =
to the WG draft versions).
>=20
> Yes. However, this document is not using the ELC =E2=80=94 that=E2=80=99=
s my point.
>=20
> Sri> Does the explanation to the earlier comments suffice?
>=20

Sorry, it is not clear to me. Perhaps a diagram might help.

>=20
>>=20
>>=20
>> In other words, this seems like a bug. Is the ingress is inserting a =
label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node segment for =
example) might not understand and would drop?
>>=20
>> Sri> No. The recommended solution takes ELC into account and the =
advertisement of ELC is as per the referenced drafts/RFCs.
>>=20
>=20
> How does the solution take into account the ELC? Can you please =
copy/paste text from the draft?
>=20
> Currently the draft says:
>=20
>    The RLD can be advertised via protocols and those extensions are
>    described in separate documents [I-D.xu-isis-mpls-elc] and
>    [I-D.xu-ospf-mpls-elc].
>=20
> So it is talking about the advertisement of RLD, but not the ELC, and =
not the use (after advertisement).
>=20
> Sri> Does the explanation to the earlier comments suffice?

Nope.

>=20
>=20
>>=20
>>=20
>> 5. Labels to push?
>>=20
>> Inserting N * 2 LSEs can have implications on the head-end in terms =
of max numbers of labels which can be pushed. A label stack that is =
pushed onto a packet, might not be able to be pushed if the stack grows =
by 2 * N LSEs.
>>=20
>> The text says in various portions things like:
>>=20
>>    The LSR that inserts  pairs MAY have limitations
>>    on the number of such pairs that it can insert and also the depth =
at
>>    which it can insert them.
>>=20
>> However, is it really the limitation how many labels an ingress can =
push?
>>=20
>> Sri> How about re-wording it as "The LSR that inserts  pairs =
MAY have limitations on the number of labels that can be pushed and this =
can limit the number of  pairs that it can insert and also the =
depth at which it can insert them".
>>=20
>=20
> To me, that is not a =E2=80=9CMAY=E2=80=9D. It may (not MAY) have =
limitations. But, the more important piece is missing =E2=80=94 how do =
these limitations impact the solution in this doc?
>=20
> Sri> Ok. I can change MAY to may. Does earlier explanation about ELC =
suffice?
>=20

I=E2=80=99ve not changed my mind on the same question :-)

>=20
>>=20
>> Also, if there is one node in the path which does not advertise the =
RLD, then would the RLD be zero and make the algorithm moot?
>>=20
>> Sri> If the RLD of a node is not available at the headend, then it is =
a local matter on how to treat it.
>>=20
>=20
> I believe this is incorrect. It=E2=80=99s part of the calculation, not =
a local matter.
>=20
> Sri> Yes, it is part of the calculation. But it not being available at =
the headend is presumably due to the appropriate protocol extensions not =
being implemented in that intermediate node and would suggest that the =
best course of action be some kind of default value determined by the =
headend.
>=20

Making an assumption about RLD is a big difference from what the =
document says. That has risks.

>=20
>>=20
>>=20
>> More editorial comments:
>>=20
>> No reference to draft-ietf-spring-segment-routing-mpls?
>>=20
>> Sri> Accepted. Will add it.
>>=20
>>=20
>>=20
>>    Source routed tunnels with label stacking is a technique that can =
be
>>    leveraged to provide a method to steer a packet through a =
controlled
>>    set of segments.
>>=20
>> Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D =
(SRTLS?) and not Segment Routing with MPLS data plane?
>>=20
>> Sri> Because Segment Routing is based on Source Routing.
>>=20
>>=20
>>       OAM - Operation, Administration and Maintenance
>>=20
>> Should be "OAM - Operation, Administration, and Maintenance"
>>=20
>> Sri> Accepted
>>=20
>>=20
>>=20
>>    [I-D.xu-isis-mpls-elc]
>>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>>               Litkowski, "Signaling Entropy Label Capability Using =
IS-
>>               IS", draft-xu-isis-mpls-elc-02 (work in progress), =
April
>>               2015.
>>=20
>>    [I-D.xu-ospf-mpls-elc]
>>               Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S.
>>               Litkowski, "Signaling Entropy Label Capability Using
>>               OSPF", draft-xu-ospf-mpls-elc-01 (work in progress),
>>               October 2014.
>>=20
>>=20
>> These are expired and replaced by other documents. They should be =
marked as Replaced-by in the Tracker.
>>=20
>> Sri> Accepted
>>=20
>=20
> Thanks,
>=20
> =E2=80=94 Carlos.
>=20
>>=20
>> Thanks!
>>=20
>> =E2=80=94 Carlos.
>>=20
>>> On Apr 25, 2016, at 3:19 PM, Gregory Mirsky =
> =
wrote:
>>>=20
>>> Hi George, et. al,
>>> I=E2=80=99ve found several occurrences, three actually, of SHOULD =
being used in Section 4.
>>>=20
>>> And I agree with Stewart that application of  is the local =
decision and, at most, this work can be published as Informational.
>>> One comment, suggestion:
>>> =C2=B7         the sample algorithm in Section 4 suggests that the =
same  tuple been used multiple times whereas it may be =
advantageous to generalize and point that the different entropy label =
value may be used by referring to the tuple as 
>>>=20
>>> Regards,
>>>         Greg
>>>=20
>>>=20
>>> From: mpls [mailto:mpls-bounces@ietf.org =
] On Behalf Of George Swallow
>>> Sent: Monday, April 25, 2016 10:57 AM
>>> To: Stewart Bryant
>>> Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org =
; =
mpls@ietf.org ; mpls-chairs@ietf.org =

>>> Subject: Re: [mpls] working group last call on =
draft-ietf-mpls-spring-entropy-label
>>>=20
>>> Stewart -
>>>=20
>>> On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant =
> wrote:
>>> I support this becoming a WG doc and thereby comming under WG
>>> control.
>>>=20
>>> The document is a WG doc.   We are now in WG last call.
>>>=20
>>> However I am not sure about the dismissal of the option to reuse
>>> the ELI+EL. This clutters the stack less than the proposed option.
>>>=20
>>> Also I wonder why this is standards track?
>>>=20
>>> A reasonable question, particularly since there are no MUSTs, SHALLs =
or REQUIREDs.  Will discuss with my Co-Chairs and ADs.
>>>=20
>>> Surely any equipment that understands the ELI can do this and thus =
this is just an informal description of the problem and a solution.
>>>=20
>>> Stewart
>>>=20
>>>=20
>>> On 23/04/2016 08:53, Loa Andersson wrote:
>>> Working Group,
>>>=20
>>> This is to initiate a two week working group last call on
>>> draft-ietf-mpls-spring-entropy-label.
>>>=20
>>> Please send your comments to the mpls wg mailing list (mpls@ietf.org =
).
>>>=20
>>> There are no IPR disclosures against this document.
>>>=20
>>> All the authors and contributors (with one exception) have stated on
>>> the working group mailing list that they are not aware of any other
>>> IPRs that relates to this draft.
>>>=20
>>> This working group last call ends May 12, 2016.
>>>=20
>>>=20
>>> /Loa
>>> for the MPLS wg chairs
>>>=20
>>>=20
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/mpls =

>>=20
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org 
>> https://www.ietf.org/mailman/listinfo/mpls =


--Apple-Mail=_6526DA02-4870-45AD-9AD7-A5917AAA4775
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi, Sri,

On Apr 29, 2016, at 6:51 PM, =
Sri <sriganeshkini@gmail.com> wrote:

Hi Carlos, pls see =
inline.

On Fri, Apr 29, 2016 at 3:08 PM, Carlos Pignataro =
(cpignata) <cpignata@cisco.com> wrote:
Hi, Sri,

Thanks for the response =E2=80=94 =
please see inline.

On Apr 29, 2016, at 5:37 PM, Sri <sriganeshkini@gmail.com> wrote:

Hi Carlos,

Thanks for your comments. Pls see =
inline.

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro =
(cpignata) <cpignata@cisco.com> wrote:
Loa,

I just scanned =
through draft-ietf-mpls-spring-entropy-label-03 and wanted to share =
some observations. Please treat these as WGLC comments.

I have a number of =
concerns. It seems as if this document was not really reviewed to see if =
it was ready for WGLC:

1. What is this document specifying?

As Greg just mentioned below, there are =
several SHOULD terms in Section 4. Those SHOULD are dependent upon the =
=E2=80=9CRLD".


Sri> As per my response to Loa's =
suggestion, this draft would be changed to Informational with all the =
SHOULDs retained.
 

Sorry I still do =
not understand. My comment is not about the intended status of the =
document.

Those =
SHOULDs depend on the RLD. So it is a protocol specification. However, =
the RLD is defined in other docs, and loosely integrated. How does the =
solution work without RLD (i.e., if the SHOULD is not followed)? And how =
is this whole thing specified without the ELC as a mandatory =
field?

Sri> The SHOULDs are part of the =
recommended solution. That does not imply that this draft is a protocol =
specification. The documents draft-xu-ospf-mpls-elc and =
draft-xu-isis-mpls-elc are the protocol specifications and those are =
used in the recommended solution. They ELC is required anytime EL is =
used. There is no implication in this doc that ELC is not required. If =
it is not clear the the determination in the pseudocode of whether a =
label is EL-capable can be done through ELC, I can modify the first =
sentence in the second last para of section 4 to read "The RLD and ELC =
can be advertised via protocols and =E2=80=A6"

I=E2=80=99m still having trouble parsing some of =
this. The RLD and ELC are not global variables. They are per-node (it =
seems, as defined at draft-*-mpls-elc). The ELC is relevant in the =
context of the node popping ELI/EL. This is not clear in the doc or in =
the pseudocode (esp. using a different name for the variable). The RLD =
relevant to the calculation seems to be a characteristic of the path on =
a segment, spanning multiple nodes. Is this the case? Perhaps a topology =
diagram and a stack diagram can clarify. The pseudocode seems to be =
treating the RLD as a constant. 

Further, saying "The RLD and ELC can be advertised =
via protocols and =E2=80=A6=E2=80=9D seems to also confuse the context =
of these, and seems to be not enough. It is not as if they can (and =
cannot) be advertised a specific way. It is that are REQUIRED for the =
calculation.

Also, the algorithm =
assumes an LSR knows how many ELI/ELs can insert. Does an LSR know =
instead the max number of labels it can push?

Also, looking at the design principles, the first =
bullet says:

  =
 o  An LSR that is limited in the number of <ELI, EL> =
pairs that it
      can insert =
SHOULD insert such pairs deeper in the stack.

Why is that? If the top segment =
traverses 15 LSRs and the next-to-bottom segment traverses 1 hop, and =
the source can only afford a single ELI;EL, are we missing a LB =
opportunity?

Lastly, the algorithm does not consider Node SIDs versus =
Adjacency SIDs. Why would you want to add an ELI/EL in an Adjacency =
SID?

 

That same =
section then lists the following:

   The RLD =
can be advertised via protocols and those extensions are
   described in separate documents =
[I-D.xu-isis-mpls-elc] and
  =
 [I-D.xu-ospf-mpls-elc].

First, those are expired and should be =
marked as replaced by wg docs.
Sri> Accepted. These references =
would be updated.
 

OK.


But the main point is that knowing the =
RLD is REQUIRED (neither RECOMMENDED nor OPTIONAL) to be able to follow =
and comply with the requirements on where to position the {ELI; EL} and =
with the pseudocode.

Sri> The RLD is required to follow =
the recommended solution in the draft. What exactly is the =
comment?
 

The comment is, =
quoting from above, that =E2=80=9C the RLD is REQUIRED (neither =
RECOMMENDED nor OPTIONAL) to be able to follow and comply with the =
requirements=E2=80=9D. Why SHOULD? And how is the RLD learned, used, =
calculated, etc?

Sri> Note that it is REQUIRED to =
follow and comply with the recommendation (not requirements). RLD is =
advertised (learned) via the extensions in draft-xu-ospf-mpls-elc and =
draft-xu-isis-mpls-elc, used as described in the pseudocode and =
calculated as described in the second para of sec 4 (i.e. based on the =
hardware limitations)
 

Are RLDs and ELCs required to use the mechanism in =
this draft?

Note that the section =
you point to says =E2=80=9Cwithin the RLD of LSRs along the path =
corresponding to a label stack=E2=80=9D. How are the RLDs of LSRs along =
the path contemplated in the pseudocode?




2. =
OAM?

The =
document says the following:

   The =
recommendations above are not expected to bring any additional
   OAM considerations beyond those described in =
section 6 of [RFC6790].
   However, the =
OAM requirements and solutions for source routed tunnels
   formed by label stacking are still under =
discussion and future
   revisions of =
this document will address those if needed.
Is this saying that the document still =
needs to evolve to be ready? What are really the OAM considerations =
related to this draft?

Sri> There are no new OAM =
consideration related to the recommendations in this draft. Having said =
that, the SPRING OAM drafts are not RFCs yet. Hence the =
wording.
 

If the wording of =
=E2=80=9Cand future revisions of this document will address those if =
needed=E2=80=9D is intended, is a WGLC =
premature?

Sri> I don't think so. I can remove =
the second sentence and add a reference to =
draft-ietf-spring-sr-oam-requirement and refer to it in the first =
sentence right after RFC6790.
 

These two features seem to be quite entangled. Is =
SR-EL adding requirements to SR-OAM, or viceversa? Or both?




3. =
Intended status:

I agree with others in the sense that this is not a Standards =
Track doc.

Sri> As per an earlier response to =
Loa's suggestion, the draft will be changed to Informational.
 


4. =
EL Capability?

This is probably the most important comment. The document =
defines the ELC acronym, but it does not use =
it.

Sri> ELC is not defined in this draft. It is taken from =
RFC6790
 

I know, but it is =
not used.

Moreover, RFC 6790 defines the ELC, and explains how to =
signal it (Section 5) with LDP, BGP, and RSVP-TE. Later, RFC 7447 =
obsoleted the BGP use. However, this document does not use LDP or =
RSVP-TE. 

If the ELC is not considered, then you can end up with =
pushing ELI/EL to a node that does not understand =
it.

Sri> Does the explanation to the =
earlier comments suffice?
 

Not to me, sorry.



      ELC - Entropy =
Label Capability

=46rom RFC 6790, the egress capability of processing EL needs =
to be signaled to the ingress for the ingress to be able to insert an =
ELI; EL. 

In this case, the proposed method tries to optimize for =
position, but it is not taking into account whether the egress of each =
segment can actually process ELI; EL (or if it would otherwise Drop the =
packet!). The algorithm does says =E2=80=9Cif EL-capable=E2=80=9D, but =
how is that learned? 

Sri> RFC6790 defined procedures to =
signal ELC, but did not do so for OSPF/ISIS and these are defined in the =
documents referenced - draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc =
(which will be changed to the WG draft =
versions).

Yes. However, this document is =
not using the ELC =E2=80=94 that=E2=80=99s my =
point.

Sri> Does the explanation to the =
earlier comments suffice?
 

Sorry, it is not clear to me. Perhaps a diagram =
might help.


 

In other words, this seems like a bug. Is the ingress is =
inserting a label (ELI) which the =E2=80=9Cegress=E2=80=9D (each Node =
segment for example) might not understand and would =
drop?

Sri> No. The recommended solution takes ELC into account =
and the advertisement of ELC is as per the referenced =
drafts/RFCs. 


How does the solution take into =
account the ELC? Can you please copy/paste text from the =
draft?

Currently the draft says:

   The RLD =
can be advertised via protocols and those extensions are
   described in separate documents =
[I-D.xu-isis-mpls-elc] and
  =
 [I-D.xu-ospf-mpls-elc].

So it is talking about the =
advertisement of RLD, but not the ELC, and not the use (after =
advertisement).

Sri> Does the explanation to the =
earlier comments =
suffice?

Nope.

 



5. =
Labels to push?

Inserting N * 2 LSEs can have implications on the head-end in =
terms of max numbers of labels which can be pushed. A label stack that =
is pushed onto a packet, might not be able to be pushed if the stack =
grows by 2 * N LSEs. 

The text says in various portions things like:

  =
 The LSR that inserts <ELI, EL> pairs MAY have =
limitations
   on the number of such =
pairs that it can insert and also the depth at
 =
  which it can insert them.  

However, is it really the limitation =
how many labels an ingress can push?

Sri> How about =
re-wording it as "The LSR that inserts <ELI, EL> pairs MAY have =
limitations on the number of labels that can be pushed and this can =
limit the number of <ELI, EL> pairs that it can insert and also =
the depth at which it can insert them".


To me, that is not a =E2=80=9CMAY=E2=
=80=9D. It may (not MAY) have limitations. But, the more important piece =
is missing =E2=80=94 how do these limitations impact the solution in =
this doc?

Sri> Ok. I can change MAY to may. =
Does earlier explanation about ELC suffice?
 

I=E2=80=99ve not changed my mind on the same =
question :-)



Also, if there is one node in the path =
which does not advertise the RLD, then would the RLD be zero and make =
the algorithm moot?

Sri> If the RLD of a node is not =
available at the headend, then it is a local matter on how to treat =
it.
 

I believe this is =
incorrect. It=E2=80=99s part of the calculation, not a local =
matter.

Sri> Yes, it is part of the =
calculation. But it not being available at the headend is presumably due =
to the appropriate protocol extensions not being implemented in that =
intermediate node and would suggest that the best course of action be =
some kind of default value determined by the headend.
 

Making an assumption about RLD is a big difference =
from what the document says. That has risks.




More=
 editorial comments:

No reference =
to draft-ietf-spring-segment-routing-mpls?

Sri> =
Accepted. Will add it.
 


  =
 Source routed tunnels with label stacking is a technique that can =
be
   leveraged to provide a method to =
steer a packet through a controlled
  =
 set of segments.

Why =E2=80=9Csource router tunnels with =
label stacking=E2=80=9D (SRTLS?) and not Segment Routing with MPLS data =
plane?

Sri> Because Segment Routing is based on Source =
Routing.
 

      OAM - Operation, Administration and =
Maintenance

Should be "OAM - Operation, Administration, and =
Maintenance"

Sri> Accepted
 


   [I-D.xu-isis-mpls-elc]
  =
            Xu, X., Kini, S., Sivabalan, =
S., Filsfils, C., and S.
      =
        Litkowski, "Signaling Entropy Label =
Capability Using IS-
        =
      IS", draft-xu-isis-mpls-elc-02 (work in progress), =
April
            =
  2015.

   [I-D.xu-ospf-mpls-elc]
 =
             Xu, X., Kini, S., Sivabalan, =
S., Filsfils, C., and S.
      =
        Litkowski, "Signaling Entropy Label =
Capability Using
          =
    OSPF", draft-xu-ospf-mpls-elc-01 (work in =
progress),
          =
    October 2014.


These are expired and replaced by other documents. They =
should be marked as Replaced-by in the =
Tracker.

Sri> Accepted
 

Thanks,

=E2=80=94 =
Carlos.


Thanks!

=E2=80=94 =
Carlos.

On Apr 25, 2016, at 3:19 PM, =
Gregory Mirsky <gregory.mirsky@ericsson.com> =
wrote:

Hi George, et. al,
I=E2=80=99ve found several occurrences, =
three actually, of SHOULD being used in Section 4.
 
And I agree with Stewart that application =
of <ELI, EL> is the local decision and, at most, this work can be =
published as Informational.
One comment, suggestion:
=C2=B7         the sample algorithm in Section 4 suggests that the same =
<ELI,EL> tuple been used multiple times whereas it may be =
advantageous to generalize and point that the different entropy label =
value may be used by referring to the tuple as <ELI, ELn>
 
Regards,
        Greg
 
 
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
Sent: Monday, April 25, 2016 =
10:57 AM
To: Stewart Bryant
Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org
Subject: Re: [mpls] working =
group last call on draft-ietf-mpls-spring-entropy-label
 
Stewart -
 
On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:
I support this =
becoming a WG doc and thereby comming under WG
control.
 
The document is a WG doc.   We are now in WG last =
call.
 
However I am not sure =
about the dismissal of the option to reuse
the ELI+EL. =
This clutters the stack less than the proposed option.

Also I wonder why this is standards track?
 
A reasonable question, particularly since there are no MUSTs, =
SHALLs or REQUIREDs.  Will discuss with my Co-Chairs and ADs.
 
Surely any equipment =
that understands the ELI can do this and thus this is just an informal =
description of the problem and a solution.

Stewart


On 23/04/2016 08:53, =
Loa Andersson wrote:
Working Group,

This is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no IPR disclosures against this =
document.

All the authors and contributors =
(with one exception) have stated on
the working group =
mailing list that they are not aware of any other
IPRs =
that relates to this draft.

This working =
group last call ends May 12, 2016.


/Loa
for the MPLS wg chairs
 
 
_______________________________________________
mpls mailing =
list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


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

=

--Apple-Mail=_6526DA02-4870-45AD-9AD7-A5917AAA4775--

--Apple-Mail=_0C38E7E1-DC89-424F-97A1-0F01BF71EC23
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJXJRASAAoJEIXgpQGOZny9NsEP/1W5MbrsrmrJbFQJsuJGzKLz
nO0q9xdHxOwJm8pF1NJ3rCqFYRBgrXyiTKihzwEbAhlIQL6dxoM1NeSMYiDxtNi8
siuRQZmX4RCiTW/PengxkeduVblGWPBxP7pew7D3dBFUJOQoftDGF5LBJ58VEuFv
08vp5k8y0KcVmS+xrbW4E4JqhnqaAqXEDz07j7w06V78rPCjuTNjP7b2tKm0Ldh3
dXQQnKU0f31qEG0HhIc9QJzDeR5LEterpkas3Fbkk8CZ8Z7g7GC3ETg+MMk84t/N
NvDtpCG5jbvoodJts7lSx0eUH2JrWdiJ/676r4JdSuTiumFDnLMXA1ouedTt1HJ9
G0vKrxYEPMhHuh7lwMUBPUfo3vVTt70YM+VLXCXygUTkWP+ew8yVKwEHHuQfEZL+
Btg+cI3laGFEfLb5FBg2wc0PXa2lJ//Bd8RTCNxCfisbWroP6DiJLEIB9Gxs0NNR
bZB2OBmUi46ARXpWxtiDEwjPuNM0SBGrsaYB+kwfIHlOub2yN0jGkfa364WjcWxs
f6J4aZT0KaBrmUFlHM+5J582BDaMQoxLuNRFGQvKOVGcMfcgYkEKuteg1KsvCW1M
FwX/vQBk8JLeDkatDW5vm9pIVkfUX/T6so5PG5xK0McTtFvECfTxfJFQIVTA0Ftf
U2m+bQFqzCLf+BAGvn1W
=H1A5
-----END PGP SIGNATURE-----

--Apple-Mail=_0C38E7E1-DC89-424F-97A1-0F01BF71EC23--



On Apr 29, 2016, at 5:37 PM, Sri <sriganeshkini@gmail.com> wrote:

Hi Carlos,

Thanks for your comments. Pls see =
inline.

On Tue, Apr 26, 2016 at 9:29 PM, Carlos Pignataro =
(cpignata) <cpignata@cisco.com> wrote:
Loa,

I just scanned =
through draft-ietf-mpls-spring-entropy-label-03 and wanted to share =
some observations. Please treat these as WGLC comments.

I have a number of =
concerns. It seems as if this document was not really reviewed to see if =
it was ready for WGLC:

1. What is this document specifying?

As Greg just mentioned below, there are =
several SHOULD terms in Section 4. Those SHOULD are dependent upon the =
=E2=80=9CRLD".


Sri> As per my response to Loa's =
suggestion, this draft would be changed to Informational with all the =
SHOULDs retained.
 

Sorry I still do not understand. My comment is not =
about the intended status of the document.

Those SHOULDs depend on the RLD. So it is a =
protocol specification. However, the RLD is defined in other docs, and =
loosely integrated. How does the solution work without RLD (i.e., if the =
SHOULD is not followed)? And how is this whole thing specified without =
the ELC as a mandatory field?

That same section then =
lists the following:

   The RLD can be advertised via =
protocols and those extensions are
  =
 described in separate documents [I-D.xu-isis-mpls-elc] =
and
  =
 [I-D.xu-ospf-mpls-elc].

First, those are expired and should be =
marked as replaced by wg docs.
Sri> Accepted. These references =
would be updated.
 

OK.


But the =
main point is that knowing the RLD is REQUIRED (neither RECOMMENDED nor =
OPTIONAL) to be able to follow and comply with the requirements on where =
to position the {ELI; EL} and with the =
pseudocode.

Sri> The RLD is required to follow =
the recommended solution in the draft. What exactly is the =
comment?
 

The comment is, quoting from above, that =
=E2=80=9C the RLD is REQUIRED (neither RECOMMENDED nor OPTIONAL) to =
be able to follow and comply with the requirements=E2=80=9D. Why SHOULD? =
And how is the RLD learned, used, calculated, etc?



2. =
OAM?

The =
document says the following:

   The =
recommendations above are not expected to bring any additional
   OAM considerations beyond those described in =
section 6 of [RFC6790].
   However, the =
OAM requirements and solutions for source routed tunnels
   formed by label stacking are still under =
discussion and future
   revisions of =
this document will address those if needed.
Is this saying that the document still =
needs to evolve to be ready? What are really the OAM considerations =
related to this draft?

Sri> There are no new OAM =
consideration related to the recommendations in this draft. Having said =
that, the SPRING OAM drafts are not RFCs yet. Hence the =
wording.
 

If the wording of =E2=80=9Cand future revisions of =
this document will address those if needed=E2=80=9D is intended, is a =
WGLC premature?



3. Intended status:

I agree with others in =
the sense that this is not a Standards Track =
doc.

Sri> As per an earlier response to Loa's suggestion, the =
draft will be changed to Informational.
 


4. =
EL Capability?

This is probably the most important comment. The document =
defines the ELC acronym, but it does not use =
it.

Sri> ELC is not defined in this draft. It is taken from =
RFC6790
 

I know, but it is not used.

Moreover, RFC 6790 defines the ELC, and explains =
how to signal it (Section 5) with LDP, BGP, and RSVP-TE. Later, =
RFC 7447 obsoleted the BGP use. However, this document does not use =
LDP or RSVP-TE. 

If the ELC is =
not considered, then you can end up with pushing ELI/EL to a node that =
does not understand it.


  =
    ELC - Entropy Label Capability

=46rom RFC 6790, the egress capability =
of processing EL needs to be signaled to the ingress for the ingress to =
be able to insert an ELI; EL. 

In this case, the proposed method tries =
to optimize for position, but it is not taking into account whether the =
egress of each segment can actually process ELI; EL (or if it would =
otherwise Drop the packet!). The algorithm does says =E2=80=9Cif =
EL-capable=E2=80=9D, but how is that =
learned? 

Sri> RFC6790 defined procedures to =
signal ELC, but did not do so for OSPF/ISIS and these are defined in the =
documents referenced - draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc =
(which will be changed to the WG draft =
versions).

Yes. However, this document is not using the ELC =
=E2=80=94 that=E2=80=99s my point.

 

In other words, this seems like a bug. =
Is the ingress is inserting a label (ELI) which the =E2=80=9Cegress=E2=80=9D=
 (each Node segment for example) might not understand and would =
drop?

Sri> No. The recommended solution takes ELC into account =
and the advertisement of ELC is as per the referenced =
drafts/RFCs. 


How does the solution take into account the ELC? =
Can you please copy/paste text from the draft?

Currently the draft says:

   The RLD can be =
advertised via protocols and those extensions are
   described in separate documents =
[I-D.xu-isis-mpls-elc] and
  =
 [I-D.xu-ospf-mpls-elc].

So=
 it is talking about the advertisement of RLD, but not the ELC, and not =
the use (after advertisement).



5. Labels to push?

Inserting N * 2 LSEs can =
have implications on the head-end in terms of max numbers of labels =
which can be pushed. A label stack that is pushed onto a packet, might =
not be able to be pushed if the stack grows by 2 * N =
LSEs. 

The =
text says in various portions things like:

   The LSR =
that inserts <ELI, EL> pairs MAY have limitations
   on the number of such pairs that it can insert =
and also the depth at
   which it can =
insert them.  

However, is it really the limitation how many labels an =
ingress can push?

Sri> How about re-wording it as "The =
LSR that inserts <ELI, EL> pairs MAY have limitations on the =
number of labels that can be pushed and this can limit the number of =
<ELI, EL> pairs that it can insert and also the depth at which it =
can insert them".


To me, that is not a =E2=80=9CMAY=E2=80=9D. It may =
(not MAY) have limitations. But, the more important piece is missing =E2=80=
=94 how do these limitations impact the solution in this doc?


Also, if there is one node in the path =
which does not advertise the RLD, then would the RLD be zero and make =
the algorithm moot?

Sri> If the RLD of a node is not =
available at the headend, then it is a local matter on how to treat =
it.
 

I believe this is incorrect. It=E2=80=99s part of =
the calculation, not a local matter.



More editorial comments:

No =
reference =
to draft-ietf-spring-segment-routing-mpls?

Sri> =
Accepted. Will add it.
 


   Source =
routed tunnels with label stacking is a technique that can be
   leveraged to provide a method to steer a packet =
through a controlled
   set of =
segments.

Why =E2=80=9Csource router tunnels with label stacking=E2=80=9D=
 (SRTLS?) and not Segment Routing with MPLS data =
plane?

Sri> Because Segment Routing is based on Source =
Routing.
 

  =
    OAM - Operation, Administration and Maintenance

Should be "OAM - =
Operation, Administration, and Maintenance"

Sri> =
Accepted
 


   [I-D.xu-isis-mpls-elc]
              Xu, X., =
Kini, S., Sivabalan, S., Filsfils, C., and S.
  =
            Litkowski, "Signaling Entropy =
Label Capability Using IS-
      =
        IS", draft-xu-isis-mpls-elc-02 (work in =
progress), April
          =
    2015.

   [I-D.xu-ospf-mpls-elc]
 =
             Xu, X., Kini, S., Sivabalan, =
S., Filsfils, C., and S.
      =
        Litkowski, "Signaling Entropy Label =
Capability Using
          =
    OSPF", draft-xu-ospf-mpls-elc-01 (work in =
progress),
          =
    October 2014.


These are expired and replaced by other documents. They =
should be marked as Replaced-by in the =
Tracker.

Sri> Accepted
 

Thanks,

=E2=80=94=
 Carlos.


Thanks!

=E2=80=94 Carlos.

On Apr 25, 2016, at 3:19 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Hi George, et. al,
I=E2=80=99ve found several occurrences, three actually, of =
SHOULD being used in Section 4.
 
And I agree with Stewart that application of <ELI, =
EL> is the local decision and, at most, this work can be published as =
Informational.
One comment, suggestion:
=C2=B7         the sample algorithm in Section 4 suggests that the same =
<ELI,EL> tuple been used multiple times whereas it may be =
advantageous to generalize and point that the different entropy label =
value may be used by referring to the tuple as <ELI, ELn>
 
Regards,
        Greg
 
 
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow
Sent: Monday, April 25, 2016 =
10:57 AM
To: Stewart Bryant
Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org
Subject: Re: [mpls] working =
group last call on draft-ietf-mpls-spring-entropy-label
 
Stewart -
 
On Mon, Apr 25, 2016 at 9:58 AM, Stewart Bryant =
<stewart.bryant@gmail.com> wrote:
I =
support this becoming a WG doc and thereby comming under WG
control.
 
The document is a WG doc.   We are =
now in WG last call.
 
However I am not sure about the dismissal of =
the option to reuse
the ELI+EL. This clutters the stack =
less than the proposed option.

Also I =
wonder why this is standards track?
 
A =
reasonable question, particularly since there are no MUSTs, SHALLs or =
REQUIREDs.  Will discuss with my Co-Chairs and ADs.
 
Surely any equipment that understands the ELI =
can do this and thus this is just an informal description of the problem =
and a solution.

Stewart


On 23/04/2016 08:53, Loa =
Andersson wrote:
Working Group,

This =
is to initiate a two week working group last call on
draft-ietf-mpls-spring-entropy-label.

Please send your comments to the mpls wg mailing list (mpls@ietf.org).

There are no =
IPR disclosures against this document.

All =
the authors and contributors (with one exception) have stated on
the working group mailing list that they are not aware of any =
other
IPRs that relates to this draft.

This working group last call ends May 12, 2016.


/Loa
for the MPLS =
wg chairs
 
 
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls


_______________________________________________

mpls mailing list

mpls@ietf.org

https://www.ietf.org/mailman/listinfo/mpls