From nobody Mon Aug 1 03:00:12 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6067512D12B; Mon, 1 Aug 2016 03:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 X4Z3sHXh9q9H; Mon, 1 Aug 2016 03:00:09 -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 EFEA012D550; Mon, 1 Aug 2016 02:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=827; q=dns/txt; s=iport; t=1470045599; x=1471255199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WjB6s0wLNA1hss2Seg2jXx4xJV6OD21pj50EzAUd8cs=; b=jFT8uXT33jVVyINFBWAuykvY8KANda8Gwysd2lKv9e6j7Y+YEGgK0E+Z 9Bt1mHgQ89VGLUfAdhGf9kelhkd7xFWHqjBw7i3L5U1MBp3iEWP759d3U Zn+8LyqbSwOBEARhTH6wOv+YplS4THyz3AjID2lhu8At6d5OjlwRv46ht k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AgCCHJ9X/5xdJa1dg0WBUga2fIIPg?= =?us-ascii?q?X2GHQKBKzgUAQEBAQEBAV0nhF4BAQU6PwwEAgEIEQQBAR8JBzIUCQgCBAENBQi?= =?us-ascii?q?IKcBuAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIp3ihsBBJkzAY53gXKEWoh6jDCDd?= =?us-ascii?q?gEeNoN6bodSfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,454,1464652800"; d="scan'208";a="305246170" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 09:59:59 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u719xxYK029671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Aug 2016 09:59:59 GMT Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 1 Aug 2016 04:59:58 -0500 Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1210.000; Mon, 1 Aug 2016 04:59:58 -0500 From: "Roberta Maglione (robmgl)" To: "John G.Scudder" , "draft-ietf-spring-ipv6-use-cases@ietf.org" Thread-Topic: IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC Thread-Index: AQHR5ambCBmmkQemfUibBbbc27WZbaAz6jQw Date: Mon, 1 Aug 2016 09:59:58 +0000 Message-ID: <1af990f874df45788230018ad896ef17@XCH-RCD-009.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: [10.61.207.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:00:11 -0000 Hello, I'm not aware of any IPR that hasn't been disclosed already. Regards Roberta -----Original Message----- From: John G.Scudder [mailto:jgs@juniper.net]=20 Sent: Sunday, July 24, 2016 2:48 PM To: draft-ietf-spring-ipv6-use-cases@ietf.org Cc: spring@ietf.org Subject: IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC Dear Authors: As we discussed at the SPRING meeting, working group last call has been req= uested for draft-ietf-spring-ipv6-use-cases. Before we begin the WGLC, plea= se indicate whether you are aware of any relevant IPR and if so, whether it= has been disclosed. (Please do this even if you've done it before, thanks = for your help.) Please cc the WG in your reply. As soon as this has been collected from all authors, we'll start the WGLC. Thanks, --Bruno and John From nobody Mon Aug 1 03:15:18 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8212D12B; Mon, 1 Aug 2016 03:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 p6w0WDEmqdmI; Mon, 1 Aug 2016 03:15:16 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF97A12B013; Mon, 1 Aug 2016 03:15:15 -0700 (PDT) X-AuditID: 60721c4b-403ff700000014a4-be-579f212f396f Received: from VAADCEX11.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 23.FD.05284.F212F975; Mon, 1 Aug 2016 06:15:12 -0400 (EDT) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX11.cable.comcast.com (147.191.102.78) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 1 Aug 2016 06:15:10 -0400 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1130.005; Mon, 1 Aug 2016 06:15:10 -0400 From: "Brzozowski, John" To: John G.Scudder , "draft-ietf-spring-ipv6-use-cases@ietf.org" Thread-Topic: IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC Thread-Index: AQHR5ama7dtAZRrLBEGtr2sqQt7eNKAz79aA Date: Mon, 1 Aug 2016 10:15:10 +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/f.18.0.160709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.9] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsWSUOxpoWugOD/c4MFCQ4u1G18zWcy88ZXV 4viF34wOzB5Llvxk8rjedJU9gCmKyyYlNSezLLVI3y6BK2PntCPMBdt4Ktr2eTYw9vB0MXJy SAiYSCyaepK5i5GLQ0hgJpPE1ue/2CCc/YwSj3bsZ4RwTjBK3Fr0iBmkhU3ATGLLwdvsIAkR gUZGiUtfPoMlmAXUJZbtv8ACYgsLOEv8X/kfzBYRcJG4fHUtI4RtJPF9x1R2EJtFQEXi6v25 bCA2L1DNxIXLwOYICdhJ9D9ZzApicwrYSxxY9gbMZhQQk/h+ag0TxC5xiVtP5jNB/CAgsWTP eWYIW1Ti5eN/YPWiAnoSfw58garRkTh7/QkjhG0gsXXpPhYIW0Hi/b9TQDdwAM3UlFi/Sx9i vIPE4qsb2CFsRYkp3Q/ZIc4UlDg58wlUq7jE4SM7WCcwSs9CctEshEmzkEyahWTSLCSTFjCy rmKUK0tMTEnOzcgvLTEw1EtOTMpJ1UvOz01OLC4B0ZsYQbFeJOO9g3HdT/dDjAIcjEo8vIeE 54cLsSaWFVfmHmKU4GBWEuF1UAAK8aYkVlalFuXHF5XmpBYfYpTmYFES55UynBguJJCeWJKa nZpakFoEk2Xi4JRqYDxlpDmTKfpwYq6Sbmd+TvfpN3+UdN70nGXKMHZRm/ry61nzs14zjZrE JrNnaMQ0FFjV2ejI3GVe2cyxSdf7/fLG9iR1xkmnsjxkC5aaPLar9Tm9qN93af/EKZY8hx3v L1My8W56ZN+tx5RZc5el6tmByMbXSSJLd+6OD178y/vpi0U/jLyDlViKMxINtZiLihMB9ySg 3fECAAA= Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] IPR for draft-ietf-spring-ipv6-use-cases prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:15:17 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KSm9obg0KKzEtNDg0LTk2Mi0w MDYwDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIFNjdWRkZXIgPGpn c0BqdW5pcGVyLm5ldD4NCkRhdGU6IFN1bmRheSwgSnVseSAyNCwgMjAxNiBhdCAwODo0Nw0KVG86 ICJkcmFmdC1pZXRmLXNwcmluZy1pcHY2LXVzZS1jYXNlc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYt c3ByaW5nLWlwdjYtdXNlLWNhc2VzQGlldGYub3JnPg0KQ2M6ICJzcHJpbmdAaWV0Zi5vcmciIDxz cHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBJUFIgZm9yIGRyYWZ0LWlldGYtc3ByaW5nLWlwdjYt dXNlLWNhc2VzIHByaW9yIHRvIFdHTEMNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRm Lm9yZz4NClJlc2VudC1UbzogPGpvaG5fYnJ6b3pvd3NraUBjb21jYXN0LmNvbT4sIEpvaG4gTGVk ZHkgPGpvaG5fbGVkZHlAY2FibGUuY29tY2FzdC5jb20+LCBNYXJrIFRvd25zbGV5IDx0b3duc2xl eUBjaXNjby5jb20+LCBDbGFyZW5jZSBGaWxzZmlscyA8Y2ZpbHNmaWxAY2lzY28uY29tPiwgPHJv Ym1nbEBjaXNjby5jb20+DQpSZXNlbnQtRGF0ZTogU3VuZGF5LCBKdWx5IDI0LCAyMDE2IGF0IDA4 OjQ3DQoNCiAgICBEZWFyIEF1dGhvcnM6DQogICAgDQogICAgQXMgd2UgZGlzY3Vzc2VkIGF0IHRo ZSBTUFJJTkcgbWVldGluZywgd29ya2luZyBncm91cCBsYXN0IGNhbGwgaGFzIGJlZW4gcmVxdWVz dGVkIGZvciBkcmFmdC1pZXRmLXNwcmluZy1pcHY2LXVzZS1jYXNlcy4gQmVmb3JlIHdlIGJlZ2lu IHRoZSBXR0xDLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSBy ZWxldmFudCBJUFIgYW5kIGlmIHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Nsb3NlZC4gKFBs ZWFzZSBkbyB0aGlzIGV2ZW4gaWYgeW91J3ZlIGRvbmUgaXQgYmVmb3JlLCB0aGFua3MgZm9yIHlv dXIgaGVscC4pIFBsZWFzZSBjYyB0aGUgV0cgaW4geW91ciByZXBseS4NCiAgICANCiAgICBBcyBz b29uIGFzIHRoaXMgaGFzIGJlZW4gY29sbGVjdGVkIGZyb20gYWxsIGF1dGhvcnMsIHdlJ2xsIHN0 YXJ0IHRoZSBXR0xDLg0KICAgIA0KICAgIFRoYW5rcywNCiAgICANCiAgICAtLUJydW5vIGFuZCBK b2huDQogICAgDQogICAgDQoNCg== From nobody Mon Aug 1 22:45:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2631B12B024 for ; Mon, 1 Aug 2016 22:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NEdvEEauizh for ; Mon, 1 Aug 2016 22:45:40 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F0A12B01C for ; Mon, 1 Aug 2016 22:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FzDveluAbj8vgnrUfBu3MbimhJ7C2GWDKyTBiLI0lIo=; b=Y1o1QOrBSackzEmH9EH8urX64eMI7FffTGdFQyCaNm8clW8PS9lt6EKd/sIBXLHXq0QHBW7ksDBfcHZrZQwdu86h19zSFbM/8aYzmapb65SI9DcrBD1WRj/tTo34MDebkdaOrQjX1Jj/SeuvuYDzDmtpcROvXyiPPri5Iz7BGNQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=exa@juniper.net; Received: from [172.29.98.91] (66.129.239.13) by DM2PR0501MB1167.namprd05.prod.outlook.com (10.160.245.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Tue, 2 Aug 2016 05:45:37 +0000 To: References: <3CCBF587-3720-4051-BCF4-3597E587E575@juniper.net> From: Ebben Aries Message-ID: Date: Mon, 1 Aug 2016 22:45:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3CCBF587-3720-4051-BCF4-3597E587E575@juniper.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.239.13] X-ClientProxiedBy: BY1PR18CA0019.namprd18.prod.outlook.com (10.162.126.29) To DM2PR0501MB1167.namprd05.prod.outlook.com (10.160.245.16) X-MS-Office365-Filtering-Correlation-Id: 5def61ee-c2fb-4190-0f65-08d3ba983b58 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 2:VD/9Qp5GReOPj06gTRVXabhujV7sS1C5YTq0Ls65yWQ6ZACtyDiZqK6yGSJn98eswVtz1cMBZJXGYgwDgaN6GlMhq7goJXi3+cm/OxSDfsL7TlxnkN3lCPFD9+2weymS0eI74XnQecIj5dgwqJ72nozfNvLnnymPKqF8lPjDuX9XTnXN5NDu9GAwb6fFdabh; 3:M9EQNMOBAlzPJMFCAZeOEhYMxEQhjG6NYKTga4zI4rWzi5sC66ZNstnvJy66ksrCmzRaFC5b40FG+YjU/rFiYgOksD1DRfKmvEbzKBlt6QGzIfCs8dKSDFQ2zlQPUx1e X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1167; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 25:DE8PFSA6pWrOo3ODMoF+H1R/dg/hVFMLkKQGGAEbJ9SRBjKM2Lkt1MM9Y2x/dO/NXHraSHZnMn21ATm4FYfJohx8wY6vKZoM/7CcSmBpOa0gAythjMplUI/vSZ2DGUZ38mz6dxR02Is4vSaPcv6crDkL0Axe7jZ4vTblYu2tm6LycExUZAoSGcslUN70kKViDddEtok1DIs9nEeN8bOtNe4OMd3koUqzdu+XQ5vvLMQ5di+Vpi4q3R99O6BMI1/JJlHKf+mj7n7onncDOZCLTaxOoFpQwb1rOJH14J0F5182LzI0COrVHS3UplgC0Zb6v3c1nLnsFswLg19WvLDrxefOicN4yCLxUqpaoZ+EFRQ5hImwRKsrLwiQjvFzkWWB6GDHivRufal6njYihv+XPV+LXziQALPfybGd3mVYeLC69XYYGsSOrGXT6O9KQeY8fZgP9earNpZLWNSCTBRqbWFhJwZfdloTEdKF+7rwVWbd2xbImESLwY5zFk9zqLqj8rK0//rYiu2EPs5WmGQ7zktCKsDHGLQT7l3BCbZPTDdrPXWoFv+ey56TAgWCM45bZMwPrIWF7KRYyCYdYqgZF5wZx8k5aMr6Y1rwXGnC1Ki/VJOaET0wXrsDrnU0vjpYbuYAcxsbnQjSvq6kA2v4pIWGR17Bq9tmcwv8RYitYsOI2YqAqmuqlJd6JQ74WTM7+JXYICKvoQr1LTo8DyINgN9kSKK+f+96mFkENN7XTsAfl9Wj6XPKZ/WPQlgFPOqqtaXrUfOd5Krsagq6AjO1vNVqnCjlGUf3l13kZYfQ59CPCuGGGe6XrKnzYWzG1o08 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 31:15/SmmZ0sJwsnpgSpRVRy9lQ39gcP3f8DF1UUIUiIIN1crf3zD841CuXhtKkGDXvITnvGZeN0mmP7nrUA/BzrPhj/1N/1JuG3wLcvVbg/VFC5sYn6EsySJX4kHLo4RZlix8n+iCN0UhiUIoRJsWUoYd9A3p9AXTHjIVgdIKyv5hpnU4xu5NWnTkWTJWYRfLGEIfO32lxeNsyXDFU/6obVqRTfetmp6+m6o2SvB3N1Dk=; 20:SWF2arB1lCTBCCla6kA/SDSnhFYLGCD5LzbNQnywz3yT0D4UBOFy2rSBovilENUILKVlF7FZqhZ0kD/sITPPIdQScdRKGlC5CUFoequIZ8teA9stUhVdYym2dpQcNfavrfnVWQ96ByGG1HwhzoPfFl+hbfmTWYrtb7W8/k8RgJUmW7b5uwksFRb5OI9DwZMYC0AK1Q/rMRBsNu77nIu7Hb7HRFxWwM6Jrn8Jz7WGSTBSk98N4VnoA6dhQAOeImXKRLe9/iv9qwAh4KxMkPY8OQoc6rNSwFN2ZQyqNCZjGe5CVqPzCFwTGbOuC1kNBnfrcILPpl+IlWL8WCVqtQE3MHnWsZ+lZsOZM1VyfVibO76eRZv4LXNUrgQKcf/CgVOBi9wU8fipfoKi18xc2RE9CwnmXqm5rxek7VY4ixSEpaKx7WI9zC08JADpDU5uvwaz494QpP13puOxKiqob0+gELTFZHJTcHrMBsTF0kWpxBkGXXAoHhgmNPd6G5070ikX 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:DM2PR0501MB1167; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1167; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 4:nINpYPpq7nBjr2QVV17CCtgA7H+IPE9mtM6pBEN4Pip/KOYXaaELHjkvh3SB8qOgZO+fDezDLLYtnVofB17lM7eB3fnBC3AK781iR8tiw7zNAv9wnxfV+rmFALfSM8dVi7CJ9izmFt9NLiO38n7cU1ER5io3KErA2DWGPxJxygags+BgTY2RlE78GHNX5ngHVdxuTi+rdfm53Xcdd+dwR4GV16d4l5+x6WVs+VbcJGhGgFHU5VymLvs/NxjuiEQekpkxSiKEMxck6RKn+cwykP9C6NFuzB/CAfXtRkGOL9QsufHEdxw8gldbxBkrMWQuB13g2SjIkaX+X2zxhm1DaIREpZBkxXAvnQ7wvzD9LAD0Pob0M7ZFAs/S4z01jniUrOFiH9MSGk6QxL8IBkp+0Q== X-Forefront-PRVS: 0022134A87 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(40764003)(24454002)(189002)(199003)(377454003)(65956001)(33646002)(3846002)(6116002)(450100001)(5820100001)(86362001)(65806001)(2351001)(19580395003)(105586002)(47776003)(66066001)(230783001)(106356001)(83506001)(19580405001)(7846002)(50466002)(64126003)(81166006)(81156014)(586003)(54356999)(76176999)(2950100001)(77096005)(2906002)(97736004)(23676002)(68736007)(305945005)(15975445007)(8676002)(50986999)(4001350100001)(189998001)(31686004)(110136002)(92566002)(107886002)(101416001)(31696002)(230700001)(7736002)(36756003)(42186005)(65826006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1167; H:[172.29.98.91]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjA1MDFNQjExNjc7MjM6aG5wMFR3WGtPbUdYanNuOUZzT1VFVEtH?= =?utf-8?B?S2EvMSswZm5kTFVoZHFKSjQ5TFB5MWRsS3pvdGoxSTJ1dlFDYW1DNHNpdUt6?= =?utf-8?B?YXBmTUFuQytVeTFTNm16VGlzbFEwbUI1bWtCdkJhdElEbVdOa3p0NDJiM1lJ?= =?utf-8?B?YVpVSyt0NzdWZXR1ZmkvcVJoRmhjVmd0NWpEb0JuS3hWYXptZ1VZSmFjVzY4?= =?utf-8?B?RExWZFRHVlJkaUlIWC9CRldBVXhYOFBnejVNMHRTQVlMejNYbWVPaGgzS2dM?= =?utf-8?B?K0UzaHM5N2hrd1BCQjhWMGxwcGVIMkpBM3B3UW52Nm5hNXhhd0JFa3BwRVJF?= =?utf-8?B?Qm80YzlqRjMwTFR6RFdEY0dFUnJuNk9LRVIrYkRJdU82MGVqbGhOS3kzWUgx?= =?utf-8?B?T21SYzA0Skw1OEJBMXQrMXBrTTdOejZXZlh4WnRKdDhLL29ES1lHSUp1TExx?= =?utf-8?B?djVEVTNwVmYwTTlKR1lPdTd4TXQvY1I2L2Z6SXJJV0YrT0trSG9EZjVISFhG?= =?utf-8?B?RGkyb2dQU2YwakdabTZCVERyU3dWZWc2TzZvT3Jja3NrU3JHN2hMdHdCTVBG?= =?utf-8?B?SUlmVEovOHZodTVMMUx0d2tBVjl1NXp1eTR4YUkvK2N2MG91NVI0TTNTYjE0?= =?utf-8?B?WW1xRU1pai9ING5zUFVoNGsrWWdVOUlKMWdwSDRkK0l4VVdKL2ZmZUZJT3Nx?= =?utf-8?B?Y3Jjc2RmWW8zVVJHNjFLWEI1NXNlNmJ1ZlhYNFhtR2tQUnJKNTlrU0ZrTjJn?= =?utf-8?B?SEY4eXNVYWVsOExXZUlrcHNHeEdBVUpBcGJoUTMrZzN2Q2NoTVVBMXByN0NB?= =?utf-8?B?bDFsME9FdnhRMjZKNWNEeitaUVlXSmY2elNHVjNwbm1MRFNNNjV0a0hoYVhI?= =?utf-8?B?dGxtcStzY0hCZHR0QUkra28rSktBSmNxNHJXWE9kc3JmS2VUQlJFU1lqSnRq?= =?utf-8?B?OE5vV1RoSWRkSmxPbmthMDNDSzRERUxNVGowQlBhZkpOSTFXVFBDclN1bTFI?= =?utf-8?B?eVp0TmNYYnp1WVJ5YkwxQkExQ1pWaUlvR016alBHMU5LQ1ZhbE1rQVBNNHht?= =?utf-8?B?Q1BpYXRLVjFtdEIraWh4bGtlblZCUEFpeFdBcVRnK0g0ME5EQVNPVVNGcEEv?= =?utf-8?B?cEpXclI4NG9MTEpLOVEzSWlzMTNIbnNxNmhLVVo0QktDc2pNTXNrZ2U5UExh?= =?utf-8?B?dmJnQkNNWHJUbnNUSHRqQ2RvRHJ1S0NoY3IyeHlGOUlhY1NuSHBZalJ2N3BV?= =?utf-8?B?bGprWGQ2MitQRnlkM1JJWEhocExDV1krYk0wYWhWL1Bya0h4VWtWZUhWU3RU?= =?utf-8?B?ZzlTUFRnci9MN0J1VSs1dDV1TFdQeVZ5S2M0dlpKK2dQaUlKT2l2TFhObW03?= =?utf-8?B?TmdESU9zdnA1OUdtMU9meWN1Mjl2d3ord3FEYXNBTXQweWJldHhuSklHWFZH?= =?utf-8?B?TUpIVDkrWnoyRGkxVC9oQ2M2c0tGTlJpRzZyZ1FyK2VSaW5GeTA4YVdUbGl2?= =?utf-8?B?ZENBRDd1dlkxMlp0Q1p2QWp0aWtMN2tFOWI5NDdiUlRsZkp2L2tQMUVJMHox?= =?utf-8?B?aGdzeTk5djNraFp4a05nZXUyc0xRcmhxeXZubXZyZWQyNzRZQ1p1WEd0YXQw?= =?utf-8?B?dkUvY3I3LzVGYzYzWXp4YjREOGk2ZDBsa3dCamFkQjNvbzNtVmgwd2xOWmtU?= =?utf-8?B?OHdyQ0xmMUZlb3U3THRPcHYyNHNXQmdwZUlMTnd2WUFQTjhjMzg0VVJJMUEx?= =?utf-8?B?eWtvT1VwU0xTY3VURW5mS3ZSVGdidFJ2S01kNzZ6TG1vc1E3WW1CejlLUndy?= =?utf-8?B?ZDlqa3F4OHNVSC9QYUlxaHhERXNOc09GWlJwMGJwa21sRVp0NnVIcDZuYUxE?= =?utf-8?B?N2pCMm5VYU9mNkU0K01IeWhGL3BPZUI5dDhZNCsyNDBvSlRYVzl6MGVsSHF0?= =?utf-8?B?cmtma2lCVlU3T3c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 6:zsn71p9mS2pwMaEujcTATXc2HWkB6NBAUxwCo9QCkf8/5TFZuREzu7ALQYimJITl8Q9RVbvHhX08k7sGuICRZqZ009qPHl3S9jXsZMWFaOYzKQANXV20Y2tM7YZFhEOrCfBiV5QKVJYrMKFQ7JvqD0I61WzzSVeL2Jxzrd8tMndKxURk2BKe8ctlXbqalzJiLZxfEcxVWaunet3e/jmMlxX1MjcN6aZgFCGdJB9toRAQ1ytWmMMfDWXcL/Oq0JpDrTxXUvWzACaSrERLCcpC2rw+WvhLgifl3mg4fyGJZStm+WtpiWUQCHc9Z/cGIeTkkrFR3iIiJ6hSxYJm+mL0Lw==; 5:aDO46TYJVVEkMhFzVNE+S85QUQjXeOXEMUcQYfQSa9J7Wd4leRJwK2t7WxXMVPH7IEhxi9IdufZ0nTBfHlbji2+zOOIYvxCpTnsW6ygHuwKQf6/yO1YLoC5I6acd1KCODUNZ95ImweYWSAoxveRmBg==; 24:vNDqzAUGIDt2ZxdQP6MHU4kV1Jb5xOGwQtGtoRKDFH90X+bpr1bt88xTdfAFCsQCGhATBxLUvTXhI2YZPmozRLRi7G0oSDQQ/q4MWZUwIoQ=; 7:TlEqLvlmkzTWToaEchwv8JcAj8K2fEO4HZ7CaExJHRJLD2OQ1HCUNRNudzU2ecTO5Km/0iRBP6qCwP87bCZhqEWvQfY6gRqcf/Ek1KLn70gHG/rctXkGxMB6WWaVvtGF0q/MkbG3tAYTxHHk4dBd+CKHoMTVPRl2PI72avtJWagffIXL9vLeWMJkGv8Xmsl7hB24CoODtbN5SI5yr1+6YM4fyXaf88AilQ50u1Q2rsiGFzqwx0/9se7KRfMDvSmI SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 05:45:37.9851 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1167 Archived-At: Subject: Re: [spring] IPR for draft-ietf-spring-segment-routing-central-epe prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 05:45:43 -0000 I am not aware of any IPR that has not already been disclosed /ebben On 07/24/2016 05:50 AM, John G.Scudder wrote: > Dear Authors: > > As we discussed at the SPRING meeting, working group last call has been requested for draft-ietf-spring-segment-routing-central-epe. Before we begin the WGLC, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. (Please do this even if you've done it before, thanks for your help.) Please cc the WG in your reply. > > As soon as this has been collected from all authors, we'll start the WGLC. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Wed Aug 3 01:54:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F324112D1AA; Wed, 3 Aug 2016 01:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 pAvWgIAGq2qk; Wed, 3 Aug 2016 01:54:21 -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 A23EF12B074; Wed, 3 Aug 2016 01:54:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COU72807; Wed, 03 Aug 2016 08:54:18 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Aug 2016 09:54:16 +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, 3 Aug 2016 16:54:07 +0800 From: Xuxiaohu To: "mpls@ietf.org" , "spring@ietf.org" Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQ Date: Wed, 3 Aug 2016 08:54:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> In-Reply-To: <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.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.0A0B0206.57A1B13B.0035, 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: 43e7d5472f6d6bcf2e537bbc364b06bf Archived-At: Subject: Re: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 08:54:23 -0000 Hi MPLS WG and SPRING WG, I have been told by many people that connecting MPLS segment routing (SR) i= slands/nodes over IP as described in (https://tools.ietf.org/html/draft-xu-= spring-islands-connection-over-ip-05) is very useful for the incremental de= ployment of MPLS SR. However, the remote label distribution peer mode for M= PLS SR (which is used for connecting MPLS SR islands/nodes) conflicts with = RFC3031 (see Section 3.22. Lack of Outgoing Label). I discussed with Bruno = (SPRPING WG co-chair) offline about the next step of this draft at IETF96. = he suggested that it'd better to update RFC3031 so as to take the remote la= bel distribution peer mode for MPLS SR into account. I would like to hear m= ore suggestions and comments from MPLS and SPRING WGs on the necessity of R= FC3031bis and the best way to standardize the remote label distribution pee= r mode for MPLS SR.=20 Best regards, Xiaohu > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > Sent: Wednesday, April 06, 2016 11:37 PM > To: spring@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > Hi all, >=20 > According to suggestions from SPRING co-chairs, I would clarify the inten= tion of > this draft > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-0= 5) as > follows. >=20 > If I understood the current MPLS-SR specification > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls) corr= ectly, > the IGP next-hop for a given /32 or /128 prefix FEC (i.e., node segment p= refix) is > taken as the next-hop of the received MPLS packet belonging to that FEC. = When > the IGP next-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 FE= C would > be dropped BY DEFAULT according to the following specification as quoted = from > RFC3031: >=20 > "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." >=20 > In the T-LDP or L-BGP case, the next-hop for the MPLS packet belong to a = given > prefix FEC is not the IGP next-hop of that FEC anymore. For instance, in = the > T-LDP case, the next-hop is the T-LDP peer, and in the L-BGP case, the ne= xt-hop is > the L-BGP peer. As a result, if T-LDP peers or L-BGP peers are not direct= ly > connected and are separated by an IP network, the LSP signaled by T-LDP o= r > L-BGP could be transported over that IP network. >=20 > 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 th= at FEC > or the originator of that FEC due to the IGP flooding property. In the fo= rmer 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 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 descr= ibed in > the current MPLS-SR drafts. In fact, the latter case belongs to the "remo= te label > distribution peer" case as defined in RFC3031, see below: >=20 > "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." >=20 > In a word, this draft > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-0= 5) > describes the remote label distribution peer mode which is useful for > incremental deployment purpose. >=20 > I would like to hear from SPRING and MPLS WGs whether the remote label > distribution peer mode is valid for MPLS-SR and whether we need a draft t= o > describe the remote label distribution peer mode for MPLS-SR. >=20 > Best regards, > Xiaohu > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Aug 3 03:33:38 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4312D1AE; Wed, 3 Aug 2016 03:33:32 -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 FSb5XtwGUpGp; Wed, 3 Aug 2016 03:33: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 9A0DE12D090; Wed, 3 Aug 2016 03:33:29 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BD19A2DC1A6; Wed, 3 Aug 2016 12:33:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 99A79238099; Wed, 3 Aug 2016 12:33:27 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0301.000; Wed, 3 Aug 2016 12:33:27 +0200 From: To: Xuxiaohu Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQgAAXzDA= Date: Wed, 3 Aug 2016 10:33:26 +0000 Message-ID: <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> 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.6.17.114517 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 10:33:33 -0000 Xiaohu, > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Xuxiaohu > Sen= t: Wednesday, August 03, 2016 10:54 AM >=20 > Hi MPLS WG and SPRING WG, >=20 > I have been told by many people that connecting MPLS segment routing (SR)= islands/nodes > over IP as described in (https://tools.ietf.org/html/draft-xu-spring-isla= nds-connection-over- > ip-05) is very useful for the incremental deployment of MPLS SR. However,= the remote > label distribution peer mode for MPLS SR (which is used for connecting MP= LS SR > islands/nodes) conflicts with RFC3031 (see Section 3.22. Lack of Outgoing= Label). I > discussed with Bruno (SPRPING WG co-chair) offline about the next step of= this draft at > IETF96. he suggested that it'd better to update RFC3031 so as to take the= remote label > distribution peer mode for MPLS SR into account. I think that you are referring to a private conversation that we had during= the Bits-N-Bites, Thursday evening. To be clear, on my side, I assumed tha= t this was a private conversation over a few beers. (and thanks Juniper for= the beers). Then, this is not what I said. Coming back to the technical point: First of all, it's not clear to me what, according to you, is missing in th= e current IETF specifications, to allow for your use case. - On the data plane standpoint, multiple forms of IP tunnels are capable of= carrying MPLS packets. Presumably to be able to send MPLS packets between = MPLS nodes which are not adjacent but separated by IP routers. Do we agree = on this, or is something missing? - On the control plane standpoint, the draft is very light on this, but acc= ording to the discussion, both tunnels end-points are MPLS segment routing = capable and advertise their labels (index) in the IGP. So we do have the la= bels of the IP tunnel egress/remote end point. Is there something missing? - On the specification standpoint, your draft is informational, so is not g= oing to change an existing standard track document. So it looks like to me that you could locally do what you want, e.g. assume= that the IP tunnel is a virtual MPLS link/shortcut to the egress (even tho= ugh not advertised in the IGP), and send the MPLS SR packet over that tunne= l. Then you replied that, even if it's a local behavior, a MPLS RFC prohibited= this. Then I replied that this looks like a work for the MPLS WG. e.g. if = a MPLS RFC prohibits this behavior, you need to discuss this in the MPLS WG= , and if needed, have this MPLS RFC updated. > I would like to hear more suggestions > and comments from MPLS and SPRING WGs on the necessity of RFC3031bis IMHO this part seems primarily for the MPLS WG > and the best way to standardize the remote label distribution peer mode f= or MPLS SR. IMHO this part seems primarily for the SPRING WG. MPLS SR uses routing protocols to advertise labels, more specifically link = state IGP (OSPF, IS-IS) or BGP. Can you elaborate on what is missing? Again= , the draft is light on this (to say the least). According to our discussio= n, nodes share the same IGP, hence they should already have the labels. In = all cases, your half-page draft is not proposing something new on the label= distribution standpoint. Regards, --Bruno >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > Sent: Wednesday, April 06, 2016 11:37 PM > > To: spring@ietf.org > > Cc: mpls@ietf.org > > Subject: [mpls] Clarification on the motivation of > > draft-xu-spring-islands-connection-over-ip-05 > > > > Hi all, > > > > According to suggestions from SPRING co-chairs, I would clarify the int= ention of > > this draft > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip= -05) as > > follows. > > > > If I understood the current MPLS-SR specification > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls) co= rrectly, > > 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 next-hop for that FEC is a non-MPLS node, the outgoing label fo= r 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 quote= d from > > 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 given > > 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, the = next-hop is > > the L-BGP peer. As a result, if T-LDP peers or L-BGP peers are not dire= ctly > > connected and are separated by an IP network, the LSP signaled by T-LDP= or > > L-BGP could be transported over that IP network. > > > > The situation in MPLS-SR is a little bit complex since the outgoing lab= el 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 receiv= ed MPLS > > packet belonging to that FEC; in the latter case, the originator of tha= t FEC is taken > > as the next-hop of the MPLS packet belonging to that FEC. The former ca= se is > > straightforward to understand and has been described in the current MPL= S-SR > > draft. the latter case is a bit hard to understand and has not been des= cribed in > > the current MPLS-SR drafts. In fact, the latter case belongs to the "re= mote 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 distributi= on > > 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 which is useful for > > incremental deployment purpose. > > > > I would like to hear from SPRING and MPLS WGs whether the remote label > > distribution peer mode is valid for MPLS-SR and whether we need a draft= to > > describe the remote label distribution peer mode for MPLS-SR. > > > > Best regards, > > Xiaohu > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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 Aug 3 07:28:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31712D5AB for ; Wed, 3 Aug 2016 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcfQL8LZOHAn for ; Wed, 3 Aug 2016 07:28:37 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0108.outbound.protection.outlook.com [104.47.32.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2E812DD0F for ; Wed, 3 Aug 2016 07:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hx2hpP9n4i0STngsD2tf7UDe94AgtyOj/0+r6zBwffM=; b=jkJ31gKPPuz09yB697mnHm/O6EC40Q8KRk2Twr0Y9/ZNYr9WvxcI0giyqFaKUJT53DC6OuvTxWqzBiYeoznic8neY9YwVRxIqHrNPJwjImwkKhddb/c12vURBr+ywlVWq5QSopTzGfWGGQZqfLR8tDgrgXtlYU8Q++Wg06SgElA= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2830.namprd05.prod.outlook.com (10.168.245.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Wed, 3 Aug 2016 14:24:19 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0557.009; Wed, 3 Aug 2016 14:24:19 +0000 From: Chris Bowers To: "spring@ietf.org" Thread-Topic: clarification of text in draft-ietf-spring-segment-routing-09 Thread-Index: AdHtj9OWTl/X2uSrQPadAdVrICCUdw== Date: Wed, 3 Aug 2016 14:24:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.12] x-ms-office365-filtering-correlation-id: 1a82d8c4-ee3e-49eb-2a4d-08d3bba9db9d x-microsoft-exchange-diagnostics: 1; MWHPR05MB2830; 6:bjOQDwFpL7PGQeXMufDJbgVwJYspVvwdAoVVfx7DqxFhOxJiFSPyiBICXr2tD6RiJ++mHjsZe2nvD/dkRus1nInA8WSRIIQyBmoBI3hvvgDTyZMzsqoCSfq/XQ7MYKkrwyWmb1pSubT83sBS3jAxuuHpUzDzUKSSWqV5KJAzOL4Qtq4gxDmQlRhDEImbIC/lyP5oMIR+DSCU8dEXMK2S1RS9vDmXcECk+Ra487HG44Drrm1GyTETNLx1dCIh2pbJcjKDzykeP+aU70T8G4lXmWohe2WAbc5neqN6ieSN+/lnwH/ycrXFUEx0aOamZd8IeagdFxGAyh58b2x4fP/BQg==; 5:xDGs6ZSPXJldk7OXzqTqpoOEz36MZ7E9vjclbCfTwuZaMVsG2/xxcJY01QlR1BVruqzH0OMRwlesqH6KIlsp4QjDKuDYmvy2H3ILYhf7I9U0rUIkjkCNta/6n0Z9bv59GXcsG5T1pPG6xLt/cvWA6g==; 24:WLU2Jl7gwwz1t+rBvZhgGkivkVOq5LdpLUYnCvt2Lx59EziZVzGTlhIWE90ywDCNxXv7Eh4DwhUvygvIxo4LYy7ZWpMAVci0S/EWRAXb1yc=; 7:KnbkqQyvs/pEZn6AlivrpqEpOxpJ4iFunmewDmco04rfNhcHIdEvyLRqAlkM0Nd5BsRzX2453VInSCP5FP/8Ek+mJULicRTi5cZhLLMg6RcUHe8Ah5USZebxR7tZ4BXlncVyKmfQQX08fFhXlorrxkhquLyaj/SPe6D06Y9Hry37rTeie5WvTtcpuvtVMDOXfHzVx46GEhcO4UGkyMArAZFb49pHh2xEpezfx+I67g5bvYaG4TorB0ZjVGhcP7ov x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB2830; 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:MWHPR05MB2830; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2830; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(2501003)(74316002)(81156014)(8936002)(9686002)(76576001)(77096005)(305945005)(189998001)(66066001)(7736002)(68736007)(7696003)(5640700001)(3280700002)(2900100001)(230783001)(1730700003)(110136002)(5002640100001)(8676002)(2351001)(450100001)(3660700001)(97736004)(86362001)(3846002)(101416001)(586003)(102836003)(6116002)(105586002)(10400500002)(33656002)(229853001)(54356999)(81166006)(2906002)(122556002)(106356001)(11100500001)(50986999)(87936001)(92566002)(107886002)(99286002)(7846002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2830; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 14:24:19.6017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2830 Archived-At: Subject: [spring] clarification of text in draft-ietf-spring-segment-routing-09 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:28:43 -0000 SPRING WG, The following paragraph in section 3.2.1 of draft-ietf-spring-segment-routi= ng-09 is confusing. The ingress node of an SR domain validates that the path to a prefix, advertised with a given algorithm, includes nodes all supporting the advertised algorithm. In other words, when computing paths for a given algorithm, the transit nodes MUST compute the algorithm X on the IGP topology, regardless of the support of the algorithm X by the nodes in that topology. As a consequence, if a node on the path does not support algorithm X, the IGP-Prefix segment will be interrupted and will drop packet on that node. It's the responsibility of the ingress node using a segment to check that all downstream nodes support the algorithm of the segment. I interpret the first, third, and fourth sentences in this paragraph as saying that an ingress node should make sure that transit nodes on a pat= h=20 install transit forwarding entries for prefix-SIDs for a given algorithm by= looking that=20 the SR-Algorithm (sub)-TLV advertised by the transit nodes before sending t= raffic on that path. =20 However, the second sentence in the paragraph confuses this interpretation.= =20 "In other words, when computi= ng paths for a given algorithm, the transit nodes MUST compute the algorithm X on the IGP topology, regardless of the support of the algorithm X by the nodes in that topology." This sentence could be interpreted as saying that transit nodes must comput= e=20 all algorithms advertised by any node in the topology, even if the transit = node doesn't support the algorithm. This sentence doesn't make sense to me.=20 A simple solution would be to delete this second sentence. However,=20 other clarifying text would be another solution. Thanks, Chris From nobody Wed Aug 3 20:28:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4512D87A; Wed, 3 Aug 2016 20:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 rtcT5DLEro_H; Wed, 3 Aug 2016 20:28: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 CBD0312D873; Wed, 3 Aug 2016 20:28:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COV90040; Thu, 04 Aug 2016 03:27:57 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Aug 2016 04:27:53 +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, 4 Aug 2016 11:27:46 +0800 From: Xuxiaohu To: "bruno.decraene@orange.com" Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQgAAXzDCAAQtyYA== Date: Thu, 4 Aug 2016 03:27:46 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E19C@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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.57A2B63E.00C7, 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: 43e7d5472f6d6bcf2e537bbc364b06bf Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 03:28:05 -0000 Hi Bruno, Thanks a lot for your detailed clarification. Please see my response inline= . > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Wednesday, August 03, 2016 6:33 PM > To: Xuxiaohu > Cc: mpls@ietf.org; spring@ietf.org > Subject: RE: Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > Xiaohu, >=20 > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Xuxiaohu > > > Sent: Wednesday, August 03, 2016 10:54 AM > > > > Hi MPLS WG and SPRING WG, > > > > I have been told by many people that connecting MPLS segment routing > > (SR) islands/nodes over IP as described in > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over- > > ip-05) is very useful for the incremental deployment of MPLS SR. > > However, the remote label distribution peer mode for MPLS SR (which is > > used for connecting MPLS SR > > islands/nodes) conflicts with RFC3031 (see Section 3.22. Lack of > > Outgoing Label). I discussed with Bruno (SPRPING WG co-chair) offline > > about the next step of this draft at IETF96. he suggested that it'd > > better to update RFC3031 so as to take the remote label distribution pe= er > mode for MPLS SR into account. >=20 > I think that you are referring to a private conversation that we had duri= ng the > Bits-N-Bites, Thursday evening. To be clear, on my side, I assumed that t= his was a > private conversation over a few beers. (and thanks Juniper for the beers)= . >=20 > Then, this is not what I said. >=20 > Coming back to the technical point: > First of all, it's not clear to me what, according to you, is missing in = the current > IETF specifications, to allow for your use case. > - On the data plane standpoint, multiple forms of IP tunnels are capable = of > carrying MPLS packets. Presumably to be able to send MPLS packets between > MPLS nodes which are not adjacent but separated by IP routers. Do we agre= e on > this, or is something missing? This draft doesn't talk about specific IP tunneling technologies for carryi= ng MPLS packets which have been specified in other RFCs (e.g., RFC4023 and = RFC7510). Instead, it talks about the remote label distribution peer mode f= or MPLS-SR. > - On the control plane standpoint, the draft is very light on this, but a= ccording to > the discussion, both tunnels end-points are MPLS segment routing capable = and > advertise their labels (index) in the IGP. So we do have the labels of th= e IP tunnel > egress/remote end point. Is there something missing? This draft doesn't talk about control plane protocols either. Labels/indexe= s are advertised by using IGP extensions for SR. Tunneling capabilities are= advertised by using the mechanisms as described in (https://tools.ietf.org= /html/draft-ietf-ospf-encapsulation-cap) and (https://tools.ietf.org/html/d= raft-xu-isis-encapsulation-cap). Instead, it talks about the remote label d= istribution peer mode for MPLS-SR. > - On the specification standpoint, your draft is informational, so is not= going to > change an existing standard track document. Maybe this draft should be "Standard Track" as the SR-LDP interoperation im= plementation draft (https://tools.ietf.org/html/draft-ietf-spring-segment-r= outing-ldp-interop) since both of them are internal implementation related. > So it looks like to me that you could locally do what you want, e.g. assu= me that > the IP tunnel is a virtual MPLS link/shortcut to the egress (even though = not > advertised in the IGP), and send the MPLS SR packet over that tunnel. That's the remote label distribution mode for MPLS-SR which is not obvious = as T-LDP or L-BGP. BTW, it seems not obvious like the SR-LDP interoperatio= n implementation (Note that we have ever done LDP-LBGP interoperation imple= mentation(not LBGP over LDP) many years before)). Since we have a draft to = describe SR-LDP interoperation implementation, we should have a draft to de= scribe the remote label distribution mode for MPLS-SR as well, since they a= re alternatives for incremental deployment of MPLS-SR: one is more suitable= for greenfield case while the other is more suitable for brownfield case. > Then you replied that, even if it's a local behavior, a MPLS RFC prohibit= ed this. > Then I replied that this looks like a work for the MPLS WG. e.g. if a MPL= S RFC > prohibits this behavior, you need to discuss this in the MPLS WG, and if = needed, > have this MPLS RFC updated. Provided the remote label distraction peer mode for MPLS-SR was not standar= dized, when an MPLS-SR-enabled router X receives an MPLS packet with the to= p indicating a given node segment Y, if the next-hop router of the best pat= h to Y is a non-MPLS router, X couldn't map the packet's top label into an = Next Hop Label Forwarding Entry (NHLFE) , even though the top label itself = is a valid incoming label. As a result, X would have to drop that packet ac= cording to RFC3031 (see Section 3.22. Lack of Outgoing Label). In contrast,= assume the remote label distribution peer mode for MPLS-SR is standardized= , that packet could be transported over an IP tunnel towards Y instead of b= eing dropped. Now this special implementation becomes standard-compliance, = rather than proprietary. IMHO, this situation is almost the same as the SR-= LDP interoperation implementation.=20 >=20 > > I would like to hear more suggestions > > and comments from MPLS and SPRING WGs on the necessity of RFC3031bis >=20 > IMHO this part seems primarily for the MPLS WG It seems no need to modify RFC3031 if the remote label distribution peer mo= de for MPLS-SR could be endorsed by the SPRING WG (or MPLS WG?). > > and the best way to standardize the remote label distribution peer mode= for > MPLS SR. >=20 > IMHO this part seems primarily for the SPRING WG. Agree. Any comments and suggestions on the remote label distribution peer m= ode for MPLS-SR are welcome. > MPLS SR uses routing protocols to advertise labels, more specifically lin= k state > IGP (OSPF, IS-IS) or BGP. Can you elaborate on what is missing? Again, th= e draft > is light on this (to say the least). According to our discussion, nodes s= hare the > same IGP, hence they should already have the labels. In all cases, your h= alf-page > draft is not proposing something new on the label distribution standpoint= . It's no problem to make this draft more detailed as long as the WG believes= this work (i.e., standardize the remote label distribution peer mode for M= PLS-SR) is worthwhile to do. Best regards, Xiaohu > Regards, > --Bruno >=20 > > > > Best regards, > > Xiaohu > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > Sent: Wednesday, April 06, 2016 11:37 PM > > > To: spring@ietf.org > > > Cc: mpls@ietf.org > > > Subject: [mpls] Clarification on the motivation of > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > Hi all, > > > > > > According to suggestions from SPRING co-chairs, I would clarify the > > > intention of this draft > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over > > > -ip-05) as follows. > > > > > > If I understood the current MPLS-SR specification > > > (https://tools.ietf.org/html/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 next-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 from > > > RFC3031: > > > > > > "3.22. Lack of Outgoing Label > > > When a labeled packet is traveling along an LSP, it may occasional= ly > > > 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 la= bel > > > 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 atte= mpt > > > to forward the packet further via conventional forwarding, based o= n > > > its network layer header. However, in general this is not a safe > > > procedure: > > > - If the packet has been following an explicitly routed LSP, t= his > > > 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 given prefix FEC is not the IGP next-hop of that FEC anymore. > > > For instance, in the T-LDP case, the next-hop is the T-LDP peer, and > > > in the L-BGP case, the next-hop is the L-BGP peer. As a result, if > > > T-LDP peers or L-BGP peers are not directly connected and are > > > separated by an IP network, the LSP signaled by T-LDP or L-BGP could = be > transported over that IP network. > > > > > > 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 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, th= e latter > case belongs to the "remote label distribution peer" case as defined in R= FC3031, > see below: > > > > > > "When two LSRs are IGP neighbors, we will refer to them as "local > > > label distribution peers". When two LSRs may be label distribu= tion > > > peers, but are not IGP neighbors, we will refer to them as "rem= ote > > > 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 which is > > > useful for incremental deployment purpose. > > > > > > I would like to hear from SPRING and MPLS WGs whether the remote > > > label distribution peer mode is valid for MPLS-SR and whether we > > > need a draft to describe the remote label distribution peer mode for > MPLS-SR. > > > > > > Best regards, > > > Xiaohu > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >=20 > _____________________________________________________________ > ____________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute respo= nsabilite > si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Thu Aug 4 01:18:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11312D5E8; Thu, 4 Aug 2016 01:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 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, RP_MATCHES_RCVD=-1.287, 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 CXKuun8h5tUC; Thu, 4 Aug 2016 01:18:07 -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 88FDE12D5C5; Thu, 4 Aug 2016 01:18:07 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id D7958180506; Thu, 4 Aug 2016 10:18:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id A68714006D; Thu, 4 Aug 2016 10:18:05 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0301.000; Thu, 4 Aug 2016 10:18:05 +0200 From: To: Xuxiaohu Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQgAAXzDCAAQtyYIAAaEsQ Date: Thu, 4 Aug 2016 08:18:04 +0000 Message-ID: <24264_1470298685_57A2FA3D_24264_942_1_53C29892C857584299CBF5D05346208A0F97F3A1@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E19C@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E19C@NKGEML515-MBX.china.huawei.com> 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 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 08:18:10 -0000 Xiaohu, 1) Trying to summarize your email: > It seems no need to modify RFC3031 if the remote label distribution peer = mode for MPLS- > SR could be endorsed by the SPRING WG (or MPLS WG?). On the MPLS side, you don't have an issue with any MPLS document. All you n= eed is " the remote label distribution peer mode for MPLS-SR". Is this correct? On the SPRING side, what you are asking is "the remote label distribution m= ode for MPLS-SR". Is this correct? 2) On my side, it's still not clear to me what you mean by "the remote labe= l distribution mode for MPLS-SR" In particular MPLS-SR is all about stacking labels from remote peers, so it= seems to me that the "remote label distribution mode for MPLS-SR" is there= from day 1. 3) Regarding your specific issue with RFC 3031=20 > when > an MPLS-SR-enabled router X receives an MPLS packet with the top indicati= ng a given node > segment Y, if the next-hop router of the best path to Y is a non-MPLS rou= ter, X couldn't > map the packet's top label into an Next Hop Label Forwarding Entry (NHLFE= ) , even though > the top label itself is a valid incoming label. As a result, X would have= to drop that packet > according to RFC3031 (see Section 3.22. Lack of Outgoing Label). RFC 3031 says: " 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." https://tools.ietf.org/html/rfc3031#section-3.22 In your use case, you would have a NHLFE. It would be the IP tunnel to the = egress (considered as a virtual interface if you want) plus swapping the in= coming label with the label of the egress for this FEC. In my understanding, this section describes the forwarding plane behavior w= hen no NHLFE is present. While what you are talking about is the control pl= ane behavior to build this NHLFE. So I'm not seeing that RFC 3031 prohibits= your use case. Regards, Bruno > -----Original Message----- > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > Sent: Thursday, August 04, 2016 5:28 AM > To: DECRAENE Bruno IMT/OLN > Cc: mpls@ietf.org; spring@ietf.org > Subject: RE: Clarification on the motivation of draft-xu-spring-islands-c= onnection-over-ip-05 >=20 > Hi Bruno, >=20 > Thanks a lot for your detailed clarification. Please see my response inli= ne. >=20 > > -----Original Message----- > > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > > Sent: Wednesday, August 03, 2016 6:33 PM > > To: Xuxiaohu > > Cc: mpls@ietf.org; spring@ietf.org > > Subject: RE: Clarification on the motivation of > > draft-xu-spring-islands-connection-over-ip-05 > > > > Xiaohu, > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > Sent: Wednesday, August 03, 2016 10:54 AM > > > > > > Hi MPLS WG and SPRING WG, > > > > > > I have been told by many people that connecting MPLS segment routing > > > (SR) islands/nodes over IP as described in > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over- > > > ip-05) is very useful for the incremental deployment of MPLS SR. > > > However, the remote label distribution peer mode for MPLS SR (which is > > > used for connecting MPLS SR > > > islands/nodes) conflicts with RFC3031 (see Section 3.22. Lack of > > > Outgoing Label). I discussed with Bruno (SPRPING WG co-chair) offline > > > about the next step of this draft at IETF96. he suggested that it'd > > > better to update RFC3031 so as to take the remote label distribution = peer > > mode for MPLS SR into account. > > > > I think that you are referring to a private conversation that we had du= ring the > > Bits-N-Bites, Thursday evening. To be clear, on my side, I assumed that= this was a > > private conversation over a few beers. (and thanks Juniper for the beer= s). > > > > Then, this is not what I said. > > > > Coming back to the technical point: > > First of all, it's not clear to me what, according to you, is missing i= n the current > > IETF specifications, to allow for your use case. > > - On the data plane standpoint, multiple forms of IP tunnels are capabl= e of > > carrying MPLS packets. Presumably to be able to send MPLS packets betwe= en > > MPLS nodes which are not adjacent but separated by IP routers. Do we ag= ree on > > this, or is something missing? >=20 > This draft doesn't talk about specific IP tunneling technologies for carr= ying MPLS packets > which have been specified in other RFCs (e.g., RFC4023 and RFC7510). Inst= ead, it talks > about the remote label distribution peer mode for MPLS-SR. >=20 > > - On the control plane standpoint, the draft is very light on this, but= according to > > the discussion, both tunnels end-points are MPLS segment routing capabl= e and > > advertise their labels (index) in the IGP. So we do have the labels of = the IP tunnel > > egress/remote end point. Is there something missing? >=20 > This draft doesn't talk about control plane protocols either. Labels/inde= xes are advertised > by using IGP extensions for SR. Tunneling capabilities are advertised by = using the > mechanisms as described in (https://tools.ietf.org/html/draft-ietf-ospf-e= ncapsulation-cap) > and (https://tools.ietf.org/html/draft-xu-isis-encapsulation-cap). Instea= d, it talks about the > remote label distribution peer mode for MPLS-SR. >=20 > > - On the specification standpoint, your draft is informational, so is n= ot going to > > change an existing standard track document. >=20 > Maybe this draft should be "Standard Track" as the SR-LDP interoperation = implementation > draft (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-= interop) since both > of them are internal implementation related. >=20 > > So it looks like to me that you could locally do what you want, e.g. as= sume that > > the IP tunnel is a virtual MPLS link/shortcut to the egress (even thoug= h not > > advertised in the IGP), and send the MPLS SR packet over that tunnel. >=20 > That's the remote label distribution mode for MPLS-SR which is not obviou= s as T-LDP or L- > BGP. BTW, it seems not obvious like the SR-LDP interoperation implementa= tion (Note that > we have ever done LDP-LBGP interoperation implementation(not LBGP over LD= P) many > years before)). Since we have a draft to describe SR-LDP interoperation i= mplementation, > we should have a draft to describe the remote label distribution mode for= MPLS-SR as > well, since they are alternatives for incremental deployment of MPLS-SR: = one is more > suitable for greenfield case while the other is more suitable for brownfi= eld case. >=20 > > Then you replied that, even if it's a local behavior, a MPLS RFC prohib= ited this. > > Then I replied that this looks like a work for the MPLS WG. e.g. if a M= PLS RFC > > prohibits this behavior, you need to discuss this in the MPLS WG, and i= f needed, > > have this MPLS RFC updated. >=20 > Provided the remote label distraction peer mode for MPLS-SR was not stand= ardized, when > an MPLS-SR-enabled router X receives an MPLS packet with the top indicati= ng a given node > segment Y, if the next-hop router of the best path to Y is a non-MPLS rou= ter, X couldn't > map the packet's top label into an Next Hop Label Forwarding Entry (NHLFE= ) , even though > the top label itself is a valid incoming label. As a result, X would have= to drop that packet > according to RFC3031 (see Section 3.22. Lack of Outgoing Label). In contr= ast, assume the > remote label distribution peer mode for MPLS-SR is standardized, that pac= ket could be > transported over an IP tunnel towards Y instead of being dropped. Now thi= s special > implementation becomes standard-compliance, rather than proprietary. IMHO= , this > situation is almost the same as the SR-LDP interoperation implementation. >=20 > > > > > I would like to hear more suggestions > > > and comments from MPLS and SPRING WGs on the necessity of RFC3031bis > > > > IMHO this part seems primarily for the MPLS WG >=20 > It seems no need to modify RFC3031 if the remote label distribution peer = mode for MPLS- > SR could be endorsed by the SPRING WG (or MPLS WG?). >=20 > > > and the best way to standardize the remote label distribution peer mo= de for > > MPLS SR. > > > > IMHO this part seems primarily for the SPRING WG. >=20 > Agree. Any comments and suggestions on the remote label distribution peer= mode for > MPLS-SR are welcome. >=20 > > MPLS SR uses routing protocols to advertise labels, more specifically l= ink state > > IGP (OSPF, IS-IS) or BGP. Can you elaborate on what is missing? Again, = the draft > > is light on this (to say the least). According to our discussion, nodes= share the > > same IGP, hence they should already have the labels. In all cases, your= half-page > > draft is not proposing something new on the label distribution standpoi= nt. >=20 > It's no problem to make this draft more detailed as long as the WG believ= es this work (i.e., > standardize the remote label distribution peer mode for MPLS-SR) is worth= while to do. >=20 > Best regards, > Xiaohu >=20 > > Regards, > > --Bruno > > > > > > > > Best regards, > > > Xiaohu > > > > > > > -----Original Message----- > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > Sent: Wednesday, April 06, 2016 11:37 PM > > > > To: spring@ietf.org > > > > Cc: mpls@ietf.org > > > > Subject: [mpls] Clarification on the motivation of > > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > > > Hi all, > > > > > > > > According to suggestions from SPRING co-chairs, I would clarify the > > > > intention of this draft > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-over > > > > -ip-05) as follows. > > > > > > > > If I understood the current MPLS-SR specification > > > > (https://tools.ietf.org/html/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 next-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 from > > > > RFC3031: > > > > > > > > "3.22. Lack of Outgoing Label > > > > When a labeled packet is traveling along an LSP, it may occasion= ally > > > > 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, o= r 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 at= tempt > > > > 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 scop= e 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 given prefix FEC is not the IGP next-hop of that FEC anymore. > > > > For instance, in the T-LDP case, the next-hop is the T-LDP peer, and > > > > in the L-BGP case, the next-hop is the L-BGP peer. As a result, if > > > > T-LDP peers or L-BGP peers are not directly connected and are > > > > separated by an IP network, the LSP signaled by T-LDP or L-BGP coul= d be > > transported over that IP network. > > > > > > > > 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 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 distri= bution > > > > peers, but are not IGP neighbors, we will refer to them as "r= emote > > > > 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 which is > > > > useful for incremental deployment purpose. > > > > > > > > I would like to hear from SPRING and MPLS WGs whether the remote > > > > label distribution peer mode is valid for MPLS-SR and whether we > > > > need a draft to describe the remote label distribution peer mode for > > MPLS-SR. > > > > > > > > Best regards, > > > > Xiaohu > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > _____________________________________________________________ > > ____________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, e= xploites ou > > copies sans autorisation. Si vous avez recu ce message par erreur, veui= llez le > > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages > > electroniques etant susceptibles d'alteration, Orange decline toute res= ponsabilite > > si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; they should not be distribute= d, used > > or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > > modified, changed or falsified. > > Thank you. ___________________________________________________________________________= ______________________________________________ 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 Thu Aug 4 02:33:02 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2939412D882; Thu, 4 Aug 2016 02:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.508 X-Spam-Level: X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 vBCdmYEZ_uzM; Thu, 4 Aug 2016 02:32:52 -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 9A8DF12D883; Thu, 4 Aug 2016 02:32:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COW36235; Thu, 04 Aug 2016 09:32:49 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Aug 2016 10:32:46 +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, 4 Aug 2016 17:32:40 +0800 From: Xuxiaohu To: "bruno.decraene@orange.com" Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQgAAXzDCAAQtyYIAAaEsQgAAMaMA= Date: Thu, 4 Aug 2016 09:32:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E2DB@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E19C@NKGEML515-MBX.china.huawei.com> <24264_1470298685_57A2FA3D_24264_942_1_53C29892C857584299CBF5D05346208A0F97F3A1@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <24264_1470298685_57A2FA3D_24264_942_1_53C29892C857584299CBF5D05346208A0F97F3A1@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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.0A090203.57A30BC1.0326, 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: 43e7d5472f6d6bcf2e537bbc364b06bf Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" Subject: Re: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:32:56 -0000 Hi Bruno, > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Thursday, August 04, 2016 4:18 PM > To: Xuxiaohu > Cc: mpls@ietf.org; spring@ietf.org > Subject: RE: Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > Xiaohu, >=20 > 1) Trying to summarize your email: >=20 > > It seems no need to modify RFC3031 if the remote label distribution > > peer mode for MPLS- SR could be endorsed by the SPRING WG (or MPLS > WG?). >=20 > On the MPLS side, you don't have an issue with any MPLS document. All you > need is " the remote label distribution peer mode for MPLS-SR". > Is this correct? >=20 > On the SPRING side, what you are asking is "the remote label distribution= mode > for MPLS-SR". > Is this correct? >=20 >=20 > 2) On my side, it's still not clear to me what you mean by "the remote la= bel > distribution mode for MPLS-SR" > In particular MPLS-SR is all about stacking labels from remote peers, so = it seems > to me that the "remote label distribution mode for MPLS-SR" is there from= day > 1. For a given MPLS-SR node, it could act as a remote label distribution peer = for any FECs other than itself from day 1. However, what's needed for conne= cting MPLS-SR nodes over IP is to allow an MPLS-SR node to act as a remote = label distribution peer "for itself" when the IGP next-hop from that MPLS-S= R node is a non-MPLS-SR node. For instance, when receiving an MPLS packet w= ith its top label indicating a given SR node, if the IGP next-hop towards t= hat SR node is a non-MPLS-SR node, that MPLS packet could be transported ov= er an IP tunnel towards that SR node.=20 > 3) Regarding your specific issue with RFC 3031 >=20 > > when > > an MPLS-SR-enabled router X receives an MPLS packet with the top > > indicating a given node segment Y, if the next-hop router of the best > > path to Y is a non-MPLS router, X couldn't map the packet's top label > > into an Next Hop Label Forwarding Entry (NHLFE) , even though the top > > label itself is a valid incoming label. As a result, X would have to dr= op that > packet according to RFC3031 (see Section 3.22. Lack of Outgoing Label). >=20 > RFC 3031 says: > " 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." >=20 > https://tools.ietf.org/html/rfc3031#section-3.22 >=20 > In your use case, you would have a NHLFE. It would be the IP tunnel to th= e > egress (considered as a virtual interface if you want) plus swapping the = incoming > label with the label of the egress for this FEC. Your description of such implementation is correct. However, such implement= ation is not obvious and not standard-compliance and therefore we need a dr= aft to describe it. The reason why SR-LDP implementation needs a draft is a= pplicable to this implementation as well, IMHO. Best regards, Xiaohu > In my understanding, this section describes the forwarding plane behavior= when > no NHLFE is present. While what you are talking about is the control plan= e > behavior to build this NHLFE. So I'm not seeing that RFC 3031 prohibits y= our use > case. >=20 > Regards, > Bruno >=20 > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Thursday, August 04, 2016 5:28 AM > > To: DECRAENE Bruno IMT/OLN > > Cc: mpls@ietf.org; spring@ietf.org > > Subject: RE: Clarification on the motivation of > > draft-xu-spring-islands-connection-over-ip-05 > > > > Hi Bruno, > > > > Thanks a lot for your detailed clarification. Please see my response in= line. > > > > > -----Original Message----- > > > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > > > Sent: Wednesday, August 03, 2016 6:33 PM > > > To: Xuxiaohu > > > Cc: mpls@ietf.org; spring@ietf.org > > > Subject: RE: Clarification on the motivation of > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > Xiaohu, > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > > > > Xuxiaohu > > > > > Sent: Wednesday, August 03, 2016 10:54 AM > > > > > > > > Hi MPLS WG and SPRING WG, > > > > > > > > I have been told by many people that connecting MPLS segment > > > > routing > > > > (SR) islands/nodes over IP as described in > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-ov > > > > er- > > > > ip-05) is very useful for the incremental deployment of MPLS SR. > > > > However, the remote label distribution peer mode for MPLS SR > > > > (which is used for connecting MPLS SR > > > > islands/nodes) conflicts with RFC3031 (see Section 3.22. Lack of > > > > Outgoing Label). I discussed with Bruno (SPRPING WG co-chair) > > > > offline about the next step of this draft at IETF96. he suggested > > > > that it'd better to update RFC3031 so as to take the remote label > > > > distribution peer > > > mode for MPLS SR into account. > > > > > > I think that you are referring to a private conversation that we had > > > during the Bits-N-Bites, Thursday evening. To be clear, on my side, > > > I assumed that this was a private conversation over a few beers. (and= thanks > Juniper for the beers). > > > > > > Then, this is not what I said. > > > > > > Coming back to the technical point: > > > First of all, it's not clear to me what, according to you, is > > > missing in the current IETF specifications, to allow for your use cas= e. > > > - On the data plane standpoint, multiple forms of IP tunnels are > > > capable of carrying MPLS packets. Presumably to be able to send MPLS > > > packets between MPLS nodes which are not adjacent but separated by > > > IP routers. Do we agree on this, or is something missing? > > > > This draft doesn't talk about specific IP tunneling technologies for > > carrying MPLS packets which have been specified in other RFCs (e.g., > > RFC4023 and RFC7510). Instead, it talks about the remote label distribu= tion > peer mode for MPLS-SR. > > > > > - On the control plane standpoint, the draft is very light on this, > > > but according to the discussion, both tunnels end-points are MPLS > > > segment routing capable and advertise their labels (index) in the > > > IGP. So we do have the labels of the IP tunnel egress/remote end poin= t. Is > there something missing? > > > > This draft doesn't talk about control plane protocols either. > > Labels/indexes are advertised by using IGP extensions for SR. > > Tunneling capabilities are advertised by using the mechanisms as > > described in > > (https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap) > > and (https://tools.ietf.org/html/draft-xu-isis-encapsulation-cap). > > Instead, it talks about the remote label distribution peer mode for MPL= S-SR. > > > > > - On the specification standpoint, your draft is informational, so > > > is not going to change an existing standard track document. > > > > Maybe this draft should be "Standard Track" as the SR-LDP > > interoperation implementation draft > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-inte= rop) > since both of them are internal implementation related. > > > > > So it looks like to me that you could locally do what you want, e.g. > > > assume that the IP tunnel is a virtual MPLS link/shortcut to the > > > egress (even though not advertised in the IGP), and send the MPLS SR = packet > over that tunnel. > > > > That's the remote label distribution mode for MPLS-SR which is not > > obvious as T-LDP or L- BGP. BTW, it seems not obvious like the SR-LDP > > interoperation implementation (Note that we have ever done LDP-LBGP > > interoperation implementation(not LBGP over LDP) many years before)). > > Since we have a draft to describe SR-LDP interoperation > > implementation, we should have a draft to describe the remote label > > distribution mode for MPLS-SR as well, since they are alternatives for > incremental deployment of MPLS-SR: one is more suitable for greenfield ca= se > while the other is more suitable for brownfield case. > > > > > Then you replied that, even if it's a local behavior, a MPLS RFC proh= ibited > this. > > > Then I replied that this looks like a work for the MPLS WG. e.g. if > > > a MPLS RFC prohibits this behavior, you need to discuss this in the > > > MPLS WG, and if needed, have this MPLS RFC updated. > > > > Provided the remote label distraction peer mode for MPLS-SR was not > > standardized, when an MPLS-SR-enabled router X receives an MPLS packet > > with the top indicating a given node segment Y, if the next-hop router > > of the best path to Y is a non-MPLS router, X couldn't map the > > packet's top label into an Next Hop Label Forwarding Entry (NHLFE) , > > even though the top label itself is a valid incoming label. As a > > result, X would have to drop that packet according to RFC3031 (see > > Section 3.22. Lack of Outgoing Label). In contrast, assume the remote > > label distribution peer mode for MPLS-SR is standardized, that packet > > could be transported over an IP tunnel towards Y instead of being dropp= ed. > Now this special implementation becomes standard-compliance, rather than > proprietary. IMHO, this situation is almost the same as the SR-LDP > interoperation implementation. > > > > > > > > > I would like to hear more suggestions and comments from MPLS and > > > > SPRING WGs on the necessity of RFC3031bis > > > > > > IMHO this part seems primarily for the MPLS WG > > > > It seems no need to modify RFC3031 if the remote label distribution > > peer mode for MPLS- SR could be endorsed by the SPRING WG (or MPLS > WG?). > > > > > > and the best way to standardize the remote label distribution peer > > > > mode for > > > MPLS SR. > > > > > > IMHO this part seems primarily for the SPRING WG. > > > > Agree. Any comments and suggestions on the remote label distribution > > peer mode for MPLS-SR are welcome. > > > > > MPLS SR uses routing protocols to advertise labels, more > > > specifically link state IGP (OSPF, IS-IS) or BGP. Can you elaborate > > > on what is missing? Again, the draft is light on this (to say the > > > least). According to our discussion, nodes share the same IGP, hence > > > they should already have the labels. In all cases, your half-page dra= ft is not > proposing something new on the label distribution standpoint. > > > > It's no problem to make this draft more detailed as long as the WG > > believes this work (i.e., standardize the remote label distribution pee= r mode > for MPLS-SR) is worthwhile to do. > > > > Best regards, > > Xiaohu > > > > > Regards, > > > --Bruno > > > > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > > Sent: Wednesday, April 06, 2016 11:37 PM > > > > > To: spring@ietf.org > > > > > Cc: mpls@ietf.org > > > > > Subject: [mpls] Clarification on the motivation of > > > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > > > > > Hi all, > > > > > > > > > > According to suggestions from SPRING co-chairs, I would clarify > > > > > the intention of this draft > > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection- > > > > > over > > > > > -ip-05) as follows. > > > > > > > > > > If I understood the current MPLS-SR specification > > > > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-m > > > > > pls) 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 > > > > > next-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 from > > > > > RFC3031: > > > > > > > > > > "3.22. Lack of Outgoing Label > > > > > When a labeled packet is traveling along an LSP, it may occasi= onally > > > > > happen that it reaches an LSR at which the ILM does not map th= e > > > > > packet's incoming label into an NHLFE, even though the incomin= g > 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, bas= ed on > > > > > its network layer header. However, in general this is not a s= afe > > > > > procedure: > > > > > - If the packet has been following an explicitly routed LS= P, 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 sc= ope > of > > > > > this document) that neither of these situations obtains, the o= nly > > > > > 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 given prefix FEC is not the IGP next-hop of that FEC = anymore. > > > > > For instance, in the T-LDP case, the next-hop is the T-LDP peer, > > > > > and in the L-BGP case, the next-hop is the L-BGP peer. As a > > > > > result, if T-LDP peers or L-BGP peers are not directly connected > > > > > and are separated by an IP network, the LSP signaled by T-LDP or > > > > > L-BGP could be > > > transported over that IP network. > > > > > > > > > > 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 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 which > > > > > is useful for incremental deployment purpose. > > > > > > > > > > I would like to hear from SPRING and MPLS WGs whether the remote > > > > > label distribution peer mode is valid for MPLS-SR and whether we > > > > > need a draft to describe the remote label distribution peer mode > > > > > for > > > MPLS-SR. > > > > > > > > > > Best regards, > > > > > Xiaohu > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _____________________________________________________________ > > > > ____________________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > etant susceptibles d'alteration, Orange decline toute responsabilite = si ce > message a ete altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been modified, changed or falsified. > > > Thank you. >=20 >=20 > _____________________________________________________________ > ____________________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuill= ez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages > electroniques etant susceptibles d'alteration, Orange decline toute respo= nsabilite > si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed,= used > or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Fri Aug 5 13:32:06 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3351012D605 for ; Fri, 5 Aug 2016 13:32:05 -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=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 FsjTtxHXaPh6 for ; Fri, 5 Aug 2016 13:32:03 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0117.outbound.protection.outlook.com [104.47.32.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134D712D18A for ; Fri, 5 Aug 2016 13:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e8Czs5b1wKVUE/9T7e/xlnOR9qR6+Xg4RaraJbd1rsQ=; b=KwQqj4IIGoGPx2YFVcErdnJ6hQpr5Teyahnm9xjQJLXDcVpBUknoAHLEmNlw2P8EequJ+cjfRLvJE69Ec//wwDMEp1muyNxIRohTYNgiBoE3tpj8+InB+oXxNC9pHzoeTFSHMngi7QacHUpdMVwwrPbBZT+wKb9/bJTgOAwGjn4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.241] (66.129.241.14) by SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Fri, 5 Aug 2016 20:31:56 +0000 To: "John G. Scudder" , References: From: Eric C Rosen Message-ID: Date: Fri, 5 Aug 2016 16:31:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BLUPR17CA0042.namprd17.prod.outlook.com (10.164.14.180) To SN1PR05MB2191.namprd05.prod.outlook.com (10.169.124.139) X-MS-Office365-Filtering-Correlation-Id: 5152da57-fe50-48a1-3ddb-08d3bd6f8b88 X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 2:M9ecV1jVrIqI7bgr8PLfKO4NTc1i/XqRJHKRgTM/++etwLyrzDQETk1GOgiADxj7oii72xaToAF67SM47RTMZ7DHwF8WaKW8CD+Wz7c1R62sqIUUnMyTRqWm03SInOlzlhbgmJIR5qp4VqwBO4qiZS6wvW3Iwcxjab5vJ2kl0qIgemWqw8xfUMJD/UoE+aMp; 3:OI5kw83NAUXoAB74NLrLY6DkfGbS9iMTOVbAOyZhNaIiCNtkTW/hHUUZxaMzQaLf5pCCsASVWQc0dn4KnwNAWHMnbyw5pTcrKWqlvrbo2169tmPZ7vUVYwqLzkvoeQF7; 25:6rU7S62ohkifEGIqeywsknYMRz1W0Eud0ejDnNdmGe09MqaUYnry6zkgAEJL6Zsff34sgOUp/fCR2d0bc+R1XK0aY9+1vtZ35Cx/sJnoSmEgUsTka1cJkPcqZ1EgluMxM7Fr+wfCeGWg0lLmMZxdpvN7RtdxXjKAmVU8aBseEwOFIFqEfrn5zg4Hz5LC/or+CcJnw8Y0Kc9wzF6dvAb6qVGE28fUYeAa/NDwST90TEn13PEKmwupOeIrpx1CONYcaTR3I8EUrV4C+uV3zv1us7w5v1yr4FIfHYdU9HS2Ypw8AgA+gSu+f+uCjrGrUxIWHf1KXDpe+rz1zEjKIfdgvAr+iCjwRjEu7UocNMzoVjlwcTD7tmUTcUqWdwohTN9K+rhpwnXkU+TFGT6oESkR1HGBVFBOg7OntYaFK3u/Wqg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 31:JbFW01y90I283XgFBpHzfFpGv5qeIBGOhxh1GNq+tsrT67+eaWeMFgCDDgN9b7WcKQANBYh3BnWHH1a40PZgUMYIcUVwcw5W/rT7T7RjuWsaFa4TJ77kEy4aEdUClqQi6KJjX4bj0e/ReusfxC7NmbOUkgg5UjoH10tJBFn+O4U5mhdD4kjIBtWTRmaCBW+5A2s3iRfXNpaMnyZQ3vcOKS/JRU9pZaxPKMzVvWSTKXQ=; 20:UI+EwT0bfhD4xkvU12QJ4XTcgAs5O+q9zCdFR35441P6ljAwqx7TXfEkV9Q4dD4WAsFVDIdx5zFmgGwrgYVrVUnoOrBxIccFAmNKL9Lo7UkB2HHBY0+YniJUpAt62Kl7yBsfVN/WoEdxl3mmYd9QvxPYvr6hkJ11eWehUJO4r/WfgLHiifq/9pf+IOYvJmFeb0tGjlbglUtTTQuepVxLOoIH4hyvkAqCujD1096BBfZmGoC44oEAdFQgTMHOM8F40TTQpl8aaLz1cOGWkLr4i9y1t3/EOJ+5MMZ7qC8uupZQ+xiR0m172gNQSV1m4U1bxyM14sekSRzVvCDPjKlzg3TTf1i2bzWku5/ViH63PYIloFstA1F/DrwICJXOmuBkKfPWrv05sCKX4nxSgsyLDGF3flROYiBCTCr2n1mIONROlefkDSWalviJ8RYxnJN4bM0GHXFb2FNPHogBjHEr/wZEybKFloJSB73dE0/9x+9Ae3lWP1nBW4k0J8ztE/3p 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:SN1PR05MB2191; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2191; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 4:y/9VYgqN6FW6nid8lJThrUvzsLVAZQlLmJg4M/+ZAv2hiYU0Oh8tziw84ebCzMs88lPw2toZvgYxkgIOO9Tew1dxEax5DxGECUrm2H8r3bOLdR5UUkYZSVDsAMNQMy9mtgGNAmiiDNlyTm+Jkoyoi6VqTgbcbiubxCYfxNzEL5tM786PGPDX8Ncam+WZSu8Yl6fAZP3LhQZn1ers29TnN+tyy8Fis6D1F3IfV1aTjmGKSVBKzWsPLaOfMG8ZjGYkGQUP6edF6bHVZj999f/sQwtvm/zHJCn4Q+s0P8IPjJEUPuvADQsjHDmbBTUe9Qkb4c3wsEJ3uMMlDmitz71rWSTEXMThxnP1VTfN2Kgov7Abak/QQkpKytQiSywg6DBe07kEep9wi8RCNjvxUd3ntA== X-Forefront-PRVS: 0025434D2D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(189002)(377454003)(199003)(1941001)(64126003)(86362001)(106356001)(5001770100001)(54356999)(189998001)(107886002)(586003)(36756003)(97736004)(81166006)(68736007)(65806001)(3846002)(65956001)(305945005)(81156014)(47776003)(2906002)(6116002)(7736002)(66066001)(7846002)(76176999)(83506001)(77096005)(2870700001)(15975445007)(2950100001)(50466002)(42186005)(92566002)(19580405001)(23676002)(19580395003)(31686004)(105586002)(31696002)(4001350100001)(101416001)(450100001)(50986999)(230783001)(33646002)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2191; H:[172.29.32.241]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA1TUIyMTkxOzIzOk53L3RoVGh1UzZKWnhwakxlT0J5NktCVG5N?= =?utf-8?B?V0N2UnhNWmoydVowOFBzbmt0SmlSN2F6NFFveGpHa01ndE5XQy81Y1p4UlJa?= =?utf-8?B?L1Zyeml6eUMxL0NxUGNZMS9PRDlpa1lWOUpBK3ZVNStaalUyKzdvdzN4c0NM?= =?utf-8?B?NkNFU3ZsV2crYkhadTBQbU95blZmTXIyZmhYSmUyVndWY1JONkgxc1RvUkR0?= =?utf-8?B?QnptWGZuMURKOWNaZDFnWmxBQVA5Q0QrbmNxT0dDQTdsWEM2YzBrQXlLUncy?= =?utf-8?B?dkdXcERnVUdsRmhreFZneGxpRXVrbWIzL1FCY1M5eG0wclRpNERtcElPZW1i?= =?utf-8?B?QWdqWnZWczBnWmx0Snd6eGZFN2FGK295U1ZiUGZNRlN6RWhJWGl1MVQxcFF0?= =?utf-8?B?MG1lb243UEZUdndFN210VmpqNDVKYmI3SUJhOHNza3JXOFFBSVhWYmlOSmRp?= =?utf-8?B?bFVnbnBmeTRyZmN5dFVSYVF2Ym9DNkg2bXlKN3lCNmFsUUlRTzdKdjMzd21u?= =?utf-8?B?Uml1SW91bWZvNjc4bE1kQzlPaUVoRU1HWVNRQjlpdzhtalBBdzVTVkVwUFdx?= =?utf-8?B?NFNRMHd4WVZpaW82VWZ0Z1M1aFBLb2k4bThZbXdBWXNDaW1JM1EvenZiT2tQ?= =?utf-8?B?V0NpRDNOS1dvc3ZPTXNVb29ObXpkMzZFMXo4RmlmYUJtamtFWUpXNWdXNDMx?= =?utf-8?B?WkFDMm1xcjFJemhKRU1UZmc5K0hESTNwM1RiblpEd0Mvc3NPREREMW13dHlI?= =?utf-8?B?Y0N1cUg1N3BFV1lUWWVtSDZRUExZZGlVWkNTMVQxMDg5c20vd0FSOWoyT1gv?= =?utf-8?B?SVB6Vkd0ZTJGUy9Dald1Ti9Ed0c2OGREaVV5amNJZFVQUzY5d3UzWi9nNjR0?= =?utf-8?B?QW16elpsV3dSY1pQZVNIN0NyeEYzS2J3U2lhNGtwckMvcUdvVVhkbUdVcmdB?= =?utf-8?B?bU91cWk4NWxRMWx1ZmNzQW9KbnlJYWlXTEdsQ0VlanJCencvbFFxaVY4elRZ?= =?utf-8?B?aXBkU3pRS3d6UjZ0aTBLUld0WDFZSGpXNVZkY09LckppS3FCQzZ4M09rN1dV?= =?utf-8?B?azQvLzNJcko4RUFUM280ank4NmxvaFo5eDk5MTI4Y3QrR1Z1SDgvOENwVm5L?= =?utf-8?B?WTg1ME11Z3Q0RURQUVNhRytUNGltWU9qWmJmOUNxeWRrY1EyaUdESG83emhW?= =?utf-8?B?RWI4V2IxMlVFUVEzZFlRd2haRHJPczAvaXEwMG5CVzhjRENNZTBMdS91Wm00?= =?utf-8?B?dnBNV1dMTG56SnNVQzJCTHlDRWdyMGluNEJqRzBLeXI1STdkdFlnK0RmUkJs?= =?utf-8?B?aU1GMURWTmltM01OTVNteXpLS3JSYStkUWtTYWZtVDV5Q0VIbDhBUnBYNytt?= =?utf-8?B?eVZqdXhScEdFL3E1ZkNITWdObEw0WEw0ek9pN1hPa3d1MkxYaVgzcXNZVGcr?= =?utf-8?B?Z2tlMTR4ZlpFemw0aFJIR2tiV0VGcHlCK3Q5SE1sdlNpK3ZGRXpiL2NTWEpV?= =?utf-8?B?SGk5dk9rZWx6VXhpdXBHYzAxaEhzcDNCNWtHME40QWZEVDdCS2dOTmJNUkwx?= =?utf-8?B?Kzh3aEg1dzkveUYvNmpYUUJRRlBhN3lpeithU1ZKYWNJV2hZZFRibDFiU0o0?= =?utf-8?B?MDhtbUhEbkNHYjkzdlNUTEVkeU5QYld1MVh5WlNEZzN2N1dFd3BtSDlUNFNS?= =?utf-8?B?UmE1TEgzcHViMGwrdzNMdUhKYnlBeUtsN2pkdno1ckE1L0taMlIzMzJ0dmNa?= =?utf-8?B?M1dLalgwbUhVUDNqUGt5VTZsc0hEVW1XYVd6cTBsVWprM0pWR0RNOWtoNWlu?= =?utf-8?B?UjVOVGxEM0V4QzhDT01EbjVTSXZlMWJYb1l2S1FuWkJJSlE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2191; 6:zUC9aFC7bSrcUt6kfHbj0XRmnM35Ny9sZcrD4fmyjYEH5C8Jbdga3XhEOhyI3YxHo99r8YJP2uFbwX1sEYku73zMyaexPhDL1sLuQar49iAermx43mq3Pcd9jC09IkGWUYC7WWNQDEBzN/SYewhzAYsbDl7REYd4gVY3sXPtgp6+5rNPzSxLyOfUuGAQ/jarw6vwvr2zm22RC0BVQ2PR3/MllaX6l7feMtm3MHrFmiAPck0SqCktCNeLYyL1lh8XwreVwyI/cU5jxW9W1xKesvNpJr338AHP28ExNutAcma9zlBxgTOOgUZ8eQwuH6rmHxhiVwF8DXiCv+Nk1QFJXA==; 5:eu7wtY7svEqLfjkEltA2tTcYjQLvHJnj4bVhk71+TDjYExDr9SaUDoTf/24krEoftyOOFroFAs/mqD8dqjwexFNPb0otmW2vvZi02qnJBQxHgJ8W/GPq6Ob5MNniwzns9KImIVsGSWUFug5vviKhBQ==; 24:O/sKkjlmd9g6GyKDGLMJwHFCecNELhXg+w37BstqqbwCyFWEDUL67hNdaBgCwO2WlGZVMOavwZjMwiI4Y+FBQop++8tuGKgq84KLMNMGrnI=; 7:iWmF19aqDO6m+/rPlKEXX5H45D9cC3oZ7IyUWTr7oKgU0gp1pA/stOGWa1hPPIYAGLfK6vApqyFrVucH/iwfcnjoLDjvI6M0Zbjxb9BARZP2QAu2VQhX+aQ1hStI+iYz6CTsso5Z1fWRT09QGyXDB+6ZDfn96lGA9lCIadcz9ApB+tZoDviittKsIeZjwxUTIpUckXwKL4blpwPn7WmFYeE5lU+RLo9LM8+gjMX7viPBPnpulm5aiHnUd0DsGon0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 20:31:56.5740 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2191 Archived-At: Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 20:32:05 -0000 I'm afraid I really don't understand just what the point of adopting this document would be. All the document really says is that one can improve scale by using hierarchy. That is certainly true, but hardly a new result. The document gives two examples of hierarchical structure: a two-level hierarchy and an "optional" three-level hierarchy. I'm not sure why the three-level hierarchy is any more or less optional than the two-level hierarchy or any other form of hierarchy. The document goes on to sketch an application that could be run over the hierarchy, the application of setting up pseudowires with SLA. Then it gives an example of how one might (or might not) set up a control plane to run the example application over the example hierarchy. But one certainly couldn't hand this draft to a vendor and say "this is what I want"; there isn't nearly enough content in the draft for it to be used that way. The document doesn't seem to rule out any alternatives, or even give considerations that could be used to rule out alternatives. The document doesn't require anything, doesn't prohibit anything, doesn't provide any kind of comprehensive analysis, doesn't really address any protocol issues. While it does present some interesting thoughts about the use of hieararchy in a spring-based network, I don't think it makes any sense for the working group to adopt the document in its present form. It is possible that the document is intended to evolve into a more comprehensive study of hierarchical approaches to segment routing. In that case, I think it would be useful to see a little more of that evolution before considering whether to adopt the document. On 7/24/2016 8:55 AM, John G. Scudder wrote: > Dear WG, > > As we discussed at our meeting, working group adoption has been requested for draft‐filsfils‐spring‐large-scale-interconnect. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document greatly exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Fri Aug 5 14:09:52 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F64C12D595 for ; Fri, 5 Aug 2016 14:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7up5nzrh7lr for ; Fri, 5 Aug 2016 14:09:49 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 43E2C12D516 for ; Fri, 5 Aug 2016 14:09:49 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id g62so211531353lfe.3 for ; Fri, 05 Aug 2016 14:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aHlMOl3BUJHMOy9lJAD712+VNDYrV5QDT/k3kSr0cdU=; b=hE4gC2C9Mzwp6hJW4cBIlKOIh214OnZIWDYCwg8ncOPodazYpXVbk5fKj6paFcmj3c MbsAFk3ICCeZh7UCVSWuiOvc1oRpXXlvOfnPO8wHNx3aezsxsyHFj9JUM31wudHknYyF KmUH8gzV2JuQiLjcMhznlmYustNw21pUuKg2MkeYajyljKOSYF0bP+4wobTX0zw/Ehpb UYlIVrkEzy9KoGfpLHBW2xQEf/CtuAZvfmbIqrDwts+0daBBrpcVSo3Flb0AVPHLOHmf KTXQHdlU93+2YqESve+z7/aH+cDnxlgUJ7wMApzLGGE1mBOKwqvn3viozhRR6x/PnH5/ VR2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aHlMOl3BUJHMOy9lJAD712+VNDYrV5QDT/k3kSr0cdU=; b=dErXyduylVbuH52SaWjjIAZPHOYST4VCpxjrAhrw6xdXkcjRVC9H/Ys9U2jzsopU58 N6Ab3oFfWFfvdoXvnBdocBlqTu9zBM7tkXvvoX/wSJ3v5IXbma0xljttAhr160Mwaxem A4dW1vbqAUF0pNxE2u2Kl46SAa6CR7Nz65mdXwOfmMdkYyLOYGPQY2uD55CoLbUJUUYf jgDrnYD63513253p0pQ1R0vTLku5bTbSvvRCqj3WN2hb+kC3JLdEZeAN9iIHnqk5q/Oj WDAip9opZi1NjiDdRr0N95jaO1JhTAjh4vQRlK+ldOIJZz7q1TrXNb6aLtcSZ+zBaXnj IUyQ== X-Gm-Message-State: AEkoouv4ISaUxW/UzkmhSypIEN4Hck5F9H8YjSaFCYB1xKEV+RrGSdaBGbUBZYNEyQJRa7by3w45r+vcpjpv3g== X-Received: by 10.25.37.18 with SMTP id l18mr27229639lfl.88.1470431387312; Fri, 05 Aug 2016 14:09:47 -0700 (PDT) MIME-Version: 1.0 Sender: rraszuk@gmail.com Received: by 10.25.10.131 with HTTP; Fri, 5 Aug 2016 14:09:46 -0700 (PDT) In-Reply-To: References: From: Robert Raszuk Date: Fri, 5 Aug 2016 23:09:46 +0200 X-Google-Sender-Auth: o3zTAbKN9bLXYyfaP5iY1gWxav0 Message-ID: To: Eric C Rosen Content-Type: multipart/alternative; boundary=001a114117e281e9000539597c7f Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 21:09:52 -0000 --001a114117e281e9000539597c7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As not a co-author I support the adoption of this document. It is to be used as deployment guideline and contains very useful examples for ops and network engineering teams. It has been discussed that IETF drafts should not be limited to protocol specifications. In general we publish a lot of dry documents which in number of cases lack of comprehensive operational guidelines. It is however to the working group and area director to categorize such document as informational RFC or make it a BCP. Useful work ! As to one comment made: > But one certainly couldn't hand this draft to a vendor and say "this is what I want"; > there isn't nearly enough content in the draft for it to be used that way= . I must say that this really depends on the vendor. If I have internal development teams or external vendor developing controller such document is a very good reference to base customized details on. And those would normally be given SP or Enterprise "secret sauce". Kind regards, Robert. On Fri, Aug 5, 2016 at 10:31 PM, Eric C Rosen wrote: > I'm afraid I really don't understand just what the point of adopting this > document would be. > > All the document really says is that one can improve scale by using > hierarchy. That is certainly true, but hardly a new result. The documen= t > gives two examples of hierarchical structure: a two-level hierarchy and a= n > "optional" three-level hierarchy. I'm not sure why the three-level > hierarchy is any more or less optional than the two-level hierarchy or an= y > other form of hierarchy. > > The document goes on to sketch an application that could be run over the > hierarchy, the application of setting up pseudowires with SLA. Then it > gives an example of how one might (or might not) set up a control plane t= o > run the example application over the example hierarchy. But one certainl= y > couldn't hand this draft to a vendor and say "this is what I want"; there > isn't nearly enough content in the draft for it to be used that way. > > The document doesn't seem to rule out any alternatives, or even give > considerations that could be used to rule out alternatives. > > The document doesn't require anything, doesn't prohibit anything, doesn't > provide any kind of comprehensive analysis, doesn't really address any > protocol issues. While it does present some interesting thoughts about t= he > use of hieararchy in a spring-based network, I don't think it makes any > sense for the working group to adopt the document in its present form. > > It is possible that the document is intended to evolve into a more > comprehensive study of hierarchical approaches to segment routing. In th= at > case, I think it would be useful to see a little more of that evolution > before considering whether to adopt the document. > > > > > > > On 7/24/2016 8:55 AM, John G. Scudder wrote: > >> Dear WG, >> >> As we discussed at our meeting, working group adoption has been requeste= d >> for draft=E2=80=90filsfils=E2=80=90spring=E2=80=90large-scale-interconne= ct. Please reply to the >> list with your comments, including although not limited to whether or no= t >> you support adoption. Non-authors are especially encouraged to comment. >> >> We will end the call on August 31, 2015. >> >> Authors, please indicate whether you are aware of any relevant IPR and i= f >> so, whether it has been disclosed. Also, the length of the author list f= or >> this document greatly exceeds the maximum recommended. Assuming the >> document is adopted, the authors should be prepared to correct this when >> submitting as a WG document, ideally by reducing the list to simply the >> active editor(s) and making use of the "contributors" section for the fu= ll >> list. >> >> Thanks, >> >> --Bruno and John >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a114117e281e9000539597c7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

As not a c= o-author I support the adoption of this document. It is to be used as deplo= yment guideline and contains very useful examples for ops and network engin= eering teams.=C2=A0

It= has been discussed that IETF drafts should not be limited to protocol spec= ifications. In general we publish a lot of dry documents which in number of= cases lack of comprehensive operational guidelines.=C2=A0

It is however to the working group an= d area director to categorize such document as informational RFC or make it= a BCP.=C2=A0

Useful w= ork !

As to one comme= nt made:=C2=A0

> But one certain= ly couldn't hand this draft to a vendor and say "this is what I wa= nt";=C2=A0
> there isn't nearly enough conten= t in the draft for it to be used that way.

I must say that this really depends on the vendor.=C2=A0

If I have internal development teams or= external vendor developing controller such document is a very good referen= ce to base customized details on. And those would normally be given SP or E= nterprise "secret sauce".

Kind regards,
Robert.

<= /div>

On Fri= , Aug 5, 2016 at 10:31 PM, Eric C Rosen <erosen@juniper.net> wrote:
I'm afraid I really don'= t understand just what the point of adopting this document would be.

All the document really says is that one can improve scale by using hierarc= hy.=C2=A0 That is certainly true, but hardly a new result.=C2=A0 The docume= nt gives two examples of hierarchical structure: a two-level hierarchy and = an "optional" three-level hierarchy.=C2=A0 I'm not sure why t= he three-level hierarchy is any more or less optional than the two-level hi= erarchy or any other form of hierarchy.

The document goes on to sketch an application that could be run over the hi= erarchy, the application of setting up pseudowires with SLA.=C2=A0 Then it = gives an example of how one might (or might not) set up a control plane to = run the example application over the example hierarchy.=C2=A0 But one certa= inly couldn't hand this draft to a vendor and say "this is what I = want"; there isn't nearly enough content in the draft for it to be= used that way.

The document doesn't seem to rule out any alternatives, or even give co= nsiderations that could be used to rule out alternatives.

The document doesn't require anything, doesn't prohibit anything, d= oesn't provide any kind of comprehensive analysis, doesn't really a= ddress any protocol issues.=C2=A0 While it does present some interesting th= oughts about the use of hieararchy in a spring-based network, I don't t= hink it makes any sense for the working group to adopt the document in its = present form.

It is possible that the document is intended to evolve into a more comprehe= nsive study of hierarchical approaches to segment routing.=C2=A0 In that ca= se, I think it would be useful to see a little more of that evolution befor= e considering whether to adopt the document.






On 7/24/2016 8:55 AM, John G. Scudder wrote:
Dear WG,

As we discussed at our meeting, working group adoption has been requested f= or draft=E2=80=90filsfils=E2=80=90spring=E2=80=90large-scale-interconn= ect. Please reply to the list with your comments, including although not li= mited to whether or not you support adoption. Non-authors are especially en= couraged to comment.

We will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Also, the length of the author list for t= his document greatly exceeds the maximum recommended. Assuming the document= is adopted, the authors should be prepared to correct this when submitting= as a WG document, ideally by reducing the list to simply the active editor= (s) and making use of the "contributors" section for the full lis= t.

Thanks,

--Bruno and John

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

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

--001a114117e281e9000539597c7f-- From nobody Mon Aug 8 04:11:22 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805C612D7F6; Mon, 8 Aug 2016 04:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 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, RP_MATCHES_RCVD=-1.247, 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 mrdJTMQhtLyj; Mon, 8 Aug 2016 04:11:19 -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 0439812D807; Mon, 8 Aug 2016 04:10:26 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2DF70C086D; Mon, 8 Aug 2016 13:10:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id ECB8212007E; Mon, 8 Aug 2016 13:10:24 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 13:10:24 +0200 From: To: John G.Scudder , "draft-ietf-spring-segment-routing-mpls@ietf.org" Thread-Topic: =?utf-8?B?SVBSIGZvciBkcmFmdOKAkGlldGYtc3ByaW5nLXNlZ21lbnTigJByb3V0aW5n?= =?utf-8?Q?-mpls_prior_to_WGLC?= Thread-Index: AQHR5apAiT8EVUm3eUuH3Gjrk3xbpKA+/3PQ Date: Mon, 8 Aug 2016 11:10:24 +0000 Message-ID: <17664_1470654625_57A868A1_17664_334_1_9E32478DFA9976438E7A22F69B08FF921BD1AABF@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> In-Reply-To: <12104508-FA42-4237-AC1E-358781A121DD@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] =?utf-8?q?IPR_for_draft=E2=80=90ietf-spring-segment?= =?utf-8?q?=E2=80=90routing-mpls_prior_to_WGLC?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 11:11:20 -0000 SGksDQoNCkknbSBub3QgYXdhcmUgb2YgYW55IElQUiBmb3IgdGhpcyBkb2MuDQoNCkJyZ2RzLA0K DQpTdGVwaGFuZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBHLlNj dWRkZXIgW21haWx0bzpqZ3NAanVuaXBlci5uZXRdIA0KU2VudDogU3VuZGF5LCBKdWx5IDI0LCAy MDE2IDE0OjUyDQpUbzogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHNAaWV0 Zi5vcmcNCkNjOiBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IElQUiBmb3IgZHJhZnTigJBpZXRm LXNwcmluZy1zZWdtZW504oCQcm91dGluZy1tcGxzIHByaW9yIHRvIFdHTEMNCg0KRGVhciBBdXRo b3JzOg0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgdGhlIFNQUklORyBtZWV0aW5nLCB3b3JraW5nIGdy b3VwIGxhc3QgY2FsbCBoYXMgYmVlbiByZXF1ZXN0ZWQgZm9yIGRyYWZ04oCQaWV0Zi1zcHJpbmct c2VnbWVudOKAkHJvdXRpbmctbXBscy4gQmVmb3JlIHdlIGJlZ2luIHRoZSBXR0xDLCBwbGVhc2Ug aW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlm IHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Nsb3NlZC4gKFBsZWFzZSBkbyB0aGlzIGV2ZW4g aWYgeW91J3ZlIGRvbmUgaXQgYmVmb3JlLCB0aGFua3MgZm9yIHlvdXIgaGVscC4pIFBsZWFzZSBj YyB0aGUgV0cgaW4geW91ciByZXBseS4NCg0KQXMgc29vbiBhcyB0aGlzIGhhcyBiZWVuIGNvbGxl Y3RlZCBmcm9tIGFsbCBhdXRob3JzLCB3ZSdsbCBzdGFydCB0aGUgV0dMQy4NCg0KVGhhbmtzLA0K DQotLUJydW5vIGFuZCBKb2huDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Aug 8 04:11:59 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB38412D68B; Mon, 8 Aug 2016 04:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 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, RP_MATCHES_RCVD=-1.247, 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 tHCuYM6uleDg; Mon, 8 Aug 2016 04:11:56 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A876F12D79D; Mon, 8 Aug 2016 04:11:08 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id C4564208C3; Mon, 8 Aug 2016 13:11:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 92AF412007F; Mon, 8 Aug 2016 13:11:06 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0301.000; Mon, 8 Aug 2016 13:11:06 +0200 From: To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments Thread-Index: AQHR5ah3Ub8m7Byuu0yhTZ6ZxLyUeaA+/8GQ Date: Mon, 8 Aug 2016 11:11:06 +0000 Message-ID: <17660_1470654666_57A868CA_17660_116_1_9E32478DFA9976438E7A22F69B08FF921BD1AAD3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> In-Reply-To: <5D8D1F47-F36D-48FB-A256-2C338D2E5612@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US 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" Subject: Re: [spring] [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 11:11:58 -0000 Support -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Sunday, July 24, 2016 14:39 To: spring@ietf.org Cc: mpls@ietf.org Subject: [mpls] WG adoption requested for draft-psarkar-spring-mpls-anycast= -segments Dear WG (and cc MPLS, please include SPRING in replies), As we discussed at our meeting, working group adoption has been requested f= or draft-psarkar-spring-mpls-anycast-segments. Please reply to the list wit= h your comments, including although not limited to whether or not you suppo= rt adoption. Non-authors are especially encouraged to comment. We will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Also, the length of the author list for t= his document exceeds the maximum recommended. Assuming the document is adop= ted, the authors should be prepared to correct this when submitting as a WG= document, ideally by reducing the list to simply the active editor(s) and = making use of the "contributors" section for the full list. Thanks, --Bruno and John _______________________________________________ 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 Mon Aug 8 20:55:43 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310A412D752 for ; Mon, 8 Aug 2016 20:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.448 X-Spam-Level: X-Spam-Status: No, score=-105.448 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpYP3chklBvI for ; Mon, 8 Aug 2016 20:55:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9A12D751 for ; Mon, 8 Aug 2016 20:55:40 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id DDCDE7E8A0AC6; Tue, 9 Aug 2016 11:55:31 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 6DC584112089C; Tue, 9 Aug 2016 11:55:32 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u793tPw5019941; Tue, 9 Aug 2016 11:55:25 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: , spring@ietf.org MIME-Version: 1.0 X-KeepSent: 2B65EC48:3F46DA6B-4825800A:0014578C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 9 Aug 2016 11:55:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-08-09 11:55:10, Serialize complete at 2016-08-09 11:55:10 Content-Type: multipart/alternative; boundary="=_alternative 00158E4D4825800A_=" X-MAIL: mse01.zte.com.cn u793tPw5019941 Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 03:55:42 -0000 This is a multipart message in MIME format. --=_alternative 00158E4D4825800A_= Content-Type: text/plain; charset="US-ASCII" Other documents have already addressed this issue, for example, set L-flag of Prefix-SID Sub-TLV in draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source Router ID in rfc7794. Thanks, Deccan [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info "John G. Scudder" Sun, 24 July 2016 12:54 UTCShow header Dear WG, As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. We will end the call on August 31, 2015. Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Thanks, --Bruno and John --=_alternative 00158E4D4825800A_= Content-Type: text/html; charset="US-ASCII" Other documents have already addressed this issue, for example, set L-flag of Prefix-SID Sub-TLV in draft-ietf-isis-segment-routing-extensions-05 and contain IPv4 Source Router ID in rfc7794.


Thanks,

Deccan





[spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
"John G. Scudder" <jgs@juniper.net> Sun, 24 July 2016 12:54 UTCShow header

Dear WG,

As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

We will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed.

Thanks,

--Bruno and John


--=_alternative 00158E4D4825800A_=-- From nobody Tue Aug 9 00:56:20 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F412D1DC for ; Tue, 9 Aug 2016 00:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 Ptya2dKINbUa for ; Tue, 9 Aug 2016 00:56:16 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [82.212.219.2]) by ietfa.amsl.com (Postfix) with ESMTP id B15C712D1D7 for ; Tue, 9 Aug 2016 00:56:15 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 104584BD02A; Tue, 9 Aug 2016 07:56:10 +0000 (UTC) Date: Tue, 9 Aug 2016 00:56:10 -0700 From: Marc Binderberger To: bruno.decraene@orange.com, "spring@ietf.org" Message-ID: <20160809005610361624.5ef56c4c@sniff.de> In-Reply-To: <30779_1469709362_5799FC32_30779_217_1_53C29892C857584299CBF5D05346208A0F96DEB2@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> <0039f4f2-e09a-f61c-6089-9a488d8bf2da@nic.dtag.de> <30779_1469709362_5799FC32_30779_217_1_53C29892C857584299CBF5D05346208A0F96DEB2@OPEXCLILM21.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.17 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , Martin Horneffer , "Horneffer, Martin" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Rule X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 07:56:19 -0000 Hello Bruno and spring list experts, jumping late into the discussion (sorry). I would see any kind of preference list to handle a conflict to be an=20 somewhat arbitrary decision. That is okay for a particular network (assumin= g=20 the network operator had a word or two about the rules) but I don't conside= r=20 this a good idea for a standard to reflect specific designs or=20 operational/troubleshooting procedures. E.g. who is saying that IPv6 should be preferred over IPv4? What when the= =20 operator's workhorse is still IPv4 traffic and s/he would prefer to sacrifi= ce=20 IPv6 to keep IPv4 running? In reality, don't we expect the rule ... "Local configuration conflicts can be prevented before they are advertis= ed" ... to cover the large amount of mistakes? Then the basic "ignore" policy= =20 would cover the few cases where things went really bad. We seem to spend a= =20 lot of time and energy on solving a problem that should be rare (with the= =20 quoted rule above). Basically what I propose is to keep it simple. At least start simple. _If_= =20 network operators find during operation that the basic don't-advertise/igno= re=20 rule is insufficient then we can still increase the complexity of the=20 conflict handling procedure (and add a config knob to select the new=20 procedure). Regards, Marc On Thu, 28 Jul 2016 12:36:01 +0000, bruno.decraene@orange.com wrote: > Hi Les, all >=20 > As an individual contributor. >=20 > As a network operator, I have a slight preference for the older preferenc= e=20 > rule, and more specifically for the following preference rule: > 1) PFX source wins over SRMS source > 2) Between redundant SRMS, operator defined preference (aka weight) >=20 > Note however, that for me, this is a lighter preference compared to the= =20 > choice of the policy. Besides, my above preference assumes that the polic= y=20 > "Per FEC/Ignore overlap only" be selected. If "Quarantine" were selected,= I=20 > would have a strong preference for the revised preference rule (Larger=20 > range wins) in order to limit the consequences on the network availabilit= y. >=20 > Regarding 1, > I would assume that before the conflicting advertisement, the network was= =20 > running fine. i.e. conflict entries is not the nominal behavior in the=20 > network, and conflict are detected and reported to the network operator f= or=20 > correction. (e.g. via the yang model, syslog, error message on the termin= al=20 > (hence in particular the one configuring the conflicting entry...). > With such assumption, the conflict is likely the result of a=20 > misconfiguration on one node. Preferring PFX source over SRMS give=20 > preference to diversity/the majority of the nodes rather than the=20 > individual (mapping server). In this assumption where a single node is=20 > misconfigured, preference many advertisement over a single one, maximize= =20 > the number of valid advertisement kept. I agree that this is dependent on= =20 > the assumption, and another scenario could be that one had mis-program th= e=20 > script configuring the prefix SID on N routers, which would results in N= =20 > simultaneous misconfigurations. > Additionally, following the principle that the one speaking for himself i= s=20 > probably the best source, I'd be inclined to trust the originator of the = IP=20 > prefix, as the reference for the SID to be used. >=20 > Regarding 2, > Some network operation people have expressed a need to control which=20 > advertisement is preferred, especially to control SID renumbering (e.g. = in=20 > case of network merge). cf St=E9phane email. Putting this preference lowe= r=20 > (e.g. after preferring the larger range) would somewhat defeat the goal o= r=20 > make it less predictable for people. >=20 > Regards, > --Bruno >=20 >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Hornef= fer >> Sent: Friday, July 22, 2016 10:59 AM >> To: Les Ginsberg (ginsberg); spring@ietf.org >> Cc: Horneffer, Martin >> Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Rul= e >>=20 >> Hi Les, >>=20 >> this topic, and this document is in my eyes a very important one. Thanks >> a lot for writing and promoting it! >>=20 >> During the Berlin WG session you proposed a new preference rule which >> would make the policy choice easier. You asked for a discussion on the >> list - more on your slides rather than the existing draft document. >>=20 >> As an operator, and as an individual that has insight in more than just >> one or two IP/MPLS carrier networks, that has the main engineering >> responsibility for a rather large backbone, and that stays in actual >> contact with the operational staff and security authorities, I strongly >> ask you: PLEASE DO NOT CHANGE THE PREFERENCE RULE! >>=20 >> The first two elements of the preference rule are, in my eyes, the most >> important ones of the whole document and must not be changed or dropped! >> 1) PFX source wins over SRMS soucre >> 2) Smaller range wins >>=20 >> Why is this so important? >>=20 >> I don't care so much about the _amount_ of traffic that would be >> affected by a conflict. No amount of traffic lost due to a network >> design or configuration error is permissible. But I do care about the >> overall _robustness_ and _security_ of the network. >>=20 >> Of course - in terms of security a first approximation would say that >> segment routing plays within the IGP only, and that the IGP needs to be >> trusted anyways. It must be secured against the outside. While this is >> true, I nevertheless would like to differentiate a bit more. >>=20 >> For the sake of robustness, and possibly also for security, I would like >> to apply the following guidelines: >> a) Effects of local misconfiguration should be as local as possible. >> b) The more reliable and controllable source should win over a less >> reliable or controllable one. >>=20 >> As I see it, both guidelines lead to a clear preference of PFX sources >> over SRMS sources. Also the preference for smaller ranges seems to fit. >>=20 >> Please do consider environments where more and more formely separate >> IP/MPLS networks get merged into a single IGP domain. I am seeing this a >> lot since a couple of years - several times within DT, but also at other >> carriers. Sometimes this is done as a complete merge e.g. into a single >> IS-IS area, sometimes different areas are used, and sometimes seperate >> IGP instances are maintained but connected. While redistributing from >> one IGP area or instance to the other you can do more or less filtering, >> but it definitely is being done. Thus, even within the IGP filters and >> policies are being applied - be it for the sake of security or >> scalability. While there are well-known mechanisms and tools to filter >> and control prefix redistribution, I am not so sure about SRMS. >>=20 >>=20 >> I'm going to also write my opinion about the policy selection, but >> keeping the preference rule really is my main concern. >>=20 >>=20 >> BR, >> Martin >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >=20 >=20 ___________________________________________________________________________= ______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu=20 > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= =20 > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u=20 > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged= =20 > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n=20 > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >=20 From nobody Thu Aug 11 22:43:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFE712D99E for ; Thu, 11 Aug 2016 22:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 l08zvkw4wV2o for ; Thu, 11 Aug 2016 22:43:45 -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 70EB512D990 for ; Thu, 11 Aug 2016 22:43:44 -0700 (PDT) Received: from [2602:4b:a27f:3000:39cd:2401:dd01:e1a0] by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bY5Fb-0000d8-Go; Fri, 12 Aug 2016 06:43:23 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Rob Shakir In-Reply-To: Date: Thu, 11 Aug 2016 23:43:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4AFA19-69DF-4354-BD46-980A94930537@rob.sh> References: To: Eric C Rosen X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "John G. Scudder" , spring@ietf.org Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 05:43:47 -0000 > On 5 Aug 2016, at 14:31, Eric C Rosen wrote: >=20 > The document goes on to sketch an application that could be run over = the hierarchy, the application of setting up pseudowires with SLA. Then = it gives an example of how one might (or might not) set up a control = plane to run the example application over the example hierarchy. But = one certainly couldn't hand this draft to a vendor and say "this is what = I want"; there isn't nearly enough content in the draft for it to be = used that way. It will not be possible to define such a document within the standards = process anyway, every network operator will have different constraints = as to what their problem space is, and hence the exact details of the = solution will differ from operator to operator. (Speaking as someone = that has designed a solution for the same problem of MPLS in the = aggregation domain for multiple operators, and come out with different = solutions each time.) The intention of this document is to describe a high-level architecture = that could be used to scale an MPLS domain using SR. The advantage of = documenting such things is that the IETF provides some guidance as to = how one might use some of the protocols it develops, which informs = network architects as they choose what technology to implement. The = advantage of doing this from a vendor perspective is that one might = limit the many different approaches that exist to solve a certain = problem, limiting the number of unique-snowflake architectures that must = be supported in network element code. One could assert that the IETF is not the right place to publish such = documents, but I really agree with Robert that we are collectively = neglecting an opportunity to write documents which aid operators = (including those that might not care about the exact encoding of bits on = the wire) in deploying the technologies that we define.=20 r. From nobody Mon Aug 15 06:54:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED09F12D741 for ; Mon, 15 Aug 2016 06:54:03 -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 hMNk6o4CaUBL for ; Mon, 15 Aug 2016 06:54:02 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1060012D9A7 for ; Mon, 15 Aug 2016 06:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4LtP9v9WMnMxzJQrZPEFbiUvI1/SyG4pLLOi+tCb1mg=; b=h3HlrF65ubEtWdiUE4LBvnOU2cVk9V1yvDW5P51BDtEO1SAOwGXQ6u+RGBDxoa1q5ZaBtVgi/fmXikdrPo+ErT6QVzcq5t7zB7JAmJQxP9pkI6a0FLRGVLY7RUzHPBonJP2VAmCAcmM8MA2/FuxEmJucHpJtHzlTiakPE72kEX0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=erosen@juniper.net; Received: from [172.29.32.81] (66.129.241.14) by SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 15 Aug 2016 13:53:53 +0000 To: Rob Shakir References: <9B4AFA19-69DF-4354-BD46-980A94930537@rob.sh> From: Eric C Rosen Message-ID: <569d5e88-0925-43d0-ea3c-53848198cb77@juniper.net> Date: Mon, 15 Aug 2016 09:53:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9B4AFA19-69DF-4354-BD46-980A94930537@rob.sh> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN6PR14CA0017.namprd14.prod.outlook.com (10.173.157.155) To SN1PR05MB2189.namprd05.prod.outlook.com (10.169.124.137) X-MS-Office365-Filtering-Correlation-Id: c708dd57-c74c-4285-fbe6-08d3c5139b5b X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 2:d8X7dTmbkg5mQq5emfztWGHun7FR3ut2blhelJLnMFS4xQZW6aWW6petWOC6BAdjmajHLG9qwL5IG/Q87kYjYy2NzfNHvOlCOMoPPfIxTVifFapmM5BLXOwsekUmPN/oNyl6uvPefNeK9arH3cQMdwnOhaEJ1X0l07bRkkQe5mkGMRQ32CV+YHg7Q6wsTy8j; 3:RCEqbDCpLUmPyC3Ua/J0xyY+hD1XwnIito1Et2fFASjfLgGHEi2aT4mPzYDmY+ke0TzCiAMf832m9GolWq2ciAi5faxbcnObA5BgF0LjczWyaAbrIvPzFxgkghju+wG3; 25:S0Txdpddf92f9nf+ZK6fvRPBqL683PGhHxNoyScUVNBIJXwKv6cNITbPv2mVo4YSNTEW1KbNchSxAqPHgiiIjITRK19zXgfoH02PiUMO1CkXk1B8dNwEDh9CrpeASSeicTNsNsWNGNEsx7dzBJCiKDnNSNFvNoe/INMcCwKANHYRw9hpkq6/ijlLHgwDl9BQfnaxlCjOapl2Aq1DKvNfjT7TBJ9LKbH0jVm6b3ONrbNLmTDstI5nduanftO0uIkcjjeJ8RBPlau8D+l+Q3WCJYxurSbB0O40jqNCbgpDStJl6G2ToMw7sPmHJuIpR5BdTaHRrEeW+65aYTnoMhrDreTYE0ZZ6m9iouzDapwZUC4kiYy64hhGBn61b6wDCIEAZhKh07/N6asqQe0Jhf4jOxJ0L1HYAkk2vKXRRxkJTpI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 31:RJdBTJdbeoBYU/94QN7vtZsPNdFsUvcNwFUbiVeGHBtKX6zsQrt4RUuh+Q+FNw16AP6N56CvwTgSfUYoHRvJibAAa5LFlIQ572fegD5ZZJPMxT6KLkzarEQeK7D8Fbfx0FyTxRoRrNwJIOyuiBsc/wE4MKUfTLY38BQzJCsT+0lp1rGSChtGlSfGZ8ZrQYUNXkUeup/E/xKjN4cmseGpwL0SxA8Jx7A85pq1/Pw2GV4=; 20:XfJi9+EcjZqeMGuQTuuP5OtcWKT58ORHmz7eoi8KNgfQs0whFQW4INp5yWRcfbWtDatwA1J4usMvW+IvH84l9eGBIXOP1CnmxaLnhO3gnCUnR8SwXVWfbLBlJeCMPQ2r8hZCXyKZ3V5Mb8neOL+FKfyY5z2aidOFPwGvJe5SIsEqLpjrrzivr3MqB+zltyozrJ60jdDLaULyIjhtAEMg2j/5NbM7vZ6rkjrNaVD5C2ozZqfClW3qz5WhWvaOLZYXMnXh5XoAQZQrg0cEgKGnlmEjhoAHqlrceftM9uRPVPAGhbs9MZ6QDXxSTmuwGvZYyj9nE1+7m2H4Qjdqk5XQbcfbgxK8eUsLCGTSEPsRa/Yoattg4cJxe9BbIvb9EM8+YWPDUZehr2BArvX+Aj9VQRMefC77CcyESJ7uIPU7daEJj5FK6fovUKtz5ktLvpbxzJ1KGlwc+daxxNrXigd6SzHBku1A7GpzWw6uAfk0896xktF3aYnSGVjotsrvxSJF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:SN1PR05MB2189; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB2189; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 4:h15xVHJz7SPosMZFTNlvuwd6sSqUMl74xjwFhwTH2GZ25OPkFVyiuyXX+IYqJXskMApeERXpF3MVRnyLImD2m2AkmKlLfsYmKGWgMaumw5BZ75mjg3+BnlYO9ZFnHnjw2DZbtzsKY2ipa2els/txoKLbi5KImCRERV4gQO/rZ4+Afxr7okX6w1fVlB0dPzishXd06XQFuNk7hfZjtOHHGVcWcQDMbpaBX9gRNCipZKwjHNbcmAkA6IRuqI+JwynQf7zpcnkA198H4kfMn8ust56qOnmi2V/k5g4ufxHvw7ppXbo511FBqihsD/5pI2ZpzNUsPw36t6zXfcRS6G+Vkq1yQBgnIuiNp65TxhDFV1eED0zn2qePQeVfH9jj7MVQcTyOP8Q45HoIM5LrxIdJHtsxkUcdDfAjwG0BC/nmMKkBRvZXiDsphC81zSN7SVyAYpY40I2WMjk7hIMiASxH7w== X-Forefront-PRVS: 0035B15214 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(24454002)(52314003)(189002)(377454003)(199003)(31686004)(42186005)(83506001)(305945005)(68736007)(106356001)(2950100001)(7846002)(33646002)(101416001)(31696002)(36756003)(19580395003)(77096005)(54356999)(50986999)(76176999)(81166006)(110136002)(7736002)(66066001)(65956001)(50466002)(92566002)(81156014)(86362001)(4001350100001)(189998001)(586003)(230700001)(23746002)(65806001)(64126003)(4326007)(47776003)(97736004)(3846002)(6116002)(105586002)(19580405001)(2906002)(230783001)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB2189; H:[172.29.32.81]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; SN1PR05MB2189; 23:JkGkf0ugQQeGqAfKckWVl+JrKxkfTtIcBpE/I?= =?Windows-1252?Q?c4EfhOiUCGaPUMspNwYs5YJfRYaaZ/wuvJYSwDn3ur2N9BqWvx5Pt4CO?= =?Windows-1252?Q?qBBgCUJZCNI2/8toKMxcB0MhDted1x63T+lgJb8+i5xmlkktsvri7eE2?= =?Windows-1252?Q?3/CDR2+YM/gLV3juMBsds9LCEMd/w/iktN/BmGqz7TbxiyzK1t69uNvh?= =?Windows-1252?Q?zL2nV7SPdoZNwVuDUaLClgPzLR8Bo3BATfECK4HZc6qItZe8HWfNJyb0?= =?Windows-1252?Q?wPSA3mFmFf1ZCYl6ck7cR2vFXfWujXzKzncxwcrtmV5NTwOsN5FOshx3?= =?Windows-1252?Q?wWOuDEBhAvG4CFT8/IVsm1J4DY3NgQAcC6rNUSnt02LJIJRZ5NSKIN0V?= =?Windows-1252?Q?jDbkfohpgs7Q6H9uG1eOQjFpVHl8ubjjoUwV/w6epKeYZDZn7RsVCbr4?= =?Windows-1252?Q?l+ZIEMQxFB9dYNbe7Fbd/7RM0k6So7cC6CR/JsZFWS/BsOy7iu5EsN/U?= =?Windows-1252?Q?1RRFd39ETyz2zjjMLzGvQfyoPquw21oedGpbeADFUyRsmolPEXVW/6p5?= =?Windows-1252?Q?FWB2CjWBkIzzEeO2krHgcdi8wxMmqpIAcTpa6J9gsCSTZ7IAzdKWZV6n?= =?Windows-1252?Q?Y/GfwDtMRV/J3KsCZD9nbNfM0dvMcPDfjkJGahx/HNE1dnKfMXGh3L0J?= =?Windows-1252?Q?eadGankNdxIGwqVZeEfLlGP8kwIruAEEABnpTLIuncRNXYBF3fEXbJxg?= =?Windows-1252?Q?u6KERtkfy25ri3Z0sa4FW2mdiLZP5gn1xZ8YEu9BisU7tAo049caRExD?= =?Windows-1252?Q?ENsdvfIJ1iHdohYD7NGnO43NTigVDKzYcllF1HTzLCp5c56xiX+HUcU1?= =?Windows-1252?Q?ExuaUP7EhoMIJKNWctTy/SYtpbHsE/Ya+x/Gg5jHEUTBCX/CUtQFKe6Y?= =?Windows-1252?Q?+pcrq4Fl4kablyoDqsggiEsFUj4+550YHYgNSAZDTU9Qi+qBX6YK3Miv?= =?Windows-1252?Q?2clLlNqaIPnhfZxq6xyXWhQxelpGjczhMPhDjGNhS7V2ZSH5lYkokGlA?= =?Windows-1252?Q?4cEGl0EJncJ2P0tsGf9MyDOmginAtSh3/tlJRkXAaTM/KCx1aXjcAW2i?= =?Windows-1252?Q?ryfEgneYwlZ+53Jy+xaZXsoeND6qTy5EieQxZ2Xd6m7rxgvmNxb2ThcO?= =?Windows-1252?Q?WOZY2GVDeMdBwlXOdVOsRlhmv9/I5MIdnPAZybVtlwwYD53pcOvZXNOl?= =?Windows-1252?Q?IwxAfB6QLMEnCmBYyRHfsfglEvo7wfgf+5KoJABqx40PXfBRUlfDLByc?= =?Windows-1252?Q?jy6VUytIMSqM/bNgZJgIkjV9Tmt2t7/qGBlqq7zyXZOZgkyogFV6EqUG?= =?Windows-1252?Q?YqbTS1Le+rEDpFzQQuDfaUtx6V5TXO8hg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB2189; 6:GRSQWT6zNxOWNrWwenuVI8HVwPIsmogNliXtWHQ9SIOFz3DJQIYoz3uYX3Uobrw/OmMgim0SqrmURzOMc+6TyTF6co7sHo6tL85Mcn1wpUWgivN9spdyr2u5BqqNmd49dZ4vS59fIXZdYCu/txDOk81XwkXX26froSlFnz+cqqJKLBLoknPFpGRiC0zoglGy4u5EODR3ZqziSmeOpa473PpEvGmVZUi0KagVOs8cvlxBTB/DDJoQlBnrKau91RX2tlRKnVTN+5pJ2YlAN3aYZFQVY2SGuHYrGp62Grf2cpGbc/x72PKokgWmFxz0Rn25oZr83+Puum00Uw/KIivXSw==; 5:ETOwanBEjh9MOmLZSVcWgdmDj/AWqRwPhE4lmV7kzOlMFI2w6ui7v0qP+nA8xI+OUgnqRnpi2vIMvhVwBVH+DWD/41/qM/4+yLjhgSeEgQrw0U3Spk3xJCeJw3bdHilZhdiEVx/+wpLvm5QJJK/Fqw==; 24:Ti5H/JMUPAWxD7HFBzm6pbIZhCRlgYv063Mnlx9H9/CUvJEnbofxOkQU2nxfDfLz7myDs5I1As5u46WU5Xcp/UfHvBSHORFc8DriGW4TRw4=; 7:0qckrL9Moh0V25jJoMiUGOuSxyful+eiE7sxgnl0+/2YIgar1Kt3yPk0gbA2Z6XO1o4z7ZjxwQHMwTHyXjXOIuexpViAPP78viodDsIs+p2Ms+Ob1Ov6dAk1XmA0Tt17iCWxoYCguvfTNkzfR5NJbYVYaV7ROj4cjgG1Z4GgPXs1CiFb8tbsOc+NQ6RDvADGVOIh5atQxyhBqRv2pSqB4V8eoM9NP6mRvvADTGF0s0uJywqdlf3VKbIt2b6vScY1 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2016 13:53:53.6254 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB2189 Archived-At: Cc: "John G. Scudder" , spring@ietf.org Subject: Re: [spring] =?utf-8?q?WG_adoption_requested_for_draft=E2=80=90filsfi?= =?utf-8?q?ls=E2=80=90spring=E2=80=90large-scale-interconnect?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 13:54:04 -0000 On 8/12/2016 1:43 AM, Rob Shakir wrote: >> On 5 Aug 2016, at 14:31, Eric C Rosen wrote: >> >> The document goes on to sketch an application that could be run over the hierarchy, the application of setting up pseudowires with SLA. Then it gives an example of how one might (or might not) set up a control plane to run the example application over the example hierarchy. But one certainly couldn't hand this draft to a vendor and say "this is what I want"; there isn't nearly enough content in the draft for it to be used that way. > It will not be possible to define such a document within the standards process anyway, every network operator will have different constraints as to what their problem space is, and hence the exact details of the solution will differ from operator to operator. I agree that an IETF WG should not adopt a draft that attempts to restrict what operators should do. > > The intention of this document is to describe a high-level architecture that could be used to scale an MPLS domain using SR. But all the document really says is "use two levels of hierarchy, or optionally three". It's not clear that anything is required or prohibited. The draft raises some issues that have to be thought about when designing a deployment. If the draft simply said "here are some operational considerations to think about if you have a hierarchy in which the lower layers have limited FIB size", and if the draft made clear that it isn't mandating (or even describing) a particular solution, I think it would be less problematic. > The advantage of documenting such things is that the IETF provides some guidance as to how one might use some of the protocols it develops, "might use" ---> "might or might not use" ? > which informs network architects as they choose what technology to implement. The advantage of doing this from a vendor perspective is that one might limit the many different approaches that exist to solve a certain problem, limiting the number of unique-snowflake architectures that must be supported in network element code. I don't believe the document has nearly enough content to say how any particular problem is or is not to be solved in any particular deployment scenario, so I don't think it is useful for that purpose. I can however see the document being used in ways that probably aren't intended. Since the document is mostly about a 2-level hierarchy, and allows a third level "optionally", one could interpret the document as prohibiting a 4-level hierarchy. I doubt that that is intended. But maybe it is, it's not really possible to tell. Even for the single application that is mentioned, it is not clear what if anything is being ruled out or why. And given that different operators will require different approaches, I don't see why we would want to rule out different approaches. > > One could assert that the IETF is not the right place to publish such documents, but I really agree with Robert that we are collectively neglecting an opportunity to write documents which aid operators (including those that might not care about the exact encoding of bits on the wire) in deploying the technologies that we define. > > r. > I'd have less of a problem if the document said, "here is some guidance as to how one might use SR to scale an MPLS domain, but no claim is made that this is the only way, or the best way, or the preferred way; different deployment scenarios and/or requirements may require different procedures." From nobody Mon Aug 22 03:30:59 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909512D114 for ; Mon, 22 Aug 2016 03:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 lq4yG-cinxW3 for ; Mon, 22 Aug 2016 03:30:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CADA12D106 for ; Mon, 22 Aug 2016 03:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1186; q=dns/txt; s=iport; t=1471861856; x=1473071456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KFPQ2uCEgrl11q/J2YG0QAntmWhnAjpYgX6PAcsMTeU=; b=k7jkFL1zciqXVSUmXPw5OBTXOD3tlMQ7rRaLcEhYKbLWkQn38fk2uAvy cVe/JXMR5Gylp0STBvkV0NXnDN2N980oAhaTa8Fs1/DwEfk+gllfz1abr ECJAxoCJcN+yzfNvycJE2JzZ64VCGIfwdiibPRfDlO/Xmf/Zl7Zl6kQZw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAgAJ07pX/4cNJK1eg0RWfAe3cIF9J?= =?us-ascii?q?IUvSgKBTDgUAgEBAQEBAQFeJ4ReAQEEAQEBODQLBQsCAQgOCh4QJwslAgQBDQW?= =?us-ascii?q?IKQgOvUcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYrgXgIgk2EQIMsgi8FmUgBj?= =?us-ascii?q?x6PUIw/g3cBHjaDenCFfH8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,559,1464652800"; d="scan'208";a="140458563" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2016 10:30:55 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7MAUt4i006540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 10:30:55 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 06:30:54 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 06:30:54 -0400 From: "Stefano Previdi (sprevidi)" To: John Scudder , Martin Vigoureux Thread-Topic: [spring] New spring WG Co-Chair Thread-Index: AQHR51ZxxQXCjmgvAUSvp9CEwwhggKBVNOQA Date: Mon, 22 Aug 2016 10:30:54 +0000 Message-ID: <480769E1-1213-4F9B-8FB0-035B4B70E212@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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.89.158] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Alvaro Retana \(aretana\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] New spring WG Co-Chair X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 10:30:58 -0000 Many thanks to John for his excellent work on spring wg co-chair duty.=20 Hi Martin and welcome to the party. s. > On Jul 26, 2016, at 5:57 PM, Alvaro Retana (aretana) = wrote: >=20 > Dear spring WG: >=20 > Due to the demands of his job John has decided to step down as spring Co-= Chair, a position he has held since the formation of the WG almost 3 years = ago. John has been instrumental in driving the collaboration with other gr= oups working on spring-related extensions. Thank you!! >=20 > In consultation with Bruno and the other RTG ADs, we have asked Martin Vi= goureux to take on the role of spring Co-Chair. Martin is an experienced C= hair (he is also the Co-Chair of bess) and will work with Bruno on driving = the current work items to completion and publication. We expect the transi= tion to be seamless as the WG moves through a period of adoption and WGLCs.= Welcome Martin! >=20 > Martin can be reached at martin.vigoureux@nokia.com. >=20 > Thanks! >=20 > Alvaro. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Aug 22 03:34:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA10512D12F for ; Mon, 22 Aug 2016 03:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 SNk4aK9eqy_E for ; Mon, 22 Aug 2016 03:34:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE3D12D129 for ; Mon, 22 Aug 2016 03:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1471862069; x=1473071669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X0U+E90v5mVVmpY1PKKO8l3UIWDKzgZVkUJXKIs8ijo=; b=Ez3acRClKeZ8cWvfHbKRKQS+6LpHEo2p0IGauhQudoUflo7o/1l7XpBG aeP7nu4Ly6AOE4YRULBnsMh+L3elGuacIGXo37LiIcfYSGOIsczVlv1/X Vn3pd7Xty0M6vLAOTKueP78bY4vYKP2KDisESItxzVUq0PiuZDLmPbbXI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAgBD1LpX/5ldJa1eg0RWfAe3cIF9J?= =?us-ascii?q?IUvSgKBTDgUAgEBAQEBAQFeJ4ReAQEEAQEBODQLBQsCAQgYHhAnCyUCBAENBYg?= =?us-ascii?q?pCA69OwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhiuBeIJVhBwkgyyCLwWZSAGPH?= =?us-ascii?q?oFthFyJB4w/g3cBHjaDenCFNkZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,559,1464652800"; d="scan'208";a="140459724" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 10:34:28 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7MAYSjh000616 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 10:34:28 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 06:34:27 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 06:34:27 -0400 From: "Stefano Previdi (sprevidi)" To: Martin Vigoureux , DECRAENE Bruno IMT/OLN Thread-Topic: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info Thread-Index: AQHR5aqN/jY+0u2FUEOcFY2M/EtljqBVOTsA Date: Mon, 22 Aug 2016 10:34:27 +0000 Message-ID: <43C0467D-6BAA-42F1-BB2C-A7473AA5F717@cisco.com> References: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> In-Reply-To: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> 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.61.89.158] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 10:34:31 -0000 as co-author I support the adoption of this document as WG item. I know about IPR related to this draft and it has been disclosed. s. > On Jul 24, 2016, at 2:54 PM, John G. Scudder wrote: >=20 > Dear WG, >=20 > As we discussed at our meeting, working group adoption has been requested= for draft-filsfils-spring-sr-recursing-info. Please reply to the list with= your comments, including although not limited to whether or not you suppor= t adoption. Non-authors are especially encouraged to comment. >=20 > We will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. >=20 > Thanks, >=20 > --Bruno and John >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Aug 22 06:14:13 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C713412D1EA; Mon, 22 Aug 2016 06:14:10 -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 CsJCfPoTKmvz; Mon, 22 Aug 2016 06:14:06 -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 F025B12D50A; Mon, 22 Aug 2016 06:14:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0E4F0324634; Mon, 22 Aug 2016 15:14:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.63]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D35E635C079; Mon, 22 Aug 2016 15:14:03 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 15:14:03 +0200 From: To: "draft-ietf-spring-resiliency-use-cases@ietf.org" Thread-Topic: Shepherd review of draft-oetf-spring-resiliency-use-cases Thread-Index: AdH8dr4WPQceoNkkS8W1oLG3Av5lIw== Date: Mon, 22 Aug 2016 13:14:03 +0000 Message-ID: <26825_1471871643_57BAFA9B_26825_33_1_9E32478DFA9976438E7A22F69B08FF921BD3D66A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.17.114517 Archived-At: Cc: "spring@ietf.org" , "rtgwg@ietf.org" Subject: [spring] Shepherd review of draft-oetf-spring-resiliency-use-cases X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:14:11 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have been selected as Shepherd for this document, and as part of my revie= w I have several comments that you will find below : General : Is it a requirement document ? If yes, it would be good to mention it. The = document states requirements multiple times. Abstract : The abstract is really short, would be good to enhance it with what is exac= tly described. In Section 1, there should be an issue with the XML file as the hypertext l= ink is missing at : "We discuss two different approaches to provide ..., in= Section 3". Hyperlink missing for "Section 3". In Section 2, It would be good to state in the example that the paths must not be protect= ed by any local repair techniques. Example : "The two paths are made disjoi= nt using the SPRING architecture and must not be protected by any local rep= air techniques". As a requirement, the two paths must be disjoint (link or node, or srlg), t= his has some impacts on the path expression : using a node-SID would be a b= ad idea as there is no guarantee. It would be good to mention that the solu= tion must take care of this. It would be easier to state that path T1 is primary and T2 is backup instea= d of : "When T1 is up, the packets of the PW are sent on T1". Why not using the following text : "T1 is programmed as primary forwarding entry while T2 is a backup entry. I= n nominal state, PW traffic is carried over T1. When T1 fails, the PW traff= ic is switched on T2". Before telling that the solution for end-to-end liveness is out of scope, i= t would be good to state that it is mandatory to have such mechanism to mak= e the solution work. Is it a SPRING path liveness check or service liveness= check ? It would be good to tell who is in charge of the detection and pa= th switchover ? is it LSP ingress, is it a node outside SPRING network ? If= there are multiple options, please tell it. I would propose to change the last sentence to highlight the two requiremen= ts in case we need SPRING path liveness check : "From a SPRING viewpoint, the SPRING architecture MUST provide end-to-end l= iveness check of SPRING based LSPs. In addition, it MUST provide a way to c= reate LSPs that must not be protected by local repair techniques." Globally this section looks confusing to me. End to end protection could be= achieved in multiple ways, for example : - Having a dumb network that only provides disjoint non protected path and = having end-to-end probes at service level that would help an external compo= nent to switchover traffic. Provider network is not aware of the protection= done. In your figure we can add A' and Z', and we establish two disjoint L= SPs (A->Z and A'->Z'). Customer is dual meshed to A/A' and Z/Z' and is mana= ging liveness check and switchover (network is not involved). - Having primary/backup like approach : two disjoint LSPs from A->Z , A pro= grams one in FIB. A provides OAM on the LSP. When primary LSP fails, the se= cond one is installed in FIB. - Having FRR like approach : two disjoint LSPs from A->Z , A programs both = in FIB in a FRR like fashion. A provides aggressive OAM on the LSPs to enab= le traffic switchover in a very short time. The current text is not really clear on the proposed approach. Maybe anothe= r one ? Section 3 s/the backup path computation should/the backup path computation SHOULD/ s/in any topology/in any topology./ s/by the IGP/by the IGP./ Section 3.1 "ending at the protected nexthop", that's true only for link protection, bu= t not possible in case of node protection. This sentence is a generic one a= nd is not specific to link protection case. I cannot parse : "so as to bypass the failed component ..." I would propose something like : "One way to provide local repair is to enforce a failover along the shortes= t path around the protected component. In case of link protection, the poi= nt of local repair will create a bypass avoiding the protected link and mer= ging back to primary path at the nexthop. In case of node protection, the b= ypass will avoid the protected node and merge back to primary path at the n= ext-nexthop." What about SRLG case ? "In our example, C protects Z", protects for what ? link / node /srlg failu= re ? proposed text : "In our example, C protects destination Z for a failur= e CD link" "that it initially reaches via CD", yes and also using CH because of ECMP, = it would be better to change the example to disable ECMP. There are multipl= e ECMPs that would not help the reading. Even A as ECMP to Z. Section 3.2 "providing a repair for the destination based on shortest path state for th= at destination". Why using "state" ? Again : "In our example, C protects Z", protects for what ? link / node /sr= lg failure ? You have again ECMP starting from A, and at other nodes that complexifies t= he example. Why not talking about pros/cons between approaches ? Section 4. SRLG was mentioned as a requirement in Section 3. So why considering it as = a more high level constraint ? If SRLG is management-free, please change your example with another constra= int type (bandwidth for example). You can refer to RFC7916 as an example of managed computation. Similar appr= oach can be used here. Section 4.1 Is the path {CG,GH,HD} computed automatically or putted manually ? Please b= e clear on what must be done. Section 4.2 This case is a bit strange. The goal is to use shortest path protection to = the destination but here we enforce a non shortest path, so the name is no = more applicable. It is more a per-destination protection tweaking. Again ho= w is it done, configured manually per destination or group of destinations = ? Do you have requirements here ? Section 5 First sentence is hard to read (it works but hard to read). Is it possible = to make it simpler ? For example, "when a topology change occurs in a netwo= rk, transient inconsistencies of router FIBs can occur." Could you point to relevant RFCs/drafts on microloops to help readers that = are interested by more information on the subject. You could tell that those micro-loops are breaking local repair techniques = preventing 50msec restoration. Could you provide an example on how SPRING can prevent loops ? (as you done= for protection cases) Section 6. Could you rename the title to be more explicit : co-existence of what ? Section 8. You also provide requirements, and you have example of manageability requir= ements (revert ability for path protection, managed path) ... Please state clearly that the manageability requirements provided in this d= ocument must be addressed by the solution documents. Could you summarize th= e manageability requirements here ? Best Regards, Stephane [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/OINIS/NET Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have been selected as Shepherd for this document, = and as part of my review I have several comments that you will find below :=

 

General :

Is it a requirement document ? If yes, it would be g= ood to mention it. The document states requirements multiple times.

 

 

Abstract :

The abstract is really short, would be good to enhan= ce it with what is exactly described.

 

In Section 1, there should be an issue with the XML = file as the hypertext link is missing at : “We discuss two different = approaches to provide …, in Section 3”. Hyperlink missing for &= #8220;Section 3”.

 

In Section 2,

It would be good to state in the example that the pa= ths must not be protected by any local repair techniques. Example : “= The two paths are made disjoint using the SPRING architecture and must not = be protected by any local repair techniques”.

 

As a requirement, the two paths must be disjoint (li= nk or node, or srlg), this has some impacts on the path expression : using = a node-SID would be a bad idea as there is no guarantee. It would be good t= o mention that the solution must take care of this.

 

It would be easier to state that path T1 is primary = and T2 is backup instead of : “When T1 is  up, the packets of th= e PW are sent on T1”.

Why not using the following text :

“T1 is programmed as primary forwarding entry = while T2 is a backup entry. In nominal state, PW traffic is carried over T1= . When T1 fails, the PW traffic is switched on T2”.

Before telling that the solution for end-to-end live= ness is out of scope, it would be good to state that it is mandatory to hav= e such mechanism to make the solution work. Is it a SPRING path liveness ch= eck or service liveness check ?  It would be good to tell who is in charge of the detection and path switchove= r ? is it LSP ingress, is it a node outside SPRING network ? If there are m= ultiple options, please tell it.

 

I would propose to change the last sentence to highl= ight the two requirements in case we need SPRING path liveness check :=

“From a SPRING viewpoint, the SPRING architect= ure MUST provide end-to-end liveness check of SPRING based LSPs. In additio= n, it MUST provide a way to create LSPs that must not be protected by local= repair techniques.”

 

Globally this section looks confusing to me. End to = end protection could be achieved in multiple ways, for example :=

- Having a dumb network that only provides disjoint = non protected path and having end-to-end probes at service level that would= help an external component to switchover traffic. Provider network is not = aware of the protection done. In your figure we can add A’ and Z’, and we establish two disjoint LSP= s (A->Z and A’->Z’). Customer is dual meshed to A/A’= ; and Z/Z’ and is managing liveness check and switchover (network is = not involved).

- Having primary/backup like approach : two disjoint= LSPs from A->Z , A programs one in FIB. A provides OAM on the LSP. When= primary LSP fails, the second one is installed in FIB.

- Having FRR like approach : two disjoint LSPs from = A->Z , A programs both in FIB in a FRR like fashion. A provides aggressi= ve OAM on the LSPs to enable traffic switchover in a very short time.<= /o:p>

 

The current text is not really clear on the proposed= approach. Maybe another one ?

 

 

Section 3

s/the backup path computation should/the backup path= computation SHOULD/

s/in any topology/in any topology./

s/by the IGP/by the IGP./

 

Section 3.1

“ending at the protected nexthop”, that&= #8217;s true only for link protection, but not possible in case of node pro= tection. This sentence is a generic one and is not specific to link protect= ion case.

I cannot parse : “so as to bypass the failed c= omponent …”

I would propose something like :

“One way to provide local repair is to enforce= a failover along the shortest path around the protected component. In case= of link protection,  the point of local repair will create a bypass a= voiding the protected link and merging back to primary path at the nexthop. In case of node protection, the bypass will a= void the protected node and merge back to primary path at the next-nexthop.= ”

What about SRLG case ?

 

“In our example, C protects Z”, protects= for what ? link / node /srlg failure ? proposed text : “In our examp= le, C protects destination Z for a failure CD link”

 

“that it initially= reaches via CD”, yes and also using CH because of ECMP, it would be = better to change the example to disable ECMP. There are multiple ECMPs that= would not help the reading. Even A as ECMP to Z.

 =

 =

Section 3.2

“providing a repai= r for the destination based on shortest path state for that destinationR= 21;. Why using “state” ?

Again : “In= our example, C protects Z”, protects for what ? link / node /srlg fa= ilure ?

 

You have again ECMP starting from A, and at other no= des that complexifies the example.

 

Why not talking about pros/cons between approaches ?=

 

 

Section 4.

SRLG was mentioned as a requirement in Section 3. So= why considering it as a more high level constraint ?

If SRLG is management-free, please change your examp= le with another constraint type (bandwidth for example).

You can refer to RFC7916 as an example of managed co= mputation. Similar approach can be used here.

 

Section 4.1

Is the path {CG,GH,HD} computed automatically or put= ted manually ? Please be clear on what must be done.

 

Section 4.2

This case is a bit strange. The goal is to use short= est path protection to the destination but here we enforce a non shortest p= ath, so the name is no more applicable. It is more a per-destination protec= tion tweaking. Again how is it done, configured manually per destination or group of destinations ? Do you have= requirements here ?

 

Section 5

First sentence is hard to read (it works but hard to= read). Is it possible to make it simpler ? For example, “when a topo= logy change occurs in a network, transient inconsistencies of router FIBs c= an occur.”

Could you point to relevant RFCs/drafts on microloop= s to help readers that are interested by more information on the subject.

 

You could tell that those micro-loops are breaking l= ocal repair techniques preventing 50msec restoration.

 

Could you provide an example on how SPRING can preve= nt loops ? (as you done for protection cases)

 

Section 6.

Could you rename the title to be more explicit : co-= existence of what ?

 

Section 8.

You also provide requirements, and you have example = of manageability requirements (revert ability for path protection, managed = path) …

Please state clearly that the manageability requirem= ents provided in this document must be addressed by the solution documents.= Could you summarize the manageability requirements here ?

 

 

 

Best Regards,=

 =

Stephane

 

 

 

 

 

 

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET

Orange Expert Future Networks=

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

______________________________________________________________________=
___________________________________________________

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_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1093; creation-date="Mon, 22 Aug 2016 13:14:02 GMT"; modification-date="Mon, 22 Aug 2016 13:14:02 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAoACgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1O48f afbXMsDWl0WjcoSAuDg49aj/AOFiad/z53f5L/jXB6r/AMhe9/67v/M1Ur5Geb4pSaTX3H2dPJcJ KCbT+89H/wCFiad/z53f5L/jR/wsTTv+fO7/ACX/ABrziip/tnFd19xX9iYPs/vPR/8AhYmnf8+d 3+S/40V5xRR/bOK7r7g/sTB9n95b1X/kL3v/AF3f+ZqpW3Po17qGo3s0Cx7DdPGpeQLvbOdq56mo R4d1EmEFYVaZdyI0oDY9cda450KspNqLO2niKUYJOSvbv5GVRWwPC+qmR4zFErI/l4aUDc2A2B68 GmDw7qTQrIIkJZVYR+YN+GOAdvuan6tW/lf3FfWqH86+8yqK2bjQG0+EvqU/2dmyIgieYGI6gkHg 0VM6M4O0tGVCtCavF3R1o8Oa7BcTtbXdh5TztPGJYyxjY9xxwcUxfDniNZ1m+32DOIPs+WjJymc8 8dc96KK+y/s+l3f3s+J/tKt2X3Ie+geJZJlla/0/eswmH7s/eChfT0FXDo2rDTRCktoLoIqfaCxy NrZGPlz+GaKKpYGmr6vXzJlj6sraLTyMrUPCOuant+03lh8pJ+RGXJPUniiiisZ5Thpvmldv1N4Z xioLljZL0R//2Q== --_004_9E32478DFA9976438E7A22F69B08FF921BD3D66AOPEXCLILMA4corp_-- From nobody Mon Aug 22 06:39:02 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0212D158 for ; Mon, 22 Aug 2016 06:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 q0ErpAXZmYgo for ; Mon, 22 Aug 2016 06:38:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BFF12D1D5 for ; Mon, 22 Aug 2016 06:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2000; q=dns/txt; s=iport; t=1471873139; x=1473082739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iaPSNKHr/UYf4V0kNz8GCM+qHdiMQUaUTuTSgOEBQvc=; b=d40wU9NS1Jv6KaAL3QYG4rxksJwKybHkmVtxWW57Il8WeRz4lq4IZlvm 4vZKvwH2qmYzhttSw3beqot7e63bAP6/73uYEvz1GzZmnOlkRmgytjH+4 ADgqof5Vp8ZfxLLcr4b6vD7vIoK85OqHSWodYxLJYvSPPpZ6Jq4BgxyaT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgArALtX/51dJa1dg0RWfAe3cYF9J?= =?us-ascii?q?IUvSgIcgTs4FAIBAQEBAQEBXhwLhF4BAQQBAQEhEToLBQsCAQgYAgImAgICJQs?= =?us-ascii?q?VEAIEDgWIKQgOrXiPcAEBAQEBAQEBAQEBAQEBAQEBAQEBARcFgQKFKYF4glWEH?= =?us-ascii?q?IMlK4IvBZlIAY8egW2EXIkHjD+DdwEeNoISHIFMcIU2Rn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,560,1464652800"; d="scan'208";a="140351091" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2016 13:38:58 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u7MDcwxN013209 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Aug 2016 13:38:58 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 22 Aug 2016 09:38:54 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Mon, 22 Aug 2016 09:38:55 -0400 From: "Stefano Previdi (sprevidi)" To: "peng.shaofu@zte.com.cn" Thread-Topic: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info Thread-Index: AQHR8fHqMV2hR85oiUCEJAOb8otLcqBVVDYA Date: Mon, 22 Aug 2016 13:38:54 +0000 Message-ID: References: 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.61.89.158] Content-Type: text/plain; charset="utf-8" Content-ID: <654DE831884092478E4175637EB7CEDA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPRING WG Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 13:39:01 -0000 DQo+IE9uIEF1ZyA5LCAyMDE2LCBhdCA1OjU1IEFNLCBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHdy b3RlOg0KPiANCj4gT3RoZXIgZG9jdW1lbnRzIGhhdmUgYWxyZWFkeSBhZGRyZXNzZWQgdGhpcyBp c3N1ZSwNCg0KDQpJIGRvbuKAmXQgdGhpbmsgc28uIENhbiB5b3UgcG9pbnQgdG8gdGhlc2UgZG9j dW1lbnRzID8NCg0KDQo+IGZvciBleGFtcGxlLCBzZXQgTC1mbGFnIG9mIFByZWZpeC1TSUQgU3Vi LVRMViBpbiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMtMDUgYW5k IGNvbnRhaW4gSVB2NCBTb3VyY2UgUm91dGVyIElEIGluIHJmYzc3OTQuIA0KDQoNCnRoZSBMIGZs YWcgaGFzIHRoZSBzb2xlbHkgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHRoZSBzaWQgY29udGFpbnMg YSBsb2NhbCB2YWx1ZS4gVHlwaWNhbGx5IGl0IGdvZXMgd2l0aCB0aGUgViBmbGFnIHRoYXQgaW5k aWNhdGVzIGEgdmFsdWUgKGkuZS46IGxvY2FsIGxhYmVsKS4NCg0KTm90aGluZyBpcyBtZW50aW9u ZWQgcmVnYXJkaW5nIHNoYXJpbmcgdGhlIHNhbWUgc2lkIGFtb25nIGRpZmZlcmVudCBzZXJ2aWNl cy4NCg0Kcy4NCg0KDQoNCj4gDQo+IA0KPiBUaGFua3MsIA0KPiANCj4gRGVjY2FuIA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IFtzcHJpbmddIFdHIGFkb3B0aW9uIHJlcXVlc3RlZCBmb3IgZHJhZnQt Zmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvIA0KPiAiSm9obiBHLiBTY3VkZGVyIiA8 amdzQGp1bmlwZXIubmV0PiBTdW4sIDI0IEp1bHkgMjAxNiAxMjo1NCBVVENTaG93IGhlYWRlcg0K PiBEZWFyIFdHLA0KPiANCj4gQXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5n IGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3By aW5nLXNyLXJlY3Vyc2luZy1pbmZvLiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3Vy IGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBu b3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291 cmFnZWQgdG8gY29tbWVudC4NCj4gDQo+IFdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAz MSwgMjAxNS4gDQo+IA0KPiBBdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJl IGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlmIHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVu IGRpc2Nsb3NlZC4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IC0tQnJ1bm8gYW5kIEpvaG4NCj4gDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiANCg0K From nobody Mon Aug 22 19:39:38 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98E912D866 for ; Mon, 22 Aug 2016 19:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.749 X-Spam-Level: X-Spam-Status: No, score=-104.749 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcQWUN5F4j8H for ; Mon, 22 Aug 2016 19:39:35 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 68DE912D1A2 for ; Mon, 22 Aug 2016 19:39:35 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id C22CF65299F81 for ; Tue, 23 Aug 2016 10:39:31 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id A8DED3DCD3C04; Tue, 23 Aug 2016 10:39:31 +0800 (CST) Received: from notes_svr7_1.zte.com.cn ([10.30.1.248]) by mse01.zte.com.cn with ESMTP id u7N2dT0A087172; Tue, 23 Aug 2016 10:39:29 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: References: To: "Stefano Previdi (sprevidi)" MIME-Version: 1.0 X-KeepSent: BCE9C33B:6859FA01-48258018:00092828; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 23 Aug 2016 10:39:43 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 9.0.1FP6|April 20, 2016) at 2016-08-23 10:39:12, Serialize complete at 2016-08-23 10:39:12 Content-Type: multipart/alternative; boundary="=_alternative 000E9A4948258018_=" X-MAIL: mse01.zte.com.cn u7N2dT0A087172 Archived-At: Cc: SPRING WG Subject: [spring] =?gb2312?b?tPC4tDogUmU6ICBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQg?= =?gb2312?b?Zm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmctaW5mbw==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 02:39:38 -0000 This is a multipart message in MIME format. --=_alternative 000E9A4948258018_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU3RlZmFubw0KDQpTdXJlLCBTUlJJIHByb3ZpZGVkIGluIHRoaXMgZG9jdW1lbnQgY2FuIGV4 cGxpY2l0bHkgaW5kaWNhdGUgYSByZWN1cnNpdmUgDQpvcGVyYXRpb24gKG9yIHJlbGF0aW9uc2hp cCkuIA0KQnV0IGl0IG1heWJlIGEgZGVmYXVsdCBiZWhhdmlvciB0byBkbyByZWN1cnNpdmUgb3Bl cmF0aW9uIHdoZW4gYW4gU1ItTk9ERSANCnJlY2VpdmVkIHJlbW90ZSBwcmVmaXgtc2lkIHdpdGgg TC9WIGZsYWcgc2V0IGFjY29yZGluZyB0byB0aGUgZG9jdW1lbnRzIA0KYWxyZWFkeSBleGlzdGVk LiBGb3IgZXhhbXBsZSwgDQpwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgcmVjZWl2 ZWQ6DQogICAgcHJlZml4ICgxLjAuMC45OS8zMikgDQogICAgICAgIHByZWZpeC1zaWQgKDMwMDA0 KSwgTC9WIGZsYWcgc2V0LCAgLy9JU0lTLVNSDQogICAgICAgICJJUHY0IFNvdXJjZSBSb3V0ZXIg SUQiIGlzIDEuMC4wLjQgLy9yZmM3Nzk0DQpUaGVuLCBwcmVmaXggMS4wLjAuOS8zMiBjYW4gZG8g cmVjdXJzaW9uIHRvIHByZWZpeCAxLjAuMC40LzMyIGJ5IGRlZmF1bHQuIA0KSWYgImRlZmF1bHQg YmVoYXZpb3IiIGlzIG5vdCBhY2NlcHRlZCwgd2UgY2FuIGRlZmluZSBhIG5ldyBSRUNVUlNJVkUg ZmxhZyANCmluIFByZWZpeC1TSUQgU3ViLVRMVi4NCg0KQlRXLCBhbGwgd2UgZGlzY3Vzc2VkIGlz IFNJRCByZWN1cnNpdmUgYnV0IG5vdCBzaGFyaW5nLCBldmVuIHRoZSBmaXJzdCANCmNhc2UgaW4g dGhpcyBkcmFmdCBpcyBhY3R1YWxseSBub3QgU0lEIHNoYXJpbmcsIG90aGVyd2lzZSBpdCB3aWxs IGJlIGNhcmVkIA0KYnkgZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi4NCg0K DQpUaGFua3MNCkRlY2Nhbg0KDQoNCg0KDQoNCg0KIlN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp IiA8c3ByZXZpZGlAY2lzY28uY29tPiANCjIwMTYtMDgtMjIgMjE6MzgNCg0KytW8/sjLDQoicGVu Zy5zaGFvZnVAenRlLmNvbS5jbiIgPHBlbmcuc2hhb2Z1QHp0ZS5jb20uY24+LCANCrOty80NClNQ UklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0K1vfM4g0KUmU6IFtzcHJpbmddIFdHIGFkb3B0aW9u IHJlcXVlc3RlZCBmb3IgDQpkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8N Cg0KDQoNCg0KDQoNCg0KPiBPbiBBdWcgOSwgMjAxNiwgYXQgNTo1NSBBTSwgcGVuZy5zaGFvZnVA enRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IE90aGVyIGRvY3VtZW50cyBoYXZlIGFscmVhZHkgYWRk cmVzc2VkIHRoaXMgaXNzdWUsDQoNCg0KSSBkb26hr3QgdGhpbmsgc28uIENhbiB5b3UgcG9pbnQg dG8gdGhlc2UgZG9jdW1lbnRzID8NCg0KDQo+IGZvciBleGFtcGxlLCBzZXQgTC1mbGFnIG9mIFBy ZWZpeC1TSUQgU3ViLVRMViBpbiANCmRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9ucy0wNSBhbmQgY29udGFpbiBJUHY0IFNvdXJjZSANClJvdXRlciBJRCBpbiByZmM3Nzk0 LiANCg0KDQp0aGUgTCBmbGFnIGhhcyB0aGUgc29sZWx5IHB1cnBvc2Ugb2YgaW5kaWNhdGluZyB0 aGUgc2lkIGNvbnRhaW5zIGEgbG9jYWwgDQp2YWx1ZS4gVHlwaWNhbGx5IGl0IGdvZXMgd2l0aCB0 aGUgViBmbGFnIHRoYXQgaW5kaWNhdGVzIGEgdmFsdWUgKGkuZS46IA0KbG9jYWwgbGFiZWwpLg0K DQpOb3RoaW5nIGlzIG1lbnRpb25lZCByZWdhcmRpbmcgc2hhcmluZyB0aGUgc2FtZSBzaWQgYW1v bmcgZGlmZmVyZW50IA0Kc2VydmljZXMuDQoNCnMuDQoNCg0KDQo+IA0KPiANCj4gVGhhbmtzLCAN Cj4gDQo+IERlY2NhbiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBbc3ByaW5nXSBXRyBhZG9wdGlv biByZXF1ZXN0ZWQgZm9yIA0KZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZv IA0KPiAiSm9obiBHLiBTY3VkZGVyIiA8amdzQGp1bmlwZXIubmV0PiBTdW4sIDI0IEp1bHkgMjAx NiAxMjo1NCBVVENTaG93IA0KaGVhZGVyDQo+IERlYXIgV0csDQo+IA0KPiBBcyB3ZSBkaXNjdXNz ZWQgYXQgb3VyIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gDQpyZXF1 ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmctaW5mby4gUGxlYXNl IHJlcGx5IHRvIHRoZSANCmxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91 Z2ggbm90IGxpbWl0ZWQgdG8gd2hldGhlciBvciBub3QgDQp5b3Ugc3VwcG9ydCBhZG9wdGlvbi4g Tm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KPiANCj4g V2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDMxLCAyMDE1LiANCj4gDQo+IEF1dGhvcnMs IHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ UiBhbmQgDQppZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuDQo+IA0KPiBUaGFu a3MsDQo+IA0KPiAtLUJydW5vIGFuZCBKb2huDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiBz cHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmcNCj4gDQoNCg0KDQo= --=_alternative 000E9A4948258018_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFN0ZWZhbm88L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cmUsIFNSUkkgcHJvdmlkZWQgaW4g dGhpcyBkb2N1bWVudA0KY2FuIGV4cGxpY2l0bHkgaW5kaWNhdGUgYSByZWN1cnNpdmUgb3BlcmF0 aW9uIChvciByZWxhdGlvbnNoaXApLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkJ1dCBpdCBtYXliZSBhIGRlZmF1bHQgYmVoYXZpb3IgdG8gZG8NCnJlY3Vyc2l2 ZSBvcGVyYXRpb24gd2hlbiBhbiBTUi1OT0RFIHJlY2VpdmVkIHJlbW90ZSBwcmVmaXgtc2lkIHdp dGggTC9WDQpmbGFnIHNldCBhY2NvcmRpbmcgdG8gdGhlIGRvY3VtZW50cyBhbHJlYWR5IGV4aXN0 ZWQuIEZvciBleGFtcGxlLCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPnByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCByZWNlaXZlZDo8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgcHJlZml4ICgx LjAuMC45OS8zMikgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcHJlZml4LXNpZA0KKDMwMDA0KSwgTC9WIGZsYWcg c2V0LCAmbmJzcDsvL0lTSVMtU1I8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7SVB2NCBTb3VyY2UgUm91dGVyDQpJRDwvZm9udD48 L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsgaXMgMS4wLjAuNCAvL3Jm Yzc3OTQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4sIHBy ZWZpeCAxLjAuMC45LzMyIGNhbiBkbyByZWN1cnNpb24NCnRvIHByZWZpeCAxLjAuMC40LzMyIGJ5 IGRlZmF1bHQuIElmICZxdW90O2RlZmF1bHQgYmVoYXZpb3ImcXVvdDsgaXMgbm90DQphY2NlcHRl ZCwgd2UgY2FuIGRlZmluZSBhIG5ldyBSRUNVUlNJVkUgZmxhZyBpbiA8L2ZvbnQ+PHR0Pjxmb250 IHNpemU9Mj5QcmVmaXgtU0lEDQpTdWItVExWPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxiPi48L2I+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5CVFcsIGFsbCB3ZSBkaXNjdXNzZWQgaXMgU0lEIHJlY3Vyc2l2ZQ0KYnV0 IG5vdCBzaGFyaW5nLCBldmVuIHRoZSBmaXJzdCBjYXNlIGluIHRoaXMgZHJhZnQgaXMgYWN0dWFs bHkgbm90IFNJRA0Kc2hhcmluZywgb3RoZXJ3aXNlIGl0IHdpbGwgYmUgY2FyZWQgYnkgZHJhZnQt aWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGVjY2FuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90O1N0ZWZh bm8gUHJldmlkaSAoc3ByZXZpZGkpJnF1b3Q7DQombHQ7c3ByZXZpZGlAY2lzY28uY29tJmd0Ozwv Yj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYtMDgtMjIg MjE6Mzg8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+JnF1b3Q7cGVuZy5zaGFvZnVAenRlLmNvbS5jbiZxdW90OyAmbHQ7cGVuZy5zaGFvZnVA enRlLmNvbS5jbiZndDssDQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNQUklORyBXRyAmbHQ7c3ByaW5n QGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzcHJpbmddIFdHIGFkb3B0aW9u IHJlcXVlc3RlZCBmb3INCmRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmctaW5mbzwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KJmd0OyBPbiBBdWcgOSwgMjAxNiwgYXQgNTo1NSBBTSwgcGVuZy5zaGFvZnVAenRlLmNv bS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgT3RoZXIgZG9jdW1lbnRzIGhhdmUgYWxy ZWFkeSBhZGRyZXNzZWQgdGhpcyBpc3N1ZSw8YnI+DQo8YnI+DQo8YnI+DQpJIGRvbqGvdCB0aGlu ayBzby4gQ2FuIHlvdSBwb2ludCB0byB0aGVzZSBkb2N1bWVudHMgPzxicj4NCjxicj4NCjxicj4N CiZndDsgZm9yIGV4YW1wbGUsIHNldCBMLWZsYWcgb2YgUHJlZml4LVNJRCBTdWItVExWIGluIGRy YWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wNQ0KYW5kIGNvbnRhaW4g SVB2NCBTb3VyY2UgUm91dGVyIElEIGluIHJmYzc3OTQuIDxicj4NCjxicj4NCjxicj4NCnRoZSBM IGZsYWcgaGFzIHRoZSBzb2xlbHkgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHRoZSBzaWQgY29udGFp bnMgYSBsb2NhbA0KdmFsdWUuIFR5cGljYWxseSBpdCBnb2VzIHdpdGggdGhlIFYgZmxhZyB0aGF0 IGluZGljYXRlcyBhIHZhbHVlIChpLmUuOg0KbG9jYWwgbGFiZWwpLjxicj4NCjxicj4NCk5vdGhp bmcgaXMgbWVudGlvbmVkIHJlZ2FyZGluZyBzaGFyaW5nIHRoZSBzYW1lIHNpZCBhbW9uZyBkaWZm ZXJlbnQgc2VydmljZXMuPGJyPg0KPGJyPg0Kcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBEZWNj YW4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgW3NwcmluZ10gV0cgYWRvcHRpb24gcmVxdWVzdGVkIGZvciBkcmFmdC1maWxz Zmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8NCjxicj4NCiZndDsgJnF1b3Q7Sm9obiBHLiBT Y3VkZGVyJnF1b3Q7ICZsdDtqZ3NAanVuaXBlci5uZXQmZ3Q7IFN1biwgMjQgSnVseSAyMDE2DQox Mjo1NCBVVENTaG93IGhlYWRlcjxicj4NCiZndDsgRGVhciBXRyw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgQXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9u IGhhcyBiZWVuIHJlcXVlc3RlZA0KZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNp bmctaW5mby4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGgNCnlvdXIgY29tbWVudHMsIGlu Y2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9y dA0KYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29t bWVudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0 IDMxLCAyMDE1LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQXV0aG9ycywgcGxlYXNlIGluZGljYXRl IHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSDQphbmQgaWYgc28sIHdo ZXRoZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3Ms PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tQnJ1bm8gYW5kIEpvaG48YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgc3ByaW5nQGlldGYu b3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3ByaW5nPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 Mj48YnI+DQomZ3Q7IDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 000E9A4948258018_=-- From nobody Tue Aug 23 08:35:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C368812D62D for ; Tue, 23 Aug 2016 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGmeX4bFc3HE for ; Tue, 23 Aug 2016 08:35:01 -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 C032712D9B3 for ; Tue, 23 Aug 2016 08:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6310; q=dns/txt; s=iport; t=1471965745; x=1473175345; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kYiYsdgpKFdTZtifnHy7Sf4kGW8ucAQ7EXpiSVEkyeA=; b=bO+cDTWRWICmpjK0WIV9Ixf6ksBW8ZAqa2rgXZUdCT5UC2i7IaHVo3PI m6LYnKJ1ncf5If3JEMnsfMAr5DDSxCqQsWjnZ7CdB5lV9ccVHyj339XPH qK5wXm1cwz6DTiB/AgU6JEkG7mrQnBqpExb40jiVkv/ieSBijsdB8RajV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAgBCabxX/4UNJK1dgykBAQEBARxWf?= =?us-ascii?q?Ae4A4F9JIUvSgIcgU04FAIBAQEBAQEBXhwLhGABAQQBAQEhEToEBwULAgEGAhg?= =?us-ascii?q?CAiYCAgIlCxUQAgQOBYgpCA6QNp0ikAQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXB?= =?us-ascii?q?YEChSuBeIJVhBwkFxWCVSuCLwWZSAGPIIFthFyJB4xAg3gBHjaCEhyBTHCETEZ?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,566,1464652800"; d="scan'208";a="144475885" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2016 15:22:24 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u7NFMOc7017004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Aug 2016 15:22:24 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 11:22:23 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 11:22:23 -0400 From: "Stefano Previdi (sprevidi)" To: "peng.shaofu@zte.com.cn" Thread-Topic: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info Thread-Index: AQHR/VIm3ukE8/WGtUWp8lnkkg4KAg== Date: Tue, 23 Aug 2016 15:22:23 +0000 Message-ID: <01B14068-3F4F-43DA-B536-988819E13C18@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-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.90.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPRING WG Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:35:03 -0000 SGkgRGVjY2FuLA0KDQoNCj4gT24gQXVnIDIzLCAyMDE2LCBhdCA0OjM5IEFNLCBwZW5nLnNoYW9m dUB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGkgU3RlZmFubyANCj4gDQo+IFN1cmUsIFNSUkkg cHJvdmlkZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gZXhwbGljaXRseSBpbmRpY2F0ZSBhIHJlY3Vy c2l2ZSBvcGVyYXRpb24gKG9yIHJlbGF0aW9uc2hpcCkuIA0KPiBCdXQgaXQgbWF5YmUgYSBkZWZh dWx0IGJlaGF2aW9yIHRvIGRvIHJlY3Vyc2l2ZSBvcGVyYXRpb24gd2hlbiBhbiBTUi1OT0RFIHJl Y2VpdmVkIHJlbW90ZSBwcmVmaXgtc2lkIHdpdGggTC9WIGZsYWcgc2V0IGFjY29yZGluZyB0byB0 aGUgZG9jdW1lbnRzIGFscmVhZHkgZXhpc3RlZC4gRm9yIGV4YW1wbGUsIA0KPiBwcmVmaXggcmVh Y2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgcmVjZWl2ZWQ6IA0KPiAgICAgcHJlZml4ICgxLjAuMC45 OS8zMikgDQo+ICAgICAgICAgcHJlZml4LXNpZCAoMzAwMDQpLCBML1YgZmxhZyBzZXQsICAvL0lT SVMtU1IgDQo+ICAgICAgICAgIklQdjQgU291cmNlIFJvdXRlciBJRCIgaXMgMS4wLjAuNCAvL3Jm Yzc3OTQgDQo+IFRoZW4sIHByZWZpeCAxLjAuMC45LzMyIGNhbiBkbyByZWN1cnNpb24gdG8gcHJl Zml4IDEuMC4wLjQvMzIgYnkgZGVmYXVsdC4NCg0KDQp0aGVyZSBhcmUgb3RoZXIgY2FzZXMgd2hl cmUgVi9MIGFyZSB1c2VkIHNvIEkgd291bGRu4oCZdCANCmJpbmQgdGhlc2UgZmxhZ3MgdG8gdGhl IHJlY3Vyc2l2ZSBiZWhhdmlvci4NCg0KDQo+IElmICJkZWZhdWx0IGJlaGF2aW9yIiBpcyBub3Qg YWNjZXB0ZWQsIHdlIGNhbiBkZWZpbmUgYSBuZXcgUkVDVVJTSVZFIGZsYWcgaW4gUHJlZml4LVNJ RCBTdWItVExWLiANCg0KDQppZiBJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCwgeW91IGNvdWxk Og0KLiBhdHRhY2ggdGhlIFNvdXJjZVJvdXRlcklEIChSRkM3Nzk0KSB0byB0aGUgcHJlZml4DQou IGF0dGFjaCBhIHByZWZpeC1zaWQgd2l0aDoNCiAgIC4gcmVjdXJzaXZlIGZsYWcgc2V0LCB3aGlj aCBtZWFucyB0aGUgc2lkIGlzIHRvIGJlIA0KICAgICAgdGFrZW4gZnJvbSB0aGUgc291cmNlUm91 dGVySUQNCiAgIC4gb3B0aW9uYWxseSBzZXQgdGhlIFYvTCBmbGFnIGFuZCBhbHNvIGEgbG9jYWwg bGFiZWwNCiAgIC4gaWYgbm8gVi9MIGZsYWcgYXJlIHNldCwgdGhlIHZhbHVlIG9mIHRoZSBzaWQv bGFiZWwgDQogICAgICBmaWVsZCBpbiB0aGUgcHJlZml4LXNpZCBtdXN0IGJlIDAgb24gdHJhbnNt aXQgYW5kIA0KICAgICAgaWdub3JlZCBvbiByZWNlaXZlLg0KDQpJIHNlZSBhdCBsZWFzdCAyIHBy b2JsZW1zIHdpdGggdGhhdDoNCjEuIHRoZSB2YWx1ZSBvZiB0aGUgcHJlZml4LXNpZCB5b3XigJly ZSBnb2luZyB0byBhZHZlcnRpc2UgDQogICB3aWxsIGJlIG1pc2ludGVycHJldGVkIGJ5IG5vbi1z cnJpLWNhcGFibGUgbm9kZXMgDQogICAoaS5lLjogbm9kZXMga25vdyBrbm93aW5nIHRoZSByZWN1 cnNpdmUgZmxhZykuIEkuZTogVGhlIA0KICAgdmFsdWUgb2YgdGhlIHByZWZpeCBzaWQgd291bGQg YmUgZWl0aGVyIGFuIGV4cGxpY2l0IA0KICAgbnVsbCBsYWJlbCBlaXRoZXIgYSAwLXZhbHVlIGlu ZGV4Lg0KMi4gUkZDNzc5NCBzdGF0ZXMgdGhhdDogdGhlIFJvdXRlciBJRCBhZHZlcnRpc2VkIGlz IA0KICAgYWx3YXlzIHRoZSBSb3V0ZXIgSUQgb2YgdGhlIElTLUlTIGluc3RhbmNlIHRoYXQgDQog ICBvcmlnaW5hdGVkIHRoZSBhZHZlcnRpc2VtZW50Lg0KIA0KICAgVGhpcyByZWR1Y2VzIHRoZSBh YmlsaXR5IHRvIHVzZSBvdGhlciBhZGRyZXNzZXMgb2YgdGhlIA0KICAgbm9kZSBmb3IgcmVjdXJz aW9uLg0KDQpCb3R0b20gbGluZSwgaGF2aW5nIGEgc2VwYXJhdGUgcmVwb3NpdG9yeSBmb3IgdGhl IHJlY3Vyc2luZyANCmluZm9ybWF0aW9uIGlzIHRoZSBzYWZlc3QgYW5kIGNsZWFuZXN0IG9wdGlv biB3aGljaCBhbGxvd3MgDQpiZXR0ZXIgZmxleGliaWxpdHkgKGkuZS46IGFsbG93aW5nIHRvIHJl Y3Vyc2UgdG8gYSANCm5vbi1yb3V0ZXItSUQgYWRkcmVzcykgYW5kIHdoaWNoIGVuc3VyZSBiYWNr d2FyZCANCmNvbXBhdGliaWxpdHkgKGkuZS46IG5vbi1zcnJpLW5vZGVzIHdpbGwgc2ltcGx5IGln bm9yZSB0aGUgDQp3aG9sZSBzcnJpIGluZm8gYW5kIGNvbnNpZGVyIHRoZSBwcmVmaXggYXMgaXQg aGFkIG5vIHNpZCBhdCANCmFsbCkuDQoNCg0KPiBCVFcsIGFsbCB3ZSBkaXNjdXNzZWQgaXMgU0lE IHJlY3Vyc2l2ZSBidXQgbm90IHNoYXJpbmcsDQoNCg0Kb2YgY291cnNlIGl0IGlzIHNoYXJpbmcu IEFzIGRlZmluZWQgaW4gdGhlIGRyYWZ0LCB0aGUgDQpsb2NhbCBsYWJlbCBhdHRhY2hlZCB0byB0 aGUgc3JyaSBpbmZvIGl04oCZcyBhbiBvcHRpb25hbCANCm9wdGltaXphdGlvbi4gV2l0aG91dCB0 aGUgbG9jYWwgbGFiZWwsIHlvdSB3aWxsIHNoYXJlIHRoZSANCnNhbWUgc2lkIGFtb25nIG11bHRp cGxlIHByZWZpeGVzLiANCg0KDQo+IGV2ZW4gdGhlIGZpcnN0IGNhc2UgaW4gdGhpcyBkcmFmdCBp cyBhY3R1YWxseSBub3QgU0lEIHNoYXJpbmcsIG90aGVyd2lzZSBpdCB3aWxsIGJlIGNhcmVkIGJ5 IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24uIA0KDQoNCk5vLCBpdCBpcyBu b3QgYSBjb25mbGljdC4gSGF2aW5nIGEgZGVkaWNhdGVkIHNycmkgDQpyZXBvc2l0b3J5IG1ha2Vz IGl0IGNsZWFyLg0KDQpzLg0KDQoNCj4gVGhhbmtzIA0KPiBEZWNjYW4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gIlN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIiA8c3ByZXZpZGlAY2lzY28uY29t Pg0KPiAyMDE2LTA4LTIyIDIxOjM4DQo+IA0KPiDmlLbku7bkuroNCj4gInBlbmcuc2hhb2Z1QHp0 ZS5jb20uY24iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPiwNCj4g5oqE6YCBDQo+IFNQUklORyBX RyA8c3ByaW5nQGlldGYub3JnPg0KPiDkuLvpopgNCj4gUmU6IFtzcHJpbmddIFdHIGFkb3B0aW9u IHJlcXVlc3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvDQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ID4gT24gQXVnIDksIDIwMTYsIGF0IDU6NTUgQU0sIHBl bmcuc2hhb2Z1QHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gDQo+ID4gT3RoZXIgZG9jdW1lbnRzIGhh dmUgYWxyZWFkeSBhZGRyZXNzZWQgdGhpcyBpc3N1ZSwNCj4gDQo+IA0KPiBJIGRvbuKAmXQgdGhp bmsgc28uIENhbiB5b3UgcG9pbnQgdG8gdGhlc2UgZG9jdW1lbnRzID8NCj4gDQo+IA0KPiA+IGZv ciBleGFtcGxlLCBzZXQgTC1mbGFnIG9mIFByZWZpeC1TSUQgU3ViLVRMViBpbiBkcmFmdC1pZXRm LWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMtMDUgYW5kIGNvbnRhaW4gSVB2NCBTb3Vy Y2UgUm91dGVyIElEIGluIHJmYzc3OTQuIA0KPiANCj4gDQo+IHRoZSBMIGZsYWcgaGFzIHRoZSBz b2xlbHkgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHRoZSBzaWQgY29udGFpbnMgYSBsb2NhbCB2YWx1 ZS4gVHlwaWNhbGx5IGl0IGdvZXMgd2l0aCB0aGUgViBmbGFnIHRoYXQgaW5kaWNhdGVzIGEgdmFs dWUgKGkuZS46IGxvY2FsIGxhYmVsKS4NCj4gDQo+IE5vdGhpbmcgaXMgbWVudGlvbmVkIHJlZ2Fy ZGluZyBzaGFyaW5nIHRoZSBzYW1lIHNpZCBhbW9uZyBkaWZmZXJlbnQgc2VydmljZXMuDQo+IA0K PiBzLg0KPiANCj4gDQo+IA0KPiA+IA0KPiA+IA0KPiA+IFRoYW5rcywgDQo+ID4gDQo+ID4gRGVj Y2FuIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFtzcHJpbmddIFdHIGFkb3B0 aW9uIHJlcXVlc3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZv IA0KPiA+ICJKb2huIEcuIFNjdWRkZXIiIDxqZ3NAanVuaXBlci5uZXQ+IFN1biwgMjQgSnVseSAy MDE2IDEyOjU0IFVUQ1Nob3cgaGVhZGVyDQo+ID4gRGVhciBXRywNCj4gPiANCj4gPiBBcyB3ZSBk aXNjdXNzZWQgYXQgb3VyIG1lZXRpbmcsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4g cmVxdWVzdGVkIGZvciBkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8uIFBs ZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRo b3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4g Tm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KPiA+IA0K PiA+IFdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAzMSwgMjAxNS4gDQo+ID4gDQo+ID4g QXV0aG9ycywgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVs ZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuDQo+ID4g DQo+ID4gVGhhbmtzLA0KPiA+IA0KPiA+IC0tQnJ1bm8gYW5kIEpvaG4NCj4gPiANCj4gPiANCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNw cmluZyBtYWlsaW5nIGxpc3QNCj4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiA+IA0KPiANCj4gDQoNCg== From nobody Tue Aug 23 10:25:18 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E317B12D1AD for ; Tue, 23 Aug 2016 10:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.068 X-Spam-Level: X-Spam-Status: No, score=-15.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_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 H__3nZgicaZn for ; Tue, 23 Aug 2016 10:25:16 -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 55D8C12B02B for ; Tue, 23 Aug 2016 10:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8328; q=dns/txt; s=iport; t=1471973116; x=1473182716; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EvCTQFcpSAB0LGBkCKBMC5T9wt4zNOd9ldb8OIr6DEY=; b=Uem2ZnUrmFzYPtMSEWL9ooc90LzQU6ofyoqJZZe7rFqNVxoKWTyOTr9i tHDqTUolqgvyJwFxr0AgKb2UBCfRpJYcC4M/LETUgCoEdcOSRGoUkvg1L uqEziP2r3hJKU354+iWl2RwE9WJpNOZHzsrPI+jeoWj8Qsk68UWYzEzm+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AgAvhrxX/4YNJK1dgnYzAQEBAQEcV?= =?us-ascii?q?nwHsnuFCIF9JIUvSgIcgU04FAIBAQEBAQEBXieEYAEBBQEBIQpBGwIBCBEEAQE?= =?us-ascii?q?oAwICAiULFAkIAgQBEgiIKQ6tS5AEAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGL?= =?us-ascii?q?YRNhBxagkuCWgWZSAGPGYF0hFyJB4xAg3gBHjaDenCETEYBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,567,1464652800"; d="scan'208,217";a="314485176" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2016 17:25:15 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u7NHPFJh005420 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Aug 2016 17:25:15 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 23 Aug 2016 12:25:14 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Tue, 23 Aug 2016 12:25:14 -0500 From: "Les Ginsberg (ginsberg)" To: Jeff Tantsura , "John G. Scudder" , "spring@ietf.org" Thread-Topic: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info Thread-Index: AQHR5f00f8tVL2ii2kiM2oMc6WuvfaBW+New Date: Tue, 23 Aug 2016 17:25:14 +0000 Message-ID: <6a851b141c9849f884d298e6171cdfe8@XCH-ALN-001.cisco.com> References: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> 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: [128.107.151.58] Content-Type: multipart/alternative; boundary="_000_6a851b141c9849f884d298e6171cdfe8XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 17:25:18 -0000 --_000_6a851b141c9849f884d298e6171cdfe8XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgY28tYXV0aG9yIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBX RyBpdGVtLg0KDQpJUFIgdGhhdCBJIGFtIGF3YXJlIG9mIGhhcyBiZWVuIGRpc2Nsb3NlZC4NCg0K cy4NCg0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEplZmYgVGFudHN1cmENClNlbnQ6IFN1bmRheSwgSnVseSAyNCwgMjAxNiAzOjQ2 IFBNDQpUbzogSm9obiBHLiBTY3VkZGVyOyBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb c3ByaW5nXSBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1z ci1yZWN1cnNpbmctaW5mbw0KDQpZZXMvc3VwcG9ydA0KT24gU3VuLCBKdWwgMjQsIDIwMTYgYXQg NTo1NCBBTSBKb2huIEcuIFNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldDxtYWlsdG86amdzQGp1bmlw ZXIubmV0Pj4gd3JvdGU6DQpEZWFyIFdHLA0KDQpBcyB3ZSBkaXNjdXNzZWQgYXQgb3VyIG1lZXRp bmcsIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1m aWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8uIFBsZWFzZSByZXBseSB0byB0aGUgbGlz dCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3 aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVj aWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50Lg0KDQpXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBB dWd1c3QgMzEsIDIwMTUuDQoNCkF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBh cmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28sIHdoZXRoZXIgaXQgaGFzIGJl ZW4gZGlzY2xvc2VkLg0KDQpUaGFua3MsDQoNCi0tQnJ1bm8gYW5kIEpvaG4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== --_000_6a851b141c9849f884d298e6171cdfe8XCHALN001ciscocom_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgY28tYXV0aG9yIEkg c3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBXRyBpdGVtLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SVBSIHRoYXQgSSBhbSBhd2FyZSBvZiBoYXMgYmVlbiBkaXNjbG9zZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkplZmYgVGFudHN1cmE8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBKdWx5IDI0LCAyMDE2IDM6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4g Ry4gU2N1ZGRlcjsgc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3By aW5nXSBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1y ZWN1cnNpbmctaW5mbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlllcy9zdXBwb3J0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFN1biwgSnVsIDI0LCAyMDE2IGF0IDU6NTQgQU0gSm9obiBHLiBTY3VkZGVy ICZsdDs8YSBocmVmPSJtYWlsdG86amdzQGp1bmlwZXIubmV0Ij5qZ3NAanVuaXBlci5uZXQ8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkRlYXIgV0csPGJyPg0KPGJyPg0KQXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBt ZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvLiBQbGVhc2UgcmVwbHkgdG8gdGhl IGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQg dG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBl c3BlY2lhbGx5DQogZW5jb3VyYWdlZCB0byBjb21tZW50Ljxicj4NCjxicj4NCldlIHdpbGwgZW5k IHRoZSBjYWxsIG9uIEF1Z3VzdCAzMSwgMjAxNS48YnI+DQo8YnI+DQpBdXRob3JzLCBwbGVhc2Ug aW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlm IHNvLCB3aGV0aGVyIGl0IGhhcyBiZWVuIGRpc2Nsb3NlZC48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KPGJyPg0KLS1CcnVubyBhbmQgSm9objxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6a851b141c9849f884d298e6171cdfe8XCHALN001ciscocom_-- From nobody Wed Aug 24 00:17:23 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8412B035 for ; Wed, 24 Aug 2016 00:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG3C2U7aoZRo for ; Wed, 24 Aug 2016 00:17:20 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB78612B015 for ; Wed, 24 Aug 2016 00:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=820; q=dns/txt; s=iport; t=1472023039; x=1473232639; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=dQhoTAzZyLA9Cd+hlqcxWKbnOBupBcntZBlKsWz4xkw=; b=HauSlG5HzL/ZPRX5FDvuBbplT6xCUzDOQK8IkSR/pwbZnjvBX4BLVGw6 QtSOPPdHG8x4tf8LEtdm2JRPcHmCf1MWKyWA0vXgoUE8Oes05cb+iQNAf sNHz1Badz9lXMmUG7S1lnDS6t0Fe10IHE3MOZ7vjRuqw9DiWtEICpr8Fz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1BACxSL1X/xbLJq1dgykBAQEBAXR8u?= =?us-ascii?q?gwkhS9KAoISEAIBAQEBAQEBXieEYgEFAQE2NgoRCxgJFg8JAwIBAgEVMAYBDAY?= =?us-ascii?q?CAQGILQ6+OwEBAQEBAQEBAQEBAQEBAQEBARoFhi2ETYQchX8BBJlIjyKBbYRcg?= =?us-ascii?q?xCFd5A5NR+DfDo0hEyCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,569,1464652800"; d="scan'208";a="646046194" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2016 07:17:17 +0000 Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7O7HGU9020843; Wed, 24 Aug 2016 07:17:17 GMT Message-ID: <57BD49FD.6040800@cisco.com> Date: Wed, 24 Aug 2016 09:17:17 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "John G. Scudder" , spring@ietf.org References: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> In-Reply-To: <9FACC4BB-B13C-4247-A8D4-07F6458E6000@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 07:17:21 -0000 As co-author I support the adoption of this document as WG item. I'm not aware of any undisclosed IPR. Peter On 24/07/16 14:54 , John G. Scudder wrote: > Dear WG, > > As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > We will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > . > From nobody Wed Aug 24 19:41:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E712D1CA for ; Wed, 24 Aug 2016 19:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.749 X-Spam-Level: X-Spam-Status: No, score=-104.749 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa6k1HZVnATe for ; Wed, 24 Aug 2016 19:41:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2E812B02A for ; Wed, 24 Aug 2016 19:41:03 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 0067D1F357109 for ; Thu, 25 Aug 2016 10:40:59 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id C9C65A8D02A51; Thu, 25 Aug 2016 10:40:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u7P2eYoC001479; Thu, 25 Aug 2016 10:40:34 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) In-Reply-To: <01B14068-3F4F-43DA-B536-988819E13C18@cisco.com> References: <01B14068-3F4F-43DA-B536-988819E13C18@cisco.com> To: "Stefano Previdi (sprevidi)" MIME-Version: 1.0 X-KeepSent: 571D7535:54D8101D-48258019:00149634; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Thu, 25 Aug 2016 10:41:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-08-25 10:40:34, Serialize complete at 2016-08-25 10:40:34 Content-Type: multipart/alternative; boundary="=_alternative 000EB3C94825801A_=" X-MAIL: mse01.zte.com.cn u7P2eYoC001479 Archived-At: Cc: SPRING WG Subject: [spring] =?gb2312?b?tPC4tDogUmU6ICBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQg?= =?gb2312?b?Zm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmctaW5mbw==?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 02:41:07 -0000 This is a multipart message in MIME format. --=_alternative 000EB3C94825801A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3RlZmFubywNCg0Kc2VlIGlubGluZSB3aXRoIFtEZWNjYW5dDQoNClRoYW5rcw0KRGVjY2FuDQoN Cg0KDQoNCiJTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSIgPHNwcmV2aWRpQGNpc2NvLmNvbT4g DQoyMDE2LTA4LTIzIDIzOjIyDQoNCsrVvP7Iyw0KInBlbmcuc2hhb2Z1QHp0ZS5jb20uY24iIDxw ZW5nLnNoYW9mdUB6dGUuY29tLmNuPiwgDQqzrcvNDQpTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9y Zz4NCtb3zOINClJlOiBbc3ByaW5nXSBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQgZm9yIA0KZHJhZnQt Zmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvDQoNCg0KDQoNCg0KDQpIaSBEZWNjYW4s DQoNCg0KPiBPbiBBdWcgMjMsIDIwMTYsIGF0IDQ6MzkgQU0sIHBlbmcuc2hhb2Z1QHp0ZS5jb20u Y24gd3JvdGU6DQo+IA0KPiBIaSBTdGVmYW5vIA0KPiANCj4gU3VyZSwgU1JSSSBwcm92aWRlZCBp biB0aGlzIGRvY3VtZW50IGNhbiBleHBsaWNpdGx5IGluZGljYXRlIGEgcmVjdXJzaXZlIA0Kb3Bl cmF0aW9uIChvciByZWxhdGlvbnNoaXApLiANCj4gQnV0IGl0IG1heWJlIGEgZGVmYXVsdCBiZWhh dmlvciB0byBkbyByZWN1cnNpdmUgb3BlcmF0aW9uIHdoZW4gYW4gDQpTUi1OT0RFIHJlY2VpdmVk IHJlbW90ZSBwcmVmaXgtc2lkIHdpdGggTC9WIGZsYWcgc2V0IGFjY29yZGluZyB0byB0aGUgDQpk b2N1bWVudHMgYWxyZWFkeSBleGlzdGVkLiBGb3IgZXhhbXBsZSwgDQo+IHByZWZpeCByZWFjaGFi aWxpdHkgYWR2ZXJ0aXNlbWVudCByZWNlaXZlZDogDQo+ICAgICBwcmVmaXggKDEuMC4wLjk5LzMy KSANCj4gICAgICAgICBwcmVmaXgtc2lkICgzMDAwNCksIEwvViBmbGFnIHNldCwgIC8vSVNJUy1T UiANCj4gICAgICAgICAiSVB2NCBTb3VyY2UgUm91dGVyIElEIiBpcyAxLjAuMC40IC8vcmZjNzc5 NCANCj4gVGhlbiwgcHJlZml4IDEuMC4wLjkvMzIgY2FuIGRvIHJlY3Vyc2lvbiB0byBwcmVmaXgg MS4wLjAuNC8zMiBieSANCmRlZmF1bHQuDQoNCg0KdGhlcmUgYXJlIG90aGVyIGNhc2VzIHdoZXJl IFYvTCBhcmUgdXNlZCBzbyBJIHdvdWxkbqGvdCANCmJpbmQgdGhlc2UgZmxhZ3MgdG8gdGhlIHJl Y3Vyc2l2ZSBiZWhhdmlvci4NCg0KW0RlY2Nhbl0gWWVzLCBpdCBpcyBlbnRpcmVseSBwb3NzaWJs ZSB0byBnZW5lcmF0ZSBhIHNlZ21lbnQgbGlzdCBvbmx5IA0KaW5jbHVkaW5nIHNlZ21lbnRzIHdp dGggbG9jYWwgbWVhbmluZywgc3VjaCBhcyBhZGphY2VuY3kgc2VnbWVudCBsaXN0LCANCnNlcnZp Y2Ugc2VnbWVudCBsaXN0LCBldGMuLCB3aXRob3V0IGFueSBub2RlIHNlZ21lbnQuIFNvIGl0IGlz IG5vdCANCmFwcHJvcHJpYXRlIHRvIGRvIHJlY3Vyc2l2ZSBvcGVyYXRpb24gZm9yIGxvY2FsIG1l YW5pbmcgc2VnbWVudHMgYnkgDQpkZWZhdWx0LiBUaGVyZSBtYXliZSBvdGhlciBjYXNlcyB0aGF0 IEkgZG9uJ3Qga25vdy4NCg0KPiBJZiAiZGVmYXVsdCBiZWhhdmlvciIgaXMgbm90IGFjY2VwdGVk LCB3ZSBjYW4gZGVmaW5lIGEgbmV3IFJFQ1VSU0lWRSANCmZsYWcgaW4gUHJlZml4LVNJRCBTdWIt VExWLiANCg0KDQppZiBJIHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbCwgeW91IGNvdWxkOg0KLiBh dHRhY2ggdGhlIFNvdXJjZVJvdXRlcklEIChSRkM3Nzk0KSB0byB0aGUgcHJlZml4DQouIGF0dGFj aCBhIHByZWZpeC1zaWQgd2l0aDoNCiAgIC4gcmVjdXJzaXZlIGZsYWcgc2V0LCB3aGljaCBtZWFu cyB0aGUgc2lkIGlzIHRvIGJlIA0KICAgICAgdGFrZW4gZnJvbSB0aGUgc291cmNlUm91dGVySUQN CiAgIC4gb3B0aW9uYWxseSBzZXQgdGhlIFYvTCBmbGFnIGFuZCBhbHNvIGEgbG9jYWwgbGFiZWwN CiAgIC4gaWYgbm8gVi9MIGZsYWcgYXJlIHNldCwgdGhlIHZhbHVlIG9mIHRoZSBzaWQvbGFiZWwg DQogICAgICBmaWVsZCBpbiB0aGUgcHJlZml4LXNpZCBtdXN0IGJlIDAgb24gdHJhbnNtaXQgYW5k IA0KICAgICAgaWdub3JlZCBvbiByZWNlaXZlLg0KDQpbRGVjY2FuXSBUaGUgYWJvdmUgbGFzdCBw b2ludCBjb3VsZCBiZSBtb2RpZmllZDoNCkluIGRlc3BpdGUgVi9MIGZsYWcgc2V0IG9yIG5vdCwg dGhlIHZhbHVlIG9mIHRoZSBzaWQvbGFiZWwgZmllbGQgaW4gdGhlIA0KcHJlZml4LXNpZCBtdXN0 IGFsd2F5cyBiZSBhIHZhbGlkIHZhbHVlLiBUaGF0IGlzLCBmb3IgcmVjdXJzaXZlIHVzZS1jYXNl LCANCml0IGlzIGl0cyBvd24gc2lkOyBmb3Igc2hhcmluZyB1c2UtY2FzZSwgaXQgaXMgdGhlIHNo YXJpbmcgc2lkLiBIb3dldmVyLCANCmlmIHRoZSByZWNlaXZlZCBub2RlcyBkb24ndCBrbm93IFJF Q1VSU0lWRSBmbGFnLCBmb3Igc2hhcmluZyB1c2UtY2FzZSwgc2lkIA0KY29uZmxpY3Rpbmcgd2ls bCBwcm9jZXNzOyBmb3IgcmVjdXJzaXZlIHVzZS1jYXNlLCBubyByZWN1cnNpb24gdG8gYmUgZG9u ZS4NCg0KDQpJIHNlZSBhdCBsZWFzdCAyIHByb2JsZW1zIHdpdGggdGhhdDoNCjEuIHRoZSB2YWx1 ZSBvZiB0aGUgcHJlZml4LXNpZCB5b3Whr3JlIGdvaW5nIHRvIGFkdmVydGlzZSANCiAgIHdpbGwg YmUgbWlzaW50ZXJwcmV0ZWQgYnkgbm9uLXNycmktY2FwYWJsZSBub2RlcyANCiAgIChpLmUuOiBu b2RlcyBrbm93IGtub3dpbmcgdGhlIHJlY3Vyc2l2ZSBmbGFnKS4gSS5lOiBUaGUgDQogICB2YWx1 ZSBvZiB0aGUgcHJlZml4IHNpZCB3b3VsZCBiZSBlaXRoZXIgYW4gZXhwbGljaXQgDQogICBudWxs IGxhYmVsIGVpdGhlciBhIDAtdmFsdWUgaW5kZXguDQoyLiBSRkM3Nzk0IHN0YXRlcyB0aGF0OiB0 aGUgUm91dGVyIElEIGFkdmVydGlzZWQgaXMgDQogICBhbHdheXMgdGhlIFJvdXRlciBJRCBvZiB0 aGUgSVMtSVMgaW5zdGFuY2UgdGhhdCANCiAgIG9yaWdpbmF0ZWQgdGhlIGFkdmVydGlzZW1lbnQu DQogDQogICBUaGlzIHJlZHVjZXMgdGhlIGFiaWxpdHkgdG8gdXNlIG90aGVyIGFkZHJlc3NlcyBv ZiB0aGUgDQogICBub2RlIGZvciByZWN1cnNpb24uDQoNCkJvdHRvbSBsaW5lLCBoYXZpbmcgYSBz ZXBhcmF0ZSByZXBvc2l0b3J5IGZvciB0aGUgcmVjdXJzaW5nIA0KaW5mb3JtYXRpb24gaXMgdGhl IHNhZmVzdCBhbmQgY2xlYW5lc3Qgb3B0aW9uIHdoaWNoIGFsbG93cyANCmJldHRlciBmbGV4aWJp bGl0eSAoaS5lLjogYWxsb3dpbmcgdG8gcmVjdXJzZSB0byBhIA0Kbm9uLXJvdXRlci1JRCBhZGRy ZXNzKSBhbmQgd2hpY2ggZW5zdXJlIGJhY2t3YXJkIA0KY29tcGF0aWJpbGl0eSAoaS5lLjogbm9u LXNycmktbm9kZXMgd2lsbCBzaW1wbHkgaWdub3JlIHRoZSANCndob2xlIHNycmkgaW5mbyBhbmQg Y29uc2lkZXIgdGhlIHByZWZpeCBhcyBpdCBoYWQgbm8gc2lkIGF0IA0KYWxsKS4NCg0KW0RlY2Nh bl0gWWVzLCB0aGUgYWx0ZXJuYXRlIG1ldGhvZCBvbmx5IGFsbG93cyB0byByZWN1cnNlIHRvIGEg cm91dGVyLWlkIA0KYWRkcmVzcy4gQnV0LCBkb24ndCB5b3UgdGhpbmsgcm91dGVyLWlkIGFkZHJl c3MgaXMgZW5vdWdoIGZvciBhbnkgc2VnbWVudCANCmxpc3Q/IEVzcGVjaWFsbHkgZm9yIGFuIFNS LVRFIHBhdGggZHluYW1pYyBjb21wdXRlZCBieSBDU1BGLCBJIHRoaW5rIGEgDQpub24tcm91dGVy LWlkIGFkZHJlc3Mgd2lsbCBoYXZlIG5vIGNoYW5jZSB0byByZXByZXNlbnQgYSBub2RlLXNlZ21l bnQuIA0KSG93ZXZlciwgdGhlIGFsdGVybmF0ZSBtZXRob2Qgc2VlbXMgdG8gYmUgbm90IG11Y2gg Y2xlYW4gdGhhbiBTUlJJIG1ldGhvZCwgDQpmb3IgdGhlIHBvc3NpYmxlIHNpZCBjb25mbGljdGlu ZyBpbnRyb2R1Y2VkIGluIHNoYXJpbmcgdXNlLWNhc2UsIGZyb20gdGhpcyANCnBvaW50LCB0aGUg U1JSSSBtZXRob2QgaXMgZ29vZC4NCg0KDQo+IEJUVywgYWxsIHdlIGRpc2N1c3NlZCBpcyBTSUQg cmVjdXJzaXZlIGJ1dCBub3Qgc2hhcmluZywNCg0KDQpvZiBjb3Vyc2UgaXQgaXMgc2hhcmluZy4g QXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQsIHRoZSANCmxvY2FsIGxhYmVsIGF0dGFjaGVkIHRvIHRo ZSBzcnJpIGluZm8gaXShr3MgYW4gb3B0aW9uYWwgDQpvcHRpbWl6YXRpb24uIFdpdGhvdXQgdGhl IGxvY2FsIGxhYmVsLCB5b3Ugd2lsbCBzaGFyZSB0aGUgDQpzYW1lIHNpZCBhbW9uZyBtdWx0aXBs ZSBwcmVmaXhlcy4gDQoNCg0KPiBldmVuIHRoZSBmaXJzdCBjYXNlIGluIHRoaXMgZHJhZnQgaXMg YWN0dWFsbHkgbm90IFNJRCBzaGFyaW5nLCBvdGhlcndpc2UgDQppdCB3aWxsIGJlIGNhcmVkIGJ5 IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24uIA0KDQoNCk5vLCBpdCBpcyBu b3QgYSBjb25mbGljdC4gSGF2aW5nIGEgZGVkaWNhdGVkIHNycmkgDQpyZXBvc2l0b3J5IG1ha2Vz IGl0IGNsZWFyLg0KDQpbRGVjY2FuXSBPaywgSSBoYXZlIG5vdCBnb3QgdGhpcyBwb2ludCBiZWZv cmUuIEhvd2V2ZXIsIGlmIHJvdXRlci1pZCANCmFkZHJlc3MgaXMgZW5vdWdoLCBzaWQgc2hhcmlu ZyBzZWVtcyB0byBiZSBub3Qgc28gbXVjaCBzaWduaWZpY2FudCwgZG8geW91IA0KdGhpbmsgc28/ DQoNCnMuDQoNCg0KPiBUaGFua3MgDQo+IERlY2NhbiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAi U3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkiIDxzcHJldmlkaUBjaXNjby5jb20+DQo+IDIwMTYt MDgtMjIgMjE6MzgNCj4gDQo+IMrVvP7Iyw0KPiAicGVuZy5zaGFvZnVAenRlLmNvbS5jbiIgPHBl bmcuc2hhb2Z1QHp0ZS5jb20uY24+LA0KPiCzrcvNDQo+IFNQUklORyBXRyA8c3ByaW5nQGlldGYu b3JnPg0KPiDW98ziDQo+IFJlOiBbc3ByaW5nXSBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQgZm9yIA0K ZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+ID4gT24gQXVnIDksIDIwMTYsIGF0IDU6NTUgQU0sIHBlbmcuc2hhb2Z1QHp0ZS5j b20uY24gd3JvdGU6DQo+ID4gDQo+ID4gT3RoZXIgZG9jdW1lbnRzIGhhdmUgYWxyZWFkeSBhZGRy ZXNzZWQgdGhpcyBpc3N1ZSwNCj4gDQo+IA0KPiBJIGRvbqGvdCB0aGluayBzby4gQ2FuIHlvdSBw b2ludCB0byB0aGVzZSBkb2N1bWVudHMgPw0KPiANCj4gDQo+ID4gZm9yIGV4YW1wbGUsIHNldCBM LWZsYWcgb2YgUHJlZml4LVNJRCBTdWItVExWIGluIA0KZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQt cm91dGluZy1leHRlbnNpb25zLTA1IGFuZCBjb250YWluIElQdjQgU291cmNlIA0KUm91dGVyIElE IGluIHJmYzc3OTQuIA0KPiANCj4gDQo+IHRoZSBMIGZsYWcgaGFzIHRoZSBzb2xlbHkgcHVycG9z ZSBvZiBpbmRpY2F0aW5nIHRoZSBzaWQgY29udGFpbnMgYSBsb2NhbCANCnZhbHVlLiBUeXBpY2Fs bHkgaXQgZ29lcyB3aXRoIHRoZSBWIGZsYWcgdGhhdCBpbmRpY2F0ZXMgYSB2YWx1ZSAoaS5lLjog DQpsb2NhbCBsYWJlbCkuDQo+IA0KPiBOb3RoaW5nIGlzIG1lbnRpb25lZCByZWdhcmRpbmcgc2hh cmluZyB0aGUgc2FtZSBzaWQgYW1vbmcgZGlmZmVyZW50IA0Kc2VydmljZXMuDQo+IA0KPiBzLg0K PiANCj4gDQo+IA0KPiA+IA0KPiA+IA0KPiA+IFRoYW5rcywgDQo+ID4gDQo+ID4gRGVjY2FuIA0K PiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFtzcHJpbmddIFdHIGFkb3B0aW9uIHJl cXVlc3RlZCBmb3IgDQpkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8gDQo+ ID4gIkpvaG4gRy4gU2N1ZGRlciIgPGpnc0BqdW5pcGVyLm5ldD4gU3VuLCAyNCBKdWx5IDIwMTYg MTI6NTQgVVRDU2hvdyANCmhlYWRlcg0KPiA+IERlYXIgV0csDQo+ID4gDQo+ID4gQXMgd2UgZGlz Y3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIA0K cmVxdWVzdGVkIGZvciBkcmFmdC1maWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8uIFBs ZWFzZSByZXBseSB0byB0aGUgDQpsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFs dGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IA0KeW91IHN1cHBvcnQgYWRvcHRp b24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCj4g PiANCj4gPiBXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBdWd1c3QgMzEsIDIwMTUuIA0KPiA+IA0K PiA+IEF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55 IHJlbGV2YW50IElQUiBhbmQgDQppZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQu DQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IA0KPiA+IC0tQnJ1bm8gYW5kIEpvaG4NCj4gPiANCj4g PiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiA+IA0KPiANCj4gDQoNCg0K DQo= --=_alternative 000EB3C94825801A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN0ZWZhbm8sPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zZWUgaW5saW5lIHdpdGggW0RlY2Nhbl08 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rczwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGVjY2FuPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD00MCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZxdW90 O1N0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpJnF1b3Q7DQombHQ7c3ByZXZpZGlAY2lzY28uY29t Jmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTYt MDgtMjMgMjM6MjI8L2ZvbnQ+DQo8dGQgd2lkdGg9NTklPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7cGVuZy5zaGFvZnVAenRlLmNvbS5jbiZxdW90OyAmbHQ7cGVuZy5z aGFvZnVAenRlLmNvbS5jbiZndDssDQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNQUklORyBXRyAmbHQ7 c3ByaW5nQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzcHJpbmddIFdHIGFk b3B0aW9uIHJlcXVlc3RlZCBmb3INCmRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmct aW5mbzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+SGkgRGVjY2FuLDxicj4NCjxicj4NCjxicj4NCiZndDsgT24gQXVnIDIzLCAyMDE2LCBh dCA0OjM5IEFNLCBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHdyb3RlOjxicj4NCiZndDsgPGJyPg0K Jmd0OyBIaSBTdGVmYW5vIDxicj4NCiZndDsgPGJyPg0KJmd0OyBTdXJlLCBTUlJJIHByb3ZpZGVk IGluIHRoaXMgZG9jdW1lbnQgY2FuIGV4cGxpY2l0bHkgaW5kaWNhdGUgYSByZWN1cnNpdmUNCm9w ZXJhdGlvbiAob3IgcmVsYXRpb25zaGlwKS4gPGJyPg0KJmd0OyBCdXQgaXQgbWF5YmUgYSBkZWZh dWx0IGJlaGF2aW9yIHRvIGRvIHJlY3Vyc2l2ZSBvcGVyYXRpb24gd2hlbiBhbg0KU1ItTk9ERSBy ZWNlaXZlZCByZW1vdGUgcHJlZml4LXNpZCB3aXRoIEwvViBmbGFnIHNldCBhY2NvcmRpbmcgdG8g dGhlIGRvY3VtZW50cw0KYWxyZWFkeSBleGlzdGVkLiBGb3IgZXhhbXBsZSwgPGJyPg0KJmd0OyBw cmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgcmVjZWl2ZWQ6IDxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyBwcmVmaXggKDEuMC4wLjk5LzMyKSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBwcmVmaXgtc2lkICgzMDAwNCksIEwvViBmbGFnIHNldCwgJm5ic3A7Ly9J U0lTLVNSDQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtJUHY0 IFNvdXJjZSBSb3V0ZXIgSUQmcXVvdDsgaXMgMS4wLjAuNA0KLy9yZmM3Nzk0IDxicj4NCiZndDsg VGhlbiwgcHJlZml4IDEuMC4wLjkvMzIgY2FuIGRvIHJlY3Vyc2lvbiB0byBwcmVmaXggMS4wLjAu NC8zMiBieSBkZWZhdWx0Ljxicj4NCjxicj4NCjxicj4NCnRoZXJlIGFyZSBvdGhlciBjYXNlcyB3 aGVyZSBWL0wgYXJlIHVzZWQgc28gSSB3b3VsZG6hr3QgPGJyPg0KYmluZCB0aGVzZSBmbGFncyB0 byB0aGUgcmVjdXJzaXZlIGJlaGF2aW9yLjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+W0RlY2Nhbl0gWWVzLCBpdCBpcyBlbnRpcmVseSBwb3NzaWJsZSB0byBnZW5lcmF0 ZQ0KYSBzZWdtZW50IGxpc3Qgb25seSBpbmNsdWRpbmcgc2VnbWVudHMgd2l0aCBsb2NhbCBtZWFu aW5nLCBzdWNoIGFzIGFkamFjZW5jeQ0Kc2VnbWVudCBsaXN0LCBzZXJ2aWNlIHNlZ21lbnQgbGlz dCwgZXRjLiwgd2l0aG91dCBhbnkgbm9kZSBzZWdtZW50LiBTbw0KaXQgaXMgbm90IGFwcHJvcHJp YXRlIHRvIGRvIHJlY3Vyc2l2ZSBvcGVyYXRpb24gZm9yIGxvY2FsIG1lYW5pbmcgc2VnbWVudHMN CmJ5IGRlZmF1bHQuIFRoZXJlIG1heWJlIG90aGVyIGNhc2VzIHRoYXQgSSBkb24ndCBrbm93Ljxi cj4NCjxicj4NCiZndDsgSWYgJnF1b3Q7ZGVmYXVsdCBiZWhhdmlvciZxdW90OyBpcyBub3QgYWNj ZXB0ZWQsIHdlIGNhbiBkZWZpbmUgYSBuZXcNClJFQ1VSU0lWRSBmbGFnIGluIFByZWZpeC1TSUQg U3ViLVRMVi4gPGJyPg0KPGJyPg0KPGJyPg0KaWYgSSB1bmRlcnN0YW5kIHlvdXIgcHJvcG9zYWws IHlvdSBjb3VsZDo8YnI+DQouIGF0dGFjaCB0aGUgU291cmNlUm91dGVySUQgKFJGQzc3OTQpIHRv IHRoZSBwcmVmaXg8YnI+DQouIGF0dGFjaCBhIHByZWZpeC1zaWQgd2l0aDo8YnI+DQogJm5ic3A7 IC4gcmVjdXJzaXZlIGZsYWcgc2V0LCB3aGljaCBtZWFucyB0aGUgc2lkIGlzIHRvIGJlIDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwO3Rha2VuIGZyb20gdGhlIHNvdXJjZVJvdXRlcklEPGJyPg0K ICZuYnNwOyAuIG9wdGlvbmFsbHkgc2V0IHRoZSBWL0wgZmxhZyBhbmQgYWxzbyBhIGxvY2FsIGxh YmVsPGJyPg0KICZuYnNwOyAuIGlmIG5vIFYvTCBmbGFnIGFyZSBzZXQsIHRoZSB2YWx1ZSBvZiB0 aGUgc2lkL2xhYmVsIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZpZWxkIGluIHRoZSBwcmVm aXgtc2lkIG11c3QgYmUgMCBvbiB0cmFuc21pdCBhbmQNCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwO2lnbm9yZWQgb24gcmVjZWl2ZS48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPltEZWNjYW5dIFRoZSBhYm92ZSBsYXN0IHBvaW50IGNvdWxkIGJlIG1vZGlmaWVkOjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SW4gZGVzcGl0ZSBWL0wgZmxhZyBzZXQg b3Igbm90LCB0aGUgdmFsdWUgb2YgdGhlIHNpZC9sYWJlbA0KZmllbGQgaW4gdGhlIHByZWZpeC1z aWQgbXVzdCBhbHdheXMgYmUgYSB2YWxpZCB2YWx1ZS4gVGhhdCBpcywgZm9yIHJlY3Vyc2l2ZQ0K dXNlLWNhc2UsIGl0IGlzIGl0cyBvd24gc2lkOyBmb3Igc2hhcmluZyB1c2UtY2FzZSwgaXQgaXMg dGhlIHNoYXJpbmcgc2lkLg0KSG93ZXZlciwgaWYgdGhlIHJlY2VpdmVkIG5vZGVzIGRvbid0IGtu b3cgUkVDVVJTSVZFIGZsYWcsIGZvciBzaGFyaW5nIHVzZS1jYXNlLA0Kc2lkIGNvbmZsaWN0aW5n IHdpbGwgcHJvY2VzczsgZm9yIHJlY3Vyc2l2ZSB1c2UtY2FzZSwgbm8gcmVjdXJzaW9uIHRvIGJl DQpkb25lLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KSSBz ZWUgYXQgbGVhc3QgMiBwcm9ibGVtcyB3aXRoIHRoYXQ6PGJyPg0KMS4gdGhlIHZhbHVlIG9mIHRo ZSBwcmVmaXgtc2lkIHlvdaGvcmUgZ29pbmcgdG8gYWR2ZXJ0aXNlIDxicj4NCiAmbmJzcDsgd2ls bCBiZSBtaXNpbnRlcnByZXRlZCBieSBub24tc3JyaS1jYXBhYmxlIG5vZGVzIDxicj4NCiAmbmJz cDsgKGkuZS46IG5vZGVzIGtub3cga25vd2luZyB0aGUgcmVjdXJzaXZlIGZsYWcpLiBJLmU6IFRo ZSA8YnI+DQogJm5ic3A7IHZhbHVlIG9mIHRoZSBwcmVmaXggc2lkIHdvdWxkIGJlIGVpdGhlciBh biBleHBsaWNpdCA8YnI+DQogJm5ic3A7IG51bGwgbGFiZWwgZWl0aGVyIGEgMC12YWx1ZSBpbmRl eC48YnI+DQoyLiBSRkM3Nzk0IHN0YXRlcyB0aGF0OiB0aGUgUm91dGVyIElEIGFkdmVydGlzZWQg aXMgPGJyPg0KICZuYnNwOyBhbHdheXMgdGhlIFJvdXRlciBJRCBvZiB0aGUgSVMtSVMgaW5zdGFu Y2UgdGhhdCA8YnI+DQogJm5ic3A7IG9yaWdpbmF0ZWQgdGhlIGFkdmVydGlzZW1lbnQuPGJyPg0K IDxicj4NCiAmbmJzcDsgVGhpcyByZWR1Y2VzIHRoZSBhYmlsaXR5IHRvIHVzZSBvdGhlciBhZGRy ZXNzZXMgb2YgdGhlIDxicj4NCiAmbmJzcDsgbm9kZSBmb3IgcmVjdXJzaW9uLjxicj4NCjxicj4N CkJvdHRvbSBsaW5lLCBoYXZpbmcgYSBzZXBhcmF0ZSByZXBvc2l0b3J5IGZvciB0aGUgcmVjdXJz aW5nIDxicj4NCmluZm9ybWF0aW9uIGlzIHRoZSBzYWZlc3QgYW5kIGNsZWFuZXN0IG9wdGlvbiB3 aGljaCBhbGxvd3MgPGJyPg0KYmV0dGVyIGZsZXhpYmlsaXR5IChpLmUuOiBhbGxvd2luZyB0byBy ZWN1cnNlIHRvIGEgPGJyPg0Kbm9uLXJvdXRlci1JRCBhZGRyZXNzKSBhbmQgd2hpY2ggZW5zdXJl IGJhY2t3YXJkIDxicj4NCmNvbXBhdGliaWxpdHkgKGkuZS46IG5vbi1zcnJpLW5vZGVzIHdpbGwg c2ltcGx5IGlnbm9yZSB0aGUgPGJyPg0Kd2hvbGUgc3JyaSBpbmZvIGFuZCBjb25zaWRlciB0aGUg cHJlZml4IGFzIGl0IGhhZCBubyBzaWQgYXQgPGJyPg0KYWxsKS48YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPltEZWNjYW5dIFllcywgdGhlIGFsdGVybmF0ZSBtZXRob2Qg b25seSBhbGxvd3MgdG8NCnJlY3Vyc2UgdG8gYSByb3V0ZXItaWQgYWRkcmVzcy4gQnV0LCBkb24n dCB5b3UgdGhpbmsgcm91dGVyLWlkIGFkZHJlc3MNCmlzIGVub3VnaCBmb3IgYW55IHNlZ21lbnQg bGlzdD8gRXNwZWNpYWxseSBmb3IgYW4gU1ItVEUgcGF0aCBkeW5hbWljIGNvbXB1dGVkDQpieSBD U1BGLCBJIHRoaW5rIGEgbm9uLXJvdXRlci1pZCBhZGRyZXNzIHdpbGwgaGF2ZSBubyBjaGFuY2Ug dG8gcmVwcmVzZW50DQphIG5vZGUtc2VnbWVudC4gSG93ZXZlciwgdGhlIGFsdGVybmF0ZSBtZXRo b2Qgc2VlbXMgdG8gYmUgbm90IG11Y2ggY2xlYW4NCnRoYW4gU1JSSSBtZXRob2QsIGZvciB0aGUg cG9zc2libGUgc2lkIGNvbmZsaWN0aW5nIGludHJvZHVjZWQgaW4gc2hhcmluZw0KdXNlLWNhc2Us IGZyb20gdGhpcyBwb2ludCwgdGhlIFNSUkkgbWV0aG9kIGlzIGdvb2QuPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IEJUVywgYWxsIHdlIGRpc2N1c3Nl ZCBpcyBTSUQgcmVjdXJzaXZlIGJ1dCBub3Qgc2hhcmluZyw8YnI+DQo8YnI+DQo8YnI+DQpvZiBj b3Vyc2UgaXQgaXMgc2hhcmluZy4gQXMgZGVmaW5lZCBpbiB0aGUgZHJhZnQsIHRoZSA8YnI+DQps b2NhbCBsYWJlbCBhdHRhY2hlZCB0byB0aGUgc3JyaSBpbmZvIGl0oa9zIGFuIG9wdGlvbmFsIDxi cj4NCm9wdGltaXphdGlvbi4gV2l0aG91dCB0aGUgbG9jYWwgbGFiZWwsIHlvdSB3aWxsIHNoYXJl IHRoZSA8YnI+DQpzYW1lIHNpZCBhbW9uZyBtdWx0aXBsZSBwcmVmaXhlcy4gPGJyPg0KPGJyPg0K PGJyPg0KJmd0OyBldmVuIHRoZSBmaXJzdCBjYXNlIGluIHRoaXMgZHJhZnQgaXMgYWN0dWFsbHkg bm90IFNJRCBzaGFyaW5nLCBvdGhlcndpc2UNCml0IHdpbGwgYmUgY2FyZWQgYnkgZHJhZnQtaWV0 Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi4gPGJyPg0KPGJyPg0KPGJyPg0KTm8sIGl0IGlz IG5vdCBhIGNvbmZsaWN0LiBIYXZpbmcgYSBkZWRpY2F0ZWQgc3JyaSA8YnI+DQpyZXBvc2l0b3J5 IG1ha2VzIGl0IGNsZWFyLjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ W0RlY2Nhbl0gT2ssIEkgaGF2ZSBub3QgZ290IHRoaXMgcG9pbnQgYmVmb3JlLiBIb3dldmVyLA0K aWYgcm91dGVyLWlkIGFkZHJlc3MgaXMgZW5vdWdoLCBzaWQgc2hhcmluZyBzZWVtcyB0byBiZSBu b3Qgc28gbXVjaCBzaWduaWZpY2FudCwNCmRvIHlvdSB0aGluayBzbz88L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCnMuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBUaGFua3Mg PGJyPg0KJmd0OyBEZWNjYW4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7U3RlZmFubyBQcmV2aWRpIChzcHJldmlk aSkmcXVvdDsgJmx0O3NwcmV2aWRpQGNpc2NvLmNvbSZndDs8YnI+DQomZ3Q7IDIwMTYtMDgtMjIg MjE6Mzg8YnI+DQomZ3Q7IDxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyAmcXVvdDtwZW5nLnNo YW9mdUB6dGUuY29tLmNuJnF1b3Q7ICZsdDtwZW5nLnNoYW9mdUB6dGUuY29tLmNuJmd0Oyw8YnI+ DQomZ3Q7ILOty808YnI+DQomZ3Q7IFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxi cj4NCiZndDsg1vfM4jxicj4NCiZndDsgUmU6IFtzcHJpbmddIFdHIGFkb3B0aW9uIHJlcXVlc3Rl ZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IE9uIEF1ZyA5LCAyMDE2LCBhdCA1OjU1IEFNLCBwZW5nLnNoYW9mdUB6dGUu Y29tLmNuIHdyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT3RoZXIgZG9jdW1l bnRzIGhhdmUgYWxyZWFkeSBhZGRyZXNzZWQgdGhpcyBpc3N1ZSw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBJIGRvbqGvdCB0aGluayBzby4gQ2FuIHlvdSBwb2ludCB0byB0aGVzZSBk b2N1bWVudHMgPzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgZm9yIGV4YW1w bGUsIHNldCBMLWZsYWcgb2YgUHJlZml4LVNJRCBTdWItVExWIGluIGRyYWZ0LWlldGYtaXNpcy1z ZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wNQ0KYW5kIGNvbnRhaW4gSVB2NCBTb3VyY2UgUm91 dGVyIElEIGluIHJmYzc3OTQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHRoZSBM IGZsYWcgaGFzIHRoZSBzb2xlbHkgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHRoZSBzaWQgY29udGFp bnMgYQ0KbG9jYWwgdmFsdWUuIFR5cGljYWxseSBpdCBnb2VzIHdpdGggdGhlIFYgZmxhZyB0aGF0 IGluZGljYXRlcyBhIHZhbHVlIChpLmUuOg0KbG9jYWwgbGFiZWwpLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBOb3RoaW5nIGlzIG1lbnRpb25lZCByZWdhcmRpbmcgc2hhcmluZyB0aGUgc2FtZSBzaWQg YW1vbmcgZGlmZmVyZW50DQpzZXJ2aWNlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgcy48YnI+DQom Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGFua3MsIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg RGVjY2FuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFtzcHJpbmddIFdH IGFkb3B0aW9uIHJlcXVlc3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2lu Zy1pbmZvDQo8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7Sm9obiBHLiBTY3VkZGVyJnF1b3Q7ICZsdDtq Z3NAanVuaXBlci5uZXQmZ3Q7IFN1biwgMjQgSnVseQ0KMjAxNiAxMjo1NCBVVENTaG93IGhlYWRl cjxicj4NCiZndDsgJmd0OyBEZWFyIFdHLDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg QXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhh cyBiZWVuDQpyZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zci1yZWN1cnNpbmct aW5mby4gUGxlYXNlIHJlcGx5IHRvDQp0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1 ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyDQpvciBub3QgeW91IHN1cHBvcnQg YWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVu dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFdlIHdpbGwgZW5kIHRoZSBjYWxsIG9u IEF1Z3VzdCAzMSwgMjAxNS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBdXRob3Jz LCBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudA0K SVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAtLUJydW5vIGFuZCBKb2huPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBzcHJpbmdA aWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9mb250PjwvdHQ+PC9hPjx0dD48 Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8 YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 000EB3C94825801A_=-- From nobody Thu Aug 25 02:39:24 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA1612D559 for ; Thu, 25 Aug 2016 02:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEHyO1ZfLXV4 for ; Thu, 25 Aug 2016 02:39:19 -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 1B23012D105 for ; Thu, 25 Aug 2016 02:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10202; q=dns/txt; s=iport; t=1472117958; x=1473327558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zDl8nmxY5RDBIm3JupcgsZcEcctpOQN6PF3SwuRD5Ks=; b=ejpT/oaj2fiC/4AN4NN9/BAs/ebS4UAdp/iZsAaJ/gsZ0Oqu3s3n9UMK jOACdVXylrC2oeDu9+/8cc5ZxnJ59KXXlq8ZZUpKTeBNe7EQA7IeLhvIL Wrv4ry678XS0eZnC/+Q8HlvXDIc5arDMOxi0pyuJnuthavXF6mnYKNO+3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgAZvL5X/5xdJa1cgykBAQEBAR5Wf?= =?us-ascii?q?AezVYRAgX4khS9KAhyBNTgUAgEBAQEBAQFeHAuEYQEBBAEBASEROgQHBQsCAQY?= =?us-ascii?q?CGAICJgICAiULFQULAgQOBRuIDwgOk3adI49oAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwWBA4UrgXiBUoEDhBwkFxWCViuCLwWZSgGPJYFthF2JB4xBg3gBHjaCFRw?= =?us-ascii?q?XgTVwhFOBL38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,575,1464652800"; d="scan'208";a="145172684" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2016 09:39:17 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7P9dH1G026152 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Aug 2016 09:39:17 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 25 Aug 2016 05:39:16 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 25 Aug 2016 05:39:16 -0400 From: "Stefano Previdi (sprevidi)" To: "peng.shaofu@zte.com.cn" Thread-Topic: =?utf-8?B?W3NwcmluZ10g562U5aSNOiBSZTogIFdHIGFkb3B0aW9uIHJlcXVlc3RlZCBm?= =?utf-8?Q?or_draft-filsfils-spring-sr-recursing-info?= Thread-Index: AQHR/nol4EjXHFIxiE2BCIdUS+KPKKBZrzMA Date: Thu, 25 Aug 2016 09:39:16 +0000 Message-ID: References: <01B14068-3F4F-43DA-B536-988819E13C18@cisco.com> 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.61.107.157] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPRING WG Subject: Re: [spring] =?utf-8?b?562U5aSNOiBSZTogIFdHIGFkb3B0aW9uIHJlcXVlc3Rl?= =?utf-8?q?d_for_draft-filsfils-spring-sr-recursing-info?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 09:39:21 -0000 DQo+IE9uIEF1ZyAyNSwgMjAxNiwgYXQgNDo0MSBBTSwgcGVuZy5zaGFvZnVAenRlLmNvbS5jbiB3 cm90ZToNCj4gDQo+IFN0ZWZhbm8sIA0KPiANCj4gc2VlIGlubGluZSB3aXRoIFtEZWNjYW5dIA0K PiANCj4gVGhhbmtzIA0KPiBEZWNjYW4gDQo+IA0KPiANCj4gDQo+ICJTdGVmYW5vIFByZXZpZGkg KHNwcmV2aWRpKSIgPHNwcmV2aWRpQGNpc2NvLmNvbT4NCj4gMjAxNi0wOC0yMyAyMzoyMg0KPiAN Cj4g5pS25Lu25Lq6DQo+ICJwZW5nLnNoYW9mdUB6dGUuY29tLmNuIiA8cGVuZy5zaGFvZnVAenRl LmNvbS5jbj4sDQo+IOaKhOmAgQ0KPiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCj4g5Li7 6aKYDQo+IFJlOiBbc3ByaW5nXSBXRyBhZG9wdGlvbiByZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNm aWxzLXNwcmluZy1zci1yZWN1cnNpbmctaW5mbw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhpIERl Y2NhbiwNCj4gDQo+IA0KPiA+IE9uIEF1ZyAyMywgMjAxNiwgYXQgNDozOSBBTSwgcGVuZy5zaGFv ZnVAenRlLmNvbS5jbiB3cm90ZToNCj4gPiANCj4gPiBIaSBTdGVmYW5vIA0KPiA+IA0KPiA+IFN1 cmUsIFNSUkkgcHJvdmlkZWQgaW4gdGhpcyBkb2N1bWVudCBjYW4gZXhwbGljaXRseSBpbmRpY2F0 ZSBhIHJlY3Vyc2l2ZSBvcGVyYXRpb24gKG9yIHJlbGF0aW9uc2hpcCkuIA0KPiA+IEJ1dCBpdCBt YXliZSBhIGRlZmF1bHQgYmVoYXZpb3IgdG8gZG8gcmVjdXJzaXZlIG9wZXJhdGlvbiB3aGVuIGFu IFNSLU5PREUgcmVjZWl2ZWQgcmVtb3RlIHByZWZpeC1zaWQgd2l0aCBML1YgZmxhZyBzZXQgYWNj b3JkaW5nIHRvIHRoZSBkb2N1bWVudHMgYWxyZWFkeSBleGlzdGVkLiBGb3IgZXhhbXBsZSwgDQo+ ID4gcHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50IHJlY2VpdmVkOiANCj4gPiAgICAg cHJlZml4ICgxLjAuMC45OS8zMikgDQo+ID4gICAgICAgICBwcmVmaXgtc2lkICgzMDAwNCksIEwv ViBmbGFnIHNldCwgIC8vSVNJUy1TUiANCj4gPiAgICAgICAgICJJUHY0IFNvdXJjZSBSb3V0ZXIg SUQiIGlzIDEuMC4wLjQgLy9yZmM3Nzk0IA0KPiA+IFRoZW4sIHByZWZpeCAxLjAuMC45LzMyIGNh biBkbyByZWN1cnNpb24gdG8gcHJlZml4IDEuMC4wLjQvMzIgYnkgZGVmYXVsdC4NCj4gDQo+IA0K PiB0aGVyZSBhcmUgb3RoZXIgY2FzZXMgd2hlcmUgVi9MIGFyZSB1c2VkIHNvIEkgd291bGRu4oCZ dCANCj4gYmluZCB0aGVzZSBmbGFncyB0byB0aGUgcmVjdXJzaXZlIGJlaGF2aW9yLg0KPiANCj4g W0RlY2Nhbl0gWWVzLCBpdCBpcyBlbnRpcmVseSBwb3NzaWJsZSB0byBnZW5lcmF0ZSBhIHNlZ21l bnQgbGlzdCBvbmx5IGluY2x1ZGluZyBzZWdtZW50cyB3aXRoIGxvY2FsIG1lYW5pbmcsIHN1Y2gg YXMgYWRqYWNlbmN5IHNlZ21lbnQgbGlzdCwgc2VydmljZSBzZWdtZW50IGxpc3QsIGV0Yy4sIHdp dGhvdXQgYW55IG5vZGUgc2VnbWVudC4gU28gaXQgaXMgbm90IGFwcHJvcHJpYXRlIHRvIGRvIHJl Y3Vyc2l2ZSBvcGVyYXRpb24gZm9yIGxvY2FsIG1lYW5pbmcgc2VnbWVudHMgYnkgZGVmYXVsdC4g VGhlcmUgbWF5YmUgb3RoZXIgY2FzZXMgdGhhdCBJIGRvbid0IGtub3cuDQo+IA0KPiA+IElmICJk ZWZhdWx0IGJlaGF2aW9yIiBpcyBub3QgYWNjZXB0ZWQsIHdlIGNhbiBkZWZpbmUgYSBuZXcgUkVD VVJTSVZFIGZsYWcgaW4gUHJlZml4LVNJRCBTdWItVExWLiANCj4gDQo+IA0KPiBpZiBJIHVuZGVy c3RhbmQgeW91ciBwcm9wb3NhbCwgeW91IGNvdWxkOg0KPiAuIGF0dGFjaCB0aGUgU291cmNlUm91 dGVySUQgKFJGQzc3OTQpIHRvIHRoZSBwcmVmaXgNCj4gLiBhdHRhY2ggYSBwcmVmaXgtc2lkIHdp dGg6DQo+ICAgLiByZWN1cnNpdmUgZmxhZyBzZXQsIHdoaWNoIG1lYW5zIHRoZSBzaWQgaXMgdG8g YmUgDQo+ICAgICAgdGFrZW4gZnJvbSB0aGUgc291cmNlUm91dGVySUQNCj4gICAuIG9wdGlvbmFs bHkgc2V0IHRoZSBWL0wgZmxhZyBhbmQgYWxzbyBhIGxvY2FsIGxhYmVsDQo+ICAgLiBpZiBubyBW L0wgZmxhZyBhcmUgc2V0LCB0aGUgdmFsdWUgb2YgdGhlIHNpZC9sYWJlbCANCj4gICAgICBmaWVs ZCBpbiB0aGUgcHJlZml4LXNpZCBtdXN0IGJlIDAgb24gdHJhbnNtaXQgYW5kIA0KPiAgICAgIGln bm9yZWQgb24gcmVjZWl2ZS4NCj4gDQo+IFtEZWNjYW5dIFRoZSBhYm92ZSBsYXN0IHBvaW50IGNv dWxkIGJlIG1vZGlmaWVkOiANCj4gSW4gZGVzcGl0ZSBWL0wgZmxhZyBzZXQgb3Igbm90LCB0aGUg dmFsdWUgb2YgdGhlIHNpZC9sYWJlbCBmaWVsZCBpbiB0aGUgcHJlZml4LXNpZCBtdXN0IGFsd2F5 cyBiZSBhIHZhbGlkIHZhbHVlLiBUaGF0IGlzLCBmb3IgcmVjdXJzaXZlIHVzZS1jYXNlLCBpdCBp cyBpdHMgb3duIHNpZDsgZm9yIHNoYXJpbmcgdXNlLWNhc2UsIGl0IGlzIHRoZSBzaGFyaW5nIHNp ZC4gSG93ZXZlciwgaWYgdGhlIHJlY2VpdmVkIG5vZGVzIGRvbid0IGtub3cgUkVDVVJTSVZFIGZs YWcsIGZvciBzaGFyaW5nIHVzZS1jYXNlLCBzaWQgY29uZmxpY3Rpbmcgd2lsbCBwcm9jZXNzOyBm b3IgcmVjdXJzaXZlIHVzZS1jYXNlLCBubyByZWN1cnNpb24gdG8gYmUgZG9uZS4gDQoNCg0Kc28s IGl04oCZcyBicm9rZW4uDQoNCg0KPiBJIHNlZSBhdCBsZWFzdCAyIHByb2JsZW1zIHdpdGggdGhh dDoNCj4gMS4gdGhlIHZhbHVlIG9mIHRoZSBwcmVmaXgtc2lkIHlvdeKAmXJlIGdvaW5nIHRvIGFk dmVydGlzZSANCj4gICB3aWxsIGJlIG1pc2ludGVycHJldGVkIGJ5IG5vbi1zcnJpLWNhcGFibGUg bm9kZXMgDQo+ICAgKGkuZS46IG5vZGVzIGtub3cga25vd2luZyB0aGUgcmVjdXJzaXZlIGZsYWcp LiBJLmU6IFRoZSANCj4gICB2YWx1ZSBvZiB0aGUgcHJlZml4IHNpZCB3b3VsZCBiZSBlaXRoZXIg YW4gZXhwbGljaXQgDQo+ICAgbnVsbCBsYWJlbCBlaXRoZXIgYSAwLXZhbHVlIGluZGV4Lg0KPiAy LiBSRkM3Nzk0IHN0YXRlcyB0aGF0OiB0aGUgUm91dGVyIElEIGFkdmVydGlzZWQgaXMgDQo+ICAg YWx3YXlzIHRoZSBSb3V0ZXIgSUQgb2YgdGhlIElTLUlTIGluc3RhbmNlIHRoYXQgDQo+ICAgb3Jp Z2luYXRlZCB0aGUgYWR2ZXJ0aXNlbWVudC4NCj4gDQo+ICAgVGhpcyByZWR1Y2VzIHRoZSBhYmls aXR5IHRvIHVzZSBvdGhlciBhZGRyZXNzZXMgb2YgdGhlIA0KPiAgIG5vZGUgZm9yIHJlY3Vyc2lv bi4NCj4gDQo+IEJvdHRvbSBsaW5lLCBoYXZpbmcgYSBzZXBhcmF0ZSByZXBvc2l0b3J5IGZvciB0 aGUgcmVjdXJzaW5nIA0KPiBpbmZvcm1hdGlvbiBpcyB0aGUgc2FmZXN0IGFuZCBjbGVhbmVzdCBv cHRpb24gd2hpY2ggYWxsb3dzIA0KPiBiZXR0ZXIgZmxleGliaWxpdHkgKGkuZS46IGFsbG93aW5n IHRvIHJlY3Vyc2UgdG8gYSANCj4gbm9uLXJvdXRlci1JRCBhZGRyZXNzKSBhbmQgd2hpY2ggZW5z dXJlIGJhY2t3YXJkIA0KPiBjb21wYXRpYmlsaXR5IChpLmUuOiBub24tc3JyaS1ub2RlcyB3aWxs IHNpbXBseSBpZ25vcmUgdGhlIA0KPiB3aG9sZSBzcnJpIGluZm8gYW5kIGNvbnNpZGVyIHRoZSBw cmVmaXggYXMgaXQgaGFkIG5vIHNpZCBhdCANCj4gYWxsKS4NCj4gDQo+IFtEZWNjYW5dIFllcywg dGhlIGFsdGVybmF0ZSBtZXRob2Qgb25seSBhbGxvd3MgdG8gcmVjdXJzZSB0byBhIHJvdXRlci1p ZCBhZGRyZXNzLiBCdXQsIGRvbid0IHlvdSB0aGluayByb3V0ZXItaWQgYWRkcmVzcyBpcyBlbm91 Z2ggZm9yIGFueSBzZWdtZW50IGxpc3Q/DQoNCg0KYWJzb2x1dGVseSBub3QuIFl1IG5lZWQgdG8g YmUgYWJsZSB0byByZWN1cnNlIG11bHRpcGxlIHByZWZpeGVzIHRvIGRpZmZlcmVudCBhZGRyZXNz ZXMgKGFsbCBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgbm9kZSkuDQoNCg0KPiBFc3BlY2lhbGx5IGZv ciBhbiBTUi1URSBwYXRoIGR5bmFtaWMgY29tcHV0ZWQgYnkgQ1NQRiwgSSB0aGluayBhIG5vbi1y b3V0ZXItaWQgYWRkcmVzcyB3aWxsIGhhdmUgbm8gY2hhbmNlIHRvIHJlcHJlc2VudCBhIG5vZGUt c2VnbWVudC4gSG93ZXZlciwgdGhlIGFsdGVybmF0ZSBtZXRob2Qgc2VlbXMgdG8gYmUgbm90IG11 Y2ggY2xlYW4gdGhhbiBTUlJJIG1ldGhvZCwgZm9yIHRoZSBwb3NzaWJsZSBzaWQgY29uZmxpY3Rp bmcgaW50cm9kdWNlZCBpbiBzaGFyaW5nIHVzZS1jYXNlLCBmcm9tIHRoaXMgcG9pbnQsIHRoZSBT UlJJIG1ldGhvZCBpcyBnb29kLiANCg0KDQpDU1BGIGlzIG5vdCB0aGUgbWFpbiB1c2UgY2FzZSBo ZXJlLg0KDQoNCj4gPiBCVFcsIGFsbCB3ZSBkaXNjdXNzZWQgaXMgU0lEIHJlY3Vyc2l2ZSBidXQg bm90IHNoYXJpbmcsDQo+IA0KPiANCj4gb2YgY291cnNlIGl0IGlzIHNoYXJpbmcuIEFzIGRlZmlu ZWQgaW4gdGhlIGRyYWZ0LCB0aGUgDQo+IGxvY2FsIGxhYmVsIGF0dGFjaGVkIHRvIHRoZSBzcnJp IGluZm8gaXTigJlzIGFuIG9wdGlvbmFsIA0KPiBvcHRpbWl6YXRpb24uIFdpdGhvdXQgdGhlIGxv Y2FsIGxhYmVsLCB5b3Ugd2lsbCBzaGFyZSB0aGUgDQo+IHNhbWUgc2lkIGFtb25nIG11bHRpcGxl IHByZWZpeGVzLiANCj4gDQo+IA0KPiA+IGV2ZW4gdGhlIGZpcnN0IGNhc2UgaW4gdGhpcyBkcmFm dCBpcyBhY3R1YWxseSBub3QgU0lEIHNoYXJpbmcsIG90aGVyd2lzZSBpdCB3aWxsIGJlIGNhcmVk IGJ5IGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24uIA0KPiANCj4gDQo+IE5v LCBpdCBpcyBub3QgYSBjb25mbGljdC4gSGF2aW5nIGEgZGVkaWNhdGVkIHNycmkgDQo+IHJlcG9z aXRvcnkgbWFrZXMgaXQgY2xlYXIuDQo+IA0KPiBbRGVjY2FuXSBPaywgSSBoYXZlIG5vdCBnb3Qg dGhpcyBwb2ludCBiZWZvcmUuIEhvd2V2ZXIsIGlmIHJvdXRlci1pZCBhZGRyZXNzIGlzIGVub3Vn aCwNCg0KDQpyb3V0ZXItSUQgaXMgbm90IGVub3VnaC4NCg0KDQo+IHNpZCBzaGFyaW5nIHNlZW1z IHRvIGJlIG5vdCBzbyBtdWNoIHNpZ25pZmljYW50LCBkbyB5b3UgdGhpbmsgc28/IA0KDQoNCkkg dGhpbmsgdGhlIHNycmkgbWV0aG9kIGlzIHRoZSBjbGVhbmVzdCBhbmQgc2FmZXN0IG9wdGlvbiB0 byBwcm92aWRlIGJvdGg6DQouIHJlY3Vyc2lvbiBvZiBhIHByZWZpeCB0byBhIGRpZmZlcmVudCBz aWQNCi4gc2hhcmluZyB0aGUgc2FtZSBzaWQgYW1vbmcgZGlmZmVyZW50IHByZWZpeGVzDQp3aXRo b3V0IGluY3VycmluZyB3ZWxsIGtub3duIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgYW5kIGNvbmZs aWN0aW5nIGlzc3Vlcy4NCg0Kc3JyaSBpcyBhIGdlbmVyaWMgc29sdXRpb24gYXBwbGljYWJsZSB0 byBhIHZhcmlldHkgb2YgdXNlIGNhc2VzLg0KDQpUaGFua3MuDQpzLg0KDQoNCj4gDQo+IHMuDQo+ IA0KPiANCj4gPiBUaGFua3MgDQo+ID4gRGVjY2FuIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0K PiA+IA0KPiA+ICJTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSIgPHNwcmV2aWRpQGNpc2NvLmNv bT4NCj4gPiAyMDE2LTA4LTIyIDIxOjM4DQo+ID4gDQo+ID4g5pS25Lu25Lq6DQo+ID4gInBlbmcu c2hhb2Z1QHp0ZS5jb20uY24iIDxwZW5nLnNoYW9mdUB6dGUuY29tLmNuPiwNCj4gPiDmioTpgIEN Cj4gPiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCj4gPiDkuLvpopgNCj4gPiBSZTogW3Nw cmluZ10gV0cgYWRvcHRpb24gcmVxdWVzdGVkIGZvciBkcmFmdC1maWxzZmlscy1zcHJpbmctc3It cmVjdXJzaW5nLWluZm8NCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiA+ IE9uIEF1ZyA5LCAyMDE2LCBhdCA1OjU1IEFNLCBwZW5nLnNoYW9mdUB6dGUuY29tLmNuIHdyb3Rl Og0KPiA+ID4gDQo+ID4gPiBPdGhlciBkb2N1bWVudHMgaGF2ZSBhbHJlYWR5IGFkZHJlc3NlZCB0 aGlzIGlzc3VlLA0KPiA+IA0KPiA+IA0KPiA+IEkgZG9u4oCZdCB0aGluayBzby4gQ2FuIHlvdSBw b2ludCB0byB0aGVzZSBkb2N1bWVudHMgPw0KPiA+IA0KPiA+IA0KPiA+ID4gZm9yIGV4YW1wbGUs IHNldCBMLWZsYWcgb2YgUHJlZml4LVNJRCBTdWItVExWIGluIGRyYWZ0LWlldGYtaXNpcy1zZWdt ZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wNSBhbmQgY29udGFpbiBJUHY0IFNvdXJjZSBSb3V0ZXIg SUQgaW4gcmZjNzc5NC4gDQo+ID4gDQo+ID4gDQo+ID4gdGhlIEwgZmxhZyBoYXMgdGhlIHNvbGVs eSBwdXJwb3NlIG9mIGluZGljYXRpbmcgdGhlIHNpZCBjb250YWlucyBhIGxvY2FsIHZhbHVlLiBU eXBpY2FsbHkgaXQgZ29lcyB3aXRoIHRoZSBWIGZsYWcgdGhhdCBpbmRpY2F0ZXMgYSB2YWx1ZSAo aS5lLjogbG9jYWwgbGFiZWwpLg0KPiA+IA0KPiA+IE5vdGhpbmcgaXMgbWVudGlvbmVkIHJlZ2Fy ZGluZyBzaGFyaW5nIHRoZSBzYW1lIHNpZCBhbW9uZyBkaWZmZXJlbnQgc2VydmljZXMuDQo+ID4g DQo+ID4gcy4NCj4gPiANCj4gPiANCj4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBUaGFua3Ms IA0KPiA+ID4gDQo+ID4gPiBEZWNjYW4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAN Cj4gPiA+IA0KPiA+ID4gW3NwcmluZ10gV0cgYWRvcHRpb24gcmVxdWVzdGVkIGZvciBkcmFmdC1m aWxzZmlscy1zcHJpbmctc3ItcmVjdXJzaW5nLWluZm8gDQo+ID4gPiAiSm9obiBHLiBTY3VkZGVy IiA8amdzQGp1bmlwZXIubmV0PiBTdW4sIDI0IEp1bHkgMjAxNiAxMjo1NCBVVENTaG93IGhlYWRl cg0KPiA+ID4gRGVhciBXRywNCj4gPiA+IA0KPiA+ID4gQXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBt ZWV0aW5nLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLXNyLXJlY3Vyc2luZy1pbmZvLiBQbGVhc2UgcmVwbHkgdG8gdGhl IGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQg dG8gd2hldGhlciBvciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBl c3BlY2lhbGx5IGVuY291cmFnZWQgdG8gY29tbWVudC4NCj4gPiA+IA0KPiA+ID4gV2Ugd2lsbCBl bmQgdGhlIGNhbGwgb24gQXVndXN0IDMxLCAyMDE1LiANCj4gPiA+IA0KPiA+ID4gQXV0aG9ycywg cGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS IGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuDQo+ID4gPiANCj4gPiA+ IFRoYW5rcywNCj4gPiA+IA0KPiA+ID4gLS1CcnVubyBhbmQgSm9obg0KPiA+ID4gDQo+ID4gPiAN Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ID4gPiANCj4gPiAN Cj4gPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= From nobody Mon Aug 29 00:10:12 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DEA12D09E for ; Mon, 29 Aug 2016 00:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.749 X-Spam-Level: X-Spam-Status: No, score=-104.749 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTZOxNq74fnQ for ; Mon, 29 Aug 2016 00:10:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 66F7E127071 for ; Mon, 29 Aug 2016 00:10:06 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTP id 45512CBB70E7; Mon, 29 Aug 2016 15:09:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u7T79Nep030736; Mon, 29 Aug 2016 15:09:23 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: , spring@ietf.org MIME-Version: 1.0 X-KeepSent: 7AD760F3:400BA671-4825801E:0026AC03; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: peng.shaofu@zte.com.cn Date: Mon, 29 Aug 2016 15:09:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-08-29 15:09:11, Serialize complete at 2016-08-29 15:09:11 Content-Type: multipart/alternative; boundary="=_alternative 002750974825801E_=" X-MAIL: mse01.zte.com.cn u7T79Nep030736 Archived-At: Subject: Re: [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 07:10:10 -0000 This is a multipart message in MIME format. --=_alternative 002750974825801E_= Content-Type: text/plain; charset="US-ASCII" Support. Thanks, Deccan [spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info "John G. Scudder" Sun, 24 July 2016 12:54 UTCShow header Dear WG, As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. We will end the call on August 31, 2015. Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Thanks, --Bruno and John --=_alternative 002750974825801E_= Content-Type: text/html; charset="US-ASCII" Support.

Thanks,

Deccan


[spring] WG adoption requested for draft-filsfils-spring-sr-recursing-info
"John G. Scudder" <jgs@juniper.net> Sun, 24 July 2016 12:54 UTCShow header

Dear WG,

As we discussed at our meeting, working group adoption has been requested for draft-filsfils-spring-sr-recursing-info. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

We will end the call on August 31, 2015.

Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed.

Thanks,

--Bruno and John
--=_alternative 002750974825801E_=-- From nobody Mon Aug 29 02:07:48 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D8912D1BC; Mon, 29 Aug 2016 02:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7I9uBmF50mN; Mon, 29 Aug 2016 02:07:44 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B88B12D1B2; Mon, 29 Aug 2016 02:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=684; q=dns/txt; s=iport; t=1472461659; x=1473671259; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=t3dcvssVlDi8KCjQZyAyG4z5kNaOifSfc9JWxC82fHw=; b=JVxJCEPFNRj/CqLvu/fjiWTn3iTkvpBGAjARmn7Crjv5K895azy0yxBM enSfgLb5kNrk+EpxTByCag956UZ8BjRdMwyGtF9YdSeQSNZMds+76dZd/ cg5YhdINooKZOHf22odQQ3mWFMJwXgquRDx3PMbfMWaSX7LK1dBocndJK o=; X-IronPort-AV: E=Sophos;i="5.28,595,1464652800"; d="scan'208";a="647125006" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 09:07:37 +0000 Received: from [10.60.210.102] (ams-cfilsfil-8815.cisco.com [10.60.210.102]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7T97au8022506; Mon, 29 Aug 2016 09:07:37 GMT To: "John G.Scudder" , draft-ietf-spring-oam-usecase@ietf.org References: From: Clarence Filsfils Message-ID: <57C3FB58.6070507@cisco.com> Date: Mon, 29 Aug 2016 11:07:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Carlos Pignataro , spring@ietf.org Subject: Re: [spring] IPR for draft-ietf-spring-oam-usecase prior to WGLC X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 09:07:46 -0000 John, I do not know other IPR than what’s already disclosed. Cheers, Clarence On 24-Jul-16 14:46, John G.Scudder wrote: > [re-sending with WG in cc. Please cc WG on your replies, thanks and sorry for the dup.] > > Dear Authors: > > As we discussed at the SPRING meeting, working group last call has been requested for draft-ietf-spring-oam-usecase. Before we begin the WGLC, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. (Please do this even if you've done it before, thanks for your help.) > > As soon as this has been collected from all authors, we'll start the WGLC. > > Thanks, > > --Bruno and John > From nobody Tue Aug 30 10:08:34 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD012B039 for ; Tue, 30 Aug 2016 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 mKlAOk2k2GSc for ; Tue, 30 Aug 2016 10:08:27 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829F212D181 for ; Tue, 30 Aug 2016 10:08:27 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id AF6FDA01A1; Tue, 30 Aug 2016 19:08:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 7F420120075; Tue, 30 Aug 2016 19:08:25 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 19:08:25 +0200 From: To: Marc Binderberger Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Preference Rule Thread-Index: AQHR8hOANibz6gJT2ECqbgGzNN0o4aBhynqw Date: Tue, 30 Aug 2016 17:08:24 +0000 Message-ID: <12561_1472576905_57C5BD89_12561_5795_1_53C29892C857584299CBF5D05346208A0F9A884D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <3616_1467210147_5773D9A3_3616_331_1_53C29892C857584299CBF5D05346208A0F92295D@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10117_1467288584_57750C07_10117_1628_1_53C29892C857584299CBF5D05346208A0F92453A@OPEXCLILM21.corporate.adroot.infra.ftgroup> <381b2391249a4975ac87e7100d56d09f@XCH-ALN-001.cisco.com> <681_1467634028_577A516B_681_14652_1_53C29892C857584299CBF5D05346208A0F92A131@OPEXCLILM21.corporate.adroot.infra.ftgroup> <269896ae1e214e9295130d1999b614c0@XCH-ALN-001.cisco.com> <0039f4f2-e09a-f61c-6089-9a488d8bf2da@nic.dtag.de> <30779_1469709362_5799FC32_30779_217_1_53C29892C857584299CBF5D05346208A0F96DEB2@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20160809005610361624.5ef56c4c@sniff.de> In-Reply-To: <20160809005610361624.5ef56c4c@sniff.de> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Les Ginsberg , Martin Horneffer , "Horneffer, Martin" , "spring@ietf.org" Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Rule X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:08:30 -0000 Hello Marc, Speaking as an individual contributor, and network operator. Please see inline. > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, August 09= , 2016 9:56 AM >=20 > Hello Bruno and spring list experts, >=20 > jumping late into the discussion (sorry). Thanks for the feedback. =20 >=20 > I would see any kind of preference list to handle a conflict to be an > somewhat arbitrary decision. Agreed. St=E9phane has proposed the addition of a "preference" field attached to ma= pping server (advertisements) to allow a network operator to control this p= reference decision, depending on SP rules or current network status (e.g. m= igrations) To increase this capacity for customization, I guess that an option would b= e to extend this preference to other SID advertisements. But I'm not sure that you are really calling for the network operator to ha= ve this flexibility. So I don't think that this comment is really the point= that you want to make. > That is okay for a particular network (assuming > the network operator had a word or two about the rules) but I don't consi= der > this a good idea for a standard to reflect specific designs or > operational/troubleshooting procedures. >=20 > E.g. who is saying that IPv6 should be preferred over IPv4? The working group. You are welcome to contribute. IIRC, this specific point has already been c= hanged based on WG feedback. > What when the > operator's workhorse is still IPv4 traffic and s/he would prefer to sacri= fice > IPv6 to keep IPv4 running? >=20 >=20 > In reality, don't we expect the rule ... >=20 > "Local configuration conflicts can be prevented before they are advert= ised" >=20 > ... to cover the large amount of mistakes?=20 I'm not sure to see why. A priori, I would expect that the more pre-existing configuration/states, t= he more chance to conflict. Given that the network wide states/configuratio= ns is greater (by at least 1 or 2 order of magnitude) compared to the state= /configuration of one device, I'd would tend to expect the opposite. (i.e. = there is more chance to conflict with 100s nodes than with itself) > Then the basic "ignore" policy > would cover the few cases where things went really bad.=20 The basic "ignore policy" would disable the traffic to 100s of PE in case o= f a single SID conflict. I would not call this "cover the few cases where t= hings went really bad". I would call this create a very bad situation, from= one single misconfiguration. > We seem to spend a > lot of time and energy on solving a problem that should be rare (with the > quoted rule above). In addition, to the above discussion regarding "large amount of mistake cov= ered" / "few remaining cases" / "rare" which I don't see the basis for, cou= ld you state how often, in your personal opinion, is it ok to drop the traf= fic to 100s of PE, in a multi-service network carrying Internet, TV, Mobile= , Enterprise VPN services? Just as a hint, how do you propose to call the people needed to resolve the= issue, whether internal to the company, or outsourced or at the vendor? Wh= at about emergency calls which won't be honored? Then, how often do you expect misconfiguration? (or bug, if you are on the = implementation side, even though I would expect that worldwide, across all = vendors and networks, configurations change are more frequent than code cha= nce, hence more test effort is given to code change rather than configurati= on change) Most network operator, pay twice to get link and node redundancy, in order = to protect important communications from a single link or node failure. Whi= le with the "Ignore policy" one single error have the ability to shut down = the whole network or a significant part of it. Indeed, in risk analysis, probability of occurrence is one important point = to consider. But consequences/cost is another important point to consider. = And in the old telco world, some level of consequences may not be considere= d acceptable. e.g. there is usually a limit defined for the number of peopl= e which may be affected by a single failure. When this limit is reached, an= other equipment is deployed to service those additional people, even though= the first equipment had enough capacity.=20 > Basically what I propose is to keep it simple. Hum... "Everything should be made as simple as possible, but no simpler."= =20 Now the problem is to draw the line. (and that's not simple) And there are multiple metrics to consider. Implementation (simplicity) is = one, network operation (simplicity) is another one. And I would note that t= he number of networks is significantly higher than the number of implementa= tions so it may be advantageous to prefer the network operation metric over= the implementation metric. Basically, what I propose is to keep it safe, and not introduce new risks, = especially with massive consequences, compared to existing signaling soluti= ons (e.g. LDP or RSVP-TE) which may be seen as a show stopper for some pers= on (before or after the failure, depending on their anticipations). > At least start simple. _If_ > network operators find during operation that the basic don't-advertise/ig= nore > rule is insufficient then we can still increase the complexity of the > conflict handling procedure (and add a config knob to select the new > procedure). I believe that we are in the process of getting network operator feedback. Regards, Bruno =20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Thu, 28 Jul 2016 12:36:01 +0000, bruno.decraene@orange.com wrote: > > Hi Les, all > > > > As an individual contributor. > > > > As a network operator, I have a slight preference for the older prefere= nce > > rule, and more specifically for the following preference rule: > > 1) PFX source wins over SRMS source > > 2) Between redundant SRMS, operator defined preference (aka weight) > > > > Note however, that for me, this is a lighter preference compared to the > > choice of the policy. Besides, my above preference assumes that the pol= icy > > "Per FEC/Ignore overlap only" be selected. If "Quarantine" were selecte= d, I > > would have a strong preference for the revised preference rule (Larger > > range wins) in order to limit the consequences on the network availabil= ity. > > > > Regarding 1, > > I would assume that before the conflicting advertisement, the network w= as > > running fine. i.e. conflict entries is not the nominal behavior in the > > network, and conflict are detected and reported to the network operator= for > > correction. (e.g. via the yang model, syslog, error message on the term= inal > > (hence in particular the one configuring the conflicting entry...). > > With such assumption, the conflict is likely the result of a > > misconfiguration on one node. Preferring PFX source over SRMS give > > preference to diversity/the majority of the nodes rather than the > > individual (mapping server). In this assumption where a single node is > > misconfigured, preference many advertisement over a single one, maximize > > the number of valid advertisement kept. I agree that this is dependent = on > > the assumption, and another scenario could be that one had mis-program = the > > script configuring the prefix SID on N routers, which would results in N > > simultaneous misconfigurations. > > Additionally, following the principle that the one speaking for himself= is > > probably the best source, I'd be inclined to trust the originator of th= e IP > > prefix, as the reference for the SID to be used. > > > > Regarding 2, > > Some network operation people have expressed a need to control which > > advertisement is preferred, especially to control SID renumbering (e.g= . in > > case of network merge). cf St=E9phane email. Putting this preference lo= wer > > (e.g. after preferring the larger range) would somewhat defeat the goal= or > > make it less predictable for people. > > > > Regards, > > --Bruno > > > >> -----Original Message----- > >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Martin Horn= effer > >> Sent: Friday, July 22, 2016 10:59 AM > >> To: Les Ginsberg (ginsberg); spring@ietf.org > >> Cc: Horneffer, Martin > >> Subject: [spring] draft-ietf-spring-conflict-resolution - Preference R= ule > >> > >> Hi Les, > >> > >> this topic, and this document is in my eyes a very important one. Than= ks > >> a lot for writing and promoting it! > >> > >> During the Berlin WG session you proposed a new preference rule which > >> would make the policy choice easier. You asked for a discussion on the > >> list - more on your slides rather than the existing draft document. > >> > >> As an operator, and as an individual that has insight in more than just > >> one or two IP/MPLS carrier networks, that has the main engineering > >> responsibility for a rather large backbone, and that stays in actual > >> contact with the operational staff and security authorities, I strongly > >> ask you: PLEASE DO NOT CHANGE THE PREFERENCE RULE! > >> > >> The first two elements of the preference rule are, in my eyes, the most > >> important ones of the whole document and must not be changed or droppe= d! > >> 1) PFX source wins over SRMS soucre > >> 2) Smaller range wins > >> > >> Why is this so important? > >> > >> I don't care so much about the _amount_ of traffic that would be > >> affected by a conflict. No amount of traffic lost due to a network > >> design or configuration error is permissible. But I do care about the > >> overall _robustness_ and _security_ of the network. > >> > >> Of course - in terms of security a first approximation would say that > >> segment routing plays within the IGP only, and that the IGP needs to be > >> trusted anyways. It must be secured against the outside. While this is > >> true, I nevertheless would like to differentiate a bit more. > >> > >> For the sake of robustness, and possibly also for security, I would li= ke > >> to apply the following guidelines: > >> a) Effects of local misconfiguration should be as local as possible. > >> b) The more reliable and controllable source should win over a less > >> reliable or controllable one. > >> > >> As I see it, both guidelines lead to a clear preference of PFX sources > >> over SRMS sources. Also the preference for smaller ranges seems to fit. > >> > >> Please do consider environments where more and more formely separate > >> IP/MPLS networks get merged into a single IGP domain. I am seeing this= a > >> lot since a couple of years - several times within DT, but also at oth= er > >> carriers. Sometimes this is done as a complete merge e.g. into a single > >> IS-IS area, sometimes different areas are used, and sometimes seperate > >> IGP instances are maintained but connected. While redistributing from > >> one IGP area or instance to the other you can do more or less filterin= g, > >> but it definitely is being done. Thus, even within the IGP filters and > >> policies are being applied - be it for the sake of security or > >> scalability. While there are well-known mechanisms and tools to filter > >> and control prefix redistribution, I am not so sure about SRMS. > >> > >> > >> I'm going to also write my opinion about the policy selection, but > >> keeping the preference rule really is my main concern. > >> > >> > >> BR, > >> Martin > >> > >> _______________________________________________ > >> spring mailing list > >> spring@ietf.org > >> https://www.ietf.org/mailman/listinfo/spring > > > > > __________________________________________________________________________ > _______________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu > > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme= ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > ___________________________________________________________________________= ______________________________________________ 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.