From stbryant@cisco.com Tue Oct 1 00:29:49 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E1F21F8EB5 for ; Tue, 1 Oct 2013 00:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amw7rPX8MLd0 for ; Tue, 1 Oct 2013 00:29:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A21D021F8F07 for ; Tue, 1 Oct 2013 00:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1380612574; x=1381822174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9BFXQRai40Gd30ILxpihlQvvZTG8pcnHAI530gqT1RM=; b=Gae7YHeR7edauGtXrQj3sm93XBiv+WEdMhpAj6OG9oavbGzgM60B0Vjz 4shaSzP91bfyUhNB+koknjdTOsWpk0LgQRo5WDPvzEMU0bDlHvwzVRJMz 04dAfW3fhK6KIAQcY7qtYLbPWsLhdNmueUECWfwzlnnugk5JMkYsXTNsP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAPp4SlKtJXG8/2dsb2JhbABagwc4wQpKgTEWdIIlAQEBAwEBAQE3MQMLBQkCAgEIEQQBAQEeCQcbDAsUCQgCBA4FiAAGDL0kBI4EgRYzB4MfgQMDl3+BL5BLgySBcQ X-IronPort-AV: E=Sophos;i="4.90,1012,1371081600"; d="scan'208";a="266556219" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2013 07:29:34 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r917TXWD001438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 07:29:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.47]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 02:29:33 -0500 From: "Stewart Bryant (stbryant)" To: Loa Andersson Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: AQFCLD8Q2E8/1HTgDEKeihibO9dHSpr3zAdAgAC/DQCAAAxfwA== Date: Tue, 1 Oct 2013 07:29:32 +0000 Message-ID: <68A0A704-7804-47C2-A83F-358E7B0390F8@cisco.com> References: <52499E3D.6090607@cisco.com> <07c401cebe12$b85c0450$29140cf0$@juniper.net>, <524A292C.7040902@pi.nu> In-Reply-To: <524A292C.7040902@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "afarrel@juniper.net" , "status@ietf.org" Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 07:29:49 -0000 We will look at how to better say this. The intent was that the rules at th= e end of the following paragraph would apply. Stewart Sent from my iPad On 1 Oct 2013, at 02:45, "Loa Andersson" wrote: > Adrian and Stewart, >=20 > what is the value of "conjuntion"? If one group develops a spec > and sends it to the owner of the technology for wglc is that > "in conjunction"? >=20 > /Loa >=20 > On 2013-10-01 03:24, Adrian Farrel wrote: >> And Stewart wanted to say... >>=20 >> http://datatracker.ietf.org/wg/spring/charter/ >>=20 >> *From:*status-bounces@ietf.org [mailto:status-bounces@ietf.org] *On >> Behalf Of *Stewart Bryant >> *Sent:* 30 September 2013 16:52 >> *To:* status@ietf.org >> *Subject:* [Status] Updated charter - version 3 and maybe 4 >>=20 >> Adrian and I took a close look the SPRING charter >>=20 >> and have edited it to get text that we think is more >>=20 >> likely to get through the review cycles. >>=20 >>=20 >>=20 >> The intent of the changes is not change the work >>=20 >> programme, the deliverables or the networks. The >>=20 >> purpose of the changes is to generate what we think >>=20 >> is a viable charter that matches the intent of >>=20 >> this list. >>=20 >>=20 >>=20 >> First we added a summary of what spring is and >>=20 >> why it is needed - that is covered by the first >>=20 >> paragraph, the list of *example* and the following >>=20 >> paragraph. >>=20 >>=20 >>=20 >> We then note that we need bot strict and loose >>=20 >> path specification. >>=20 >>=20 >>=20 >> We then discuss the trust model >>=20 >>=20 >>=20 >> We then say we start with single AS but must be >>=20 >> able to multi-AS >>=20 >>=20 >>=20 >> We call out centralized and distributed path comp. >>=20 >>=20 >>=20 >> We then call out SPRING as an OAM and the need >>=20 >> to manage SPRING. >>=20 >>=20 >>=20 >> Then for data plane, control plane and management >>=20 >> we say, try to use existing, but if that does >>=20 >> not work we specify the process for change. >>=20 >> Note that we talk about data planes in the plural. >>=20 >>=20 >>=20 >> We then provide the deliverable as an edited >>=20 >> version of the delivery plan. >>=20 >>=20 >>=20 >> We do not explicitly call out either MPLS or >>=20 >> IPv6 (or any other data plane), because, >>=20 >>=20 >>=20 >> 1) That emerges from the use cases. >>=20 >> 2) The charter says use the dataplanes (note the >>=20 >> plural) and protocols that are derived from >>=20 >> the use cases. >>=20 >>=20 >>=20 >> The charter therefore set a strong expectation >>=20 >> that whatever dataplanes need to to be used >>=20 >> to satisfy the network need is in scope. >>=20 >>=20 >>=20 >> Comments please >>=20 >>=20 >>=20 >> Stewart >>=20 >>=20 >>=20 >> PS you may see -04 with some cosmetic/layout changes. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From rjs@rob.sh Tue Oct 1 02:41:23 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63A21F9C42 for ; Tue, 1 Oct 2013 02:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv9GHCTshTQF for ; Tue, 1 Oct 2013 02:41:22 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D321F960E for ; Tue, 1 Oct 2013 02:41:18 -0700 (PDT) Received: from [86.189.3.179] (helo=pc0040.btap.btopenzone.com) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VQwR9-0007yN-Pm; Tue, 01 Oct 2013 10:40:11 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Rob Shakir In-Reply-To: <52499E3D.6090607@cisco.com> Date: Tue, 1 Oct 2013 10:41:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09654EFA-47E4-40FA-8757-EE4E9E53F2DB@rob.sh> References: <52499E3D.6090607@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1510) Cc: "status@ietf.org" Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 09:41:23 -0000 Hi Stewart, {SPRING,STATUS}, One thing that has gone missing from the charter is the specification of = where state should be maintained in the solution. I think (and I think = the feelings of the list are) that this is an absolute fundamental of = the architecture, so it would be good to have this specified in the = charter. Kind regards, r. On 30 Sep 2013, at 16:52, Stewart Bryant wrote: > Adrian and I took a close look the SPRING charter > and have edited it to get text that we think is more > likely to get through the review cycles. >=20 > The intent of the changes is not change the work=20 > programme, the deliverables or the networks. The > purpose of the changes is to generate what we think > is a viable charter that matches the intent of > this list. >=20 > First we added a summary of what spring is and=20 > why it is needed - that is covered by the first > paragraph, the list of *example* and the following > paragraph. >=20 > We then note that we need bot strict and loose > path specification. >=20 > We then discuss the trust model >=20 > We then say we start with single AS but must be > able to multi-AS >=20 > We call out centralized and distributed path comp. >=20 > We then call out SPRING as an OAM and the need > to manage SPRING. >=20 > Then for data plane, control plane and management > we say, try to use existing, but if that does > not work we specify the process for change. > Note that we talk about data planes in the plural. >=20 > We then provide the deliverable as an edited > version of the delivery plan. >=20 > We do not explicitly call out either MPLS or > IPv6 (or any other data plane), because,=20 >=20 > 1) That emerges from the use cases. > 2) The charter says use the dataplanes (note the=20 > plural) and protocols that are derived from > the use cases. >=20 > The charter therefore set a strong expectation > that whatever dataplanes need to to be used=20 > to satisfy the network need is in scope. >=20 > Comments please=20 >=20 > Stewart >=20 > PS you may see -04 with some cosmetic/layout changes. >=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From sprevidi@cisco.com Tue Oct 1 03:12:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511F821F9C00 for ; Tue, 1 Oct 2013 03:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRXrmwihSrE1 for ; Tue, 1 Oct 2013 03:12:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67721F937E for ; Tue, 1 Oct 2013 03:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2619; q=dns/txt; s=iport; t=1380622355; x=1381831955; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XnX7SSi/07ZuPpd7bdQcwQySsUY2eqDL7J/8MgREzv4=; b=IWvihspng8vcoVH1E8tKK7jPUuA4WD7eaBdzj1PJUOT1xO/qrp+Zwnnj GBzOIGEAtWtU55/C4y5XXV3PbkDblvPAR6hyatiGbri7oC0H5C21VyJro mRDet29XtXK7klzWGOYh0gjfba7ZgyuDHQmrBLQbAOBrg2FTzwEGxFOfo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAOSeSlKtJXHB/2dsb2JhbABagwc4UsA4SoEzFnSCJQEBAQMBAQEBNzQLBQsCAQgOBAYKFBAnCxcOAgQOBQgTh2UGDLxNBI8eAjEHgx+BAwOpeYMkgio X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="266572673" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 01 Oct 2013 10:12:34 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r91ACYEx025229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 10:12:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 05:12:34 -0500 From: "Stefano Previdi (sprevidi)" To: Rob Shakir Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: AQHOvfUgbfG6PPCbYkeE9yAoTxYd9pnf7KqAgAAIuoA= Date: Tue, 1 Oct 2013 10:12:33 +0000 Message-ID: References: <52499E3D.6090607@cisco.com> <09654EFA-47E4-40FA-8757-EE4E9E53F2DB@rob.sh> In-Reply-To: <09654EFA-47E4-40FA-8757-EE4E9E53F2DB@rob.sh> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <54BD12BEA4936C4A8494B1E8AADCBD7B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" , "Stewart Bryant \(stbryant\)" Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 10:12:40 -0000 I agree. s. On Oct 1, 2013, at 11:41 AM, Rob Shakir wrote: > Hi Stewart, {SPRING,STATUS}, >=20 > One thing that has gone missing from the charter is the specification of = where state should be maintained in the solution. I think (and I think the = feelings of the list are) that this is an absolute fundamental of the archi= tecture, so it would be good to have this specified in the charter. >=20 > Kind regards, > r. >=20 >=20 >=20 > On 30 Sep 2013, at 16:52, Stewart Bryant wrote: >=20 >> Adrian and I took a close look the SPRING charter >> and have edited it to get text that we think is more >> likely to get through the review cycles. >>=20 >> The intent of the changes is not change the work=20 >> programme, the deliverables or the networks. The >> purpose of the changes is to generate what we think >> is a viable charter that matches the intent of >> this list. >>=20 >> First we added a summary of what spring is and=20 >> why it is needed - that is covered by the first >> paragraph, the list of *example* and the following >> paragraph. >>=20 >> We then note that we need bot strict and loose >> path specification. >>=20 >> We then discuss the trust model >>=20 >> We then say we start with single AS but must be >> able to multi-AS >>=20 >> We call out centralized and distributed path comp. >>=20 >> We then call out SPRING as an OAM and the need >> to manage SPRING. >>=20 >> Then for data plane, control plane and management >> we say, try to use existing, but if that does >> not work we specify the process for change. >> Note that we talk about data planes in the plural. >>=20 >> We then provide the deliverable as an edited >> version of the delivery plan. >>=20 >> We do not explicitly call out either MPLS or >> IPv6 (or any other data plane), because,=20 >>=20 >> 1) That emerges from the use cases. >> 2) The charter says use the dataplanes (note the=20 >> plural) and protocols that are derived from >> the use cases. >>=20 >> The charter therefore set a strong expectation >> that whatever dataplanes need to to be used=20 >> to satisfy the network need is in scope. >>=20 >> Comments please=20 >>=20 >> Stewart >>=20 >> PS you may see -04 with some cosmetic/layout changes. >>=20 >>=20 >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From sprevidi@cisco.com Tue Oct 1 03:12:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5522321F9C42 for ; Tue, 1 Oct 2013 03:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.883 X-Spam-Level: X-Spam-Status: No, score=-109.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDtploDvfEJR for ; Tue, 1 Oct 2013 03:12:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 52EAC21F8F07 for ; Tue, 1 Oct 2013 03:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2747; q=dns/txt; s=iport; t=1380622366; x=1381831966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iNhcQaGW7sxpBxunGnNg0ukWXt2KcauetzGYWhVosl4=; b=SNlVI0BNz9TdCXfTyK1n8luTTr/BIgrXiiqlU7zRuxtv/KmlfHVRA386 gQYq4N55qyZoJE4OBiuuOX6INVUbBbsaP/1TF4g17URyvDTUncdW1QA/i 5XZ3L+48xxsafgvC0s+YwZO4QufGHXXiDUKKCz1z/mjvqiEdRlkt16xG5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAMSfSlKtJXG//2dsb2JhbABagwc4RgzAOEqBNBZ0giUBAQEEAQEBawsQAgEIGAokJwslAgQOBQiHfgy8UQSPIDEHgx+BAwOJAYshlVeDJIIq X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="266604048" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2013 10:12:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r91ACM3E006900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Oct 2013 10:12:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 05:12:22 -0500 From: "Stefano Previdi (sprevidi)" To: "Stewart Bryant (stbryant)" Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: AQHOvfUgbfG6PPCbYkeE9yAoTxYd9pnf9VOA Date: Tue, 1 Oct 2013 10:12:21 +0000 Message-ID: References: <52499E3D.6090607@cisco.com> In-Reply-To: <52499E3D.6090607@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <140BCA391E8DB64EA542DFA5EC74D03B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "status@ietf.org" Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 10:12:51 -0000 In the proposed text I read: SPRING should avoid modification to existing data=20 planes in order to remain compatible with existing=20 deployments. When a modification is necessary this=20 must be undertaken in conjunction with the working=20 group responsible for the definition and maintenance=20 of that data plane. Note that a modification to existing data planes may still=20 ensure backward compatibility so the above statement is=20 not correct and I'd rephrase it as: SPRING should avoid modifications to existing data=20 planes that would make them non compatible with=20 existing deployments. When a modification is necessary=20 this must be undertaken in conjunction with the working=20 group responsible for the definition and maintenance=20 of that data plane. s. On Sep 30, 2013, at 5:52 PM, Stewart Bryant wrote: > Adrian and I took a close look the SPRING charter > and have edited it to get text that we think is more > likely to get through the review cycles. >=20 > The intent of the changes is not change the work=20 > programme, the deliverables or the networks. The > purpose of the changes is to generate what we think > is a viable charter that matches the intent of > this list. >=20 > First we added a summary of what spring is and=20 > why it is needed - that is covered by the first > paragraph, the list of *example* and the following > paragraph. >=20 > We then note that we need bot strict and loose > path specification. >=20 > We then discuss the trust model >=20 > We then say we start with single AS but must be > able to multi-AS >=20 > We call out centralized and distributed path comp. >=20 > We then call out SPRING as an OAM and the need > to manage SPRING. >=20 > Then for data plane, control plane and management > we say, try to use existing, but if that does > not work we specify the process for change. > Note that we talk about data planes in the plural. >=20 > We then provide the deliverable as an edited > version of the delivery plan. >=20 > We do not explicitly call out either MPLS or > IPv6 (or any other data plane), because,=20 >=20 > 1) That emerges from the use cases. > 2) The charter says use the dataplanes (note the=20 > plural) and protocols that are derived from > the use cases. >=20 > The charter therefore set a strong expectation > that whatever dataplanes need to to be used=20 > to satisfy the network need is in scope. >=20 > Comments please=20 >=20 > Stewart >=20 > PS you may see -04 with some cosmetic/layout changes. >=20 >=20 >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From adrian@olddog.co.uk Tue Oct 1 03:13:10 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E4021F8F07 for ; Tue, 1 Oct 2013 03:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnHHcwhSru9F for ; Tue, 1 Oct 2013 03:13:05 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9221F9C00 for ; Tue, 1 Oct 2013 03:13:02 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r91ACxe8027827; Tue, 1 Oct 2013 11:12:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r91ACvoo027793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Oct 2013 11:12:58 +0100 From: "Adrian Farrel" To: "'Rob Shakir'" , Date: Tue, 1 Oct 2013 11:12:57 +0100 Message-ID: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6+jsdSVHiGMbhuRO6MICSehYh8uA== Content-Language: en-gb Cc: status@ietf.org Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 10:13:10 -0000 Yeah, good catch. The previous text had gone too far the other way since there is going to be some small amount of state maintained (otherwise forwarding is going to be really hard). I think it is the "per flow state" that will not be needed, and we can add that back in. Adrian > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of > Rob Shakir > Sent: 01 October 2013 10:41 > To: stbryant@cisco.com > Cc: status@ietf.org > Subject: Re: [Status] Updated charter - version 3 and maybe 4 > > Hi Stewart, {SPRING,STATUS}, > > One thing that has gone missing from the charter is the specification of where > state should be maintained in the solution. I think (and I think the feelings of the > list are) that this is an absolute fundamental of the architecture, so it would be > good to have this specified in the charter. > > Kind regards, > r. > > > > On 30 Sep 2013, at 16:52, Stewart Bryant wrote: > > > Adrian and I took a close look the SPRING charter > > and have edited it to get text that we think is more > > likely to get through the review cycles. > > > > The intent of the changes is not change the work > > programme, the deliverables or the networks. The > > purpose of the changes is to generate what we think > > is a viable charter that matches the intent of > > this list. > > > > First we added a summary of what spring is and > > why it is needed - that is covered by the first > > paragraph, the list of *example* and the following > > paragraph. > > > > We then note that we need bot strict and loose > > path specification. > > > > We then discuss the trust model > > > > We then say we start with single AS but must be > > able to multi-AS > > > > We call out centralized and distributed path comp. > > > > We then call out SPRING as an OAM and the need > > to manage SPRING. > > > > Then for data plane, control plane and management > > we say, try to use existing, but if that does > > not work we specify the process for change. > > Note that we talk about data planes in the plural. > > > > We then provide the deliverable as an edited > > version of the delivery plan. > > > > We do not explicitly call out either MPLS or > > IPv6 (or any other data plane), because, > > > > 1) That emerges from the use cases. > > 2) The charter says use the dataplanes (note the > > plural) and protocols that are derived from > > the use cases. > > > > The charter therefore set a strong expectation > > that whatever dataplanes need to to be used > > to satisfy the network need is in scope. > > > > Comments please > > > > Stewart > > > > PS you may see -04 with some cosmetic/layout changes. > > > > > > > > _______________________________________________ > > status mailing list > > status@ietf.org > > https://www.ietf.org/mailman/listinfo/status > > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From rjs@rob.sh Tue Oct 1 03:21:33 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9924821F9C9A for ; Tue, 1 Oct 2013 03:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zz4ucR3U+qw for ; Tue, 1 Oct 2013 03:21:23 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2001:b98:201:101::10:cafe]) by ietfa.amsl.com (Postfix) with ESMTP id C190E21F9C90 for ; Tue, 1 Oct 2013 03:21:10 -0700 (PDT) Received: from [31.55.13.53] (helo=[10.96.2.151]) by cappuccino.rob.sh with esmtpa (Exim 4.72) (envelope-from ) id 1VQx3h-00087x-A3; Tue, 01 Oct 2013 11:20:01 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Rob Shakir In-Reply-To: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> Date: Tue, 1 Oct 2013 11:21:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1510) Cc: status@ietf.org, stbryant@cisco.com Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 10:21:33 -0000 Hi Adrian, Thanks. The key point (for me) is that the architecture MUST NOT require = per-flow state on the mid-points (of course, the head-end of an LSP is = likely to need some form of state relating each path it wants to use). Kind regards, r. On 1 Oct 2013, at 11:12, "Adrian Farrel" wrote: > Yeah, good catch. >=20 > The previous text had gone too far the other way since there is going = to be some > small amount of state maintained (otherwise forwarding is going to be = really > hard). >=20 > I think it is the "per flow state" that will not be needed, and we can = add that > back in. >=20 > Adrian >=20 >> -----Original Message----- >> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On = Behalf Of >> Rob Shakir >> Sent: 01 October 2013 10:41 >> To: stbryant@cisco.com >> Cc: status@ietf.org >> Subject: Re: [Status] Updated charter - version 3 and maybe 4 >>=20 >> Hi Stewart, {SPRING,STATUS}, >>=20 >> One thing that has gone missing from the charter is the specification = of where >> state should be maintained in the solution. I think (and I think the = feelings > of the >> list are) that this is an absolute fundamental of the architecture, = so it > would be >> good to have this specified in the charter. >>=20 >> Kind regards, >> r. >>=20 >>=20 >>=20 >> On 30 Sep 2013, at 16:52, Stewart Bryant wrote: >>=20 >>> Adrian and I took a close look the SPRING charter >>> and have edited it to get text that we think is more >>> likely to get through the review cycles. >>>=20 >>> The intent of the changes is not change the work >>> programme, the deliverables or the networks. The >>> purpose of the changes is to generate what we think >>> is a viable charter that matches the intent of >>> this list. >>>=20 >>> First we added a summary of what spring is and >>> why it is needed - that is covered by the first >>> paragraph, the list of *example* and the following >>> paragraph. >>>=20 >>> We then note that we need bot strict and loose >>> path specification. >>>=20 >>> We then discuss the trust model >>>=20 >>> We then say we start with single AS but must be >>> able to multi-AS >>>=20 >>> We call out centralized and distributed path comp. >>>=20 >>> We then call out SPRING as an OAM and the need >>> to manage SPRING. >>>=20 >>> Then for data plane, control plane and management >>> we say, try to use existing, but if that does >>> not work we specify the process for change. >>> Note that we talk about data planes in the plural. >>>=20 >>> We then provide the deliverable as an edited >>> version of the delivery plan. >>>=20 >>> We do not explicitly call out either MPLS or >>> IPv6 (or any other data plane), because, >>>=20 >>> 1) That emerges from the use cases. >>> 2) The charter says use the dataplanes (note the >>> plural) and protocols that are derived from >>> the use cases. >>>=20 >>> The charter therefore set a strong expectation >>> that whatever dataplanes need to to be used >>> to satisfy the network need is in scope. >>>=20 >>> Comments please >>>=20 >>> Stewart >>>=20 >>> PS you may see -04 with some cosmetic/layout changes. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> status mailing list >>> status@ietf.org >>> https://www.ietf.org/mailman/listinfo/status >>=20 >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status >=20 > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Tue Oct 1 04:18:29 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319E21F9D3A for ; Tue, 1 Oct 2013 04:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvDWnsj9Q8ne for ; Tue, 1 Oct 2013 04:18:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 514F321F999B for ; Tue, 1 Oct 2013 04:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=319; q=dns/txt; s=iport; t=1380626283; x=1381835883; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=r5Jfxw5k0Oi0nSrzzGVQdSd+lLlnlcSpDWIl1lnBePU=; b=lNy6UREDNFHL/+KJDkAnuoi/sn08LItx2aWM+JwdD4aWaXqeHuWwz6EN 8D5/U8hMM+bqo3KdrfHXl+FjkPtlPU1uMEjR/OuhNK4BUsbidt1piKtkB UN563EkEtbrbDGnT53Y6sp71VsB+awqioL1fbSHGZaoYvAtZt8BpSefrc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEWuSlKQ/khM/2dsb2JhbABagwc4wVSBMxZ0giYBAQQ4QBELIRYPCQMCAQIBRRMIAQGIAgy8T49YFoQMA5d/gS+QS4Ml X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="87075888" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 Oct 2013 11:18:01 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r91BHu2f018839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Oct 2013 11:17:58 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r91BHu6A003683; Tue, 1 Oct 2013 12:17:56 +0100 (BST) Message-ID: <524AAF63.5050909@cisco.com> Date: Tue, 01 Oct 2013 12:17:55 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: status@ietf.org References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:18:29 -0000 All Version 4 is posted here: https://datatracker.ietf.org/doc/charter-ietf-spring/ and incorporates changes to address the various comments received overnight. Please remember that you can use http://datatracker.ietf.org/doc/charter-ietf-spring/history/ to see what changes were made. - Stewart From loa@pi.nu Tue Oct 1 04:29:32 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1F21F9F85 for ; Tue, 1 Oct 2013 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWSkUo-Fjfbq for ; Tue, 1 Oct 2013 04:29:25 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DDBC121F9ED1 for ; Tue, 1 Oct 2013 04:28:25 -0700 (PDT) Received: from [192.168.1.6] (unknown [112.208.84.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 47D881802039; Tue, 1 Oct 2013 13:28:23 +0200 (CEST) Message-ID: <524AB1D5.5040508@pi.nu> Date: Tue, 01 Oct 2013 19:28:21 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: status@ietf.org, "stbryant@cisco.com" References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> <524AAF63.5050909@cisco.com> In-Reply-To: <524AAF63.5050909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 11:29:32 -0000 Stewart, this is almost there, but I still have the isue from before. Not being a native English speaker, I have no sense for what conjunction means in this type of text. Looking in dictionaries does not help, it seems to imply some rather weak coordination; like joint wg last call. Anyone that can help out. /Loa On 2013-10-01 19:17, Stewart Bryant wrote: > All > > Version 4 is posted here: > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > and incorporates changes to address the various > comments received overnight. > > Please remember that you can use > > http://datatracker.ietf.org/doc/charter-ietf-spring/history/ > > to see what changes were made. > > - Stewart > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Ruediger.Geib@telekom.de Tue Oct 1 04:50:25 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DA221F9928 for ; Tue, 1 Oct 2013 04:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0A-ivrDAeRv for ; Tue, 1 Oct 2013 04:50:21 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7121F9948 for ; Tue, 1 Oct 2013 04:50:16 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 01 Oct 2013 13:50:14 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 1 Oct 2013 13:50:14 +0200 From: To: Date: Tue, 1 Oct 2013 13:50:13 +0200 Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: Ac6+l/+u5ga3+No6Ts6yvw1V9p+qVAAAy7ww Message-ID: References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> <524AAF63.5050909@cisco.com> In-Reply-To: <524AAF63.5050909@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 11:50:26 -0000 Hi Stewart, thanks. Your latest draft looks fine to me. A question for clarification: The SPRING working group will define procedures that will allow a node to steer a packet along an explicit route using information attached to the packet and without the need for per-flow state information to be held at transit nodes. By that definition it is clear that the WG is chartered to enable extension of IGPs to gain MPLS topology awareness for all nodes within a SPRING domain? If yes, then the above is fine. If not, the charter should include a statement allowing for IGP extensions resulting in MPLS topology awareness of all nodes within a SPRING domain. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Tuesday, October 01, 2013 1:18 PM To: status@ietf.org Subject: Re: [Status] Updated charter - version 3 and maybe 4 All Version 4 is posted here: https://datatracker.ietf.org/doc/charter-ietf-spring/ and incorporates changes to address the various comments received overnight. Please remember that you can use http://datatracker.ietf.org/doc/charter-ietf-spring/history/ to see what changes were made. - Stewart _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Tue Oct 1 05:42:45 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6254521E813B for ; Tue, 1 Oct 2013 05:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plbPRjcXVIja for ; Tue, 1 Oct 2013 05:42:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F34FE21E8103 for ; Tue, 1 Oct 2013 05:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4958; q=dns/txt; s=iport; t=1380631355; x=1381840955; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=NV7ZtYfDaTR5scrJfneKTTqS01174sTJWC7xyDPWbY8=; b=WMU7rj3NM1/94/ZKJ7cqAKvylqWEVPW0nwhdQvxaYoJM0a3SCb6NLJH4 YBL6ibRBPbL8HkAYyWPlWXaWXfsdkZKMGfTORS8aN1duco8emZIB60vne /OMyBH0HLxCUxdtyhzV2ho3I5S+Hkw2OFTUti56Pd4CPDuHhnnyIUKx9B 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHjCSlKQ/khL/2dsb2JhbABagwc4iVi3MkqBLxZ0giUBAQEEAQEBawoBEAsEFAkWDwkDAgECARUwBg0BBQIBAYgCDLxjj1EHhCIDl3+BL5BLgyU X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208,217";a="160199454" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2013 12:42:18 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r91CgEE3031895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 12:42:15 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r91CgCpb009165; Tue, 1 Oct 2013 13:42:12 +0100 (BST) Message-ID: <524AC324.5000103@cisco.com> Date: Tue, 01 Oct 2013 13:42:12 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Loa Andersson References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> <524AAF63.5050909@cisco.com> <524AB1D5.5040508@pi.nu> In-Reply-To: <524AB1D5.5040508@pi.nu> Content-Type: multipart/alternative; boundary="------------080702050104080909010105" Cc: status@ietf.org Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:42:46 -0000 This is a multi-part message in MIME format. --------------080702050104080909010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Loa Ah I see we fixed the first case and then left a hole with: Modification to existing control plane protocols must be done in conjunction with the responsible IETF working group. I have changes this to Modification to existing control plane protocols must be done in conjunction with the responsible IETF working group using the procedure described above. Stewart On 01/10/2013 12:28, Loa Andersson wrote: > Stewart, > > this is almost there, but I still have the isue from before. > > Not being a native English speaker, I have no sense for what > conjunction means in this type of text. Looking in dictionaries > does not help, it seems to imply some rather weak coordination; > like joint wg last call. > > Anyone that can help out. > > /Loa > > On 2013-10-01 19:17, Stewart Bryant wrote: >> All >> >> Version 4 is posted here: >> >> https://datatracker.ietf.org/doc/charter-ietf-spring/ >> >> and incorporates changes to address the various >> comments received overnight. >> >> Please remember that you can use >> >> http://datatracker.ietf.org/doc/charter-ietf-spring/history/ >> >> to see what changes were made. >> >> - Stewart >> _______________________________________________ >> status mailing list >> status@ietf.org >> https://www.ietf.org/mailman/listinfo/status > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------080702050104080909010105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Loa

Ah I  see we fixed the first case and then left a hole
with:
Modification to 
existing control plane protocols must be done in 
conjunction with the responsible IETF working group.
I have changes this to
Modification to 
existing control plane protocols must be done in 
conjunction with the responsible IETF working group
using the procedure described above.
Stewart

On 01/10/2013 12:28, Loa Andersson wrote:
Stewart,

this is almost there, but I still have the isue from before.

Not being a native English speaker, I have no sense for what
conjunction means in this type of text. Looking in dictionaries
does not help, it seems to imply some rather weak coordination;
like joint wg last call.

Anyone that can help out.

/Loa

On 2013-10-01 19:17, Stewart Bryant wrote:
All

Version 4 is posted here:

https://datatracker.ietf.org/doc/charter-ietf-spring/

and incorporates changes to address the various
comments received overnight.

Please remember that you can use

http://datatracker.ietf.org/doc/charter-ietf-spring/history/

to see what changes were made.

- Stewart
_______________________________________________
status mailing list
status@ietf.org
https://www.ietf.org/mailman/listinfo/status 



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------080702050104080909010105-- From aretana@cisco.com Tue Oct 1 05:49:44 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78921E816E for ; Tue, 1 Oct 2013 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDGsbeKnEBTs for ; Tue, 1 Oct 2013 05:49:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBE011E80D3 for ; Tue, 1 Oct 2013 05:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1380631759; x=1381841359; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=LpFaOCLuIRNMU6QRjmFEOzQ4/ntF3q4x5+PLG66ih8o=; b=dREFpR6EzypSjbfL5hKuDRzavY7eaW1clb4l834/IosfpopS3mhgPlli UUO89JcG+txfFHv2J/i/YAqxYcNCnDmyEfEL9rpS8dF327lOktNnvs/wl XtXDcvthmGcz0bpc9tfMd8PPzFkm1b9xYJCxa6KB2NzL9vB91ZdsvYeSw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFANzDSlKtJV2a/2dsb2JhbABagweBCsECgS8WdIInAQQ6LSQBCBIQCwlCFw4BAQQBEggTh2u8UI8gOAqDFYEDA6l5gySCKg X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="266644114" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 01 Oct 2013 12:49:19 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r91CnJ8V013636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Oct 2013 12:49:19 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 1 Oct 2013 07:49:18 -0500 From: "Alvaro Retana (aretana)" To: Loa Andersson , "status@ietf.org" , "Stewart Bryant (stbryant)" Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: Ac6+jsdSI4hsQNhjO0yFeRzknc9yIAAKxLoAAAH7r4AAAF1IgP//01yA Date: Tue, 1 Oct 2013 12:49:16 +0000 Message-ID: In-Reply-To: <524AB1D5.5040508@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <6524C6151C9B9B47B5418877BA90F49A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 12:49:44 -0000 On 10/1/13 7:28 AM, "Loa Andersson" wrote: Loa: Hi! >this is almost there, but I still have the isue from before. > >Not being a native English speaker, I have no sense for what >conjunction means in this type of text. Looking in dictionaries >does not help, it seems to imply some rather weak coordination; >like joint wg last call. I agree with you and think we should be more specific. In looking at the charter there are at least a 2 places where interaction with other WGs is mentioned: [8th paragraph] SPRING should avoid modification to existing.. Any modification of or extension to existing architectures, data planes, or protocols must be carried out in the working groups responsible for the architecture, data plane, or protocol being modified and in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors. ** and ** [third chartered item] o Definition of any new control plane mechanism needed to enable the use cases. Modification to existing control plane protocols must be done in conjunction with the responsible IETF working group. Because both snippets refer to the same topic (modifications to existing things), I interpret "in conjunction" to mean "carried out" in the responsible WGs. Unless agreed in advance (as the 8th paragraph says). I want to then propose a couple of changes: 1. Consistency in the language: we should be specific and write that the work should be carried out in the responsible WG. 2. If the work is to be done in a different WG, then it really means that SPRING will be developing requirements for them (not the solutions). Even though the list of documents does mention requirement documents, it is not clear from the list of chartered items what needs to be done. To avoid repetition, I would like to see the following text instead (starting with the 8th paragraph): SPRING should avoid modification to existing data planes that would make them incompatible with existing deployments. Where possible, existing control and management plane protocols must be used within existing architectures to implement the SPRING function. Any modification of or extension to existing architectures, data planes, or control or management plane protocols must be carried out in the working groups responsible for the architecture, data plane, or control or management plane protocol being modified and in co-ordination with this working group. The work may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors. The SPRING working group is chartered for the following list of items: o Identification and evaluation of use cases for SPRING . These use cases must include a definition of the data plane for the environment in which they are to be deployed. o Definition of requirements and/or any new data plane encodings and procedures, required to implement the use cases. Such procedures must include the necessary security considerations. o Definition of requirements and/or any new control plane mechanism needed to enable the use cases. o Definition of requirements and/or management plane mechanism needed to manage and operate a SPRING enabled network. Changes: =20 1. The text in the 8th paragraph seemed to use "protocols" to refer to both "control plane" and "management plane" protocols, so I explicitly mentioned "control and management plane" to avoid any confusion and make it consistent with the rest of the text. 2. Split the last sentence in the 8th paragraph for readability. 3. The chartered items now read: "Definition of requirements and/or new.." to account for both cases of the work being done somewhere else or in this WG. 4. Took out the "in conjunction" sentence because the 8th paragraph already tells us what to do. Alvaro. From stbryant@cisco.com Tue Oct 1 05:54:02 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3BA11E80E8 for ; Tue, 1 Oct 2013 05:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI3OORdQQmsY for ; Tue, 1 Oct 2013 05:53:57 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E942211E80E7 for ; Tue, 1 Oct 2013 05:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1380632024; x=1381841624; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=biaKEJN9Kkh/rrMtmDycvgTOcnRlHLmXPSp2Ht3gHSE=; b=cNsp3ehXZHJAp5keweLQlw5VrEyfDz8Yt0ijvNQlrtSxnwWOkhm+dMKl NRfNzxFM54OwDW4Wta64F8aYbVv8eEehorysxU1eREz9kfzrz32+uahFc b7rLZA2CTlcPos7XzOQrOkprdTHlUDLZWWX5HEjDPUYXzDNsErWeMhIF0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFPESlKQ/khR/2dsb2JhbABagwc4wQpKgS8WdIIlAQEBBAEBATU0AggCAQwECxEEAQEBCRYIBwkDAgECARUfCQgTAQUCAQGIAgy8RY8vHQUHBhCEDAOXf4EvkEuDJQ X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="87078726" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Oct 2013 12:53:41 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r91Crbjh020174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 12:53:38 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r91Craxs009873; Tue, 1 Oct 2013 13:53:36 +0100 (BST) Message-ID: <524AC5D0.7070007@cisco.com> Date: Tue, 01 Oct 2013 13:53:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <089101cebe8e$cdbfb6d0$693f2470$@olddog.co.uk> <524AAF63.5050909@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: status@ietf.org Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 12:54:02 -0000 On 01/10/2013 12:50, Ruediger.Geib@telekom.de wrote: > Hi Stewart, > > thanks. Your latest draft looks fine to me. > > A question for clarification: > > The SPRING working group will define procedures that > will allow a node to steer a packet along an explicit > route using information attached to the packet and > without the need for per-flow state information to be > held at transit nodes. > > By that definition it is clear that the WG is chartered to enable > extension of IGPs to gain MPLS topology awareness for all nodes > within a SPRING domain? My interpretation of the words is yes. If SPRING considers that to the the best approach, then, subject only to the rules about how they work with other WGs, they are free to pursue the lables in IGP mechanism and/or any other reasonable approach that addresses the use cases. Stewart > > If yes, then the above is fine. If not, the charter should include > a statement allowing for IGP extensions resulting in MPLS topology > awareness of all nodes within a SPRING domain. > > Regards, > > Ruediger > > -----Original Message----- > From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Tuesday, October 01, 2013 1:18 PM > To: status@ietf.org > Subject: Re: [Status] Updated charter - version 3 and maybe 4 > > All > > Version 4 is posted here: > > https://datatracker.ietf.org/doc/charter-ietf-spring/ > > and incorporates changes to address the various > comments received overnight. > > Please remember that you can use > > http://datatracker.ietf.org/doc/charter-ietf-spring/history/ > > to see what changes were made. > > - Stewart > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From stbryant@cisco.com Tue Oct 1 06:07:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6011E8180 for ; Tue, 1 Oct 2013 06:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K812ERFQM-wH for ; Tue, 1 Oct 2013 06:07:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDDB11E819B for ; Tue, 1 Oct 2013 06:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4569; q=dns/txt; s=iport; t=1380632707; x=1381842307; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=x/j0Nt6zXi8+kYE0D9/tkdJs5gOpYR6UDCrbrbNRg6Q=; b=G2zr85Rp9BBQnUuBexPZKOUtjU1CY37lH/b1ovIaD8i+QSIBxPl87iWj OQM8cZM96zbCtTM9AzkB8at1SoWcNYC9S6Q3E+NUZwFhaQBXksDRwjs/F 9fMLxQUbMjB4oS4Z3vmxeLyzL+NBu3eiRxYjQm6Q+ZQ7qkci6aQy22EUk k=; X-IronPort-AV: E=Sophos;i="4.90,1013,1371081600"; d="scan'208";a="160200862" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2013 13:05:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r91D50Xp007917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Oct 2013 13:05:02 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r91D4xJX010812; Tue, 1 Oct 2013 14:05:00 +0100 (BST) Message-ID: <524AC87B.2070406@cisco.com> Date: Tue, 01 Oct 2013 14:04:59 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "status@ietf.org" , Loa Andersson Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:07:40 -0000 I have updated the text in line with this suggestion. I think that this now makes it unambiguous how SPRING will engage with other WGs. Stewart On 01/10/2013 13:49, Alvaro Retana (aretana) wrote: > On 10/1/13 7:28 AM, "Loa Andersson" wrote: > > Loa: > > Hi! > >> this is almost there, but I still have the isue from before. >> >> Not being a native English speaker, I have no sense for what >> conjunction means in this type of text. Looking in dictionaries >> does not help, it seems to imply some rather weak coordination; >> like joint wg last call. > I agree with you and think we should be more specific. In looking at the > charter there are at least a 2 places where interaction with other WGs is > mentioned: > > [8th paragraph] > > SPRING should avoid modification to existing.. Any > modification of or extension to existing architectures, > data planes, or protocols must be carried out in the > working groups responsible for the architecture, data > plane, or protocol being modified and in co-ordination > with this working group, but may be done in this > working group after agreement with all the relevant > WG chairs and responsible Area Directors. > > > ** and ** > > [third chartered item] > > o Definition of any new control plane mechanism > needed to enable the use cases. Modification to > existing control plane protocols must be done in > conjunction with the responsible IETF working group. > > > > Because both snippets refer to the same topic (modifications to existing > things), I interpret "in conjunction" to mean "carried out" in the > responsible WGs. Unless agreed in advance (as the 8th paragraph says). > > I want to then propose a couple of changes: > > 1. Consistency in the language: we should be specific and write that the > work should be carried out in the responsible WG. > > 2. If the work is to be done in a different WG, then it really means that > SPRING will be developing requirements for them (not the solutions). Even > though the list of documents does mention requirement documents, it is > not clear from the list of chartered items what needs to be done. > > > > To avoid repetition, I would like to see the following text instead > (starting with the 8th paragraph): > > SPRING should avoid modification to existing data > planes that would make them incompatible with > existing deployments. Where possible, existing control > and management plane protocols must be used within existing > architectures to implement the SPRING function. Any > modification of or extension to existing architectures, > data planes, or control or management plane protocols must be carried out > in the > working groups responsible for the architecture, data > plane, or control or management plane protocol being modified and in > co-ordination > with this working group. The work may be done in this > working group after agreement with all the relevant > WG chairs and responsible Area Directors. > > The SPRING working group is chartered for the following > list of items: > > o Identification and evaluation of use cases for SPRING . > These use cases must include a definition of the > data plane for the environment in which they are to be > deployed. > > o Definition of requirements and/or any new data plane encodings and > procedures, required to implement the use cases. Such > procedures must include the necessary security > considerations. > > o Definition of requirements and/or any new control plane mechanism > needed to enable the use cases. > > o Definition of requirements and/or management plane mechanism needed to > manage and operate a SPRING enabled network. > > > > Changes: > > 1. The text in the 8th paragraph seemed to use "protocols" to refer to > both "control plane" and "management plane" protocols, so I explicitly > mentioned "control and management plane" to avoid any confusion and make > it consistent with the rest of the text. > > 2. Split the last sentence in the 8th paragraph for readability. > 3. The chartered items now read: "Definition of requirements and/or new.." > to account for both cases of the work being done somewhere else or in this > WG. > 4. Took out the "in conjunction" sentence because the 8th paragraph > already tells us what to do. > > > Alvaro. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From Ruediger.Geib@telekom.de Wed Oct 2 00:35:33 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25D21F9F20 for ; Wed, 2 Oct 2013 00:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCEuqXMxdmsq for ; Wed, 2 Oct 2013 00:35:23 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61421E82C5 for ; Wed, 2 Oct 2013 00:34:40 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 02 Oct 2013 09:34:30 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 2 Oct 2013 09:34:28 +0200 From: To: , Date: Wed, 2 Oct 2013 09:34:27 +0200 Thread-Topic: [Status] Updated charter - version 3 and maybe 4 Thread-Index: Ac6+sE4dz4GEmhEUTwa0XaC6jpWEpQAkTMMg Message-ID: References: <524AC87B.2070406@cisco.com> In-Reply-To: <524AC87B.2070406@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: status@ietf.org, loa@pi.nu Subject: Re: [Status] Updated charter - version 3 and maybe 4 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 02 Oct 2013 07:35:33 -0000 Stewart, Alvaro, thanks again for the effort. I think, the draft is good as it is. Regards, Ruediger -----Original Message----- From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of= Stewart Bryant Sent: Tuesday, October 01, 2013 3:05 PM To: Alvaro Retana (aretana) Cc: status@ietf.org; Loa Andersson Subject: Re: [Status] Updated charter - version 3 and maybe 4 I have updated the text in line with this suggestion. I think that this now makes it unambiguous how SPRING will engage with other WGs. Stewart On 01/10/2013 13:49, Alvaro Retana (aretana) wrote: > On 10/1/13 7:28 AM, "Loa Andersson" wrote: > > Loa: > > Hi! > >> this is almost there, but I still have the isue from before. >> >> Not being a native English speaker, I have no sense for what >> conjunction means in this type of text. Looking in dictionaries >> does not help, it seems to imply some rather weak coordination; >> like joint wg last call. > I agree with you and think we should be more specific. In looking at the > charter there are at least a 2 places where interaction with other WGs is > mentioned: > > [8th paragraph] > > SPRING should avoid modification to existing.. Any > modification of or extension to existing architectures, > data planes, or protocols must be carried out in the > working groups responsible for the architecture, data > plane, or protocol being modified and in co-ordination > with this working group, but may be done in this > working group after agreement with all the relevant > WG chairs and responsible Area Directors. > > > ** and ** > > [third chartered item] > > o Definition of any new control plane mechanism > needed to enable the use cases. Modification to > existing control plane protocols must be done in > conjunction with the responsible IETF working group. > > > > Because both snippets refer to the same topic (modifications to existing > things), I interpret "in conjunction" to mean "carried out" in the > responsible WGs. Unless agreed in advance (as the 8th paragraph says). > > I want to then propose a couple of changes: > > 1. Consistency in the language: we should be specific and write that the > work should be carried out in the responsible WG. > > 2. If the work is to be done in a different WG, then it really means that > SPRING will be developing requirements for them (not the solutions). Eve= n > though the list of documents does mention requirement documents, it is > not clear from the list of chartered items what needs to be done. > > > > To avoid repetition, I would like to see the following text instead > (starting with the 8th paragraph): > > SPRING should avoid modification to existing data > planes that would make them incompatible with > existing deployments. Where possible, existing control > and management plane protocols must be used within existing > architectures to implement the SPRING function. Any > modification of or extension to existing architectures, > data planes, or control or management plane protocols must be carried out > in the > working groups responsible for the architecture, data > plane, or control or management plane protocol being modified and in > co-ordination > with this working group. The work may be done in this > working group after agreement with all the relevant > WG chairs and responsible Area Directors. > > The SPRING working group is chartered for the following > list of items: > > o Identification and evaluation of use cases for SPRING . > These use cases must include a definition of the > data plane for the environment in which they are to be > deployed. > > o Definition of requirements and/or any new data plane encodings and > procedures, required to implement the use cases. Such > procedures must include the necessary security > considerations. > > o Definition of requirements and/or any new control plane mechanism > needed to enable the use cases. > > o Definition of requirements and/or management plane mechanism needed to > manage and operate a SPRING enabled network. > > > > Changes: > > 1. The text in the 8th paragraph seemed to use "protocols" to refer to > both "control plane" and "management plane" protocols, so I explicitly > mentioned "control and management plane" to avoid any confusion and make > it consistent with the rest of the text. > > 2. Split the last sentence in the 8th paragraph for readability. > 3. The chartered items now read: "Definition of requirements and/or new..= " > to account for both cases of the work being done somewhere else or in thi= s > WG. > 4. Took out the "in conjunction" sentence because the 8th paragraph > already tells us what to do. > > > Alvaro. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ status mailing list status@ietf.org https://www.ietf.org/mailman/listinfo/status From stbryant@cisco.com Wed Oct 9 22:24:40 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4421E828B; Wed, 9 Oct 2013 22:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.454 X-Spam-Level: X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QMecKDbpdlP; Wed, 9 Oct 2013 22:24:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A3E1121E8285; Wed, 9 Oct 2013 22:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9246; q=dns/txt; s=iport; t=1381382672; x=1382592272; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=mAsr6cFrHMk3MJluFaY+e3KeAdXmbIz+9ayCJvskeQU=; b=Mp3YJgbLgWEgQCN8Z504ghAzwsplrs1ZkRg1fjBQapK3/uYuOBR/QHO2 IMh8qLGYassVTboIR1NtSUqDhrEZrePpSFXD/J4/PbkZT+A0qz6s89qSs NqllTh/Vfkq+vtaVPb5z/rmSvF1qnOyQm/4+1DCvlHXBf4O/F3wXXR3A2 Q=; X-Files: comment.png : 309 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FANI4VlKQ/khN/2dsb2JhbABagweKD69kiDCBHhZ0gjFzATgBAgEWEQcDAgECAQUBDjcBDAEEAQIBAQKIAJ8GmjyNfIFJhCoDjg+DSgGGKZIBgyWBcA X-IronPort-AV: E=Sophos;i="4.90,1069,1371081600"; d="png'150?scan'150,208,217,150";a="160514259" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2013 05:24:22 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9A5OHH7019147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 05:24:19 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9A5O6bc000468; Thu, 10 Oct 2013 06:24:08 +0100 (BST) Message-ID: <525639F6.8010503@cisco.com> Date: Thu, 10 Oct 2013 06:24:06 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "iesg@ietf.org" , Jari Arkko Content-Type: multipart/alternative; boundary="------------020509030304060705060505" Cc: "status@ietf.org" , "iesg@ietf.org" Subject: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 05:24:40 -0000 This is a multi-part message in MIME format. --------------020509030304060705060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jari SB> Maybe my emailer has lost the email, but this block did not seem SB> to have been mailed out. Early in my AD career I had to deal with the RH0 situation, and we ended up deprecating it. Like we have, for all practical purposes, done with the similar IPv4 mechanisms. What had initially seen as simple and useful tools turned out to be far trickier than people believed. The RH0 deprecation was not merely an IETF action - we deployed emergency patches to many products, worried about people taking down networks, worried about code left in unupdated routers, and so on. I am not opposed to dealing with new and better mechanisms for source routing. We've since then succeeded in defining very constrained source routing models (RH2, for instance) that do not have the same problems. But if we do start the work, we need to take the concerns that torpedoed earlier designs seriously. I'll observe that the charter has no text about the security, denial-of-service, or perimeter security concerns. It also talks about cross-AS designs. And it paints a very powerful, flexible model that supports a number of different applications. The combination of having something that doesn't open up all kinds of vulnerabilities and is still flexible is particularly worrying. SB> I think perhaps you mean challenging, or useful? Certeainly SB> providing the capability with adequate security would be very SB> welcome by many operators. SB> Currently the most developed work is MPLS, and that has exactly SB> the same security model as MPLS has today, i.e. no new SB> security vulnerabilities are introduced in the MPLS case. SB> The expection is that a similar security model, i.e. strict SB> ingress policing, encapsulation and address management SB> would provide a similar level of security for IPv6 SB> SB> I think you are looking for some text of the form: SB> SB> For each data plane technology that SPRING specifies, a security SB> analysis must be provided showing how protection is provided SB> against an attacker disrupting the network by maliciously SB> injecting SPRING packets. SB> SB> Would that address your concern? I'd like to understand what is our plan to address this and and I'd like to see some words in the charter text to talk about this aspect. Also, this text: "Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption other than in MPLS traffic engineering. These applications may require greater flexibility and per packet source imposed routing than can be achieved through the use of the previously defined methods." seems like it is saying that the lack of flexibility caused the mechanisms to be not used. I don't think that is what happened. It was more about the security headaches that they caused to network managers... SB> No the text is saying that SR has not seen wide deployment SB> other than in MPLS traffic engineering, but there are new SB> applications that people now wish to deploy that would SB> benefit from SR. *Comment (2013-10-09)* A colleague commented that service chaining is not listed as a motivation. Should be it be? SB> It is not precluded. We only give examples and if someone wants to SB> propose an SC use case they are welcome. This text seemed somehow odd: "The SPRING working group will not work on any mechanisms for use in networks that forward IPv4 packets." Did you mean that the mechanisms can only work in v6-only networks, or that the mechanisms support only v6 traffic? I think you want the latter, not the former... SB> Yes, SPRING intend to do MPLS and IPv6 SB> We did not find anyone wanting to do IPv4, but just in case. - Stewart --------------020509030304060705060505 Content-Type: multipart/related; boundary="------------090109020000090909080802" --------------090109020000090909080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Jari

SB> Maybe my emailer has lost the email, but this block did not seem
SB> to have been mailed out.


Early in my AD career I had to deal with the RH0 situation, and we ended up
deprecating it. Like we have, for all practical purposes, done with the similar
IPv4 mechanisms. What had initially seen as simple and useful tools turned out
to be far trickier than people believed. The RH0 deprecation was not merely an
IETF action - we deployed emergency patches to many products, worried about
people taking down networks, worried about code left in unupdated routers, and
so on.

I am not opposed to dealing with new and better mechanisms for source routing.
We've since then succeeded in defining very constrained source routing models
(RH2, for instance) that do not have the same problems.

But if we do start the work, we need to take the concerns that torpedoed
earlier designs seriously. I'll observe that the charter has no text about the
security, denial-of-service, or perimeter security concerns. It also talks
about cross-AS designs. And it paints a very powerful, flexible model that
supports a number of different applications. The combination of having
something that doesn't open up all kinds of vulnerabilities and is still
flexible is particularly worrying.

SB> I think perhaps you mean challenging, or useful? Certeainly
SB> providing the capability with adequate security would be very
SB> welcome by many operators.

SB> Currently the most developed work is MPLS, and that has exactly
SB> the same security model as MPLS has today, i.e. no new 
SB> security vulnerabilities are introduced in the MPLS case.
SB> The expection is that a similar security model, i.e. strict
SB> ingress policing, encapsulation and address management 
SB> would provide a similar level of security for IPv6
SB>
SB> I think you are looking for some text of the form:
SB>
SB> For each data plane technology that SPRING specifies, a security
SB> analysis must be provided showing how protection is provided
SB> against an attacker disrupting the network by maliciously
SB> injecting SPRING packets.
SB>
SB> Would that address your concern?


I'd like to understand what is our plan to address this and and I'd like to see
some words in the charter text to talk about this aspect.

Also, this text:

"Source-based routing mechanisms have previously been
specified for network protocols, but have not seen
widespread adoption other than in MPLS traffic engineering.
These applications may require greater flexibility and
per packet source imposed routing than can be achieved
through the use of the previously defined methods."

seems like it is saying that the lack of flexibility caused the mechanisms to
be not used. I don't think that is what happened. It was more about the
security headaches that they caused to network managers...

SB> No the text is saying that SR has not seen wide deployment
SB> other than in MPLS traffic engineering, but there are new
SB> applications that people now wish to deploy that would
SB> benefit from SR.

Comment (2013-10-09) 

A colleague commented that service chaining is not listed as a motivation.
Should be it be?

SB> It is not precluded. We only give examples and if someone wants to
SB> propose an SC use case they are welcome.

This text seemed somehow odd:

  "The SPRING working group will not work on any
  mechanisms for use in networks that forward IPv4 packets."

Did you mean that the mechanisms can only work in v6-only networks, or that the
mechanisms support only v6 traffic? I think you want the latter, not the
former...

SB> Yes, SPRING intend to do MPLS and IPv6
SB> We did not find anyone wanting to do IPv4, but just in case.

- Stewart
--------------090109020000090909080802 Content-Type: image/png; name="comment.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="comment.png" iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAA/ElEQVQoz6WSO27DMAyG0xym h+gFOvUI3YPMOYS7pkOBTjlBllzD74f8lC3Z1pbZ619RjYOoDYIAIUBAAz99pKjF4tFYOQLP r7ubSTU6nizo63sHIQRa3qKuaxRFgSzLkCQJwjCA53lwtnsbptuUUuj7Hl3XoWk4qqoCy3Ok aYIoiuD7PlzXNeZ/4DCMEPLXWl1Y45isobGewKUFKjWerZw32loiz5m2phqOEQSBDVLfzuf+ BGvzOECSudXzNtpclmCMmRprRjr8fdXVxwBhzNwA75vDDC2tdRB8mQRLKQ1E55f18c1axbWg wmmajGWG7voMc7t3Wa61favmB+KXRaNbDO3XAAAAAElFTkSuQmCC --------------090109020000090909080802-- --------------020509030304060705060505-- From sriganeshkini@gmail.com Thu Oct 10 00:26:53 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE821F9C60 for ; Thu, 10 Oct 2013 00:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPyKhE04vo4N for ; Thu, 10 Oct 2013 00:26:53 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id B4CBA21F970E for ; Thu, 10 Oct 2013 00:25:50 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so2135223pbc.36 for ; Thu, 10 Oct 2013 00:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=rYZ4J67m5kfNP14LD81K2kyH8DnjLzDEhHYTlnZFv6A=; b=lT6JPPzZsM5DTpCXV9/D78ZIlbu49NDujCU39fxh1hqx/wl5LaXaJQgs7X1YY6G6wh GDdz7hXIYiwklzbytzvOxfWt18FJSmY1qpqo692+z9MYOzOh+g/QRrUt45EiYSVuTYLS 9DaO0S384Jtz0Wc2YQPKNVotNdAc1DiR2I4iYqRqZfkEAzu9aBi5M+FTiL0oXY5nlHKN YU9iPFiqBh4zm2vbKazixruVti8FBrl8h8TijsbLANNTWhqyLax+uOGqEHZi64HnUYk9 4YpCCC2Eni512ru2tsAEf2QzVDERDJEwuZJxP86i9S6gaXxajOTyGqsWRwNYP/6xu0bo 6IWw== X-Received: by 10.68.253.1 with SMTP id zw1mr12371019pbc.30.1381389945194; Thu, 10 Oct 2013 00:25:45 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Thu, 10 Oct 2013 00:25:15 -0700 (PDT) From: Sriganesh Kini Date: Thu, 10 Oct 2013 00:25:15 -0700 X-Google-Sender-Auth: S2RM7rms5g5AsBfByJjtESez2Xw Message-ID: To: "Stewart Bryant (stbryant)" , "status@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e40b8fada8104e85de8a3 Subject: [Status] Include service application to the packet in the charter (-06) X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 07:26:54 -0000 --047d7b2e40b8fada8104e85de8a3 Content-Type: text/plain; charset=UTF-8 The charter should explicitly mention that services may be applied to the packet along the steered explicit route. The application of services along the explicit route and its subsequent forwarding using information that was in the packet before the service was applied, is fundamentally different than just steering the packet. Suggested modification to charter (-06) The SPRING working group will define procedures that will allow a node to steer a packet along an explicit route using information attached to the packet and without the need for per-flow state information to be held at transit nodes.* The attached information in the packet may additionally specify services that are to be applied to the packet at the intermediate hops of the explicit route.* - Sri --047d7b2e40b8fada8104e85de8a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The charter should explicitly mention that services may be= applied to the packet along the steered explicit route. The application of= services along the explicit route and its subsequent forwarding using info= rmation that was in the packet before the service was applied, is fundament= ally different than just steering the packet.

Suggested modification to charter (-06)

The SPRI=
NG working group will define procedures that=20
will allow a node to steer a packet along an explicit=20
route using information attached to the packet and
without the need for per-flow state information to be
held at transit nodes. The attached information in the packet may additi=
onally specify services that are to be applied to the packet at the interme=
diate hops of the explicit route.


- Sri

--047d7b2e40b8fada8104e85de8a3-- From stbryant@cisco.com Thu Oct 10 04:24:24 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C630621E8114; Thu, 10 Oct 2013 04:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1amyURPaApKf; Thu, 10 Oct 2013 04:24:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC0F921E8108; Thu, 10 Oct 2013 04:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1508; q=dns/txt; s=iport; t=1381404254; x=1382613854; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fgsjgAuBNugIfidDq8xPgS5OXCxlZxgGxayEGm3ZiH0=; b=Uni1JMpTxbqxhb/D7kk3O9Bbb9JqXIUI2rxaDmWwRPLBVoNcHLzzwaLZ OznDiBMYmrj3tHvnsQ4wZMRaOhK4CPSkt5H5ELS6jFaBWxkC68g+8gSo7 uczldG2w9gMYUT/KjwZbXzMCh2K1FE5zuWkAgJK+EAE3RVo51S6zSgAoY w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFADWNVlKQ/khL/2dsb2JhbABZgwc4g3q9eIEhFnSCJQEBAQQjFUABEAsYAgIFFgsCAgkDAgECAUUGDQEHAQGIAgymaZI1gSmMVYFJB4JqgTkDmAWBL5BTgyWBcA X-IronPort-AV: E=Sophos;i="4.90,1071,1371081600"; d="scan'208";a="87314552" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Oct 2013 11:24:12 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9ABO7Fn007386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 11:24:09 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9ABO5Il018358; Thu, 10 Oct 2013 12:24:06 +0100 (BST) Message-ID: <52568E54.1040905@cisco.com> Date: Thu, 10 Oct 2013 12:24:04 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Joel Jaeggli References: <20131010071800.30339.8828.idtracker@ietfa.amsl.com> In-Reply-To: <20131010071800.30339.8828.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Joel Jaeggli's Block on charter-ietf-spring-00-06: (with BLOCK) X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 11:24:25 -0000 On 10/10/2013 08:18, Joel Jaeggli wrote: > Joel Jaeggli has entered the following ballot position for > charter-ietf-spring-00-06: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/charter-ietf-spring/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I am strongly in favor of jari's, statement. > > I would very much like to see the charter address first why it is > believed that now it is feasible to do this when we've been down this > path before. > > > > Joel, Does any of my response to Jari address your concern? Certainly in the case of one of the two technologies under consideration (MPLS) there is no additional security concern. We already impose label stacks that describe indirections on the path of a packet. The requirement is therefore to harden any other technology to the same extent when operating in this mode. Conceptually this should be no worse than applying ingress filtering to a tunnel, or executing IPFRR in an IP network. I proposed some charter text, and the IESG of the time will determine whether the proposed IPv6 arrangement is adequately secure. - Stewart From stbryant@cisco.com Thu Oct 10 04:37:51 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4621E8103 for ; Thu, 10 Oct 2013 04:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjScl+5jzl7n for ; Thu, 10 Oct 2013 04:37:45 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4121E80FB for ; Thu, 10 Oct 2013 04:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=617; q=dns/txt; s=iport; t=1381405044; x=1382614644; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=BB/zLq8rY9sVdAFOU7uBZbLEHTn7sGGPRV0yvJQ1450=; b=KT2fmE7EIcyEel2syowMFOyoVAxVk+kW97Y288NovyIydyGzVHR3Ijrl f47SArguExb4vDC9drSmqDH7tR5Auhrh1OW/5njrDOp2R5z053jMTYpmF z289zN47PEljTacEgJWiLK0VBzMzBoqQ2Tj2ZG+sPcR2vjZZaXdBh6h9v 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwFAAqRVlKQ/khN/2dsb2JhbABZgwfDShZtB4JkfTQCTA0IAQGIApdwhwKaOZNxA5gFkgKDJQ X-IronPort-AV: E=Sophos;i="4.93,466,1378857600"; d="scan'208";a="18189468" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 10 Oct 2013 11:37:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9ABbGij019568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Oct 2013 11:37:18 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9ABbEmE019338; Thu, 10 Oct 2013 12:37:15 +0100 (BST) Message-ID: <52569169.20404@cisco.com> Date: Thu, 10 Oct 2013 12:37:13 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "status@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Status] Charter security text X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 11:37:51 -0000 SPRINGers In response to a number of IESG blocking comments I have updated the security text in the charter to say: "There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so, however administrative and trust boundaries may strip explicit routes from a packet. For each data plane technology that SPRING specifies, a security analysis must be provided showing how protection is provided against an attacker disrupting the network by maliciously injecting SPRING packets." I do not know yet whether this has been accepted. Stewart From narten@us.ibm.com Thu Oct 10 06:54:59 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687A821E8114 for ; Thu, 10 Oct 2013 06:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.197 X-Spam-Level: X-Spam-Status: No, score=-110.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa31DMBmfEm8 for ; Thu, 10 Oct 2013 06:54:51 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6960121E8083 for ; Thu, 10 Oct 2013 06:54:51 -0700 (PDT) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Oct 2013 07:54:50 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 10 Oct 2013 07:54:48 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 48A8A1FF0045; Thu, 10 Oct 2013 07:54:38 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9ADslI8347514; Thu, 10 Oct 2013 07:54:47 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9ADvtno029523; Thu, 10 Oct 2013 07:57:55 -0600 Received: from cichlid.raleigh.ibm.com ([9.49.221.72]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9ADvrA0029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 07:57:55 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9ADsib8019588; Thu, 10 Oct 2013 09:54:44 -0400 Message-Id: <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> To: stbryant@cisco.com In-reply-to: <525639F6.8010503@cisco.com> References: <525639F6.8010503@cisco.com> Comments: In-reply-to Stewart Bryant message dated "Thu, 10 Oct 2013 06:24:06 +0100." Date: Thu, 10 Oct 2013 09:54:44 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13101013-1344-0000-0000-00000251D754 Cc: Jari Arkko , "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 13:54:59 -0000 FWIW, I agree with Jari's base observation about the challenges of source routing in IPv6 (and IPv4). I think a key point is that with IPv6, we are talking (potentially) end-to-end exposure of an attack vector. You can have arbitrary end nodes anywhere on the Internet injecting traffic that potentially directly invokes or impacts source routing. In contrast, one can view MPLS as an L2 technology below IP. That means it's deployed in a much more restricted setting and a normal sender of TCP/IP has a much more restricted attack vector for doing anything that impacts MPLS directly (this is key diffference). That means the threat surface for attacks on MPLS are very different than for IPv6 more generally. What has torpedoed source routing in IP is precisely that it is done at the IP level, where it's difficult to prevent arbitrary attackers from anywhere on the Internet creating mischief. Thomas Stewart Bryant writes: > This is a multi-part message in MIME format. > --===============0522178731649896465== > Content-Type: multipart/alternative; > boundary="------------020509030304060705060505" > This is a multi-part message in MIME format. > --------------020509030304060705060505 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Jari > SB> Maybe my emailer has lost the email, but this block did not seem > SB> to have been mailed out. > Early in my AD career I had to deal with the RH0 situation, and we ended up > deprecating it. Like we have, for all practical purposes, done with the similar > IPv4 mechanisms. What had initially seen as simple and useful tools turned out > to be far trickier than people believed. The RH0 deprecation was not merely an > IETF action - we deployed emergency patches to many products, worried about > people taking down networks, worried about code left in unupdated routers, and > so on. > I am not opposed to dealing with new and better mechanisms for source routing. > We've since then succeeded in defining very constrained source routing models > (RH2, for instance) that do not have the same problems. > But if we do start the work, we need to take the concerns that torpedoed > earlier designs seriously. I'll observe that the charter has no text about the > security, denial-of-service, or perimeter security concerns. It also talks > about cross-AS designs. And it paints a very powerful, flexible model that > supports a number of different applications. The combination of having > something that doesn't open up all kinds of vulnerabilities and is still > flexible is particularly worrying. > SB> I think perhaps you mean challenging, or useful? Certeainly > SB> providing the capability with adequate security would be very > SB> welcome by many operators. > SB> Currently the most developed work is MPLS, and that has exactly > SB> the same security model as MPLS has today, i.e. no new > SB> security vulnerabilities are introduced in the MPLS case. > SB> The expection is that a similar security model, i.e. strict > SB> ingress policing, encapsulation and address management > SB> would provide a similar level of security for IPv6 > SB> > SB> I think you are looking for some text of the form: > SB> > SB> For each data plane technology that SPRING specifies, a security > SB> analysis must be provided showing how protection is provided > SB> against an attacker disrupting the network by maliciously > SB> injecting SPRING packets. > SB> > SB> Would that address your concern? > I'd like to understand what is our plan to address this and and I'd like to see > some words in the charter text to talk about this aspect. > Also, this text: > "Source-based routing mechanisms have previously been > specified for network protocols, but have not seen > widespread adoption other than in MPLS traffic engineering. > These applications may require greater flexibility and > per packet source imposed routing than can be achieved > through the use of the previously defined methods." > seems like it is saying that the lack of flexibility caused the mechanisms to > be not used. I don't think that is what happened. It was more about the > security headaches that they caused to network managers... > SB> No the text is saying that SR has not seen wide deployment > SB> other than in MPLS traffic engineering, but there are new > SB> applications that people now wish to deploy that would > SB> benefit from SR. > *Comment (2013-10-09)* > A colleague commented that service chaining is not listed as a motivation. > Should be it be? > SB> It is not precluded. We only give examples and if someone wants to > SB> propose an SC use case they are welcome. > This text seemed somehow odd: > "The SPRING working group will not work on any > mechanisms for use in networks that forward IPv4 packets." > Did you mean that the mechanisms can only work in v6-only networks, or that the > mechanisms support only v6 traffic? I think you want the latter, not the > former... > SB> Yes, SPRING intend to do MPLS and IPv6 > SB> We did not find anyone wanting to do IPv4, but just in case. > - Stewart > --------------020509030304060705060505 > Content-Type: multipart/related; > boundary="------------090109020000090909080802" > --------------090109020000090909080802 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > > > > > > 
Jari

> SB> Maybe my emailer has lost the email, but this block did not seem
> SB> to have been mailed out.


> Early in my AD career I had to deal with the RH0 situation, and we ended up
> deprecating it. Like we have, for all practical purposes, done with the similar
> IPv4 mechanisms. What had initially seen as simple and useful tools turned out
> to be far trickier than people believed. The RH0 deprecation was not merely an
> IETF action - we deployed emergency patches to many products, worried about
> people taking down networks, worried about code left in unupdated routers, and
> so on.

> I am not opposed to dealing with new and better mechanisms for source routing.
> We've since then succeeded in defining very constrained source routing models
> (RH2, for instance) that do not have the same problems.

> But if we do start the work, we need to take the concerns that torpedoed
> earlier designs seriously. I'll observe that the charter has no text about the
> security, denial-of-service, or perimeter security concerns. It also talks
> about cross-AS designs. And it paints a very powerful, flexible model that
> supports a number of different applications. The combination of having
> something that doesn't open up all kinds of vulnerabilities and is still
> flexible is particularly worrying.

> SB> I think perhaps you mean challenging, or useful? Certeainly
> SB> providing the capability with adequate security would be very
> SB> welcome by many operators.

> SB> Currently the most developed work is MPLS, and that has exactly
> SB> the same security model as MPLS has today, i.e. no new 
> SB> security vulnerabilities are introduced in the MPLS case.
> SB> The expection is that a similar security model, i.e. strict
> SB> ingress policing, encapsulation and address management 
> SB> would provide a similar level of security for IPv6
> SB>
> SB> I think you are looking for some text of the form:
> SB>
> SB> For each data plane technology that SPRING specifies, a security
> SB> analysis must be provided showing how protection is provided
> SB> against an attacker disrupting the network by maliciously
> SB> injecting SPRING packets.
> SB>
> SB> Would that address your concern?


> I'd like to understand what is our plan to address this and and I'd like to see
> some words in the charter text to talk about this aspect.

> Also, this text:

> "Source-based routing mechanisms have previously been
> specified for network protocols, but have not seen
> widespread adoption other than in MPLS traffic engineering.
> These applications may require greater flexibility and
> per packet source imposed routing than can be achieved
> through the use of the previously defined methods."

> seems like it is saying that the lack of flexibility caused the mechanisms to
> be not used. I don't think that is what happened. It was more about the
> security headaches that they caused to network managers...

> SB> No the text is saying that SR has not seen wide deployment
> SB> other than in MPLS traffic engineering, but there are new
> SB> applications that people now wish to deploy that would
> SB> benefit from SR. 

>
>

Comment (2013-10-09) src="cid:part1.06060801.06090207@cisco.com" alt="" height="12" > width="14">

> 
A colleague commented that service chaining is not listed as a motivation.
> Should be it be?

> SB> It is not precluded. We only give examples and if someone wants to
> SB> propose an SC use case they are welcome.

> This text seemed somehow odd:

>   "The SPRING working group will not work on any
>   mechanisms for use in networks that forward IPv4 packets."

> Did you mean that the mechanisms can only work in v6-only networks, or that the
> mechanisms support only v6 traffic? I think you want the latter, not the
> former...

> SB> Yes, SPRING intend to do MPLS and IPv6
> SB> We did not find anyone wanting to do IPv4, but just in case.

> - Stewart

>
> > > --------------090109020000090909080802 > Content-Type: image/png; > name="comment.png" > Content-Transfer-Encoding: base64 > Content-ID: > Content-Disposition: inline; > filename="comment.png" > iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAA/ElEQVQoz6WSO27DMAyG0xym > h+gFOvUI3YPMOYS7pkOBTjlBllzD74f8lC3Z1pbZ619RjYOoDYIAIUBAAz99pKjF4tFYOQLP > r7ubSTU6nizo63sHIQRa3qKuaxRFgSzLkCQJwjCA53lwtnsbptuUUuj7Hl3XoWk4qqoCy3Ok > aYIoiuD7PlzXNeZ/4DCMEPLXWl1Y45isobGewKUFKjWerZw32loiz5m2phqOEQSBDVLfzuf+ > BGvzOECSudXzNtpclmCMmRprRjr8fdXVxwBhzNwA75vDDC2tdRB8mQRLKQ1E55f18c1axbWg > wmmajGWG7voMc7t3Wa61favmB+KXRaNbDO3XAAAAAElFTkSuQmCC > --------------090109020000090909080802-- > --------------020509030304060705060505-- > --===============0522178731649896465== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status > --===============0522178731649896465==-- From stbryant@cisco.com Thu Oct 10 07:54:28 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1421E809F; Thu, 10 Oct 2013 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbPcY1O7H45O; Thu, 10 Oct 2013 07:54:14 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3921E8090; Thu, 10 Oct 2013 07:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2625; q=dns/txt; s=iport; t=1381416851; x=1382626451; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+7gGrgeWannTRamXs5+6QufuK8gO5VE1v4CBcPyKQNM=; b=VF3G23wGI4hZgPurQEWXTelxz4d4ZJb7tPP0ZFtvbvjmA6IZhXtHJseV NkgkGQYX4vks1PquiiIWbKBQ7hbYDX67F7D+KSSg/f20Rz6ACfpQ61g19 1SgF5HZUFDC2uW+p+RFtsVie+SE77gkXslsGrI9uHPUz6zLdmAWKBeu5o 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAAK/VlKQ/khM/2dsb2JhbABZgwc4wXqBIhZ0giUBAQEEOEABEAsYCRYPCQMCAQIBRQYNAQUCAQGIAgy5XI1+gUkHhCMDmAWBL5BTgyWBcA X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="18669121" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2013 14:54:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9AEs5K5009804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 14:54:07 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AEs2vl003528; Thu, 10 Oct 2013 15:54:03 +0100 (BST) Message-ID: <5256BF89.5010402@cisco.com> Date: Thu, 10 Oct 2013 15:54:01 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: joel jaeggli References: <20131010071800.30339.8828.idtracker@ietfa.amsl.com> <52568E54.1040905@cisco.com> <356E1E7B-8193-40C5-A522-CBA37B936A33@bogus.com> In-Reply-To: <356E1E7B-8193-40C5-A522-CBA37B936A33@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Joel Jaeggli's Block on charter-ietf-spring-00-06: (with BLOCK) X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 14:54:29 -0000 On 10/10/2013 15:43, joel jaeggli wrote: > On Oct 10, 2013, at 4:24 AM, Stewart Bryant wrote: > >> On 10/10/2013 08:18, Joel Jaeggli wrote: >>> Joel Jaeggli has entered the following ballot position for >>> charter-ietf-spring-00-06: Block >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/charter-ietf-spring/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >>> >>> I am strongly in favor of jari's, statement. >>> >>> I would very much like to see the charter address first why it is >>> believed that now it is feasible to do this when we've been down this >>> path before. >>> >>> >>> >>> >> Joel, >> >> Does any of my response to Jari address your concern? > somewhat > >> Certainly in the case of one of the two technologies under consideration >> (MPLS) there is no additional security concern. We already impose >> label stacks that describe indirections on the path of a packet. > It's a property of MPLS that you push the LSP onto a packet at ingress. so specifying the LSP aligns nicely with that model. > >> The requirement is therefore to harden any other technology to the >> same extent when operating in this mode. Conceptually this should >> be no worse than applying ingress filtering to a tunnel, or >> executing IPFRR in an IP network. > Initial work will focus on SPRING within in a single AS, > however design decisions must not preclude operation > of SPRING across AS boundaries. > > It's not just an ingress problem at point, it includes transitive trust because, using MPLS as an example and the RH0 problem as a whipping boy it's hard to do loop detection if by the time the source routed packet arrives at your spring router if half the labels are already popped off. applying policy between operators may require looking all the way down the label stack or at the entire source route rather than just at the top one/next hop and so on. > Of a trust model that says if the outer label/address is good the path is good. One application for this is where one partly owns both AS, for example DC. In any case I think that what you are saying is that the hurdle is high, but that should not preclude the work. Stewart From joelja@bogus.com Thu Oct 10 07:43:42 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DD021F9C99; Thu, 10 Oct 2013 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCoxcglSbV5T; Thu, 10 Oct 2013 07:43:38 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6422B11E8170; Thu, 10 Oct 2013 07:43:38 -0700 (PDT) Received: from [192.168.1.11] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9AEhP9F049776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Oct 2013 14:43:25 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_05010AB1-533C-423A-9966-B0C07F5E0EBA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: joel jaeggli In-Reply-To: <52568E54.1040905@cisco.com> Date: Thu, 10 Oct 2013 07:43:20 -0700 Message-Id: <356E1E7B-8193-40C5-A522-CBA37B936A33@bogus.com> References: <20131010071800.30339.8828.idtracker@ietfa.amsl.com> <52568E54.1040905@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 10 Oct 2013 14:43:26 +0000 (UTC) X-Mailman-Approved-At: Thu, 10 Oct 2013 08:00:57 -0700 Cc: "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Joel Jaeggli's Block on charter-ietf-spring-00-06: (with BLOCK) X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 14:43:42 -0000 --Apple-Mail=_05010AB1-533C-423A-9966-B0C07F5E0EBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 10, 2013, at 4:24 AM, Stewart Bryant wrote: > On 10/10/2013 08:18, Joel Jaeggli wrote: >> Joel Jaeggli has entered the following ballot position for >> charter-ietf-spring-00-06: Block >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/charter-ietf-spring/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> BLOCK: >> = ---------------------------------------------------------------------- >>=20 >> I am strongly in favor of jari's, statement. >>=20 >> I would very much like to see the charter address first why it is >> believed that now it is feasible to do this when we've been down this >> path before. >>=20 >>=20 >>=20 >>=20 > Joel, >=20 > Does any of my response to Jari address your concern? somewhat >=20 > Certainly in the case of one of the two technologies under = consideration > (MPLS) there is no additional security concern. We already impose > label stacks that describe indirections on the path of a packet. It's a property of MPLS that you push the LSP onto a packet at ingress. = so specifying the LSP aligns nicely with that model. >=20 > The requirement is therefore to harden any other technology to the > same extent when operating in this mode. Conceptually this should > be no worse than applying ingress filtering to a tunnel, or > executing IPFRR in an IP network. Initial work will focus on SPRING within in a single AS,=20 however design decisions must not preclude operation=20 of SPRING across AS boundaries. It's not just an ingress problem at point, it includes transitive trust = because, using MPLS as an example and the RH0 problem as a whipping boy = it's hard to do loop detection if by the time the source routed packet = arrives at your spring router if half the labels are already popped off. = applying policy between operators may require looking all the way down = the label stack or at the entire source route rather than just at the = top one/next hop and so on. > I proposed some charter text, and the IESG of the time will determine > whether the proposed IPv6 arrangement is adequately secure. >=20 > - Stewart >=20 --Apple-Mail=_05010AB1-533C-423A-9966-B0C07F5E0EBA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJWvQgACgkQ8AA1q7Z/VrI3eACffv0+Cq7thTro6aNZWkvTk9p6 2RQAnjJyJ1NFwas54xTLlqXc23wrQq0i =NJBq -----END PGP SIGNATURE----- --Apple-Mail=_05010AB1-533C-423A-9966-B0C07F5E0EBA-- From stbryant@cisco.com Thu Oct 10 08:07:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946CE21F9D68; Thu, 10 Oct 2013 08:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CIVEkBLKnk7; Thu, 10 Oct 2013 08:07:10 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3D91221F9E1D; Thu, 10 Oct 2013 08:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1381417615; x=1382627215; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nRqP5CRo3KMCEGtBLxrJsw/YgULe130yrcybSn4rkt8=; b=Do0x3KDhAOhRRHepUV9bagx7uzRG4G+RXeP/0wMbdf8/KttWogSHjD2o DthSfBXQv8fopknGonVLz03hD3WmXsNpssqzvciAyJX8ZRylc5ATzGpug u7SBBypzjIeGE0XTDm8MXrOnJSYvNvse1LdH2dn887k9Ac1vst65iMTnP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAD7BVlKQ/khL/2dsb2JhbABZgwe/MIMDgSIWdIIlAQEBBDhAARALGAkWDwkDAgECAUUGDQEHAQGIArlpj0cHhCMDmAWSAoMl X-IronPort-AV: E=Sophos;i="4.90,1072,1371081600"; d="scan'208";a="18669483" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2013 15:06:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9AF6noX008310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 15:06:51 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AF6lAq004714; Thu, 10 Oct 2013 16:06:48 +0100 (BST) Message-ID: <5256C286.9050805@cisco.com> Date: Thu, 10 Oct 2013 16:06:46 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Narten References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> In-Reply-To: <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jari Arkko , "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:07:17 -0000 On 10/10/2013 14:54, Thomas Narten wrote: > FWIW, I agree with Jari's base observation about the challenges of > source routing in IPv6 (and IPv4). > > I think a key point is that with IPv6, we are talking (potentially) > end-to-end exposure of an attack vector. You can have arbitrary end > nodes anywhere on the Internet injecting traffic that potentially > directly invokes or impacts source routing. In contrast, one can view > MPLS as an L2 technology below IP. That means it's deployed in a much > more restricted setting and a normal sender of TCP/IP has a much more > restricted attack vector for doing anything that impacts MPLS directly > (this is key diffference). That means the threat surface for attacks > on MPLS are very different than for IPv6 more generally. > > What has torpedoed source routing in IP is precisely that it is done > at the IP level, where it's difficult to prevent arbitrary attackers > from anywhere on the Internet creating mischief. > > Thomas Thomas My point is that just because it is challenging, does not mean we should accept the challenge if the use case is there. What is required is charter text that sets the bar appropriately. Stewart From joelja@bogus.com Thu Oct 10 08:20:01 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AAE11E818B; Thu, 10 Oct 2013 08:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gFZaPKyCzTd; Thu, 10 Oct 2013 08:19:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0111E817D; Thu, 10 Oct 2013 08:19:41 -0700 (PDT) Received: from [192.168.1.11] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9AFJb7u050362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Oct 2013 15:19:38 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_35F2DE48-41F5-47F3-9C4B-A5AAD50B726E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: joel jaeggli In-Reply-To: <5256BF89.5010402@cisco.com> Date: Thu, 10 Oct 2013 08:19:34 -0700 Message-Id: <0809D257-4A4E-491C-BEE9-CEE82FDA2C0D@bogus.com> References: <20131010071800.30339.8828.idtracker@ietfa.amsl.com> <52568E54.1040905@cisco.com> <356E1E7B-8193-40C5-A522-CBA37B936A33@bogus.com> <5256BF89.5010402@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 10 Oct 2013 15:19:38 +0000 (UTC) Cc: "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Joel Jaeggli's Block on charter-ietf-spring-00-06: (with BLOCK) X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 15:20:02 -0000 --Apple-Mail=_35F2DE48-41F5-47F3-9C4B-A5AAD50B726E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 10, 2013, at 7:54 AM, Stewart Bryant wrote: > On 10/10/2013 15:43, joel jaeggli wrote: >> On Oct 10, 2013, at 4:24 AM, Stewart Bryant = wrote: >>=20 >>> On 10/10/2013 08:18, Joel Jaeggli wrote: >>>> Joel Jaeggli has entered the following ballot position for >>>> charter-ietf-spring-00-06: Block >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/charter-ietf-spring/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> BLOCK: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I am strongly in favor of jari's, statement. >>>>=20 >>>> I would very much like to see the charter address first why it is >>>> believed that now it is feasible to do this when we've been down = this >>>> path before. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>> Joel, >>>=20 >>> Does any of my response to Jari address your concern? >> somewhat >>=20 >>> Certainly in the case of one of the two technologies under = consideration >>> (MPLS) there is no additional security concern. We already impose >>> label stacks that describe indirections on the path of a packet. >> It's a property of MPLS that you push the LSP onto a packet at = ingress. so specifying the LSP aligns nicely with that model. >>=20 >>> The requirement is therefore to harden any other technology to the >>> same extent when operating in this mode. Conceptually this should >>> be no worse than applying ingress filtering to a tunnel, or >>> executing IPFRR in an IP network. >> Initial work will focus on SPRING within in a single AS, >> however design decisions must not preclude operation >> of SPRING across AS boundaries. >>=20 >> It's not just an ingress problem at point, it includes transitive = trust because, using MPLS as an example and the RH0 problem as a = whipping boy it's hard to do loop detection if by the time the source = routed packet arrives at your spring router if half the labels are = already popped off. applying policy between operators may require = looking all the way down the label stack or at the entire source route = rather than just at the top one/next hop and so on. >>=20 >=20 > Of a trust model that says if the outer label/address is good the path > is good. >=20 > One application for this is where one partly owns both AS, for example > DC. agree I have a few dozen ASNs employeed in my environment ;) > In any case I think that what you are saying is that the hurdle is = high, > but that should not preclude the work. yes. >=20 > Stewart >=20 >=20 --Apple-Mail=_35F2DE48-41F5-47F3-9C4B-A5AAD50B726E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJWxYYACgkQ8AA1q7Z/VrIb0ACeL2l99nsU8PfCKf3KyTU7JqMr tEYAmwa6lTjsdGyn7jaUukwRcofKINet =AzJ+ -----END PGP SIGNATURE----- --Apple-Mail=_35F2DE48-41F5-47F3-9C4B-A5AAD50B726E-- From rraszuk@gmail.com Thu Oct 10 08:53:38 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79A121E8056 for ; Thu, 10 Oct 2013 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCw0+HGc-VJJ for ; Thu, 10 Oct 2013 08:53:38 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70B21E812F for ; Thu, 10 Oct 2013 08:53:38 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id x13so5588404ief.1 for ; Thu, 10 Oct 2013 08:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wmSVULC023ZesPEtVkLWHd3/NzwqfYsBGfgsl1brEZs=; b=vxy+fKnQt7OM+63vkrC6AJuv8af0Fl31Um494kYt8nbacxuYvROwLno/Z2T5gfu/lg 5sXy0OLkdCoCcfQbhybchHXYtNNYvc9M26H6PNP53L8ptSlfrTM9jKSvWGTVgfvBhb+v 6bocDUKXXLcx/wFbWkYxnrcV6qKIDXRgX4WiOTfy/nLCO9wLoWxdwDEryULb3iy+VpRe qFXvi7LP1N/5iBtqJ4E41NBr8F7MBtLKUUMEjtIu/+uqekrJKCa81iDKm6gr69VSTkmE WfoV2xG86iEl9ymZhvgwfNrUjJEwBpwberBTkhQfwXXwdZEb3wRMKmv+Oe1v1IWZjn1I j4mg== MIME-Version: 1.0 X-Received: by 10.42.46.80 with SMTP id j16mr728063icf.94.1381420417532; Thu, 10 Oct 2013 08:53:37 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 08:53:37 -0700 (PDT) In-Reply-To: <52569169.20404@cisco.com> References: <52569169.20404@cisco.com> Date: Thu, 10 Oct 2013 17:53:37 +0200 X-Google-Sender-Auth: WciMSkLzoTaGhInqKzJ6aRkujOg Message-ID: From: Robert Raszuk To: "stbryant@cisco.com" Content-Type: text/plain; charset=ISO-8859-1 Cc: "status@ietf.org" Subject: Re: [Status] Charter security text X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 15:53:39 -0000 All, On the topic of MPLS vs IPv6 - one being L2 hence more secure then the other (L3) I would like to observe that any decently managed network would already today prohibit to accept any external packets which have as destination an infrastructure address of such network. That is the basic protection scheme against DOS/DDOS attacks to the infrastructure. When such packet is detected it should be dropped - not "stripped from explicit routes" like the above charter update would tend to suggest. As some may recall in the past we have been working on automating such ACLs installation based in internal IGP addresses on all border routers under same administrative domain within single AS or number of ASes to ease operational burden. Not sure if all vendors support such automation today. I think what needs to be understood that segment routing is not internet wide source routing technology. It is carefully crafted path engineering and packet encapsulation technique within controlled set of domains which really do not compare to the original issues and security concerns of source routing. Best, R. On Thu, Oct 10, 2013 at 1:37 PM, Stewart Bryant wrote: > SPRINGers > > In response to a number of IESG blocking comments I have updated > the security text in the charter to say: > > "There is an assumed trust model such that any node > imposing an explicit route on a packet is assumed to > be allowed to do so, however administrative and trust > boundaries may strip explicit routes from a packet. > For each data plane technology that SPRING specifies, > a security analysis must be provided showing how protection > is provided against an attacker disrupting the network by > maliciously injecting SPRING packets." > > I do not know yet whether this has been accepted. > > Stewart > _______________________________________________ > status mailing list > status@ietf.org > https://www.ietf.org/mailman/listinfo/status From jari.arkko@piuha.net Thu Oct 10 09:39:30 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F195521E8117; Thu, 10 Oct 2013 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EZb4TQOwPWA; Thu, 10 Oct 2013 09:39:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9121E813F; Thu, 10 Oct 2013 09:39:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D0EF12CEB1; Thu, 10 Oct 2013 19:39:23 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOfxGv0pFg2s; Thu, 10 Oct 2013 19:39:23 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 419912CCC1; Thu, 10 Oct 2013 19:39:23 +0300 (EEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> Date: Thu, 10 Oct 2013 19:39:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Thu, 10 Oct 2013 10:02:35 -0700 Cc: "iesg@ietf.org" , "status@ietf.org" , stbryant@cisco.com Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 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, 10 Oct 2013 16:39:30 -0000 Thomas, > I think a key point is that with IPv6, we are talking (potentially) > end-to-end exposure of an attack vector. You can have arbitrary end > nodes anywhere on the Internet injecting traffic that potentially > directly invokes or impacts source routing. In contrast, one can view > MPLS as an L2 technology below IP. That means it's deployed in a much > more restricted setting and a normal sender of TCP/IP has a much more > restricted attack vector for doing anything that impacts MPLS directly > (this is key diffference). That means the threat surface for attacks > on MPLS are very different than for IPv6 more generally. Yes - a good point. That is one of those restricted cases where it is = possible to provide a reasonably secure solution. But my understanding is that SPRING was at IPv6 layer as well as on MPLS = layer=85 although the charter does not explicitly say it. Just that it = is not IPv4=85 If SPRING is expected to run at the IPv6 layer, what is the plan to = contain the vulnerability? Jari From stbryant@cisco.com Thu Oct 10 10:35:17 2013 Return-Path: X-Original-To: status@ietfa.amsl.com Delivered-To: status@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C2721E8117; Thu, 10 Oct 2013 10:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU1hFTz+yDSM; Thu, 10 Oct 2013 10:35:11 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 07F3B21E8116; Thu, 10 Oct 2013 10:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6096; q=dns/txt; s=iport; t=1381426481; x=1382636081; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=gJUavXFfv1HSz0EN64YVsk603SNL9XnrnglqzXErRyI=; b=ANCI2GWDTbHbO70fEdiCYYLZy2CMOVIu4tKFt4rHduRrazjJNQ8vZZpP /zuL9gbjqYwGC4RHERTvOsgPubA1abX/pawKK5MJVbrtjr8B7WLONFhwa D8ED8YUeW7g65UlYhKcouqFo6D+odQsGkK3mXPNo746WPOy4fMj0kszI+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFADLkVlKQ/khM/2dsb2JhbABZgweKD7UigwOBIxZ0giUBAQEEeAEQCxgJFg8JAwIBAgFFBg0BBwEBF4druiGPRweEIwOYBZICgyU X-IronPort-AV: E=Sophos;i="4.90,1073,1371081600"; d="scan'208,217";a="87322232" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Oct 2013 17:34:39 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9AHYYpG024465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 17:34:35 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AHYVXb014135; Thu, 10 Oct 2013 18:34:32 +0100 (BST) Message-ID: <5256E527.1030806@cisco.com> Date: Thu, 10 Oct 2013 18:34:31 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jari Arkko References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> In-Reply-To: <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> Content-Type: multipart/alternative; boundary="------------060107010108040007010906" Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06 X-BeenThere: status@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:35:18 -0000 This is a multi-part message in MIME format. --------------060107010108040007010906 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 10/10/2013 17:39, Jari Arkko wrote: > Thomas, > >> I think a key point is that with IPv6, we are talking (potentially) >> end-to-end exposure of an attack vector. You can have arbitrary end >> nodes anywhere on the Internet injecting traffic that potentially >> directly invokes or impacts source routing. In contrast, one can view >> MPLS as an L2 technology below IP. That means it's deployed in a much >> more restricted setting and a normal sender of TCP/IP has a much more >> restricted attack vector for doing anything that impacts MPLS directly >> (this is key diffference). That means the threat surface for attacks >> on MPLS are very different than for IPv6 more generally. > Yes - a good point. That is one of those restricted cases where it is possible to provide a reasonably secure solution. > > But my understanding is that SPRING was at IPv6 layer as well as on MPLS layer… although the charter does not explicitly say it. Just that it is not IPv4… > > If SPRING is expected to run at the IPv6 layer, what is the plan to contain the vulnerability? > > Jari > > . > The following was just posted on the STATUS list and clarifies intended IPv6 scope. All, On the topic of MPLS vs IPv6 - one being L2 hence more secure then the other (L3) I would like to observe that any decently managed network would already today prohibit to accept any external packets which have as destination an infrastructure address of such network. That is the basic protection scheme against DOS/DDOS attacks to the infrastructure. When such packet is detected it should be dropped - not "stripped from explicit routes" like the above charter update would tend to suggest. As some may recall in the past we have been working on automating such ACLs installation based in internal IGP addresses on all border routers under same administrative domain within single AS or number of ASes to ease operational burden. Not sure if all vendors support such automation today. I think what needs to be understood that segment routing is not internet wide source routing technology. It is carefully crafted path engineering and packet encapsulation technique within controlled set of domains which really do not compare to the original issues and security concerns of source routing. Best, R. I could OLD The initial data planes that will be considered are MPLS and IPv6. NEW The initial data planes that will be considered are MPLS and IPv6 in constrained network scopes. END Stewart --------------060107010108040007010906 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 10/10/2013 17:39, Jari Arkko wrote:
Thomas,


I think a key point is that with IPv6, we are talking (potentially)
end-to-end exposure of an attack vector. You can have arbitrary end
nodes anywhere on the Internet injecting traffic that potentially
directly invokes or impacts source routing. In contrast, one can view
MPLS as an L2 technology below IP. That means it's deployed in a much
more restricted setting and a normal sender of TCP/IP has a much more
restricted attack vector for doing anything that impacts MPLS directly
(this is key diffference). That means the threat surface for attacks
on MPLS are very different than for IPv6 more generally.

Yes - a good point. That is one of those restricted cases where it is possible to provide a reasonably secure solution.

But my understanding is that SPRING was at IPv6 layer as well as on MPLS layer… although the charter does not explicitly say it. Just that it is not IPv4…

If SPRING is expected to run at the IPv6 layer, what is the plan to contain the vulnerability?

Jari

.
The following was just posted on the STATUS list and clarifies
intended IPv6 scope.
All,

On the topic of MPLS vs IPv6 - one being L2 hence more secure then the
other (L3) I would like to observe that any decently managed network
would already today prohibit to accept any external packets which have
as destination an infrastructure address of such network. That is the
basic protection scheme against DOS/DDOS attacks to the
infrastructure.

When such packet is detected it should be dropped - not "stripped from
explicit routes" like the above charter update would tend to suggest.

As some may recall in the past we have been working on automating such
ACLs installation based in internal IGP addresses on all border
routers under same administrative domain within single AS or number of
ASes to ease operational burden. Not sure if all vendors support such
automation today.

I think what needs to be understood that segment routing is not
internet wide source routing technology. It is carefully crafted path
engineering and packet encapsulation technique within controlled set
of domains which really do not compare to the original issues and
security concerns of source routing.

Best,
R.

I could 

OLD
The initial data planes that will be considered are MPLS
and IPv6.
NEW
The initial data planes that will be considered are MPLS
and IPv6 in constrained network scopes.

END

Stewart




  


--------------060107010108040007010906--

From stbryant@cisco.com  Thu Oct 10 11:53:29 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43021F9C99 for ; Thu, 10 Oct 2013 11:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.499
X-Spam-Level: 
X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcjgdSHP429J for ; Thu, 10 Oct 2013 11:53:24 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1E21E8117 for ; Thu, 10 Oct 2013 11:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1184; q=dns/txt; s=iport; t=1381431170; x=1382640770; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AtshHEsBn+eoJRCDMg2QYlmoPMIK3vrNk/txFf2ETpo=; b=hniPPUD6S9oUFStfQJvfyPvEjCFDOFJabO8ePGsmSVOOGRGhvq1eRegC U0abHFO43fhJ8Vbudpf78+FhflATDd3bVzgSyI531EitkmX4/EC19ethl ymkdvo3YU/3CS5B46HT3d6RlacwILd+3ZR0EW2Qhd4aJTqz60V3pIk17j I=;
X-IronPort-AV: E=Sophos;i="4.90,1074,1371081600"; d="scan'208";a="18673873"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 10 Oct 2013 18:52:39 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9AIqWom006686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 18:52:34 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9AIqTcn018351; Thu, 10 Oct 2013 19:52:30 +0100 (BST)
Message-ID: <5256F76D.9080905@cisco.com>
Date: Thu, 10 Oct 2013 19:52:29 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adrian Farrel , "status@ietf.org" 
References: <52569169.20404@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joel Jaeggli , Benoit Claise , Jari Arkko , "John G. Scudder" , Alvaro Retana 
Subject: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Oct 2013 18:53:30 -0000

The SPRING charter was discussed on the telechat today. We have
a small issue with the OAM and management deliverable text that
I am working with Benoit.

The largest sticking point is the IPv6 text, where a number of
ADs are concerned that given the previous security issues with
source routing, they are concerned at the difficulty we face
significant difficulty designing a satisfactory IPv6 solution.
There was some discussion on the call about limited network
scope, but concern was expressed that once the feature was
in the wild, the scope would be difficult to control.

Jari who is the main discuss holder will work with us over
the next couple of days to try to get some text that will allow
us to go forward. The goal is to get the charter into external
review by Monday night so it can go to external review
on Tuesday and be on the following telechat for approval
by Vancouver.

Currently SPRING is of course a BOF and I have asked Alvaro
Retana, and John Scudder to chair the BOF in Vanouver.

If the charter text still has unresolved issues by the time
we meet in Vancouver, then they should be the first
priority on the agenda.

- Stewart





From Peter.AshwoodSmith@huawei.com  Thu Oct 10 12:32:31 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B6B21F8531 for ; Thu, 10 Oct 2013 12:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7z9fSwtN5Nf for ; Thu, 10 Oct 2013 12:31:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7521E8097 for ; Thu, 10 Oct 2013 12:31:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWR60706; Thu, 10 Oct 2013 19:31:21 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 20:30:49 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 20:31:16 +0100
Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 12:31:13 -0700
From: AshwoodsmithPeter 
To: "stbryant@cisco.com" , Adrian Farrel , "status@ietf.org" 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxeoIRgp7WDel+0erZsGM5bSjqZnuUOeA
Date: Thu, 10 Oct 2013 19:31:12 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com>
In-Reply-To: <5256F76D.9080905@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.60.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Joel Jaeggli , Benoit Claise , Jari Arkko , "John G. Scudder" , Alvaro Retana 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 19:32:31 -0000

I can understand the concern. Making a new option for V6 exposes it to misu=
se by the endpoints as was previously the case for v4.

What is wrong with an approach that is MPLS first and then an evolution of =
MPLS? That would work for IPV6/V4 or whatever else goes on top.

I mean is it heresy to suggest that we should evolve MPLS in the future?=20

Peter

-----Original Message-----
From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of=
 Stewart Bryant
Sent: Thursday, October 10, 2013 2:52 PM
To: Adrian Farrel; status@ietf.org
Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
Subject: [Status] Status of Spring


The SPRING charter was discussed on the telechat today. We have
a small issue with the OAM and management deliverable text that
I am working with Benoit.

The largest sticking point is the IPv6 text, where a number of
ADs are concerned that given the previous security issues with
source routing, they are concerned at the difficulty we face
significant difficulty designing a satisfactory IPv6 solution.
There was some discussion on the call about limited network
scope, but concern was expressed that once the feature was
in the wild, the scope would be difficult to control.

Jari who is the main discuss holder will work with us over
the next couple of days to try to get some text that will allow
us to go forward. The goal is to get the charter into external
review by Monday night so it can go to external review
on Tuesday and be on the following telechat for approval
by Vancouver.

Currently SPRING is of course a BOF and I have asked Alvaro
Retana, and John Scudder to chair the BOF in Vanouver.

If the charter text still has unresolved issues by the time
we meet in Vancouver, then they should be the first
priority on the agenda.

- Stewart




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

From jdrake@juniper.net  Thu Oct 10 12:42:59 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10C311E80E7 for ; Thu, 10 Oct 2013 12:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.214
X-Spam-Level: 
X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=1.385,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DSlIYc2oLfn for ; Thu, 10 Oct 2013 12:42:38 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92021F8F3C for ; Thu, 10 Oct 2013 12:42:13 -0700 (PDT)
Received: from mail91-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 19:42:03 +0000
Received: from mail91-tx2 (localhost [127.0.0.1])	by mail91-tx2-R.bigfish.com (Postfix) with ESMTP id 2FCC34201AC; Thu, 10 Oct 2013 19:42:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h)
Received-SPF: pass (mail91-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(13464003)(54316002)(56776001)(85306002)(81686001)(76482001)(65816001)(66066001)(80022001)(74366001)(79102001)(77982001)(63696002)(59766001)(15975445006)(81816001)(74876001)(74706001)(83072001)(69226001)(15202345003)(47736001)(49866001)(50986001)(47976001)(46102001)(51856001)(53806001)(4396001)(74662001)(74502001)(19580405001)(83322001)(54356001)(80976001)(19580395003)(47446002)(31966008)(81542001)(74316001)(76796001)(76786001)(76576001)(81342001)(77096001)(33646001)(56816003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB144; H:BY2PR05MB142.namprd05.prod.outlook.com; CLIP:66.129.224.54; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail91-tx2 (localhost.localdomain [127.0.0.1]) by mail91-tx2 (MessageSwitch) id 1381434120394458_29170; Thu, 10 Oct 2013 19:42:00 +0000 (UTC)
Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.228])	by mail91-tx2.bigfish.com (Postfix) with ESMTP id 58319801AB; Thu, 10 Oct 2013 19:42:00 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 19:41:59 +0000
Received: from BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 19:41:59 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com (10.242.39.144) by BY2PR05MB144.namprd05.prod.outlook.com (10.242.39.147) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 19:41:55 +0000
Received: from BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.177]) by BY2PR05MB142.namprd05.prod.outlook.com ([169.254.12.115]) with mapi id 15.00.0775.005; Thu, 10 Oct 2013 19:41:55 +0000
From: John E Drake 
To: AshwoodsmithPeter , "stbryant@cisco.com" , Adrian Farrel , "status@ietf.org" 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxeoNgQS6mTFpbkSUiILYOR9zsJnuUrkAgAABlkA=
Date: Thu, 10 Oct 2013 19:41:54 +0000
Message-ID: <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com>
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.54]
x-forefront-prvs: 0995196AA2
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "EXT - joelja@bogus.com" , Benoit Claise , Jari Arkko , "John G. Scudder" , Alvaro Retana 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 19:42:59 -0000

Peter,

I completely agree that we should simply focus on MPLS because, as you note=
, it will support IPv6 as well as IPv4.

However, it is not clear that MPLS will need to be evolved in order to supp=
ort Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-spr=
ing-mpls-00

Yours Irrespectively,

John

> -----Original Message-----
> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf =
Of
> AshwoodsmithPeter
> Sent: Thursday, October 10, 2013 12:31 PM
> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; A=
lvaro
> Retana
> Subject: Re: [Status] Status of Spring
>=20
> I can understand the concern. Making a new option for V6 exposes it to mi=
suse
> by the endpoints as was previously the case for v4.
>=20
> What is wrong with an approach that is MPLS first and then an evolution o=
f
> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>=20
> I mean is it heresy to suggest that we should evolve MPLS in the future?
>=20
> Peter
>=20
> -----Original Message-----
> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf =
Of
> Stewart Bryant
> Sent: Thursday, October 10, 2013 2:52 PM
> To: Adrian Farrel; status@ietf.org
> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Reta=
na
> Subject: [Status] Status of Spring
>=20
>=20
> The SPRING charter was discussed on the telechat today. We have a small
> issue with the OAM and management deliverable text that I am working with
> Benoit.
>=20
> The largest sticking point is the IPv6 text, where a number of ADs are
> concerned that given the previous security issues with source routing, th=
ey are
> concerned at the difficulty we face significant difficulty designing a sa=
tisfactory
> IPv6 solution.
> There was some discussion on the call about limited network scope, but
> concern was expressed that once the feature was in the wild, the scope wo=
uld
> be difficult to control.
>=20
> Jari who is the main discuss holder will work with us over the next coupl=
e of
> days to try to get some text that will allow us to go forward. The goal i=
s to get
> the charter into external review by Monday night so it can go to external
> review on Tuesday and be on the following telechat for approval by Vancou=
ver.
>=20
> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and J=
ohn
> Scudder to chair the BOF in Vanouver.
>=20
> If the charter text still has unresolved issues by the time we meet in
> Vancouver, then they should be the first priority on the agenda.
>=20
> - Stewart
>=20
>=20
>=20
>=20
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status
>=20



From rraszuk@gmail.com  Thu Oct 10 13:04:39 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695611E80EC for ; Thu, 10 Oct 2013 13:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcebPhXF2SBh for ; Thu, 10 Oct 2013 13:04:39 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 261B421F9BEF for ; Thu, 10 Oct 2013 13:04:39 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id as1so4938384iec.27 for ; Thu, 10 Oct 2013 13:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/I3BUXDP8a75eeAhoqLgbXAvBE5FWphyz7gMs6z3M04=; b=uXfZ9RpOBgLgUpOIsXVh1UcuPG3U3bWoRL2ZIZo+6rYlA+NlvtBTGvnNZY47QSg8l4 uerDEVuyb9CzVovIi2snJUaFAFxBo2EPT9sKJeoF1E43tIqzWOwoHUEWAdPIEpXHc8Wk OyxilunmFLywTKEWhqQM+WKgMH+kOZQhQb5ZTzMb3ehRQKamsgsrnn/VY70k85l2Yq/f l4qsRDE3psrJ14cmVNUJH3vWhVzMrs3TtBXoqStXQmvG0c9a+UAFq52ICOZ9YdSkiY9Q jT2jV2tmEAZGWGjrgsSXwtA4AxHIAK3clPWqzKUQTysgdi3qDaF1EvcaR8eS62T3AP8D LQsw==
MIME-Version: 1.0
X-Received: by 10.50.107.102 with SMTP id hb6mr7667799igb.55.1381435478536; Thu, 10 Oct 2013 13:04:38 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 13:04:38 -0700 (PDT)
In-Reply-To: <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>
Date: Thu, 10 Oct 2013 22:04:38 +0200
X-Google-Sender-Auth: nxQcuEXTdDj-UZtc2ZPHiXjRyeE
Message-ID: 
From: Robert Raszuk 
To: John E Drake 
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Thu, 10 Oct 2013 13:06:47 -0700
Cc: AshwoodsmithPeter , "EXT - joelja@bogus.com" , Jari Arkko , "John G. Scudder" , Alvaro Retana , Benoit Claise , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 20:04:40 -0000

Hi John,

Simple question ...

If I have no MPLS in any of the data center how can I use segment
routing in those environments ?

Is your answer to deploy MPLS for transport in all data centers or
just not use segment routing there at all ?

Many thx,
R.


On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wrote:
> Peter,
>
> I completely agree that we should simply focus on MPLS because, as you note, it will support IPv6 as well as IPv4.
>
> However, it is not clear that MPLS will need to be evolved in order to support Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-spring-mpls-00
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of
>> AshwoodsmithPeter
>> Sent: Thursday, October 10, 2013 12:31 PM
>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro
>> Retana
>> Subject: Re: [Status] Status of Spring
>>
>> I can understand the concern. Making a new option for V6 exposes it to misuse
>> by the endpoints as was previously the case for v4.
>>
>> What is wrong with an approach that is MPLS first and then an evolution of
>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>>
>> I mean is it heresy to suggest that we should evolve MPLS in the future?
>>
>> Peter
>>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of
>> Stewart Bryant
>> Sent: Thursday, October 10, 2013 2:52 PM
>> To: Adrian Farrel; status@ietf.org
>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Retana
>> Subject: [Status] Status of Spring
>>
>>
>> The SPRING charter was discussed on the telechat today. We have a small
>> issue with the OAM and management deliverable text that I am working with
>> Benoit.
>>
>> The largest sticking point is the IPv6 text, where a number of ADs are
>> concerned that given the previous security issues with source routing, they are
>> concerned at the difficulty we face significant difficulty designing a satisfactory
>> IPv6 solution.
>> There was some discussion on the call about limited network scope, but
>> concern was expressed that once the feature was in the wild, the scope would
>> be difficult to control.
>>
>> Jari who is the main discuss holder will work with us over the next couple of
>> days to try to get some text that will allow us to go forward. The goal is to get
>> the charter into external review by Monday night so it can go to external
>> review on Tuesday and be on the following telechat for approval by Vancouver.
>>
>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and John
>> Scudder to chair the BOF in Vanouver.
>>
>> If the charter text still has unresolved issues by the time we meet in
>> Vancouver, then they should be the first priority on the agenda.
>>
>> - Stewart
>>
>>
>>
>>
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>>
>
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status

From Peter.AshwoodSmith@huawei.com  Thu Oct 10 13:49:12 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A6F21F9ECE for ; Thu, 10 Oct 2013 13:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpY8AchpfGqF for ; Thu, 10 Oct 2013 13:49:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2969D21F9B8A for ; Thu, 10 Oct 2013 13:48:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY59632; Thu, 10 Oct 2013 20:48:57 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:48:20 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:48:56 +0100
Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 13:48:53 -0700
From: AshwoodsmithPeter 
To: Robert Raszuk , John E Drake 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxeoIRgp7WDel+0erZsGM5bSjqZnuUOeAgAB6KQCAAAZaAP//j2zA
Date: Thu, 10 Oct 2013 20:48:53 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.60.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Thu, 10 Oct 2013 13:50:53 -0700
Cc: "EXT - joelja@bogus.com" , Jari Arkko , "John G. Scudder" , Alvaro Retana , Benoit Claise , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 20:49:12 -0000

Robert,

Most of the TOR's and core DC switches have MPLS data planes already built =
into the ASICs, it's just turned off. It would not be terribly difficult ac=
tually to have a Hypervisor attach an n hop or so label stack and have the =
TOR and Spine switches do pop and forward without having to enable all the =
MPLS control planes. In my lab for example I could easily do that with most=
 of my 20 odd  switches of different flavors and I'm sure that's true of mo=
st of the other vendor's DC gear/switches too. Of course you'd want a new f=
orm of control (SDN comes to mind), but that's true if you use V6 options, =
MPLS, ACL 'games' or whatever. The other advantage of MPLS in that context =
is that when the frame finally arrives at a VRF it can use MPLS IPVPN (or L=
2VPN) data plane semantics instead of something new that needs new hardware=
. The main constraint as far as I am aware is the limited stack depth avail=
able on initial push by some ASICs. Of course that's not a problem for the =
Hypervisor to VRF direction, or Hypervisor to Hypervisor but it is a proble=
m for a VRF to Hypervisor (origin is often an ASIC). Of course in the DC yo=
u are going limited hops anyway so that may not be a concern.

However an area that does concern me is mobile backhaul. In that case an MP=
LS label stack is potentially a significant overhead and we may want to add=
ress it in some future version. I have a bit of real SP data (PDU size dist=
ributions) that shows it compared to other types of SP links which I can sh=
ow in Vancouver if there is interest.

Peter



-----Original Message-----
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz=
uk
Sent: Thursday, October 10, 2013 4:05 PM
To: John E Drake
Cc: AshwoodsmithPeter; stbryant@cisco.com; Adrian Farrel; status@ietf.org; =
EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro =
Retana
Subject: Re: [Status] Status of Spring

Hi John,

Simple question ...

If I have no MPLS in any of the data center how can I use segment
routing in those environments ?

Is your answer to deploy MPLS for transport in all data centers or
just not use segment routing there at all ?

Many thx,
R.


On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wrote:
> Peter,
>
> I completely agree that we should simply focus on MPLS because, as you no=
te, it will support IPv6 as well as IPv4.
>
> However, it is not clear that MPLS will need to be evolved in order to su=
pport Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-s=
pring-mpls-00
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf=
 Of
>> AshwoodsmithPeter
>> Sent: Thursday, October 10, 2013 12:31 PM
>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; =
Alvaro
>> Retana
>> Subject: Re: [Status] Status of Spring
>>
>> I can understand the concern. Making a new option for V6 exposes it to m=
isuse
>> by the endpoints as was previously the case for v4.
>>
>> What is wrong with an approach that is MPLS first and then an evolution =
of
>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>>
>> I mean is it heresy to suggest that we should evolve MPLS in the future?
>>
>> Peter
>>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf=
 Of
>> Stewart Bryant
>> Sent: Thursday, October 10, 2013 2:52 PM
>> To: Adrian Farrel; status@ietf.org
>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Ret=
ana
>> Subject: [Status] Status of Spring
>>
>>
>> The SPRING charter was discussed on the telechat today. We have a small
>> issue with the OAM and management deliverable text that I am working wit=
h
>> Benoit.
>>
>> The largest sticking point is the IPv6 text, where a number of ADs are
>> concerned that given the previous security issues with source routing, t=
hey are
>> concerned at the difficulty we face significant difficulty designing a s=
atisfactory
>> IPv6 solution.
>> There was some discussion on the call about limited network scope, but
>> concern was expressed that once the feature was in the wild, the scope w=
ould
>> be difficult to control.
>>
>> Jari who is the main discuss holder will work with us over the next coup=
le of
>> days to try to get some text that will allow us to go forward. The goal =
is to get
>> the charter into external review by Monday night so it can go to externa=
l
>> review on Tuesday and be on the following telechat for approval by Vanco=
uver.
>>
>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and =
John
>> Scudder to chair the BOF in Vanouver.
>>
>> If the charter text still has unresolved issues by the time we meet in
>> Vancouver, then they should be the first priority on the agenda.
>>
>> - Stewart
>>
>>
>>
>>
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>>
>
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status

From Peter.AshwoodSmith@huawei.com  Thu Oct 10 13:51:50 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B410A11E80EE for ; Thu, 10 Oct 2013 13:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmWdCIzFvuqG for ; Thu, 10 Oct 2013 13:51:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3611E80F1 for ; Thu, 10 Oct 2013 13:51:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY59736; Thu, 10 Oct 2013 20:51:37 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:51:00 +0100
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:51:35 +0100
Received: from dfweml513-mbb.china.huawei.com ([169.254.15.165]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 13:51:31 -0700
From: AshwoodsmithPeter 
To: "status@ietf.org" 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxeoIRgp7WDel+0erZsGM5bSjqZnuUOeAgAB6KQCAAAZaAP//j2zAgAAH9wA=
Date: Thu, 10 Oct 2013 20:51:30 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E209913158@dfweml513-mbb.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.60.170]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 20:51:50 -0000

Most of the TOR's and core DC switches have MPLS data planes already built =
into the ASICs, it's just turned off. It would not be terribly difficult ac=
tually to have a Hypervisor attach an n hop or so label stack and have the =
TOR and Spine switches do pop and forward without having to enable all the =
MPLS control planes. In my lab for example I could easily do that with most=
 of my 20 odd  switches of different flavors and I'm sure that's true of mo=
st of the other vendor's DC gear/switches too. Of course you'd want a new f=
orm of control (SDN comes to mind), but that's true if you use V6 options, =
MPLS, ACL 'games' or whatever. The other advantage of MPLS in that context =
is that when the frame finally arrives at a VRF it can use MPLS IPVPN (or L=
2VPN) data plane semantics instead of something new that needs new hardware=
. The main constraint as far as I am aware is the limited stack depth avail=
able on initial push by some ASICs. Of course that's not a problem for the =
Hypervisor to VRF direction, or Hypervisor to Hypervisor but it is a proble=
m for a VRF to Hypervisor (origin is often an ASIC). Of course in the DC yo=
u are going limited hops anyway so that may not be a concern.

However an area that does concern me is mobile backhaul. In that case an MP=
LS label stack is potentially a significant overhead and we may want to add=
ress it in some future version. I have a bit of real SP data (PDU size dist=
ributions) that shows it compared to other types of SP links which I can sh=
ow in Vancouver if there is interest.

Peter



-----Original Message-----
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Rasz=
uk
Sent: Thursday, October 10, 2013 4:05 PM
To: John E Drake
Cc: AshwoodsmithPeter; stbryant@cisco.com; Adrian Farrel; status@ietf.org; =
EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro =
Retana
Subject: Re: [Status] Status of Spring

Hi John,

Simple question ...

If I have no MPLS in any of the data center how can I use segment
routing in those environments ?

Is your answer to deploy MPLS for transport in all data centers or
just not use segment routing there at all ?

Many thx,
R.


On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wrote:
> Peter,
>
> I completely agree that we should simply focus on MPLS because, as you no=
te, it will support IPv6 as well as IPv4.
>
> However, it is not clear that MPLS will need to be evolved in order to su=
pport Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-s=
pring-mpls-00
>
> Yours Irrespectively,
>
> John
>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf=
 Of
>> AshwoodsmithPeter
>> Sent: Thursday, October 10, 2013 12:31 PM
>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; =
Alvaro
>> Retana
>> Subject: Re: [Status] Status of Spring
>>
>> I can understand the concern. Making a new option for V6 exposes it to m=
isuse
>> by the endpoints as was previously the case for v4.
>>
>> What is wrong with an approach that is MPLS first and then an evolution =
of
>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>>
>> I mean is it heresy to suggest that we should evolve MPLS in the future?
>>
>> Peter
>>
>> -----Original Message-----
>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf=
 Of
>> Stewart Bryant
>> Sent: Thursday, October 10, 2013 2:52 PM
>> To: Adrian Farrel; status@ietf.org
>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Ret=
ana
>> Subject: [Status] Status of Spring
>>
>>
>> The SPRING charter was discussed on the telechat today. We have a small
>> issue with the OAM and management deliverable text that I am working wit=
h
>> Benoit.
>>
>> The largest sticking point is the IPv6 text, where a number of ADs are
>> concerned that given the previous security issues with source routing, t=
hey are
>> concerned at the difficulty we face significant difficulty designing a s=
atisfactory
>> IPv6 solution.
>> There was some discussion on the call about limited network scope, but
>> concern was expressed that once the feature was in the wild, the scope w=
ould
>> be difficult to control.
>>
>> Jari who is the main discuss holder will work with us over the next coup=
le of
>> days to try to get some text that will allow us to go forward. The goal =
is to get
>> the charter into external review by Monday night so it can go to externa=
l
>> review on Tuesday and be on the following telechat for approval by Vanco=
uver.
>>
>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and =
John
>> Scudder to chair the BOF in Vanouver.
>>
>> If the charter text still has unresolved issues by the time we meet in
>> Vancouver, then they should be the first priority on the agenda.
>>
>> - Stewart
>>
>>
>>
>>
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status
>>
>
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status

From jgs@juniper.net  Thu Oct 10 13:54:21 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90AB21E8087 for ; Thu, 10 Oct 2013 13:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVeg4-mmtPsA for ; Thu, 10 Oct 2013 13:54:15 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9263021E805F for ; Thu, 10 Oct 2013 13:54:09 -0700 (PDT)
Received: from mail95-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 20:54:08 +0000
Received: from mail95-ch1 (localhost [127.0.0.1])	by mail95-ch1-R.bigfish.com (Postfix) with ESMTP id BF9544401F3	for ; Thu, 10 Oct 2013 20:54:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -13
X-BigFish: VPS-13(zz4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail95-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(199002)(189002)(69226001)(53416003)(49866001)(47736001)(42186004)(50986001)(47976001)(74706001)(50466002)(83072001)(36756003)(81542001)(76786001)(76796001)(77156001)(77096001)(56816003)(81342001)(50226001)(46102001)(53806001)(51856001)(74662001)(74502001)(4396001)(19580405001)(83322001)(47446002)(19580395003)(80976001)(31966008)(76482001)(81686001)(65816001)(82746002)(56776001)(54316002)(33656001)(62966002)(85306002)(59766001)(57306001)(74876001)(81816001)(46406003)(80022001)(66066001)(47776003)(63696002)(23726002)(79102001)(74366001)(77982001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail95-ch1 (localhost.localdomain [127.0.0.1]) by mail95-ch1 (MessageSwitch) id 1381438446314035_13417; Thu, 10 Oct 2013 20:54:06 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244])	by mail95-ch1.bigfish.com (Postfix) with ESMTP id 48CD8420069 for ; Thu, 10 Oct 2013 20:54:06 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 20:54:05 +0000
Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 20:54:05 +0000
Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 20:54:03 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: "John G. Scudder" 
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>
Date: Thu, 10 Oct 2013 16:53:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <0A3CCEDF-1456-4AB0-BAA8-D2258FFECA87@juniper.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>
To: 
X-Mailer: Apple Mail (2.1510)
X-Originating-IP: [66.129.232.2]
X-ClientProxiedBy: BLUPR02CA003.namprd02.prod.outlook.com (10.255.223.151) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151)
X-Forefront-PRVS: 0995196AA2
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [Status] Please trim your cc
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 20:54:22 -0000

Folks,=20

Please refrain from cc'ing the entire universe on your messages to =
status@ietf.org. If your recipient list is too long, your message gets =
held for administrative approval, slowing its delivery and mildly =
annoying the mailing list administrator. I'm not sure what the magic =
number is, but clearly ten recipients is enough to put you in the =
doghouse.

Thanks,

--John=


From rraszuk@gmail.com  Thu Oct 10 13:58:16 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60AA21F9C9B for ; Thu, 10 Oct 2013 13:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJYL1LR-pF+O for ; Thu, 10 Oct 2013 13:58:16 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EFEFB11E80E2 for ; Thu, 10 Oct 2013 13:58:15 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id x13so6461433ief.17 for ; Thu, 10 Oct 2013 13:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7r/VBuQsd6v5tQNBvYnc/q6pPTqkfLV21WAq7ZPcDOo=; b=Unbt0LJyUrweUb96Baiiq7WNxbPl+gPWeJ57VVYrQraC3uBtE5xTmc3n0c4abWRfU2 fLVsRgaN95iLB55Tt8SA4epnPGkEjqFf951s/ezQ1vrom6rrXBD47sWry0mTov8GIOxD kWYlT1Or+wpR4z0KF3AtA9r7B11cnaFdSWrPYmqzAaw1fDMErFZo+tsi8yNqmm4B9EOn aw1DOilhQ3VoClfYD9/aIM8KxG6YYpBWBsOi3sPKdVKkfEGsrQa0I1lkLRqSSp70XQxV bcLjaMsqxq5GAG23MNQeaKh54YBOWuMNB9srTFyj/DKmaIzfTKv/gkuxcVw8yiXE+K8M j0Mw==
MIME-Version: 1.0
X-Received: by 10.50.97.35 with SMTP id dx3mr59475igb.55.1381438694984; Thu, 10 Oct 2013 13:58:14 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 13:58:14 -0700 (PDT)
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>
Date: Thu, 10 Oct 2013 22:58:14 +0200
X-Google-Sender-Auth: zKZcGFqYSV_Y9p1yr4fK_ep5ikA
Message-ID: 
From: Robert Raszuk 
To: AshwoodsmithPeter 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 20:58:16 -0000

Peter,

I admire your optimism stating that it will not be terribly difficult
to enable linux kernel support for MPLS encapsulation as well as build
IGP or LDP signalling into stock hypervisors. I think we could
continue this topic when linux supports all of the above.

However the issue is not with MPLS in the hypervisor or not. The issue
is with lack of summarization and enforcement of exact FEC match which
MPLS architecture mandates. With IP transport and subnet lookup all
works just fine without any exact match needed of FEC to next hop.

Said this one needs to clearly decouple MPLS use for application demux
(L2VPN or L3VPN) from MPLS use for transport. The latter is pretty
much dead end as far as I can see while the former works very well and
it would be a mistake to propose to change or replace it.

Best regards,
R.











On Thu, Oct 10, 2013 at 10:48 PM, AshwoodsmithPeter
 wrote:
> Robert,
>
> Most of the TOR's and core DC switches have MPLS data planes already buil=
t into the ASICs, it's just turned off. It would not be terribly difficult =
actually to have a Hypervisor attach an n hop or so label stack and have th=
e TOR and Spine switches do pop and forward without having to enable all th=
e MPLS control planes. In my lab for example I could easily do that with mo=
st of my 20 odd  switches of different flavors and I'm sure that's true of =
most of the other vendor's DC gear/switches too. Of course you'd want a new=
 form of control (SDN comes to mind), but that's true if you use V6 options=
, MPLS, ACL 'games' or whatever. The other advantage of MPLS in that contex=
t is that when the frame finally arrives at a VRF it can use MPLS IPVPN (or=
 L2VPN) data plane semantics instead of something new that needs new hardwa=
re. The main constraint as far as I am aware is the limited stack depth ava=
ilable on initial push by some ASICs. Of course that's not a problem for th=
e Hypervisor to VRF direction, or Hypervisor to Hypervisor but it is a prob=
lem for a VRF to Hypervisor (origin is often an ASIC). Of course in the DC =
you are going limited hops anyway so that may not be a concern.
>
> However an area that does concern me is mobile backhaul. In that case an =
MPLS label stack is potentially a significant overhead and we may want to a=
ddress it in some future version. I have a bit of real SP data (PDU size di=
stributions) that shows it compared to other types of SP links which I can =
show in Vancouver if there is interest.
>
> Peter
>
>
>
> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Ra=
szuk
> Sent: Thursday, October 10, 2013 4:05 PM
> To: John E Drake
> Cc: AshwoodsmithPeter; stbryant@cisco.com; Adrian Farrel; status@ietf.org=
; EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alvar=
o Retana
> Subject: Re: [Status] Status of Spring
>
> Hi John,
>
> Simple question ...
>
> If I have no MPLS in any of the data center how can I use segment
> routing in those environments ?
>
> Is your answer to deploy MPLS for transport in all data centers or
> just not use segment routing there at all ?
>
> Many thx,
> R.
>
>
> On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wrote:
>> Peter,
>>
>> I completely agree that we should simply focus on MPLS because, as you n=
ote, it will support IPv6 as well as IPv4.
>>
>> However, it is not clear that MPLS will need to be evolved in order to s=
upport Spring.  See, for example, http://tools.ietf.org/html/draft-gredler-=
spring-mpls-00
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behal=
f Of
>>> AshwoodsmithPeter
>>> Sent: Thursday, October 10, 2013 12:31 PM
>>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
>>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder;=
 Alvaro
>>> Retana
>>> Subject: Re: [Status] Status of Spring
>>>
>>> I can understand the concern. Making a new option for V6 exposes it to =
misuse
>>> by the endpoints as was previously the case for v4.
>>>
>>> What is wrong with an approach that is MPLS first and then an evolution=
 of
>>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>>>
>>> I mean is it heresy to suggest that we should evolve MPLS in the future=
?
>>>
>>> Peter
>>>
>>> -----Original Message-----
>>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behal=
f Of
>>> Stewart Bryant
>>> Sent: Thursday, October 10, 2013 2:52 PM
>>> To: Adrian Farrel; status@ietf.org
>>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro Re=
tana
>>> Subject: [Status] Status of Spring
>>>
>>>
>>> The SPRING charter was discussed on the telechat today. We have a small
>>> issue with the OAM and management deliverable text that I am working wi=
th
>>> Benoit.
>>>
>>> The largest sticking point is the IPv6 text, where a number of ADs are
>>> concerned that given the previous security issues with source routing, =
they are
>>> concerned at the difficulty we face significant difficulty designing a =
satisfactory
>>> IPv6 solution.
>>> There was some discussion on the call about limited network scope, but
>>> concern was expressed that once the feature was in the wild, the scope =
would
>>> be difficult to control.
>>>
>>> Jari who is the main discuss holder will work with us over the next cou=
ple of
>>> days to try to get some text that will allow us to go forward. The goal=
 is to get
>>> the charter into external review by Monday night so it can go to extern=
al
>>> review on Tuesday and be on the following telechat for approval by Vanc=
ouver.
>>>
>>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, and=
 John
>>> Scudder to chair the BOF in Vanouver.
>>>
>>> If the charter text still has unresolved issues by the time we meet in
>>> Vancouver, then they should be the first priority on the agenda.
>>>
>>> - Stewart
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> status mailing list
>>> status@ietf.org
>>> https://www.ietf.org/mailman/listinfo/status
>>> _______________________________________________
>>> status mailing list
>>> status@ietf.org
>>> https://www.ietf.org/mailman/listinfo/status
>>>
>>
>>
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status

From jari.arkko@piuha.net  Thu Oct 10 14:03:55 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3111E80E2 for ; Thu, 10 Oct 2013 14:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.276
X-Spam-Level: 
X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhGOWZjSj-IM for ; Thu, 10 Oct 2013 14:03:50 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72021E808F for ; Thu, 10 Oct 2013 14:03:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 328562CC95; Fri, 11 Oct 2013 00:03:46 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-hWO1TOUMJ1; Fri, 11 Oct 2013 00:03:45 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7F6752CC48; Fri, 11 Oct 2013 00:03:45 +0300 (EEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <5256F76D.9080905@cisco.com>
Date: Fri, 11 Oct 2013 00:03:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
Cc: Joel Jaeggli , "John G. Scudder" , Alvaro Retana , Benoit Claise , Adrian Farrel , "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 21:03:55 -0000

Thanks Stewart and others.

I wanted to add one clarification and some more technical discussion.

> Jari who is the main discuss holder will work with us over
> the next couple of days to try to get some text that will allow
> us to go forward.=20

I would really like to work with you to get this resolved. I see the =
issue, as I think do others, but I need your help in the WG to figure =
out what to do about it. I do not currently have a good idea, but I am =
sure we'll resolve it somehow. Some of you have already offered help - =
thanks.=20

To provide a bit more context why just saying that we'll use it in =
closed networks is unlikely to work:

The MPLS case was easy because these networks are naturally restricted =
to specific areas, and there is no way for a random person in some other =
part of the Internet to send you packets with MPLS labels.

The basic problem with IP is that when someone defines a new =
source-routing header solution and applies it in network X, it does not =
affect just X. The code will be on various devices - with RH0 we had it =
on BSD, Linux, various brands of routers, maybe even on hosts, etc. =
Often turned on by default, leaving vulnerabilities open in many =
networks.

We could say that the feature MUST be by default off and can only be =
enabled upon explicit request from the network manager. However, if I =
have a thousand devices in my network I start to worry that at least one =
of them has accidentally enabled the feature. So now that device could =
potentially reflect traffic sent to it from the outside to an internal =
destination. This could be used to subvert firewall policies, DoS =
attacks on nodes not visible from the Internet, etc. As a result of this =
worry I now have to turn on filtering on the border of my network for =
the new routing header. Is there a way around this?

Also, the charter is clear that you are wishing for at least an eventual =
inter-AS solution. That raises the bar.

In any case, I could completely off base with the above - I have not =
read your proposed solutions and maybe you are thinking of something =
completely different, or have already found the clever solutions to the =
problem. I'm happy to learn more :-)

Jari


From jgs@juniper.net  Thu Oct 10 14:15:23 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A5511E80EE for ; Thu, 10 Oct 2013 14:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nec35VYzwcuN for ; Thu, 10 Oct 2013 14:15:17 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 383D721F9D92 for ; Thu, 10 Oct 2013 14:15:14 -0700 (PDT)
Received: from mail203-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE011.bigfish.com (10.174.14.74) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 21:15:13 +0000
Received: from mail203-db9 (localhost [127.0.0.1])	by mail203-db9-R.bigfish.com (Postfix) with ESMTP id F09684012B; Thu, 10 Oct 2013 21:15:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 6
X-BigFish: VPS6(zz98dI9371Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch1de098h1de097hz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail203-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(377454003)(199002)(189002)(69226001)(49866001)(47736001)(42186004)(50986001)(47976001)(74706001)(50466002)(83072001)(36756003)(81542001)(76786001)(76796001)(77156001)(77096001)(56816003)(81342001)(50226001)(46102001)(53806001)(51856001)(74662001)(74502001)(4396001)(19580405001)(83322001)(47446002)(19580395003)(80976001)(31966008)(76482001)(81686001)(65816001)(82746002)(56776001)(54316002)(33656001)(62966002)(85306002)(59766001)(57306001)(74876001)(81816001)(46406003)(80022001)(66066001)(47776003)(63696002)(23726002)(79102001)(74366001)(77982001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.132.197]; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail203-db9 (localhost.localdomain [127.0.0.1]) by mail203-db9 (MessageSwitch) id 138143971199356_8106; Thu, 10 Oct 2013 21:15:11 +0000 (UTC)
Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.244])	by mail203-db9.bigfish.com (Postfix) with ESMTP id 13B002C0056; Thu, 10 Oct 2013 21:15:11 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 21:15:10 +0000
Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 21:15:07 +0000
Received: from [172.28.132.197] (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 10 Oct 2013 21:15:05 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: "John G. Scudder" 
In-Reply-To: <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
Date: Thu, 10 Oct 2013 17:14:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <8043AF58-3594-442A-8380-62B5569273FE@juniper.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
To: Jari Arkko 
X-Mailer: Apple Mail (2.1510)
X-Originating-IP: [66.129.232.2]
X-ClientProxiedBy: BLUPR02CA001.namprd02.prod.outlook.com (10.255.223.149) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151)
X-Forefront-PRVS: 0995196AA2
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Joel Jaeggli , Adrian Farrel , Benoit Claise , Alvaro Retana , status@ietf.org, Stewart Bryant 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 21:15:23 -0000

On Oct 10, 2013, at 5:03 PM, Jari Arkko  wrote:

> Also, the charter is clear that you are wishing for at least an =
eventual inter-AS solution. That raises the bar.

The charter is also clear [*] that the trust model presumes a single =
administration, so the inter-AS solution applies to multiple ASes under =
a single administration. This was already covered in the exchange =
between Joel and Stewart earlier today.

I do agree that IPv6 is less likely to fail safe if this assumption is =
violated, though.

--John

[*] Well, clearish -- I thought it was more explicit in earlier =
iterations. But still clear enough.=


From rraszuk@gmail.com  Thu Oct 10 14:17:33 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8270821F9CB0 for ; Thu, 10 Oct 2013 14:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVvFk+7K3N9m for ; Thu, 10 Oct 2013 14:17:33 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D751621F9BBD for ; Thu, 10 Oct 2013 14:17:32 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id as1so5066811iec.13 for ; Thu, 10 Oct 2013 14:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5UHSBMibCS62QZGI0Ym219sg4ckzx2Ss6BCD8DtuigA=; b=a/ATzwL8OVsPbGoah7+YMCN1BhaH6xxbpPTWVb4VTA3YveMr28Gacq1OJBpXn3N5F9 fX13EB3xOZ/Sh+A2v1Mey9aT8tDmumbLRytFqSzKID1Gy4GW6totOynlVa9oKuibiwM3 zWL1SZw7KxTWra+Vzn35ZdaWR/uVV6J+1D4YaIxfMMQKg24UgCR4PnBpCMaMG/hkLvJ0 1W8xJ8LtgcOiQD39/fa9KXB/DgxTEfImoRbUfbkrYcnpEKiczRzS5/YiKG9mBvgD2GP3 fVnxFFOZIB8xZpPlALsF2U4Rce9w36Aa3PwR03X4QmXbdlpaw0rtFJasARtLhbcSHoe3 mzMA==
MIME-Version: 1.0
X-Received: by 10.42.29.129 with SMTP id r1mr6229746icc.44.1381439852172; Thu, 10 Oct 2013 14:17:32 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 14:17:32 -0700 (PDT)
In-Reply-To: <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
Date: Thu, 10 Oct 2013 23:17:32 +0200
X-Google-Sender-Auth: oZMhEvsY8YcEuKWmc7WGsnRqsyo
Message-ID: 
From: Robert Raszuk 
To: Jari Arkko 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 21:17:33 -0000

Hi Jari,

> As a result of this worry I now have to turn on filtering on the border o=
f my
> network for the new routing header. Is there a way around this?

Let me clarify my previous message reg such filtering ...

The filtering to your infrastructure addresses should be applied for
both IPv4 and IPv6 packets. SR v6 header would be a regular v6 header
(not new routing header) with perhaps few additional extension headers
embedded to indicate the strict or loose transit nodes.

So filtering applied on the edge of the network (which should be there
regardless of SR or not) would be identical to normal case and would
in fact effectively filter out any external attempt to insert SR
routed packet into your network just based on the standard v6 header
destination IP address.

The only price to pay for this is to set bgp next hop to self if you
want segment route the transit traffic, but this for one is pretty
common today and also same would be required for MPLS encapsulation
anyway.

Best regards,
R.


On Thu, Oct 10, 2013 at 11:03 PM, Jari Arkko  wrote:
> Thanks Stewart and others.
>
> I wanted to add one clarification and some more technical discussion.
>
>> Jari who is the main discuss holder will work with us over
>> the next couple of days to try to get some text that will allow
>> us to go forward.
>
> I would really like to work with you to get this resolved. I see the issu=
e, as I think do others, but I need your help in the WG to figure out what =
to do about it. I do not currently have a good idea, but I am sure we'll re=
solve it somehow. Some of you have already offered help - thanks.
>
> To provide a bit more context why just saying that we'll use it in closed=
 networks is unlikely to work:
>
> The MPLS case was easy because these networks are naturally restricted to=
 specific areas, and there is no way for a random person in some other part=
 of the Internet to send you packets with MPLS labels.
>
> The basic problem with IP is that when someone defines a new source-routi=
ng header solution and applies it in network X, it does not affect just X. =
The code will be on various devices - with RH0 we had it on BSD, Linux, var=
ious brands of routers, maybe even on hosts, etc. Often turned on by defaul=
t, leaving vulnerabilities open in many networks.
>
> We could say that the feature MUST be by default off and can only be enab=
led upon explicit request from the network manager. However, if I have a th=
ousand devices in my network I start to worry that at least one of them has=
 accidentally enabled the feature. So now that device could potentially ref=
lect traffic sent to it from the outside to an internal destination. This c=
ould be used to subvert firewall policies, DoS attacks on nodes not visible=
 from the Internet, etc. As a result of this worry I now have to turn on fi=
ltering on the border of my network for the new routing header. Is there a =
way around this?
>
> Also, the charter is clear that you are wishing for at least an eventual =
inter-AS solution. That raises the bar.
>
> In any case, I could completely off base with the above - I have not read=
 your proposed solutions and maybe you are thinking of something completely=
 different, or have already found the clever solutions to the problem. I'm =
happy to learn more :-)
>
> Jari
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status

From joelja@bogus.com  Thu Oct 10 15:58:27 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA96121E816B for ; Thu, 10 Oct 2013 15:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.666
X-Spam-Level: 
X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LEH7JGssAsc for ; Thu, 10 Oct 2013 15:58:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 70DDF21F90E5 for ; Thu, 10 Oct 2013 15:58:27 -0700 (PDT)
Received: from [192.168.1.11] (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9AMwFLI056134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 10 Oct 2013 22:58:16 GMT (envelope-from joelja@bogus.com)
Content-Type: multipart/signed; boundary="Apple-Mail=_A4AAE889-8CFE-41F7-940B-2688FFB94B05"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: joel jaeggli 
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com>
Date: Thu, 10 Oct 2013 15:58:10 -0700
Message-Id: 
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com>
To: AshwoodsmithPeter 
X-Mailer: Apple Mail (2.1510)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 10 Oct 2013 22:58:17 +0000 (UTC)
Cc: Jari Arkko , "John G. Scudder" , Alvaro Retana , Benoit Claise , Adrian Farrel , "status@ietf.org" , "stbryant@cisco.com" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Oct 2013 22:58:28 -0000

--Apple-Mail=_A4AAE889-8CFE-41F7-940B-2688FFB94B05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Oct 10, 2013, at 12:31 PM, AshwoodsmithPeter =
 wrote:

> I can understand the concern. Making a new option for V6 exposes it to =
misuse by the endpoints as was previously the case for v4.

as was previously the case for ipv6 as well.

sleeping dragons aren't safe dragons.

> What is wrong with an approach that is MPLS first and then an =
evolution of MPLS? That would work for IPV6/V4 or whatever else goes on =
top.
>=20
> I mean is it heresy to suggest that we should evolve MPLS in the =
future?=20
>=20
> Peter
>=20
> -----Original Message-----
> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On =
Behalf Of Stewart Bryant
> Sent: Thursday, October 10, 2013 2:52 PM
> To: Adrian Farrel; status@ietf.org
> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro =
Retana
> Subject: [Status] Status of Spring
>=20
>=20
> The SPRING charter was discussed on the telechat today. We have
> a small issue with the OAM and management deliverable text that
> I am working with Benoit.
>=20
> The largest sticking point is the IPv6 text, where a number of
> ADs are concerned that given the previous security issues with
> source routing, they are concerned at the difficulty we face
> significant difficulty designing a satisfactory IPv6 solution.
> There was some discussion on the call about limited network
> scope, but concern was expressed that once the feature was
> in the wild, the scope would be difficult to control.
>=20
> Jari who is the main discuss holder will work with us over
> the next couple of days to try to get some text that will allow
> us to go forward. The goal is to get the charter into external
> review by Monday night so it can go to external review
> on Tuesday and be on the following telechat for approval
> by Vancouver.
>=20
> Currently SPRING is of course a BOF and I have asked Alvaro
> Retana, and John Scudder to chair the BOF in Vanouver.
>=20
> If the charter text still has unresolved issues by the time
> we meet in Vancouver, then they should be the first
> priority on the agenda.
>=20
> - Stewart
>=20
>=20
>=20
>=20
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status
>=20


--Apple-Mail=_A4AAE889-8CFE-41F7-940B-2688FFB94B05
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlJXMQIACgkQ8AA1q7Z/VrIjrwCfabqY7PZcY++w7Fc0hEQuko01
CEAAn3al7pC8ghzAIHBFACBkk/sxIOG4
=/soI
-----END PGP SIGNATURE-----

--Apple-Mail=_A4AAE889-8CFE-41F7-940B-2688FFB94B05--

From xuxiaohu@huawei.com  Thu Oct 10 18:51:25 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D681121E8188 for ; Thu, 10 Oct 2013 18:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.516
X-Spam-Level: 
X-Spam-Status: No, score=0.516 tagged_above=-999 required=5 tests=[AWL=-2.272,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drkrGAL+IPHC for ; Thu, 10 Oct 2013 18:51:15 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5D21E818A for ; Thu, 10 Oct 2013 18:51:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY73960; Fri, 11 Oct 2013 01:50:54 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 02:50:16 +0100
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 02:50:53 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 09:50:39 +0800
From: Xuxiaohu 
To: Robert Raszuk , AshwoodsmithPeter 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxftv4CKyAtw8vUuUlcOO89jTl5nuuTXA
Date: Fri, 11 Oct 2013 01:50:39 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082154DA@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" 
Subject: [Status] =?gb2312?b?tPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 01:51:27 -0000

Um9iZXJ0LA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHN0YXR1cy1ib3VuY2Vz
QGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gUm9iZXJ0
IFJhc3p1aw0KPiC3osvNyrG85DogMjAxM8TqMTDUwjExyNUgNDo1OA0KPiDK1bz+yMs6IEFzaHdv
b2RzbWl0aFBldGVyDQo+ILOty806IHN0YXR1c0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW1N0YXR1
c10gU3RhdHVzIG9mIFNwcmluZw0KPiANCj4gUGV0ZXIsDQo+IA0KPiBJIGFkbWlyZSB5b3VyIG9w
dGltaXNtIHN0YXRpbmcgdGhhdCBpdCB3aWxsIG5vdCBiZSB0ZXJyaWJseSBkaWZmaWN1bHQNCj4g
dG8gZW5hYmxlIGxpbnV4IGtlcm5lbCBzdXBwb3J0IGZvciBNUExTIGVuY2Fwc3VsYXRpb24gYXMg
d2VsbCBhcyBidWlsZA0KPiBJR1Agb3IgTERQIHNpZ25hbGxpbmcgaW50byBzdG9jayBoeXBlcnZp
c29ycy4gSSB0aGluayB3ZSBjb3VsZA0KPiBjb250aW51ZSB0aGlzIHRvcGljIHdoZW4gbGludXgg
c3VwcG9ydHMgYWxsIG9mIHRoZSBhYm92ZS4NCj4gDQo+IEhvd2V2ZXIgdGhlIGlzc3VlIGlzIG5v
dCB3aXRoIE1QTFMgaW4gdGhlIGh5cGVydmlzb3Igb3Igbm90LiBUaGUgaXNzdWUNCj4gaXMgd2l0
aCBsYWNrIG9mIHN1bW1hcml6YXRpb24gYW5kIGVuZm9yY2VtZW50IG9mIGV4YWN0IEZFQyBtYXRj
aCB3aGljaA0KPiBNUExTIGFyY2hpdGVjdHVyZSBtYW5kYXRlcy4gV2l0aCBJUCB0cmFuc3BvcnQg
YW5kIHN1Ym5ldCBsb29rdXAgYWxsDQo+IHdvcmtzIGp1c3QgZmluZSB3aXRob3V0IGFueSBleGFj
dCBtYXRjaCBuZWVkZWQgb2YgRkVDIHRvIG5leHQgaG9wLg0KDQpVbmxlc3MgeW91IHdhbnQgdG8g
c3BlY2lmeSBhbiBleHBsaWNpdCBwYXRoIGJ5IHVzaW5nIGEgbGlzdCBvZiBJUHY2IGFkZHJlc3Nl
cyBpbiBhIHNvdXJjZSByb3V0ZWQgcGFja2V0LCByYXRoZXIgdGhhbiBhIGxpc3Qgb2Ygc2hvcnQg
c2VnbWVudCBJRHMsIHlvdSB3b3VsZCBmYWNlIGFsbW9zdCB0aGUgc2FtZSBpc3N1ZSB3aXRoIE1Q
TFMuIEluIG90aGVyIHdvcmRzLCB5b3Ugd291bGQgaGF2ZSB0byBhbGxvdyBlYWNoIGhvcCBhbG9u
ZyB0aGUgZXhwbGljaXQgcGF0aCB0byBrbm93IHdoaWNoIElQdjYgYWRkcmVzcyBhIGdpdmVuIHNl
Z21lbnQgSUQgc3RhbmRzIGZvci4gUmVtZW1iZXIgdGhhdCB0aGVzZSBzZWdtZW50IElEcyBhcmUg
bm9uLWFnZ3JlZ2F0YWJsZSBhcyB3ZWxsLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBT
YWlkIHRoaXMgb25lIG5lZWRzIHRvIGNsZWFybHkgZGVjb3VwbGUgTVBMUyB1c2UgZm9yIGFwcGxp
Y2F0aW9uIGRlbXV4DQo+IChMMlZQTiBvciBMM1ZQTikgZnJvbSBNUExTIHVzZSBmb3IgdHJhbnNw
b3J0LiBUaGUgbGF0dGVyIGlzIHByZXR0eQ0KPiBtdWNoIGRlYWQgZW5kIGFzIGZhciBhcyBJIGNh
biBzZWUgd2hpbGUgdGhlIGZvcm1lciB3b3JrcyB2ZXJ5IHdlbGwgYW5kDQo+IGl0IHdvdWxkIGJl
IGEgbWlzdGFrZSB0byBwcm9wb3NlIHRvIGNoYW5nZSBvciByZXBsYWNlIGl0Lg0KPiANCj4gQmVz
dCByZWdhcmRzLA0KPiBSLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAN
Cj4gDQo+IE9uIFRodSwgT2N0IDEwLCAyMDEzIGF0IDEwOjQ4IFBNLCBBc2h3b29kc21pdGhQZXRl
cg0KPiA8UGV0ZXIuQXNod29vZFNtaXRoQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IFJvYmVydCwN
Cj4gPg0KPiA+IE1vc3Qgb2YgdGhlIFRPUidzIGFuZCBjb3JlIERDIHN3aXRjaGVzIGhhdmUgTVBM
UyBkYXRhIHBsYW5lcyBhbHJlYWR5IGJ1aWx0DQo+IGludG8gdGhlIEFTSUNzLCBpdCdzIGp1c3Qg
dHVybmVkIG9mZi4gSXQgd291bGQgbm90IGJlIHRlcnJpYmx5IGRpZmZpY3VsdCBhY3R1YWxseSB0
bw0KPiBoYXZlIGEgSHlwZXJ2aXNvciBhdHRhY2ggYW4gbiBob3Agb3Igc28gbGFiZWwgc3RhY2sg
YW5kIGhhdmUgdGhlIFRPUiBhbmQgU3BpbmUNCj4gc3dpdGNoZXMgZG8gcG9wIGFuZCBmb3J3YXJk
IHdpdGhvdXQgaGF2aW5nIHRvIGVuYWJsZSBhbGwgdGhlIE1QTFMgY29udHJvbA0KPiBwbGFuZXMu
IEluIG15IGxhYiBmb3IgZXhhbXBsZSBJIGNvdWxkIGVhc2lseSBkbyB0aGF0IHdpdGggbW9zdCBv
ZiBteSAyMCBvZGQNCj4gc3dpdGNoZXMgb2YgZGlmZmVyZW50IGZsYXZvcnMgYW5kIEknbSBzdXJl
IHRoYXQncyB0cnVlIG9mIG1vc3Qgb2YgdGhlIG90aGVyDQo+IHZlbmRvcidzIERDIGdlYXIvc3dp
dGNoZXMgdG9vLiBPZiBjb3Vyc2UgeW91J2Qgd2FudCBhIG5ldyBmb3JtIG9mIGNvbnRyb2wNCj4g
KFNETiBjb21lcyB0byBtaW5kKSwgYnV0IHRoYXQncyB0cnVlIGlmIHlvdSB1c2UgVjYgb3B0aW9u
cywgTVBMUywgQUNMICdnYW1lcycNCj4gb3Igd2hhdGV2ZXIuIFRoZSBvdGhlciBhZHZhbnRhZ2Ug
b2YgTVBMUyBpbiB0aGF0IGNvbnRleHQgaXMgdGhhdCB3aGVuIHRoZQ0KPiBmcmFtZSBmaW5hbGx5
IGFycml2ZXMgYXQgYSBWUkYgaXQgY2FuIHVzZSBNUExTIElQVlBOIChvciBMMlZQTikgZGF0YSBw
bGFuZQ0KPiBzZW1hbnRpY3MgaW5zdGVhZCBvZiBzb21ldGhpbmcgbmV3IHRoYXQgbmVlZHMgbmV3
IGhhcmR3YXJlLiBUaGUgbWFpbg0KPiBjb25zdHJhaW50IGFzIGZhciBhcyBJIGFtIGF3YXJlIGlz
IHRoZSBsaW1pdGVkIHN0YWNrIGRlcHRoIGF2YWlsYWJsZSBvbiBpbml0aWFsDQo+IHB1c2ggYnkg
c29tZSBBU0lDcy4gT2YgY291cnNlIHRoYXQncyBub3QgYSBwcm9ibGVtIGZvciB0aGUgSHlwZXJ2
aXNvciB0bw0KPiAgIFZSRiBkaXJlY3Rpb24sIG9yIEh5cGVydmlzb3IgdG8gSHlwZXJ2aXNvciBi
dXQgaXQgaXMgYSBwcm9ibGVtIGZvciBhIFZSRiB0bw0KPiBIeXBlcnZpc29yIChvcmlnaW4gaXMg
b2Z0ZW4gYW4gQVNJQykuIE9mIGNvdXJzZSBpbiB0aGUgREMgeW91IGFyZSBnb2luZyBsaW1pdGVk
DQo+IGhvcHMgYW55d2F5IHNvIHRoYXQgbWF5IG5vdCBiZSBhIGNvbmNlcm4uDQo+ID4NCj4gPiBI
b3dldmVyIGFuIGFyZWEgdGhhdCBkb2VzIGNvbmNlcm4gbWUgaXMgbW9iaWxlIGJhY2toYXVsLiBJ
biB0aGF0IGNhc2UgYW4NCj4gTVBMUyBsYWJlbCBzdGFjayBpcyBwb3RlbnRpYWxseSBhIHNpZ25p
ZmljYW50IG92ZXJoZWFkIGFuZCB3ZSBtYXkgd2FudCB0bw0KPiBhZGRyZXNzIGl0IGluIHNvbWUg
ZnV0dXJlIHZlcnNpb24uIEkgaGF2ZSBhIGJpdCBvZiByZWFsIFNQIGRhdGEgKFBEVSBzaXplDQo+
IGRpc3RyaWJ1dGlvbnMpIHRoYXQgc2hvd3MgaXQgY29tcGFyZWQgdG8gb3RoZXIgdHlwZXMgb2Yg
U1AgbGlua3Mgd2hpY2ggSSBjYW4NCj4gc2hvdyBpbiBWYW5jb3V2ZXIgaWYgdGhlcmUgaXMgaW50
ZXJlc3QuDQo+ID4NCj4gPiBQZXRlcg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVr
QGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydA0KPiBSYXN6dWsNCj4gPiBTZW50OiBUaHVy
c2RheSwgT2N0b2JlciAxMCwgMjAxMyA0OjA1IFBNDQo+ID4gVG86IEpvaG4gRSBEcmFrZQ0KPiA+
IENjOiBBc2h3b29kc21pdGhQZXRlcjsgc3RicnlhbnRAY2lzY28uY29tOyBBZHJpYW4gRmFycmVs
OyBzdGF0dXNAaWV0Zi5vcmc7DQo+IEVYVCAtIGpvZWxqYUBib2d1cy5jb207IEJlbm9pdCBDbGFp
c2U7IEphcmkgQXJra287IEpvaG4gRy4gU2N1ZGRlcjsgQWx2YXJvDQo+IFJldGFuYQ0KPiA+IFN1
YmplY3Q6IFJlOiBbU3RhdHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+ID4NCj4gPiBIaSBKb2huLA0K
PiA+DQo+ID4gU2ltcGxlIHF1ZXN0aW9uIC4uLg0KPiA+DQo+ID4gSWYgSSBoYXZlIG5vIE1QTFMg
aW4gYW55IG9mIHRoZSBkYXRhIGNlbnRlciBob3cgY2FuIEkgdXNlIHNlZ21lbnQNCj4gPiByb3V0
aW5nIGluIHRob3NlIGVudmlyb25tZW50cyA/DQo+ID4NCj4gPiBJcyB5b3VyIGFuc3dlciB0byBk
ZXBsb3kgTVBMUyBmb3IgdHJhbnNwb3J0IGluIGFsbCBkYXRhIGNlbnRlcnMgb3INCj4gPiBqdXN0
IG5vdCB1c2Ugc2VnbWVudCByb3V0aW5nIHRoZXJlIGF0IGFsbCA/DQo+ID4NCj4gPiBNYW55IHRo
eCwNCj4gPiBSLg0KPiA+DQo+ID4NCj4gPiBPbiBUaHUsIE9jdCAxMCwgMjAxMyBhdCA5OjQxIFBN
LCBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+ID4+IFBldGVyLA0K
PiA+Pg0KPiA+PiBJIGNvbXBsZXRlbHkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc2ltcGx5IGZvY3Vz
IG9uIE1QTFMgYmVjYXVzZSwgYXMgeW91DQo+IG5vdGUsIGl0IHdpbGwgc3VwcG9ydCBJUHY2IGFz
IHdlbGwgYXMgSVB2NC4NCj4gPj4NCj4gPj4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRoYXQg
TVBMUyB3aWxsIG5lZWQgdG8gYmUgZXZvbHZlZCBpbiBvcmRlciB0byBzdXBwb3J0DQo+IFNwcmlu
Zy4gIFNlZSwgZm9yIGV4YW1wbGUsDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWdyZWRsZXItc3ByaW5nLW1wbHMtMDANCj4gPj4NCj4gPj4gWW91cnMgSXJyZXNwZWN0aXZlbHks
DQo+ID4+DQo+ID4+IEpvaG4NCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+ID4+PiBGcm9tOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YNCj4gPj4+IEFzaHdvb2RzbWl0aFBldGVyDQo+
ID4+PiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMCwgMjAxMyAxMjozMSBQTQ0KPiA+Pj4gVG86
IHN0YnJ5YW50QGNpc2NvLmNvbTsgQWRyaWFuIEZhcnJlbDsgc3RhdHVzQGlldGYub3JnDQo+ID4+
PiBDYzogRVhUIC0gam9lbGphQGJvZ3VzLmNvbTsgQmVub2l0IENsYWlzZTsgSmFyaSBBcmtrbzsg
Sm9obiBHLiBTY3VkZGVyOw0KPiBBbHZhcm8NCj4gPj4+IFJldGFuYQ0KPiA+Pj4gU3ViamVjdDog
UmU6IFtTdGF0dXNdIFN0YXR1cyBvZiBTcHJpbmcNCj4gPj4+DQo+ID4+PiBJIGNhbiB1bmRlcnN0
YW5kIHRoZSBjb25jZXJuLiBNYWtpbmcgYSBuZXcgb3B0aW9uIGZvciBWNiBleHBvc2VzIGl0IHRv
DQo+IG1pc3VzZQ0KPiA+Pj4gYnkgdGhlIGVuZHBvaW50cyBhcyB3YXMgcHJldmlvdXNseSB0aGUg
Y2FzZSBmb3IgdjQuDQo+ID4+Pg0KPiA+Pj4gV2hhdCBpcyB3cm9uZyB3aXRoIGFuIGFwcHJvYWNo
IHRoYXQgaXMgTVBMUyBmaXJzdCBhbmQgdGhlbiBhbiBldm9sdXRpb24gb2YNCj4gPj4+IE1QTFM/
IFRoYXQgd291bGQgd29yayBmb3IgSVBWNi9WNCBvciB3aGF0ZXZlciBlbHNlIGdvZXMgb24gdG9w
Lg0KPiA+Pj4NCj4gPj4+IEkgbWVhbiBpcyBpdCBoZXJlc3kgdG8gc3VnZ2VzdCB0aGF0IHdlIHNo
b3VsZCBldm9sdmUgTVBMUyBpbiB0aGUgZnV0dXJlPw0KPiA+Pj4NCj4gPj4+IFBldGVyDQo+ID4+
Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IHN0YXR1cy1i
b3VuY2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
Zg0KPiBPZg0KPiA+Pj4gU3Rld2FydCBCcnlhbnQNCj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBPY3Rv
YmVyIDEwLCAyMDEzIDI6NTIgUE0NCj4gPj4+IFRvOiBBZHJpYW4gRmFycmVsOyBzdGF0dXNAaWV0
Zi5vcmcNCj4gPj4+IENjOiBKb2VsIEphZWdnbGk7IEJlbm9pdCBDbGFpc2U7IEphcmkgQXJra287
IEpvaG4gRy4gU2N1ZGRlcjsgQWx2YXJvIFJldGFuYQ0KPiA+Pj4gU3ViamVjdDogW1N0YXR1c10g
U3RhdHVzIG9mIFNwcmluZw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGUgU1BSSU5HIGNoYXJ0ZXIg
d2FzIGRpc2N1c3NlZCBvbiB0aGUgdGVsZWNoYXQgdG9kYXkuIFdlIGhhdmUgYSBzbWFsbA0KPiA+
Pj4gaXNzdWUgd2l0aCB0aGUgT0FNIGFuZCBtYW5hZ2VtZW50IGRlbGl2ZXJhYmxlIHRleHQgdGhh
dCBJIGFtIHdvcmtpbmcNCj4gd2l0aA0KPiA+Pj4gQmVub2l0Lg0KPiA+Pj4NCj4gPj4+IFRoZSBs
YXJnZXN0IHN0aWNraW5nIHBvaW50IGlzIHRoZSBJUHY2IHRleHQsIHdoZXJlIGEgbnVtYmVyIG9m
IEFEcyBhcmUNCj4gPj4+IGNvbmNlcm5lZCB0aGF0IGdpdmVuIHRoZSBwcmV2aW91cyBzZWN1cml0
eSBpc3N1ZXMgd2l0aCBzb3VyY2Ugcm91dGluZywgdGhleQ0KPiBhcmUNCj4gPj4+IGNvbmNlcm5l
ZCBhdCB0aGUgZGlmZmljdWx0eSB3ZSBmYWNlIHNpZ25pZmljYW50IGRpZmZpY3VsdHkgZGVzaWdu
aW5nIGENCj4gc2F0aXNmYWN0b3J5DQo+ID4+PiBJUHY2IHNvbHV0aW9uLg0KPiA+Pj4gVGhlcmUg
d2FzIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgY2FsbCBhYm91dCBsaW1pdGVkIG5ldHdvcmsgc2Nv
cGUsIGJ1dA0KPiA+Pj4gY29uY2VybiB3YXMgZXhwcmVzc2VkIHRoYXQgb25jZSB0aGUgZmVhdHVy
ZSB3YXMgaW4gdGhlIHdpbGQsIHRoZSBzY29wZQ0KPiB3b3VsZA0KPiA+Pj4gYmUgZGlmZmljdWx0
IHRvIGNvbnRyb2wuDQo+ID4+Pg0KPiA+Pj4gSmFyaSB3aG8gaXMgdGhlIG1haW4gZGlzY3VzcyBo
b2xkZXIgd2lsbCB3b3JrIHdpdGggdXMgb3ZlciB0aGUgbmV4dCBjb3VwbGUgb2YNCj4gPj4+IGRh
eXMgdG8gdHJ5IHRvIGdldCBzb21lIHRleHQgdGhhdCB3aWxsIGFsbG93IHVzIHRvIGdvIGZvcndh
cmQuIFRoZSBnb2FsIGlzIHRvDQo+IGdldA0KPiA+Pj4gdGhlIGNoYXJ0ZXIgaW50byBleHRlcm5h
bCByZXZpZXcgYnkgTW9uZGF5IG5pZ2h0IHNvIGl0IGNhbiBnbyB0byBleHRlcm5hbA0KPiA+Pj4g
cmV2aWV3IG9uIFR1ZXNkYXkgYW5kIGJlIG9uIHRoZSBmb2xsb3dpbmcgdGVsZWNoYXQgZm9yIGFw
cHJvdmFsIGJ5DQo+IFZhbmNvdXZlci4NCj4gPj4+DQo+ID4+PiBDdXJyZW50bHkgU1BSSU5HIGlz
IG9mIGNvdXJzZSBhIEJPRiBhbmQgSSBoYXZlIGFza2VkIEFsdmFybyBSZXRhbmEsIGFuZA0KPiBK
b2huDQo+ID4+PiBTY3VkZGVyIHRvIGNoYWlyIHRoZSBCT0YgaW4gVmFub3V2ZXIuDQo+ID4+Pg0K
PiA+Pj4gSWYgdGhlIGNoYXJ0ZXIgdGV4dCBzdGlsbCBoYXMgdW5yZXNvbHZlZCBpc3N1ZXMgYnkg
dGhlIHRpbWUgd2UgbWVldCBpbg0KPiA+Pj4gVmFuY291dmVyLCB0aGVuIHRoZXkgc2hvdWxkIGJl
IHRoZSBmaXJzdCBwcmlvcml0eSBvbiB0aGUgYWdlbmRhLg0KPiA+Pj4NCj4gPj4+IC0gU3Rld2Fy
dA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+
ID4+PiBzdGF0dXNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc3RhdHVzDQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+Pj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+Pj4gc3RhdHVzQGll
dGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1
cw0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gPj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+PiBzdGF0dXNA
aWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0
dXMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
c3RhdHVzIG1haWxpbmcgbGlzdA0KPiBzdGF0dXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCg==

From rraszuk@gmail.com  Fri Oct 11 00:26:22 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39A311E8133 for ; Fri, 11 Oct 2013 00:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.839
X-Spam-Level: *
X-Spam-Status: No, score=1.839 tagged_above=-999 required=5 tests=[AWL=-3.817,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4PyqzdOIYB1 for ; Fri, 11 Oct 2013 00:26:21 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CED6111E8138 for ; Fri, 11 Oct 2013 00:26:16 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id x18so3039360lbi.31 for ; Fri, 11 Oct 2013 00:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZIgxhb7a/ABh23S1OUJzc0edboFlW0Twr09kTGEXVwU=; b=K+B/Dba7hZgZJgKN9ONoDSlhkQPLnFIrLgUu3qQCjw8OvnCnbtnlXgPe0PMijS3zMv 5eg61R7q/X+BXqcOBbdxlPDTTET2IL59gM+LB2uPCEp4kpqgqcBpSmSHfRv/Je76LIYn fwFrB3gTJzEGA1lZn3NwC9H5p9RsC13aRO2ciRA01pSfH/p0+mtcHE3YssK/d4SSdg4f K3bWkJDDT0Tqq8MiQorqgGfUG7al9OnKn5gb6xq/JKjHAL4qkAr/UQiY6bJXrKNQ69fU bX4JCYF1mH/fksxIPhf+i5ib5og9PbaMkmu/90Bh7zuF8hdoisAKO3h6Sfhacdcv+/Ud id0A==
MIME-Version: 1.0
X-Received: by 10.152.120.5 with SMTP id ky5mr15192378lab.18.1381476369134; Fri, 11 Oct 2013 00:26:09 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.112.138.33 with HTTP; Fri, 11 Oct 2013 00:26:09 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082154DA@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082154DA@NKGEML512-MBS.china.huawei.com>
Date: Fri, 11 Oct 2013 09:26:09 +0200
X-Google-Sender-Auth: 1ufFdjaXZjOlyahzrp9_wtfpqKw
Message-ID: 
From: Robert Raszuk 
To: Xuxiaohu 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] =?gb2312?b?tPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 07:26:22 -0000

Xiaohu,

The difference is that endpoint of SR encap does not need to be a SID.
It can be normal BGP next hop fully able to be aggregated/summarized.

Few key SIDs as transit nodes or service nodes are all ok to be not
aggregatable.

If required we need to modify the SR architecture if it enforces today
that end point must be express as SID.

Best,
R.


On Fri, Oct 11, 2013 at 3:50 AM, Xuxiaohu  wrote:
> Robert,
>
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: status-bounces@ietf.org [mailto:status-bounces@ietf.=
org] =B4=FA=B1=ED
>> Robert Raszuk
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA10=D4=C211=C8=D5 4:58
>> =CA=D5=BC=FE=C8=CB: AshwoodsmithPeter
>> =B3=AD=CB=CD: status@ietf.org
>> =D6=F7=CC=E2: Re: [Status] Status of Spring
>>
>> Peter,
>>
>> I admire your optimism stating that it will not be terribly difficult
>> to enable linux kernel support for MPLS encapsulation as well as build
>> IGP or LDP signalling into stock hypervisors. I think we could
>> continue this topic when linux supports all of the above.
>>
>> However the issue is not with MPLS in the hypervisor or not. The issue
>> is with lack of summarization and enforcement of exact FEC match which
>> MPLS architecture mandates. With IP transport and subnet lookup all
>> works just fine without any exact match needed of FEC to next hop.
>
> Unless you want to specify an explicit path by using a list of IPv6 addre=
sses in a source routed packet, rather than a list of short segment IDs, yo=
u would face almost the same issue with MPLS. In other words, you would hav=
e to allow each hop along the explicit path to know which IPv6 address a gi=
ven segment ID stands for. Remember that these segment IDs are non-aggregat=
able as well.
>
> Best regards,
> Xiaohu
>
>> Said this one needs to clearly decouple MPLS use for application demux
>> (L2VPN or L3VPN) from MPLS use for transport. The latter is pretty
>> much dead end as far as I can see while the former works very well and
>> it would be a mistake to propose to change or replace it.
>>
>> Best regards,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 10, 2013 at 10:48 PM, AshwoodsmithPeter
>>  wrote:
>> > Robert,
>> >
>> > Most of the TOR's and core DC switches have MPLS data planes already b=
uilt
>> into the ASICs, it's just turned off. It would not be terribly difficult=
 actually to
>> have a Hypervisor attach an n hop or so label stack and have the TOR and=
 Spine
>> switches do pop and forward without having to enable all the MPLS contro=
l
>> planes. In my lab for example I could easily do that with most of my 20 =
odd
>> switches of different flavors and I'm sure that's true of most of the ot=
her
>> vendor's DC gear/switches too. Of course you'd want a new form of contro=
l
>> (SDN comes to mind), but that's true if you use V6 options, MPLS, ACL 'g=
ames'
>> or whatever. The other advantage of MPLS in that context is that when th=
e
>> frame finally arrives at a VRF it can use MPLS IPVPN (or L2VPN) data pla=
ne
>> semantics instead of something new that needs new hardware. The main
>> constraint as far as I am aware is the limited stack depth available on =
initial
>> push by some ASICs. Of course that's not a problem for the Hypervisor to
>>   VRF direction, or Hypervisor to Hypervisor but it is a problem for a V=
RF to
>> Hypervisor (origin is often an ASIC). Of course in the DC you are going =
limited
>> hops anyway so that may not be a concern.
>> >
>> > However an area that does concern me is mobile backhaul. In that case =
an
>> MPLS label stack is potentially a significant overhead and we may want t=
o
>> address it in some future version. I have a bit of real SP data (PDU siz=
e
>> distributions) that shows it compared to other types of SP links which I=
 can
>> show in Vancouver if there is interest.
>> >
>> > Peter
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
>> Raszuk
>> > Sent: Thursday, October 10, 2013 4:05 PM
>> > To: John E Drake
>> > Cc: AshwoodsmithPeter; stbryant@cisco.com; Adrian Farrel; status@ietf.=
org;
>> EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alva=
ro
>> Retana
>> > Subject: Re: [Status] Status of Spring
>> >
>> > Hi John,
>> >
>> > Simple question ...
>> >
>> > If I have no MPLS in any of the data center how can I use segment
>> > routing in those environments ?
>> >
>> > Is your answer to deploy MPLS for transport in all data centers or
>> > just not use segment routing there at all ?
>> >
>> > Many thx,
>> > R.
>> >
>> >
>> > On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wro=
te:
>> >> Peter,
>> >>
>> >> I completely agree that we should simply focus on MPLS because, as yo=
u
>> note, it will support IPv6 as well as IPv4.
>> >>
>> >> However, it is not clear that MPLS will need to be evolved in order t=
o support
>> Spring.  See, for example,
>> http://tools.ietf.org/html/draft-gredler-spring-mpls-00
>> >>
>> >> Yours Irrespectively,
>> >>
>> >> John
>> >>
>> >>> -----Original Message-----
>> >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Be=
half
>> Of
>> >>> AshwoodsmithPeter
>> >>> Sent: Thursday, October 10, 2013 12:31 PM
>> >>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
>> >>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudd=
er;
>> Alvaro
>> >>> Retana
>> >>> Subject: Re: [Status] Status of Spring
>> >>>
>> >>> I can understand the concern. Making a new option for V6 exposes it =
to
>> misuse
>> >>> by the endpoints as was previously the case for v4.
>> >>>
>> >>> What is wrong with an approach that is MPLS first and then an evolut=
ion of
>> >>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
>> >>>
>> >>> I mean is it heresy to suggest that we should evolve MPLS in the fut=
ure?
>> >>>
>> >>> Peter
>> >>>
>> >>> -----Original Message-----
>> >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Be=
half
>> Of
>> >>> Stewart Bryant
>> >>> Sent: Thursday, October 10, 2013 2:52 PM
>> >>> To: Adrian Farrel; status@ietf.org
>> >>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro=
 Retana
>> >>> Subject: [Status] Status of Spring
>> >>>
>> >>>
>> >>> The SPRING charter was discussed on the telechat today. We have a sm=
all
>> >>> issue with the OAM and management deliverable text that I am working
>> with
>> >>> Benoit.
>> >>>
>> >>> The largest sticking point is the IPv6 text, where a number of ADs a=
re
>> >>> concerned that given the previous security issues with source routin=
g, they
>> are
>> >>> concerned at the difficulty we face significant difficulty designing=
 a
>> satisfactory
>> >>> IPv6 solution.
>> >>> There was some discussion on the call about limited network scope, b=
ut
>> >>> concern was expressed that once the feature was in the wild, the sco=
pe
>> would
>> >>> be difficult to control.
>> >>>
>> >>> Jari who is the main discuss holder will work with us over the next =
couple of
>> >>> days to try to get some text that will allow us to go forward. The g=
oal is to
>> get
>> >>> the charter into external review by Monday night so it can go to ext=
ernal
>> >>> review on Tuesday and be on the following telechat for approval by
>> Vancouver.
>> >>>
>> >>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, =
and
>> John
>> >>> Scudder to chair the BOF in Vanouver.
>> >>>
>> >>> If the charter text still has unresolved issues by the time we meet =
in
>> >>> Vancouver, then they should be the first priority on the agenda.
>> >>>
>> >>> - Stewart
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> status mailing list
>> >>> status@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/status
>> >>> _______________________________________________
>> >>> status mailing list
>> >>> status@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/status
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> status mailing list
>> >> status@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/status
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status

From xuxiaohu@huawei.com  Fri Oct 11 02:37:12 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30DB21E80C1 for ; Fri, 11 Oct 2013 02:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.092
X-Spam-Level: 
X-Spam-Status: No, score=0.092 tagged_above=-999 required=5 tests=[AWL=-2.696,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXzM+V5vCHn0 for ; Fri, 11 Oct 2013 02:37:08 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E539821E81B2 for ; Fri, 11 Oct 2013 02:36:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWS13922; Fri, 11 Oct 2013 09:36:57 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 10:35:55 +0100
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 10:36:32 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 17:36:20 +0800
From: Xuxiaohu 
To: Robert Raszuk 
Thread-Topic: =?gb2312?B?tPC4tDogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw==?=
Thread-Index: AQHOxftv4CKyAtw8vUuUlcOO89jTl5nuuTXA///bB4CAAKB1IA==
Date: Fri, 11 Oct 2013 09:36:20 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082156A6@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082154DA@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: [Status] =?gb2312?b?tPC4tDogtPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 09:37:13 -0000

Um9iZXJ0LA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHJyYXN6dWtAZ21haWwu
Y29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dILT6se0gUm9iZXJ0IFJhc3p1aw0KPiC3osvN
yrG85DogMjAxM8TqMTDUwjExyNUgMTU6MjYNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCzrcvNOiBB
c2h3b29kc21pdGhQZXRlcjsgc3RhdHVzQGlldGYub3JnDQo+INb3zOI6IFJlOiC08Li0OiBbU3Rh
dHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+IA0KPiBYaWFvaHUsDQo+IA0KPiBUaGUgZGlmZmVyZW5j
ZSBpcyB0aGF0IGVuZHBvaW50IG9mIFNSIGVuY2FwIGRvZXMgbm90IG5lZWQgdG8gYmUgYSBTSUQu
DQo+IEl0IGNhbiBiZSBub3JtYWwgQkdQIG5leHQgaG9wIGZ1bGx5IGFibGUgdG8gYmUgYWdncmVn
YXRlZC9zdW1tYXJpemVkLg0KDQpEaWQgeW91IG1lYW4gdGhhdCB0aGUgZmluYWwgZGVzdGluYXRp
b24gYWRkcmVzcyB3b3VsZCBiZSBzdG9yZWQgaW4gYSBzZXBhcmF0ZSBmaWVsZCBvdGhlciB0aGFu
IHRoZSBib3R0b20gb2Ygc2VnbWVudCBJRCBsaXN0PyANCg0KQlRXLCBpdCBzZWVtIHRoYXQgeW91
IGNvdWxkIHJlYWxpemUgdGhlIGFib3ZlIGdvYWwgYXMgd2VsbCBieSB1c2luZyB0aGUgTVBMUyBs
YWJlbCBzdGFjayB0ZWNobm9sb2d5LiBGb3IgZXhhbXBsZSwgYXNzdW1lIHNvdXJjZSBub2RlIEEg
d2FudHMgdG8gc2VuZCBhIHBhY2tldCB0byBkZXN0aW5hdGlvbiBub2RlIFogdmlhIGFuIGV4cGxp
Y2l0IHBhdGgge1gsIFksIFp9LCAgQSBjb3VsZCBlbmNhcHN1bGF0ZSB0aGUgcGFja2V0IGZpcnN0
IHdpdGggR1JFIGVuY2Fwc3VsYXRpb24gd2l0aCB0dW5uZWwgc291cmNlIG9mIEEgYW5kIHR1bm5l
bCBkZXN0aW5hdGlvbiBvZiBaLCBhbmQgdGhlbiBhcHBlbmQgc2VnbWVudCBsYWJlbHMgZm9yIFkg
YW5kIFggaW4gdHVybiB0byB0aGUgR1JFIGVuY2Fwc3VsYXRlZCBwYWNrZXQuIE9uY2UgdGhhdCBw
YWNrZXQgYXJyaXZlcyBhdCBZLCBZIHdvdWxkIHN0cmlwIHRoZSBzZWdtZW50IGxhYmVsIGZvciBZ
IGFuZCB0aGVuIGZvcndhcmQgdGhlIGRlY2Fwc3VhbHRlZCBHUkUgcGFja2V0IHRvIFouDQoNCkJl
c3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IEZldyBrZXkgU0lEcyBhcyB0cmFuc2l0IG5vZGVzIG9y
IHNlcnZpY2Ugbm9kZXMgYXJlIGFsbCBvayB0byBiZSBub3QNCj4gYWdncmVnYXRhYmxlLg0KPiAN
Cj4gSWYgcmVxdWlyZWQgd2UgbmVlZCB0byBtb2RpZnkgdGhlIFNSIGFyY2hpdGVjdHVyZSBpZiBp
dCBlbmZvcmNlcyB0b2RheQ0KPiB0aGF0IGVuZCBwb2ludCBtdXN0IGJlIGV4cHJlc3MgYXMgU0lE
Lg0KPiANCj4gQmVzdCwNCj4gUi4NCj4gDQo+IA0KPiBPbiBGcmksIE9jdCAxMSwgMjAxMyBhdCAz
OjUwIEFNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gUm9iZXJ0
LA0KPiA+DQo+ID4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+PiC3orz+yMs6IHN0YXR1cy1ib3Vu
Y2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gPj4g
Um9iZXJ0IFJhc3p1aw0KPiA+PiC3osvNyrG85DogMjAxM8TqMTDUwjExyNUgNDo1OA0KPiA+PiDK
1bz+yMs6IEFzaHdvb2RzbWl0aFBldGVyDQo+ID4+ILOty806IHN0YXR1c0BpZXRmLm9yZw0KPiA+
PiDW98ziOiBSZTogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiA+Pg0KPiA+PiBQZXRlciwN
Cj4gPj4NCj4gPj4gSSBhZG1pcmUgeW91ciBvcHRpbWlzbSBzdGF0aW5nIHRoYXQgaXQgd2lsbCBu
b3QgYmUgdGVycmlibHkgZGlmZmljdWx0DQo+ID4+IHRvIGVuYWJsZSBsaW51eCBrZXJuZWwgc3Vw
cG9ydCBmb3IgTVBMUyBlbmNhcHN1bGF0aW9uIGFzIHdlbGwgYXMgYnVpbGQNCj4gPj4gSUdQIG9y
IExEUCBzaWduYWxsaW5nIGludG8gc3RvY2sgaHlwZXJ2aXNvcnMuIEkgdGhpbmsgd2UgY291bGQN
Cj4gPj4gY29udGludWUgdGhpcyB0b3BpYyB3aGVuIGxpbnV4IHN1cHBvcnRzIGFsbCBvZiB0aGUg
YWJvdmUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIgdGhlIGlzc3VlIGlzIG5vdCB3aXRoIE1QTFMgaW4g
dGhlIGh5cGVydmlzb3Igb3Igbm90LiBUaGUgaXNzdWUNCj4gPj4gaXMgd2l0aCBsYWNrIG9mIHN1
bW1hcml6YXRpb24gYW5kIGVuZm9yY2VtZW50IG9mIGV4YWN0IEZFQyBtYXRjaCB3aGljaA0KPiA+
PiBNUExTIGFyY2hpdGVjdHVyZSBtYW5kYXRlcy4gV2l0aCBJUCB0cmFuc3BvcnQgYW5kIHN1Ym5l
dCBsb29rdXAgYWxsDQo+ID4+IHdvcmtzIGp1c3QgZmluZSB3aXRob3V0IGFueSBleGFjdCBtYXRj
aCBuZWVkZWQgb2YgRkVDIHRvIG5leHQgaG9wLg0KPiA+DQo+ID4gVW5sZXNzIHlvdSB3YW50IHRv
IHNwZWNpZnkgYW4gZXhwbGljaXQgcGF0aCBieSB1c2luZyBhIGxpc3Qgb2YgSVB2NiBhZGRyZXNz
ZXMgaW4NCj4gYSBzb3VyY2Ugcm91dGVkIHBhY2tldCwgcmF0aGVyIHRoYW4gYSBsaXN0IG9mIHNo
b3J0IHNlZ21lbnQgSURzLCB5b3Ugd291bGQgZmFjZQ0KPiBhbG1vc3QgdGhlIHNhbWUgaXNzdWUg
d2l0aCBNUExTLiBJbiBvdGhlciB3b3JkcywgeW91IHdvdWxkIGhhdmUgdG8gYWxsb3cgZWFjaA0K
PiBob3AgYWxvbmcgdGhlIGV4cGxpY2l0IHBhdGggdG8ga25vdyB3aGljaCBJUHY2IGFkZHJlc3Mg
YSBnaXZlbiBzZWdtZW50IElEDQo+IHN0YW5kcyBmb3IuIFJlbWVtYmVyIHRoYXQgdGhlc2Ugc2Vn
bWVudCBJRHMgYXJlIG5vbi1hZ2dyZWdhdGFibGUgYXMgd2VsbC4NCj4gPg0KPiA+IEJlc3QgcmVn
YXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBTYWlkIHRoaXMgb25lIG5lZWRzIHRvIGNsZWFy
bHkgZGVjb3VwbGUgTVBMUyB1c2UgZm9yIGFwcGxpY2F0aW9uIGRlbXV4DQo+ID4+IChMMlZQTiBv
ciBMM1ZQTikgZnJvbSBNUExTIHVzZSBmb3IgdHJhbnNwb3J0LiBUaGUgbGF0dGVyIGlzIHByZXR0
eQ0KPiA+PiBtdWNoIGRlYWQgZW5kIGFzIGZhciBhcyBJIGNhbiBzZWUgd2hpbGUgdGhlIGZvcm1l
ciB3b3JrcyB2ZXJ5IHdlbGwgYW5kDQo+ID4+IGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0byBwcm9w
b3NlIHRvIGNoYW5nZSBvciByZXBsYWNlIGl0Lg0KPiA+Pg0KPiA+PiBCZXN0IHJlZ2FyZHMsDQo+
ID4+IFIuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+
ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFRodSwgT2N0IDEwLCAyMDEzIGF0IDEwOjQ4IFBNLCBB
c2h3b29kc21pdGhQZXRlcg0KPiA+PiA8UGV0ZXIuQXNod29vZFNtaXRoQGh1YXdlaS5jb20+IHdy
b3RlOg0KPiA+PiA+IFJvYmVydCwNCj4gPj4gPg0KPiA+PiA+IE1vc3Qgb2YgdGhlIFRPUidzIGFu
ZCBjb3JlIERDIHN3aXRjaGVzIGhhdmUgTVBMUyBkYXRhIHBsYW5lcyBhbHJlYWR5DQo+IGJ1aWx0
DQo+ID4+IGludG8gdGhlIEFTSUNzLCBpdCdzIGp1c3QgdHVybmVkIG9mZi4gSXQgd291bGQgbm90
IGJlIHRlcnJpYmx5IGRpZmZpY3VsdCBhY3R1YWxseSB0bw0KPiA+PiBoYXZlIGEgSHlwZXJ2aXNv
ciBhdHRhY2ggYW4gbiBob3Agb3Igc28gbGFiZWwgc3RhY2sgYW5kIGhhdmUgdGhlIFRPUiBhbmQN
Cj4gU3BpbmUNCj4gPj4gc3dpdGNoZXMgZG8gcG9wIGFuZCBmb3J3YXJkIHdpdGhvdXQgaGF2aW5n
IHRvIGVuYWJsZSBhbGwgdGhlIE1QTFMgY29udHJvbA0KPiA+PiBwbGFuZXMuIEluIG15IGxhYiBm
b3IgZXhhbXBsZSBJIGNvdWxkIGVhc2lseSBkbyB0aGF0IHdpdGggbW9zdCBvZiBteSAyMCBvZGQN
Cj4gPj4gc3dpdGNoZXMgb2YgZGlmZmVyZW50IGZsYXZvcnMgYW5kIEknbSBzdXJlIHRoYXQncyB0
cnVlIG9mIG1vc3Qgb2YgdGhlIG90aGVyDQo+ID4+IHZlbmRvcidzIERDIGdlYXIvc3dpdGNoZXMg
dG9vLiBPZiBjb3Vyc2UgeW91J2Qgd2FudCBhIG5ldyBmb3JtIG9mIGNvbnRyb2wNCj4gPj4gKFNE
TiBjb21lcyB0byBtaW5kKSwgYnV0IHRoYXQncyB0cnVlIGlmIHlvdSB1c2UgVjYgb3B0aW9ucywg
TVBMUywgQUNMDQo+ICdnYW1lcycNCj4gPj4gb3Igd2hhdGV2ZXIuIFRoZSBvdGhlciBhZHZhbnRh
Z2Ugb2YgTVBMUyBpbiB0aGF0IGNvbnRleHQgaXMgdGhhdCB3aGVuIHRoZQ0KPiA+PiBmcmFtZSBm
aW5hbGx5IGFycml2ZXMgYXQgYSBWUkYgaXQgY2FuIHVzZSBNUExTIElQVlBOIChvciBMMlZQTikg
ZGF0YSBwbGFuZQ0KPiA+PiBzZW1hbnRpY3MgaW5zdGVhZCBvZiBzb21ldGhpbmcgbmV3IHRoYXQg
bmVlZHMgbmV3IGhhcmR3YXJlLiBUaGUgbWFpbg0KPiA+PiBjb25zdHJhaW50IGFzIGZhciBhcyBJ
IGFtIGF3YXJlIGlzIHRoZSBsaW1pdGVkIHN0YWNrIGRlcHRoIGF2YWlsYWJsZSBvbiBpbml0aWFs
DQo+ID4+IHB1c2ggYnkgc29tZSBBU0lDcy4gT2YgY291cnNlIHRoYXQncyBub3QgYSBwcm9ibGVt
IGZvciB0aGUgSHlwZXJ2aXNvciB0bw0KPiA+PiAgIFZSRiBkaXJlY3Rpb24sIG9yIEh5cGVydmlz
b3IgdG8gSHlwZXJ2aXNvciBidXQgaXQgaXMgYSBwcm9ibGVtIGZvciBhIFZSRiB0bw0KPiA+PiBI
eXBlcnZpc29yIChvcmlnaW4gaXMgb2Z0ZW4gYW4gQVNJQykuIE9mIGNvdXJzZSBpbiB0aGUgREMg
eW91IGFyZSBnb2luZyBsaW1pdGVkDQo+ID4+IGhvcHMgYW55d2F5IHNvIHRoYXQgbWF5IG5vdCBi
ZSBhIGNvbmNlcm4uDQo+ID4+ID4NCj4gPj4gPiBIb3dldmVyIGFuIGFyZWEgdGhhdCBkb2VzIGNv
bmNlcm4gbWUgaXMgbW9iaWxlIGJhY2toYXVsLiBJbiB0aGF0IGNhc2UgYW4NCj4gPj4gTVBMUyBs
YWJlbCBzdGFjayBpcyBwb3RlbnRpYWxseSBhIHNpZ25pZmljYW50IG92ZXJoZWFkIGFuZCB3ZSBt
YXkgd2FudCB0bw0KPiA+PiBhZGRyZXNzIGl0IGluIHNvbWUgZnV0dXJlIHZlcnNpb24uIEkgaGF2
ZSBhIGJpdCBvZiByZWFsIFNQIGRhdGEgKFBEVSBzaXplDQo+ID4+IGRpc3RyaWJ1dGlvbnMpIHRo
YXQgc2hvd3MgaXQgY29tcGFyZWQgdG8gb3RoZXIgdHlwZXMgb2YgU1AgbGlua3Mgd2hpY2ggSSBj
YW4NCj4gPj4gc2hvdyBpbiBWYW5jb3V2ZXIgaWYgdGhlcmUgaXMgaW50ZXJlc3QuDQo+ID4+ID4N
Cj4gPj4gPiBQZXRlcg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpy
cmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+IFJvYmVydA0KPiA+PiBSYXN6dWsNCj4g
Pj4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMCwgMjAxMyA0OjA1IFBNDQo+ID4+ID4gVG86
IEpvaG4gRSBEcmFrZQ0KPiA+PiA+IENjOiBBc2h3b29kc21pdGhQZXRlcjsgc3RicnlhbnRAY2lz
Y28uY29tOyBBZHJpYW4gRmFycmVsOw0KPiBzdGF0dXNAaWV0Zi5vcmc7DQo+ID4+IEVYVCAtIGpv
ZWxqYUBib2d1cy5jb207IEJlbm9pdCBDbGFpc2U7IEphcmkgQXJra287IEpvaG4gRy4gU2N1ZGRl
cjsgQWx2YXJvDQo+ID4+IFJldGFuYQ0KPiA+PiA+IFN1YmplY3Q6IFJlOiBbU3RhdHVzXSBTdGF0
dXMgb2YgU3ByaW5nDQo+ID4+ID4NCj4gPj4gPiBIaSBKb2huLA0KPiA+PiA+DQo+ID4+ID4gU2lt
cGxlIHF1ZXN0aW9uIC4uLg0KPiA+PiA+DQo+ID4+ID4gSWYgSSBoYXZlIG5vIE1QTFMgaW4gYW55
IG9mIHRoZSBkYXRhIGNlbnRlciBob3cgY2FuIEkgdXNlIHNlZ21lbnQNCj4gPj4gPiByb3V0aW5n
IGluIHRob3NlIGVudmlyb25tZW50cyA/DQo+ID4+ID4NCj4gPj4gPiBJcyB5b3VyIGFuc3dlciB0
byBkZXBsb3kgTVBMUyBmb3IgdHJhbnNwb3J0IGluIGFsbCBkYXRhIGNlbnRlcnMgb3INCj4gPj4g
PiBqdXN0IG5vdCB1c2Ugc2VnbWVudCByb3V0aW5nIHRoZXJlIGF0IGFsbCA/DQo+ID4+ID4NCj4g
Pj4gPiBNYW55IHRoeCwNCj4gPj4gPiBSLg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBPbiBUaHUs
IE9jdCAxMCwgMjAxMyBhdCA5OjQxIFBNLCBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5l
dD4NCj4gd3JvdGU6DQo+ID4+ID4+IFBldGVyLA0KPiA+PiA+Pg0KPiA+PiA+PiBJIGNvbXBsZXRl
bHkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc2ltcGx5IGZvY3VzIG9uIE1QTFMgYmVjYXVzZSwgYXMg
eW91DQo+ID4+IG5vdGUsIGl0IHdpbGwgc3VwcG9ydCBJUHY2IGFzIHdlbGwgYXMgSVB2NC4NCj4g
Pj4gPj4NCj4gPj4gPj4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRoYXQgTVBMUyB3aWxsIG5l
ZWQgdG8gYmUgZXZvbHZlZCBpbiBvcmRlciB0bw0KPiBzdXBwb3J0DQo+ID4+IFNwcmluZy4gIFNl
ZSwgZm9yIGV4YW1wbGUsDQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdy
ZWRsZXItc3ByaW5nLW1wbHMtMDANCj4gPj4gPj4NCj4gPj4gPj4gWW91cnMgSXJyZXNwZWN0aXZl
bHksDQo+ID4+ID4+DQo+ID4+ID4+IEpvaG4NCj4gPj4gPj4NCj4gPj4gPj4+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+PiBGcm9tOiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBb
bWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPj4gT2YNCj4g
Pj4gPj4+IEFzaHdvb2RzbWl0aFBldGVyDQo+ID4+ID4+PiBTZW50OiBUaHVyc2RheSwgT2N0b2Jl
ciAxMCwgMjAxMyAxMjozMSBQTQ0KPiA+PiA+Pj4gVG86IHN0YnJ5YW50QGNpc2NvLmNvbTsgQWRy
aWFuIEZhcnJlbDsgc3RhdHVzQGlldGYub3JnDQo+ID4+ID4+PiBDYzogRVhUIC0gam9lbGphQGJv
Z3VzLmNvbTsgQmVub2l0IENsYWlzZTsgSmFyaSBBcmtrbzsgSm9obiBHLiBTY3VkZGVyOw0KPiA+
PiBBbHZhcm8NCj4gPj4gPj4+IFJldGFuYQ0KPiA+PiA+Pj4gU3ViamVjdDogUmU6IFtTdGF0dXNd
IFN0YXR1cyBvZiBTcHJpbmcNCj4gPj4gPj4+DQo+ID4+ID4+PiBJIGNhbiB1bmRlcnN0YW5kIHRo
ZSBjb25jZXJuLiBNYWtpbmcgYSBuZXcgb3B0aW9uIGZvciBWNiBleHBvc2VzIGl0IHRvDQo+ID4+
IG1pc3VzZQ0KPiA+PiA+Pj4gYnkgdGhlIGVuZHBvaW50cyBhcyB3YXMgcHJldmlvdXNseSB0aGUg
Y2FzZSBmb3IgdjQuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gV2hhdCBpcyB3cm9uZyB3aXRoIGFuIGFw
cHJvYWNoIHRoYXQgaXMgTVBMUyBmaXJzdCBhbmQgdGhlbiBhbiBldm9sdXRpb24NCj4gb2YNCj4g
Pj4gPj4+IE1QTFM/IFRoYXQgd291bGQgd29yayBmb3IgSVBWNi9WNCBvciB3aGF0ZXZlciBlbHNl
IGdvZXMgb24gdG9wLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEkgbWVhbiBpcyBpdCBoZXJlc3kgdG8g
c3VnZ2VzdCB0aGF0IHdlIHNob3VsZCBldm9sdmUgTVBMUyBpbiB0aGUgZnV0dXJlPw0KPiA+PiA+
Pj4NCj4gPj4gPj4+IFBldGVyDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gPj4gPj4+IEZyb206IHN0YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86
c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+PiBPZg0KPiA+PiA+Pj4g
U3Rld2FydCBCcnlhbnQNCj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEwLCAyMDEz
IDI6NTIgUE0NCj4gPj4gPj4+IFRvOiBBZHJpYW4gRmFycmVsOyBzdGF0dXNAaWV0Zi5vcmcNCj4g
Pj4gPj4+IENjOiBKb2VsIEphZWdnbGk7IEJlbm9pdCBDbGFpc2U7IEphcmkgQXJra287IEpvaG4g
Ry4gU2N1ZGRlcjsgQWx2YXJvIFJldGFuYQ0KPiA+PiA+Pj4gU3ViamVjdDogW1N0YXR1c10gU3Rh
dHVzIG9mIFNwcmluZw0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+PiBUaGUgU1BSSU5HIGNo
YXJ0ZXIgd2FzIGRpc2N1c3NlZCBvbiB0aGUgdGVsZWNoYXQgdG9kYXkuIFdlIGhhdmUgYQ0KPiBz
bWFsbA0KPiA+PiA+Pj4gaXNzdWUgd2l0aCB0aGUgT0FNIGFuZCBtYW5hZ2VtZW50IGRlbGl2ZXJh
YmxlIHRleHQgdGhhdCBJIGFtIHdvcmtpbmcNCj4gPj4gd2l0aA0KPiA+PiA+Pj4gQmVub2l0Lg0K
PiA+PiA+Pj4NCj4gPj4gPj4+IFRoZSBsYXJnZXN0IHN0aWNraW5nIHBvaW50IGlzIHRoZSBJUHY2
IHRleHQsIHdoZXJlIGEgbnVtYmVyIG9mIEFEcyBhcmUNCj4gPj4gPj4+IGNvbmNlcm5lZCB0aGF0
IGdpdmVuIHRoZSBwcmV2aW91cyBzZWN1cml0eSBpc3N1ZXMgd2l0aCBzb3VyY2Ugcm91dGluZywN
Cj4gdGhleQ0KPiA+PiBhcmUNCj4gPj4gPj4+IGNvbmNlcm5lZCBhdCB0aGUgZGlmZmljdWx0eSB3
ZSBmYWNlIHNpZ25pZmljYW50IGRpZmZpY3VsdHkgZGVzaWduaW5nIGENCj4gPj4gc2F0aXNmYWN0
b3J5DQo+ID4+ID4+PiBJUHY2IHNvbHV0aW9uLg0KPiA+PiA+Pj4gVGhlcmUgd2FzIHNvbWUgZGlz
Y3Vzc2lvbiBvbiB0aGUgY2FsbCBhYm91dCBsaW1pdGVkIG5ldHdvcmsgc2NvcGUsIGJ1dA0KPiA+
PiA+Pj4gY29uY2VybiB3YXMgZXhwcmVzc2VkIHRoYXQgb25jZSB0aGUgZmVhdHVyZSB3YXMgaW4g
dGhlIHdpbGQsIHRoZSBzY29wZQ0KPiA+PiB3b3VsZA0KPiA+PiA+Pj4gYmUgZGlmZmljdWx0IHRv
IGNvbnRyb2wuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSmFyaSB3aG8gaXMgdGhlIG1haW4gZGlzY3Vz
cyBob2xkZXIgd2lsbCB3b3JrIHdpdGggdXMgb3ZlciB0aGUgbmV4dA0KPiBjb3VwbGUgb2YNCj4g
Pj4gPj4+IGRheXMgdG8gdHJ5IHRvIGdldCBzb21lIHRleHQgdGhhdCB3aWxsIGFsbG93IHVzIHRv
IGdvIGZvcndhcmQuIFRoZSBnb2FsIGlzDQo+IHRvDQo+ID4+IGdldA0KPiA+PiA+Pj4gdGhlIGNo
YXJ0ZXIgaW50byBleHRlcm5hbCByZXZpZXcgYnkgTW9uZGF5IG5pZ2h0IHNvIGl0IGNhbiBnbyB0
byBleHRlcm5hbA0KPiA+PiA+Pj4gcmV2aWV3IG9uIFR1ZXNkYXkgYW5kIGJlIG9uIHRoZSBmb2xs
b3dpbmcgdGVsZWNoYXQgZm9yIGFwcHJvdmFsIGJ5DQo+ID4+IFZhbmNvdXZlci4NCj4gPj4gPj4+
DQo+ID4+ID4+PiBDdXJyZW50bHkgU1BSSU5HIGlzIG9mIGNvdXJzZSBhIEJPRiBhbmQgSSBoYXZl
IGFza2VkIEFsdmFybyBSZXRhbmEsIGFuZA0KPiA+PiBKb2huDQo+ID4+ID4+PiBTY3VkZGVyIHRv
IGNoYWlyIHRoZSBCT0YgaW4gVmFub3V2ZXIuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSWYgdGhlIGNo
YXJ0ZXIgdGV4dCBzdGlsbCBoYXMgdW5yZXNvbHZlZCBpc3N1ZXMgYnkgdGhlIHRpbWUgd2UgbWVl
dCBpbg0KPiA+PiA+Pj4gVmFuY291dmVyLCB0aGVuIHRoZXkgc2hvdWxkIGJlIHRoZSBmaXJzdCBw
cmlvcml0eSBvbiB0aGUgYWdlbmRhLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IC0gU3Rld2FydA0KPiA+
PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiBzdGF0dXMgbWFp
bGluZyBsaXN0DQo+ID4+ID4+PiBzdGF0dXNAaWV0Zi5vcmcNCj4gPj4gPj4+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQo+ID4+ID4+PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4gc3RhdHVzIG1haWxp
bmcgbGlzdA0KPiA+PiA+Pj4gc3RhdHVzQGlldGYub3JnDQo+ID4+ID4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPiA+PiA+Pj4NCj4gPj4gPj4NCj4gPj4g
Pj4NCj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPj4gPj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+PiA+PiBzdGF0dXNAaWV0Zi5vcmcN
Cj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCj4g
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4g
c3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+PiBzdGF0dXNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCg==

From xuxiaohu@huawei.com  Fri Oct 11 03:16:04 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615A321E81CC for ; Fri, 11 Oct 2013 03:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.542
X-Spam-Level: 
X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=-2.247,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IzCJOHa3FqB for ; Fri, 11 Oct 2013 03:16:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8021E8151 for ; Fri, 11 Oct 2013 03:15:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYZ14101; Fri, 11 Oct 2013 10:15:50 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 11:15:16 +0100
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 11:15:45 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 18:15:31 +0800
From: Xuxiaohu 
To: Robert Raszuk 
Thread-Topic: =?gb2312?B?tPC4tDogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw==?=
Thread-Index: AQHOxftv4CKyAtw8vUuUlcOO89jTl5nuuTXA///bB4CAALN94A==
Date: Fri, 11 Oct 2013 10:15:30 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082156C8@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082154DA@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: [Status] =?gb2312?b?tPC4tDogtPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 10:16:04 -0000

DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogcnJhc3p1a0BnbWFpbC5jb20gW21h
aWx0bzpycmFzenVrQGdtYWlsLmNvbV0gtPqx7SBSb2JlcnQgUmFzenVrDQo+ILeiy83KsbzkOiAy
MDEzxOoxMNTCMTHI1SAxNToyNg0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IEFzaHdvb2Rz
bWl0aFBldGVyOyBzdGF0dXNAaWV0Zi5vcmcNCj4g1vfM4jogUmU6ILTwuLQ6IFtTdGF0dXNdIFN0
YXR1cyBvZiBTcHJpbmcNCj4gDQo+IFhpYW9odSwNCj4gDQo+IFRoZSBkaWZmZXJlbmNlIGlzIHRo
YXQgZW5kcG9pbnQgb2YgU1IgZW5jYXAgZG9lcyBub3QgbmVlZCB0byBiZSBhIFNJRC4NCj4gSXQg
Y2FuIGJlIG5vcm1hbCBCR1AgbmV4dCBob3AgZnVsbHkgYWJsZSB0byBiZSBhZ2dyZWdhdGVkL3N1
bW1hcml6ZWQuDQo+IA0KPiBGZXcga2V5IFNJRHMgYXMgdHJhbnNpdCBub2RlcyBvciBzZXJ2aWNl
IG5vZGVzIGFyZSBhbGwgb2sgdG8gYmUgbm90DQo+IGFnZ3JlZ2F0YWJsZS4NCj4gDQo+IElmIHJl
cXVpcmVkIHdlIG5lZWQgdG8gbW9kaWZ5IHRoZSBTUiBhcmNoaXRlY3R1cmUgaWYgaXQgZW5mb3Jj
ZXMgdG9kYXkNCj4gdGhhdCBlbmQgcG9pbnQgbXVzdCBiZSBleHByZXNzIGFzIFNJRC4NCg0KUm9i
ZXJ0LA0KDQpCVFcsIERpZCB5b3UgcmVmZXIgdG8gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtZmlsc2ZpbHMtcnRnd2ctc2VnbWVudC1yb3V0aW5nLTAwIGJ5IFNSIGFyY2hpdGVjdHVy
ZT8gIEkgaGF2ZSBub3QgZm91bmQgYW55IHN0YXRlbWVudCBhcyB5b3Ugc2FpZCBpbiB0aGF0IGRv
Yy4gSW5zdGVhZCwgaW4gc2VjdGlvbiAzLjEuICBJbGx1c3RyYXRpb24gb2YgdGhhdCBkb2MsIGl0
IHNhaWQgdGhlIGVuZHBvaW50IGlzIGFzc2lnbmVkIGEgbm9kZSBzZWdtZW50IElEIGFuZCB0aGF0
IHNlZ21lbnQgSUQgaXMgcGxhY2VkIGF0IHRoZSBib3R0b20gb2YgdGhlIHNlZ21lbnQgSUQgbGlz
dC4NCg0KWGlhb2h1DQoNCj4gQmVzdCwNCj4gUi4NCj4gDQo+IA0KPiBPbiBGcmksIE9jdCAxMSwg
MjAxMyBhdCAzOjUwIEFNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+
ID4gUm9iZXJ0LA0KPiA+DQo+ID4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+PiC3orz+yMs6IHN0
YXR1cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6
se0NCj4gPj4gUm9iZXJ0IFJhc3p1aw0KPiA+PiC3osvNyrG85DogMjAxM8TqMTDUwjExyNUgNDo1
OA0KPiA+PiDK1bz+yMs6IEFzaHdvb2RzbWl0aFBldGVyDQo+ID4+ILOty806IHN0YXR1c0BpZXRm
Lm9yZw0KPiA+PiDW98ziOiBSZTogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiA+Pg0KPiA+
PiBQZXRlciwNCj4gPj4NCj4gPj4gSSBhZG1pcmUgeW91ciBvcHRpbWlzbSBzdGF0aW5nIHRoYXQg
aXQgd2lsbCBub3QgYmUgdGVycmlibHkgZGlmZmljdWx0DQo+ID4+IHRvIGVuYWJsZSBsaW51eCBr
ZXJuZWwgc3VwcG9ydCBmb3IgTVBMUyBlbmNhcHN1bGF0aW9uIGFzIHdlbGwgYXMgYnVpbGQNCj4g
Pj4gSUdQIG9yIExEUCBzaWduYWxsaW5nIGludG8gc3RvY2sgaHlwZXJ2aXNvcnMuIEkgdGhpbmsg
d2UgY291bGQNCj4gPj4gY29udGludWUgdGhpcyB0b3BpYyB3aGVuIGxpbnV4IHN1cHBvcnRzIGFs
bCBvZiB0aGUgYWJvdmUuDQo+ID4+DQo+ID4+IEhvd2V2ZXIgdGhlIGlzc3VlIGlzIG5vdCB3aXRo
IE1QTFMgaW4gdGhlIGh5cGVydmlzb3Igb3Igbm90LiBUaGUgaXNzdWUNCj4gPj4gaXMgd2l0aCBs
YWNrIG9mIHN1bW1hcml6YXRpb24gYW5kIGVuZm9yY2VtZW50IG9mIGV4YWN0IEZFQyBtYXRjaCB3
aGljaA0KPiA+PiBNUExTIGFyY2hpdGVjdHVyZSBtYW5kYXRlcy4gV2l0aCBJUCB0cmFuc3BvcnQg
YW5kIHN1Ym5ldCBsb29rdXAgYWxsDQo+ID4+IHdvcmtzIGp1c3QgZmluZSB3aXRob3V0IGFueSBl
eGFjdCBtYXRjaCBuZWVkZWQgb2YgRkVDIHRvIG5leHQgaG9wLg0KPiA+DQo+ID4gVW5sZXNzIHlv
dSB3YW50IHRvIHNwZWNpZnkgYW4gZXhwbGljaXQgcGF0aCBieSB1c2luZyBhIGxpc3Qgb2YgSVB2
NiBhZGRyZXNzZXMgaW4NCj4gYSBzb3VyY2Ugcm91dGVkIHBhY2tldCwgcmF0aGVyIHRoYW4gYSBs
aXN0IG9mIHNob3J0IHNlZ21lbnQgSURzLCB5b3Ugd291bGQgZmFjZQ0KPiBhbG1vc3QgdGhlIHNh
bWUgaXNzdWUgd2l0aCBNUExTLiBJbiBvdGhlciB3b3JkcywgeW91IHdvdWxkIGhhdmUgdG8gYWxs
b3cgZWFjaA0KPiBob3AgYWxvbmcgdGhlIGV4cGxpY2l0IHBhdGggdG8ga25vdyB3aGljaCBJUHY2
IGFkZHJlc3MgYSBnaXZlbiBzZWdtZW50IElEDQo+IHN0YW5kcyBmb3IuIFJlbWVtYmVyIHRoYXQg
dGhlc2Ugc2VnbWVudCBJRHMgYXJlIG5vbi1hZ2dyZWdhdGFibGUgYXMgd2VsbC4NCj4gPg0KPiA+
IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBTYWlkIHRoaXMgb25lIG5lZWRz
IHRvIGNsZWFybHkgZGVjb3VwbGUgTVBMUyB1c2UgZm9yIGFwcGxpY2F0aW9uIGRlbXV4DQo+ID4+
IChMMlZQTiBvciBMM1ZQTikgZnJvbSBNUExTIHVzZSBmb3IgdHJhbnNwb3J0LiBUaGUgbGF0dGVy
IGlzIHByZXR0eQ0KPiA+PiBtdWNoIGRlYWQgZW5kIGFzIGZhciBhcyBJIGNhbiBzZWUgd2hpbGUg
dGhlIGZvcm1lciB3b3JrcyB2ZXJ5IHdlbGwgYW5kDQo+ID4+IGl0IHdvdWxkIGJlIGEgbWlzdGFr
ZSB0byBwcm9wb3NlIHRvIGNoYW5nZSBvciByZXBsYWNlIGl0Lg0KPiA+Pg0KPiA+PiBCZXN0IHJl
Z2FyZHMsDQo+ID4+IFIuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIFRodSwgT2N0IDEwLCAyMDEzIGF0IDEw
OjQ4IFBNLCBBc2h3b29kc21pdGhQZXRlcg0KPiA+PiA8UGV0ZXIuQXNod29vZFNtaXRoQGh1YXdl
aS5jb20+IHdyb3RlOg0KPiA+PiA+IFJvYmVydCwNCj4gPj4gPg0KPiA+PiA+IE1vc3Qgb2YgdGhl
IFRPUidzIGFuZCBjb3JlIERDIHN3aXRjaGVzIGhhdmUgTVBMUyBkYXRhIHBsYW5lcyBhbHJlYWR5
DQo+IGJ1aWx0DQo+ID4+IGludG8gdGhlIEFTSUNzLCBpdCdzIGp1c3QgdHVybmVkIG9mZi4gSXQg
d291bGQgbm90IGJlIHRlcnJpYmx5IGRpZmZpY3VsdCBhY3R1YWxseSB0bw0KPiA+PiBoYXZlIGEg
SHlwZXJ2aXNvciBhdHRhY2ggYW4gbiBob3Agb3Igc28gbGFiZWwgc3RhY2sgYW5kIGhhdmUgdGhl
IFRPUiBhbmQNCj4gU3BpbmUNCj4gPj4gc3dpdGNoZXMgZG8gcG9wIGFuZCBmb3J3YXJkIHdpdGhv
dXQgaGF2aW5nIHRvIGVuYWJsZSBhbGwgdGhlIE1QTFMgY29udHJvbA0KPiA+PiBwbGFuZXMuIElu
IG15IGxhYiBmb3IgZXhhbXBsZSBJIGNvdWxkIGVhc2lseSBkbyB0aGF0IHdpdGggbW9zdCBvZiBt
eSAyMCBvZGQNCj4gPj4gc3dpdGNoZXMgb2YgZGlmZmVyZW50IGZsYXZvcnMgYW5kIEknbSBzdXJl
IHRoYXQncyB0cnVlIG9mIG1vc3Qgb2YgdGhlIG90aGVyDQo+ID4+IHZlbmRvcidzIERDIGdlYXIv
c3dpdGNoZXMgdG9vLiBPZiBjb3Vyc2UgeW91J2Qgd2FudCBhIG5ldyBmb3JtIG9mIGNvbnRyb2wN
Cj4gPj4gKFNETiBjb21lcyB0byBtaW5kKSwgYnV0IHRoYXQncyB0cnVlIGlmIHlvdSB1c2UgVjYg
b3B0aW9ucywgTVBMUywgQUNMDQo+ICdnYW1lcycNCj4gPj4gb3Igd2hhdGV2ZXIuIFRoZSBvdGhl
ciBhZHZhbnRhZ2Ugb2YgTVBMUyBpbiB0aGF0IGNvbnRleHQgaXMgdGhhdCB3aGVuIHRoZQ0KPiA+
PiBmcmFtZSBmaW5hbGx5IGFycml2ZXMgYXQgYSBWUkYgaXQgY2FuIHVzZSBNUExTIElQVlBOIChv
ciBMMlZQTikgZGF0YSBwbGFuZQ0KPiA+PiBzZW1hbnRpY3MgaW5zdGVhZCBvZiBzb21ldGhpbmcg
bmV3IHRoYXQgbmVlZHMgbmV3IGhhcmR3YXJlLiBUaGUgbWFpbg0KPiA+PiBjb25zdHJhaW50IGFz
IGZhciBhcyBJIGFtIGF3YXJlIGlzIHRoZSBsaW1pdGVkIHN0YWNrIGRlcHRoIGF2YWlsYWJsZSBv
biBpbml0aWFsDQo+ID4+IHB1c2ggYnkgc29tZSBBU0lDcy4gT2YgY291cnNlIHRoYXQncyBub3Qg
YSBwcm9ibGVtIGZvciB0aGUgSHlwZXJ2aXNvciB0bw0KPiA+PiAgIFZSRiBkaXJlY3Rpb24sIG9y
IEh5cGVydmlzb3IgdG8gSHlwZXJ2aXNvciBidXQgaXQgaXMgYSBwcm9ibGVtIGZvciBhIFZSRiB0
bw0KPiA+PiBIeXBlcnZpc29yIChvcmlnaW4gaXMgb2Z0ZW4gYW4gQVNJQykuIE9mIGNvdXJzZSBp
biB0aGUgREMgeW91IGFyZSBnb2luZyBsaW1pdGVkDQo+ID4+IGhvcHMgYW55d2F5IHNvIHRoYXQg
bWF5IG5vdCBiZSBhIGNvbmNlcm4uDQo+ID4+ID4NCj4gPj4gPiBIb3dldmVyIGFuIGFyZWEgdGhh
dCBkb2VzIGNvbmNlcm4gbWUgaXMgbW9iaWxlIGJhY2toYXVsLiBJbiB0aGF0IGNhc2UgYW4NCj4g
Pj4gTVBMUyBsYWJlbCBzdGFjayBpcyBwb3RlbnRpYWxseSBhIHNpZ25pZmljYW50IG92ZXJoZWFk
IGFuZCB3ZSBtYXkgd2FudCB0bw0KPiA+PiBhZGRyZXNzIGl0IGluIHNvbWUgZnV0dXJlIHZlcnNp
b24uIEkgaGF2ZSBhIGJpdCBvZiByZWFsIFNQIGRhdGEgKFBEVSBzaXplDQo+ID4+IGRpc3RyaWJ1
dGlvbnMpIHRoYXQgc2hvd3MgaXQgY29tcGFyZWQgdG8gb3RoZXIgdHlwZXMgb2YgU1AgbGlua3Mg
d2hpY2ggSSBjYW4NCj4gPj4gc2hvdyBpbiBWYW5jb3V2ZXIgaWYgdGhlcmUgaXMgaW50ZXJlc3Qu
DQo+ID4+ID4NCj4gPj4gPiBQZXRlcg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4gRnJvbTogcnJhc3p1a0BnbWFpbC5jb20g
W21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mDQo+IFJvYmVydA0KPiA+PiBS
YXN6dWsNCj4gPj4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMCwgMjAxMyA0OjA1IFBNDQo+
ID4+ID4gVG86IEpvaG4gRSBEcmFrZQ0KPiA+PiA+IENjOiBBc2h3b29kc21pdGhQZXRlcjsgc3Ri
cnlhbnRAY2lzY28uY29tOyBBZHJpYW4gRmFycmVsOw0KPiBzdGF0dXNAaWV0Zi5vcmc7DQo+ID4+
IEVYVCAtIGpvZWxqYUBib2d1cy5jb207IEJlbm9pdCBDbGFpc2U7IEphcmkgQXJra287IEpvaG4g
Ry4gU2N1ZGRlcjsgQWx2YXJvDQo+ID4+IFJldGFuYQ0KPiA+PiA+IFN1YmplY3Q6IFJlOiBbU3Rh
dHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+ID4+ID4NCj4gPj4gPiBIaSBKb2huLA0KPiA+PiA+DQo+
ID4+ID4gU2ltcGxlIHF1ZXN0aW9uIC4uLg0KPiA+PiA+DQo+ID4+ID4gSWYgSSBoYXZlIG5vIE1Q
TFMgaW4gYW55IG9mIHRoZSBkYXRhIGNlbnRlciBob3cgY2FuIEkgdXNlIHNlZ21lbnQNCj4gPj4g
PiByb3V0aW5nIGluIHRob3NlIGVudmlyb25tZW50cyA/DQo+ID4+ID4NCj4gPj4gPiBJcyB5b3Vy
IGFuc3dlciB0byBkZXBsb3kgTVBMUyBmb3IgdHJhbnNwb3J0IGluIGFsbCBkYXRhIGNlbnRlcnMg
b3INCj4gPj4gPiBqdXN0IG5vdCB1c2Ugc2VnbWVudCByb3V0aW5nIHRoZXJlIGF0IGFsbCA/DQo+
ID4+ID4NCj4gPj4gPiBNYW55IHRoeCwNCj4gPj4gPiBSLg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4g
PiBPbiBUaHUsIE9jdCAxMCwgMjAxMyBhdCA5OjQxIFBNLCBKb2huIEUgRHJha2UgPGpkcmFrZUBq
dW5pcGVyLm5ldD4NCj4gd3JvdGU6DQo+ID4+ID4+IFBldGVyLA0KPiA+PiA+Pg0KPiA+PiA+PiBJ
IGNvbXBsZXRlbHkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgc2ltcGx5IGZvY3VzIG9uIE1QTFMgYmVj
YXVzZSwgYXMgeW91DQo+ID4+IG5vdGUsIGl0IHdpbGwgc3VwcG9ydCBJUHY2IGFzIHdlbGwgYXMg
SVB2NC4NCj4gPj4gPj4NCj4gPj4gPj4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRoYXQgTVBM
UyB3aWxsIG5lZWQgdG8gYmUgZXZvbHZlZCBpbiBvcmRlciB0bw0KPiBzdXBwb3J0DQo+ID4+IFNw
cmluZy4gIFNlZSwgZm9yIGV4YW1wbGUsDQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWdyZWRsZXItc3ByaW5nLW1wbHMtMDANCj4gPj4gPj4NCj4gPj4gPj4gWW91cnMgSXJy
ZXNwZWN0aXZlbHksDQo+ID4+ID4+DQo+ID4+ID4+IEpvaG4NCj4gPj4gPj4NCj4gPj4gPj4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+PiBGcm9tOiBzdGF0dXMtYm91bmNlc0Bp
ZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4g
Pj4gT2YNCj4gPj4gPj4+IEFzaHdvb2RzbWl0aFBldGVyDQo+ID4+ID4+PiBTZW50OiBUaHVyc2Rh
eSwgT2N0b2JlciAxMCwgMjAxMyAxMjozMSBQTQ0KPiA+PiA+Pj4gVG86IHN0YnJ5YW50QGNpc2Nv
LmNvbTsgQWRyaWFuIEZhcnJlbDsgc3RhdHVzQGlldGYub3JnDQo+ID4+ID4+PiBDYzogRVhUIC0g
am9lbGphQGJvZ3VzLmNvbTsgQmVub2l0IENsYWlzZTsgSmFyaSBBcmtrbzsgSm9obiBHLiBTY3Vk
ZGVyOw0KPiA+PiBBbHZhcm8NCj4gPj4gPj4+IFJldGFuYQ0KPiA+PiA+Pj4gU3ViamVjdDogUmU6
IFtTdGF0dXNdIFN0YXR1cyBvZiBTcHJpbmcNCj4gPj4gPj4+DQo+ID4+ID4+PiBJIGNhbiB1bmRl
cnN0YW5kIHRoZSBjb25jZXJuLiBNYWtpbmcgYSBuZXcgb3B0aW9uIGZvciBWNiBleHBvc2VzIGl0
IHRvDQo+ID4+IG1pc3VzZQ0KPiA+PiA+Pj4gYnkgdGhlIGVuZHBvaW50cyBhcyB3YXMgcHJldmlv
dXNseSB0aGUgY2FzZSBmb3IgdjQuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gV2hhdCBpcyB3cm9uZyB3
aXRoIGFuIGFwcHJvYWNoIHRoYXQgaXMgTVBMUyBmaXJzdCBhbmQgdGhlbiBhbiBldm9sdXRpb24N
Cj4gb2YNCj4gPj4gPj4+IE1QTFM/IFRoYXQgd291bGQgd29yayBmb3IgSVBWNi9WNCBvciB3aGF0
ZXZlciBlbHNlIGdvZXMgb24gdG9wLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEkgbWVhbiBpcyBpdCBo
ZXJlc3kgdG8gc3VnZ2VzdCB0aGF0IHdlIHNob3VsZCBldm9sdmUgTVBMUyBpbiB0aGUgZnV0dXJl
Pw0KPiA+PiA+Pj4NCj4gPj4gPj4+IFBldGVyDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4+IEZyb206IHN0YXR1cy1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZg0KPiA+PiBPZg0K
PiA+PiA+Pj4gU3Rld2FydCBCcnlhbnQNCj4gPj4gPj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVy
IDEwLCAyMDEzIDI6NTIgUE0NCj4gPj4gPj4+IFRvOiBBZHJpYW4gRmFycmVsOyBzdGF0dXNAaWV0
Zi5vcmcNCj4gPj4gPj4+IENjOiBKb2VsIEphZWdnbGk7IEJlbm9pdCBDbGFpc2U7IEphcmkgQXJr
a287IEpvaG4gRy4gU2N1ZGRlcjsgQWx2YXJvIFJldGFuYQ0KPiA+PiA+Pj4gU3ViamVjdDogW1N0
YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+PiBUaGUg
U1BSSU5HIGNoYXJ0ZXIgd2FzIGRpc2N1c3NlZCBvbiB0aGUgdGVsZWNoYXQgdG9kYXkuIFdlIGhh
dmUgYQ0KPiBzbWFsbA0KPiA+PiA+Pj4gaXNzdWUgd2l0aCB0aGUgT0FNIGFuZCBtYW5hZ2VtZW50
IGRlbGl2ZXJhYmxlIHRleHQgdGhhdCBJIGFtIHdvcmtpbmcNCj4gPj4gd2l0aA0KPiA+PiA+Pj4g
QmVub2l0Lg0KPiA+PiA+Pj4NCj4gPj4gPj4+IFRoZSBsYXJnZXN0IHN0aWNraW5nIHBvaW50IGlz
IHRoZSBJUHY2IHRleHQsIHdoZXJlIGEgbnVtYmVyIG9mIEFEcyBhcmUNCj4gPj4gPj4+IGNvbmNl
cm5lZCB0aGF0IGdpdmVuIHRoZSBwcmV2aW91cyBzZWN1cml0eSBpc3N1ZXMgd2l0aCBzb3VyY2Ug
cm91dGluZywNCj4gdGhleQ0KPiA+PiBhcmUNCj4gPj4gPj4+IGNvbmNlcm5lZCBhdCB0aGUgZGlm
ZmljdWx0eSB3ZSBmYWNlIHNpZ25pZmljYW50IGRpZmZpY3VsdHkgZGVzaWduaW5nIGENCj4gPj4g
c2F0aXNmYWN0b3J5DQo+ID4+ID4+PiBJUHY2IHNvbHV0aW9uLg0KPiA+PiA+Pj4gVGhlcmUgd2Fz
IHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgY2FsbCBhYm91dCBsaW1pdGVkIG5ldHdvcmsgc2NvcGUs
IGJ1dA0KPiA+PiA+Pj4gY29uY2VybiB3YXMgZXhwcmVzc2VkIHRoYXQgb25jZSB0aGUgZmVhdHVy
ZSB3YXMgaW4gdGhlIHdpbGQsIHRoZSBzY29wZQ0KPiA+PiB3b3VsZA0KPiA+PiA+Pj4gYmUgZGlm
ZmljdWx0IHRvIGNvbnRyb2wuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSmFyaSB3aG8gaXMgdGhlIG1h
aW4gZGlzY3VzcyBob2xkZXIgd2lsbCB3b3JrIHdpdGggdXMgb3ZlciB0aGUgbmV4dA0KPiBjb3Vw
bGUgb2YNCj4gPj4gPj4+IGRheXMgdG8gdHJ5IHRvIGdldCBzb21lIHRleHQgdGhhdCB3aWxsIGFs
bG93IHVzIHRvIGdvIGZvcndhcmQuIFRoZSBnb2FsIGlzDQo+IHRvDQo+ID4+IGdldA0KPiA+PiA+
Pj4gdGhlIGNoYXJ0ZXIgaW50byBleHRlcm5hbCByZXZpZXcgYnkgTW9uZGF5IG5pZ2h0IHNvIGl0
IGNhbiBnbyB0byBleHRlcm5hbA0KPiA+PiA+Pj4gcmV2aWV3IG9uIFR1ZXNkYXkgYW5kIGJlIG9u
IHRoZSBmb2xsb3dpbmcgdGVsZWNoYXQgZm9yIGFwcHJvdmFsIGJ5DQo+ID4+IFZhbmNvdXZlci4N
Cj4gPj4gPj4+DQo+ID4+ID4+PiBDdXJyZW50bHkgU1BSSU5HIGlzIG9mIGNvdXJzZSBhIEJPRiBh
bmQgSSBoYXZlIGFza2VkIEFsdmFybyBSZXRhbmEsIGFuZA0KPiA+PiBKb2huDQo+ID4+ID4+PiBT
Y3VkZGVyIHRvIGNoYWlyIHRoZSBCT0YgaW4gVmFub3V2ZXIuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4g
SWYgdGhlIGNoYXJ0ZXIgdGV4dCBzdGlsbCBoYXMgdW5yZXNvbHZlZCBpc3N1ZXMgYnkgdGhlIHRp
bWUgd2UgbWVldCBpbg0KPiA+PiA+Pj4gVmFuY291dmVyLCB0aGVuIHRoZXkgc2hvdWxkIGJlIHRo
ZSBmaXJzdCBwcmlvcml0eSBvbiB0aGUgYWdlbmRhLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IC0gU3Rl
d2FydA0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiBz
dGF0dXMgbWFpbGluZyBsaXN0DQo+ID4+ID4+PiBzdGF0dXNAaWV0Zi5vcmcNCj4gPj4gPj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQo+ID4+ID4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+Pj4gc3Rh
dHVzIG1haWxpbmcgbGlzdA0KPiA+PiA+Pj4gc3RhdHVzQGlldGYub3JnDQo+ID4+ID4+PiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YXR1cw0KPiA+PiA+Pj4NCj4gPj4g
Pj4NCj4gPj4gPj4NCj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gPj4gPj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+PiA+PiBzdGF0dXNA
aWV0Zi5vcmcNCj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z
dGF0dXMNCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+PiBzdGF0dXNAaWV0Zi5vcmcNCj4gPj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGF0dXMNCg==

From hannes@juniper.net  Fri Oct 11 04:07:50 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8F21F9CED for ; Fri, 11 Oct 2013 04:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.349
X-Spam-Level: 
X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BMGwMKZPeqD for ; Fri, 11 Oct 2013 04:07:45 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10121F9C78 for ; Fri, 11 Oct 2013 04:07:41 -0700 (PDT)
Received: from mail176-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 11:07:35 +0000
Received: from mail176-ch1 (localhost [127.0.0.1])	by mail176-ch1-R.bigfish.com (Postfix) with ESMTP id DF0194600D9; Fri, 11 Oct 2013 11:07:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zz98dI9371I542Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL177df4h17326ah19a27bh1de097h186068h172cdfh8275bh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail176-ch1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail176-ch1 (localhost.localdomain [127.0.0.1]) by mail176-ch1 (MessageSwitch) id 1381489653117726_13094; Fri, 11 Oct 2013 11:07:33 +0000 (UTC)
Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236])	by mail176-ch1.bigfish.com (Postfix) with ESMTP id 182D7120158;	Fri, 11 Oct 2013 11:07:33 +0000 (UTC)
Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 11:07:32 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 11:07:29 +0000
Date: Fri, 11 Oct 2013 13:07:24 +0200
From: Hannes Gredler 
To: Robert Raszuk 
Message-ID: <20131011110724.GB29384@juniper.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 11:07:50 -0000

robert,

On Thu, Oct 10, 2013 at 10:58:14PM +0200, Robert Raszuk wrote:
| I admire your optimism stating that it will not be terribly difficult
| to enable linux kernel support for MPLS encapsulation as well as build
| IGP or LDP signalling into stock hypervisors. I think we could
| continue this topic when linux supports all of the above.

please have a look at
http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=3DMain_Page
=20
| However the issue is not with MPLS in the hypervisor or not. The issue
| is with lack of summarization and enforcement of exact FEC match which
| MPLS architecture mandates. With IP transport and subnet lookup all
| works just fine without any exact match needed of FEC to next hop.

can you point me to the text which says so.
i could not find such a claim in rfc3031 ?

/hannes

| Said this one needs to clearly decouple MPLS use for application demux
| (L2VPN or L3VPN) from MPLS use for transport. The latter is pretty
| much dead end as far as I can see while the former works very well and
| it would be a mistake to propose to change or replace it.


=20
| On Thu, Oct 10, 2013 at 10:48 PM, AshwoodsmithPeter
|  wrote:
| > Robert,
| >
| > Most of the TOR's and core DC switches have MPLS data planes already bu=
ilt into the ASICs, it's just turned off. It would not be terribly difficul=
t actually to have a Hypervisor attach an n hop or so label stack and have =
the TOR and Spine switches do pop and forward without having to enable all =
the MPLS control planes. In my lab for example I could easily do that with =
most of my 20 odd  switches of different flavors and I'm sure that's true o=
f most of the other vendor's DC gear/switches too. Of course you'd want a n=
ew form of control (SDN comes to mind), but that's true if you use V6 optio=
ns, MPLS, ACL 'games' or whatever. The other advantage of MPLS in that cont=
ext is that when the frame finally arrives at a VRF it can use MPLS IPVPN (=
or L2VPN) data plane semantics instead of something new that needs new hard=
ware. The main constraint as far as I am aware is the limited stack depth a=
vailable on initial push by some ASICs. Of course that's not a problem for =
the Hypervisor to
|   VRF direction, or Hypervisor to Hypervisor but it is a problem for a VR=
F to Hypervisor (origin is often an ASIC). Of course in the DC you are goin=
g limited hops anyway so that may not be a concern.
| >
| > However an area that does concern me is mobile backhaul. In that case a=
n MPLS label stack is potentially a significant overhead and we may want to=
 address it in some future version. I have a bit of real SP data (PDU size =
distributions) that shows it compared to other types of SP links which I ca=
n show in Vancouver if there is interest.
| >
| > Peter
| >
| >
| >
| > -----Original Message-----
| > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert =
Raszuk
| > Sent: Thursday, October 10, 2013 4:05 PM
| > To: John E Drake
| > Cc: AshwoodsmithPeter; stbryant@cisco.com; Adrian Farrel; status@ietf.o=
rg; EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudder; Alv=
aro Retana
| > Subject: Re: [Status] Status of Spring
| >
| > Hi John,
| >
| > Simple question ...
| >
| > If I have no MPLS in any of the data center how can I use segment
| > routing in those environments ?
| >
| > Is your answer to deploy MPLS for transport in all data centers or
| > just not use segment routing there at all ?
| >
| > Many thx,
| > R.
| >
| >
| > On Thu, Oct 10, 2013 at 9:41 PM, John E Drake  wrot=
e:
| >> Peter,
| >>
| >> I completely agree that we should simply focus on MPLS because, as you=
 note, it will support IPv6 as well as IPv4.
| >>
| >> However, it is not clear that MPLS will need to be evolved in order to=
 support Spring.  See, for example, http://tools.ietf.org/html/draft-gredle=
r-spring-mpls-00
| >>
| >> Yours Irrespectively,
| >>
| >> John
| >>
| >>> -----Original Message-----
| >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Beh=
alf Of
| >>> AshwoodsmithPeter
| >>> Sent: Thursday, October 10, 2013 12:31 PM
| >>> To: stbryant@cisco.com; Adrian Farrel; status@ietf.org
| >>> Cc: EXT - joelja@bogus.com; Benoit Claise; Jari Arkko; John G. Scudde=
r; Alvaro
| >>> Retana
| >>> Subject: Re: [Status] Status of Spring
| >>>
| >>> I can understand the concern. Making a new option for V6 exposes it t=
o misuse
| >>> by the endpoints as was previously the case for v4.
| >>>
| >>> What is wrong with an approach that is MPLS first and then an evoluti=
on of
| >>> MPLS? That would work for IPV6/V4 or whatever else goes on top.
| >>>
| >>> I mean is it heresy to suggest that we should evolve MPLS in the futu=
re?
| >>>
| >>> Peter
| >>>
| >>> -----Original Message-----
| >>> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Beh=
alf Of
| >>> Stewart Bryant
| >>> Sent: Thursday, October 10, 2013 2:52 PM
| >>> To: Adrian Farrel; status@ietf.org
| >>> Cc: Joel Jaeggli; Benoit Claise; Jari Arkko; John G. Scudder; Alvaro =
Retana
| >>> Subject: [Status] Status of Spring
| >>>
| >>>
| >>> The SPRING charter was discussed on the telechat today. We have a sma=
ll
| >>> issue with the OAM and management deliverable text that I am working =
with
| >>> Benoit.
| >>>
| >>> The largest sticking point is the IPv6 text, where a number of ADs are
| >>> concerned that given the previous security issues with source routing=
, they are
| >>> concerned at the difficulty we face significant difficulty designing =
a satisfactory
| >>> IPv6 solution.
| >>> There was some discussion on the call about limited network scope, but
| >>> concern was expressed that once the feature was in the wild, the scop=
e would
| >>> be difficult to control.
| >>>
| >>> Jari who is the main discuss holder will work with us over the next c=
ouple of
| >>> days to try to get some text that will allow us to go forward. The go=
al is to get
| >>> the charter into external review by Monday night so it can go to exte=
rnal
| >>> review on Tuesday and be on the following telechat for approval by Va=
ncouver.
| >>>
| >>> Currently SPRING is of course a BOF and I have asked Alvaro Retana, a=
nd John
| >>> Scudder to chair the BOF in Vanouver.
| >>>
| >>> If the charter text still has unresolved issues by the time we meet in
| >>> Vancouver, then they should be the first priority on the agenda.
| >>>
| >>> - Stewart
| >>>
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> status mailing list
| >>> status@ietf.org
| >>> https://www.ietf.org/mailman/listinfo/status
| >>> _______________________________________________
| >>> status mailing list
| >>> status@ietf.org
| >>> https://www.ietf.org/mailman/listinfo/status
| >>>
| >>
| >>
| >> _______________________________________________
| >> status mailing list
| >> status@ietf.org
| >> https://www.ietf.org/mailman/listinfo/status
| _______________________________________________
| status mailing list
| status@ietf.org
| https://www.ietf.org/mailman/listinfo/status
|=20
|=20


From stbryant@cisco.com  Fri Oct 11 05:50:44 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE611E8163 for ; Fri, 11 Oct 2013 05:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.501
X-Spam-Level: 
X-Spam-Status: No, score=-110.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmWiU6yS109M for ; Fri, 11 Oct 2013 05:50:39 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCC011E8149 for ; Fri, 11 Oct 2013 05:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3130; q=dns/txt; s=iport; t=1381495836; x=1382705436; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SvawzwT9zWLSCGnxx+9voo+vGZKpLYTmvaVT8NB8bDw=; b=IVfjSQgpPd5Uob753w8Yug62UP76y//if4STGi/uNIzANqBTvV5p6p9R 1oVsvV5C1RFco/3HTvtk9sF5VMY212N079DWq5QwAp/DBeLk/Emk3P1/P 7T2QEavHSHxu2xtv366iOj6Y/iSAZp5NJWx4ZF1pWNYqr7SiGJa3rGMcw Y=;
X-IronPort-AV: E=Sophos;i="4.90,1080,1371081600"; d="scan'208";a="18691299"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 11 Oct 2013 12:50:33 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BCoQL6024317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 12:50:28 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9BCoMxb007501; Fri, 11 Oct 2013 13:50:23 +0100 (BST)
Message-ID: <5257F40E.5080700@cisco.com>
Date: Fri, 11 Oct 2013 13:50:22 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Jari Arkko 
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
In-Reply-To: <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joel Jaeggli , "John G. Scudder" , Alvaro Retana , Benoit Claise , Adrian Farrel , "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 12:50:44 -0000

On 10/10/2013 22:03, Jari Arkko wrote:
> Thanks Stewart and others.
>
> I wanted to add one clarification and some more technical discussion.
>
>> Jari who is the main discuss holder will work with us over
>> the next couple of days to try to get some text that will allow
>> us to go forward.
> I would really like to work with you to get this resolved. I see the issue, as I think do others, but I need your help in the WG to figure out what to do about it. I do not currently have a good idea, but I am sure we'll resolve it somehow. Some of you have already offered help - thanks.
>
> To provide a bit more context why just saying that we'll use it in closed networks is unlikely to work:
>
> The MPLS case was easy because these networks are naturally restricted to specific areas, and there is no way for a random person in some other part of the Internet to send you packets with MPLS labels.
>
> The basic problem with IP is that when someone defines a new source-routing header solution and applies it in network X, it does not affect just X. The code will be on various devices - with RH0 we had it on BSD, Linux, various brands of routers, maybe even on hosts, etc. Often turned on by default, leaving vulnerabilities open in many networks.
>
> We could say that the feature MUST be by default off and can only be enabled upon explicit request from the network manager.
> However, if I have a thousand devices in my network I start to worry that at least one of them has accidentally enabled the feature.
Are we talking routers or devices here?

In the routing world many bad things can happen if a router is 
misconfigured,
so I am not sure how this is special?

>   So now that device could potentially reflect traffic sent to it from the outside to an internal destination.
>   This could be used to subvert firewall policies, DoS attacks on nodes not visible from the Internet, etc. As a result of this worry I now have to turn on filtering on the border of my network for the new routing header. Is there a way around this?
I doubt it, although presumably you will not have enabled forwarding
on the new header unless you intended to forward on it.

Off by default is a good starting position, but is not charter text.
>
> Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.
The interest here is that people run multiple AS in a DC. We are not 
talking about this being
run on the Internet core.
>
> In any case, I could completely off base with the above - I have not read your proposed solutions and maybe you are thinking of something completely different, or have already found the clever solutions to the problem. I'm happy to learn more :-)
>

I am unaware of a solution sitting on the table, but the discussion is 
about the charter
text describing what people are going to work on. It is not a detailed 
evaluation of
a solution.

So what we are looking for here is charter text that provides the 
critical success factors that
determine whether a solution can be sent for publication.

Stewart



From rraszuk@gmail.com  Fri Oct 11 06:00:03 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0A21E8100 for ; Fri, 11 Oct 2013 06:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level: 
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=0.545,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMnZHtpY2-BV for ; Fri, 11 Oct 2013 06:00:03 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D85A221E8102 for ; Fri, 11 Oct 2013 06:00:02 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id x13so8338373ief.17 for ; Fri, 11 Oct 2013 06:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DQfHe43kcT9jzIu/Zp8G7iojs/+T7CEfbCKv+IEEhi0=; b=aXPa0qL1e6aocwwG8/l3HQIhnnEGELuDvQvpLZh5l6yjorrYxo+OZhXhiq29KHJzZe FbDSj09fgm3EbUfbZVA66NU0UBtNHrAq21/txbJypWNGyHvlwSHmyOf0If/4dUqULnmQ un/+wjS3qBFpF00sZMAd0RvLGZeC99DUQZWMrbp9SCF/lnH68lqa9B39K1MpNcEq/nc2 /Ruki1UXuVRXrYDD3Z8zY23y3ok6QmD++8Jk9HjuwFt9hjAP/ouTOdwgSxk6Q9LyTzKX 70U0kOUsuByxszSy2uoGuiW4Sr80FQzwSoBz7fsJQlR4H876SRD+ETY0PkHrLENo6iR4 EKlA==
MIME-Version: 1.0
X-Received: by 10.50.55.65 with SMTP id q1mr2696145igp.4.1381496402294; Fri, 11 Oct 2013 06:00:02 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 06:00:02 -0700 (PDT)
In-Reply-To: <20131011110724.GB29384@juniper.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>
Date: Fri, 11 Oct 2013 15:00:02 +0200
X-Google-Sender-Auth: w7G_i6816qk-VnhuUMKFzEgkD3g
Message-ID: 
From: Robert Raszuk 
To: Hannes Gredler 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 13:00:03 -0000

Hannes,

> please have a look at
> http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page

Are we talking lab/experiments or production ? Please point me to any
linux distribution which officially supports this. Also please point
me to the official linux kernel which supports mpls kernel project.

> can you point me to the text which says so.
> i could not find such a claim in rfc3031 ?

Not in rfc3031 but in rfc5036 .. pretty much the only practical
signalling protocol for mpls transport (not an overlay mpls
signalling):

   "Prefix SHOULD NOT use the label for forwarding unless its routing
    table contains an entry that exactly matches the FEC Element."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
r.

From jari.arkko@piuha.net  Fri Oct 11 06:12:01 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF611E8153; Fri, 11 Oct 2013 06:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Level: 
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvmOWs7AzMyb; Fri, 11 Oct 2013 06:11:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B168E11E8150; Fri, 11 Oct 2013 06:11:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ED03B2CC5D; Fri, 11 Oct 2013 16:11:53 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTGf2MQPsinL; Fri, 11 Oct 2013 16:11:53 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4F9B22CC6F; Fri, 11 Oct 2013 16:11:53 +0300 (EEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <5256E527.1030806@cisco.com>
Date: Fri, 11 Oct 2013 16:11:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 13:12:01 -0000

After some off-line chatting, I have a proposal for text to be added to =
the charter:

There are a number of serious security concerns with source routing at =
the IP layer [RFC 5095].  As a part of its work, the working group will =
define the new IPv6-based routing header in way that blind attacks are =
never possible, i.e., attackers will be unable to send source routed =
packets that get successfully processed, without being part of the =
negations for setting up the source routes or being able to eavesdrop =
legitimate source routed packets. In some networks this base level =
security may be complemented with other mechanisms, such as packet =
filtering, cryptographic security, etc.

Would this work for people? FWIW from what I can tell, the above should =
be relatively easily doable, short cookies in headers, etc. It would =
remove my main concern of accidentally turned on devices becoming a =
security hole. It would also help deployment, as firewalls might =
otherwise default to blocking all kinds of routing headers.

Jari


From hannes@juniper.net  Fri Oct 11 07:11:39 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FCB11E81C1 for ; Fri, 11 Oct 2013 07:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvZgPtlo583E for ; Fri, 11 Oct 2013 07:11:34 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 82EFE21F9D52 for ; Fri, 11 Oct 2013 07:11:34 -0700 (PDT)
Received: from mail54-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 14:11:33 +0000
Received: from mail54-ch1 (localhost [127.0.0.1])	by mail54-ch1-R.bigfish.com (Postfix) with ESMTP id 96A7D260164; Fri, 11 Oct 2013 14:11:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: VPS-20(zz98dIdbb0izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1033IL177df4h17326ah19a27bh1de097h186068h172cdfh8275dhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail54-ch1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail54-ch1 (localhost.localdomain [127.0.0.1]) by mail54-ch1 (MessageSwitch) id 1381500692100255_16090; Fri, 11 Oct 2013 14:11:32 +0000 (UTC)
Received: from CH1EHSMHS040.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230])	by mail54-ch1.bigfish.com (Postfix) with ESMTP id 1369C34005B;	Fri, 11 Oct 2013 14:11:32 +0000 (UTC)
Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS040.bigfish.com (10.43.69.249) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 14:11:31 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 14:11:28 +0000
Date: Fri, 11 Oct 2013 16:11:23 +0200
From: Hannes Gredler 
To: Robert Raszuk 
Message-ID: <20131011141123.GD29526@juniper.net>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 14:11:39 -0000

On Fri, Oct 11, 2013 at 03:00:02PM +0200, Robert Raszuk wrote:
| > please have a look at
| > http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=Main_Page
| 
| [ ... ] Please point me to any
| linux distribution which officially supports this. Also please point
| me to the official linux kernel which supports mpls kernel project.

i am not sure if there is such a thing as an "official linux kernel"
  of course there is linus' and his lieutenants git trees - however
  every major linux distribution pulls from there and adds a ton
  of patches to it. - the linux MPLS extensions are basically
  kernel patches plus userspace utilizities - nothing more.
  so if you want to get it to work - get your favourite
  (linux from scratch) distro and apply the patches ...
  i did it with 'gentoo' linux and as far as i can tell it works fine
  even with l2vpn services on top of the transport LSPs.
    note that there are also pre-cooked debian ISO images with everything
    applied if you do not want to compile your kernel by yourself.

| > can you point me to the text which says so.
| > i could not find such a claim in rfc3031 ?
| 
| Not in rfc3031 but in rfc5036 .. pretty much the only practical
| signalling protocol for mpls transport (not an overlay mpls
| signalling):
| 
|    "Prefix SHOULD NOT use the label for forwarding unless its routing
|     table contains an entry that exactly matches the FEC Element."

oh yes, and this is indeed problematic ... and its fixed here:
http://www.ietf.org/rfc/rfc5283.txt


From joelja@bogus.com  Fri Oct 11 10:26:13 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8F11E816B; Fri, 11 Oct 2013 10:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tper5yUpDuh; Fri, 11 Oct 2013 10:26:12 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2011E81B2; Fri, 11 Oct 2013 10:26:06 -0700 (PDT)
Received: from mb-aye.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9BHPtKw067556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 11 Oct 2013 17:25:56 GMT (envelope-from joelja@bogus.com)
Content-Type: multipart/signed; boundary="Apple-Mail=_E7284CEB-BAF6-4FB2-B79F-95D13D6E1CA7"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: joel jaeggli 
In-Reply-To: 
Date: Fri, 11 Oct 2013 10:25:50 -0700
Message-Id: <8D392CDA-04BC-44DB-9F47-032C29192428@bogus.com>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> 
To: Ted Lemon 
X-Mailer: Apple Mail (2.1510)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 11 Oct 2013 17:25:56 +0000 (UTC)
Cc: Thomas Narten , Stewart Bryant , Jari Arkko , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 17:26:13 -0000

--Apple-Mail=_E7284CEB-BAF6-4FB2-B79F-95D13D6E1CA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 11, 2013, at 10:15 AM, Ted Lemon  wrote:

> On Oct 11, 2013, at 9:11 AM, Jari Arkko  wrote:
>> Would this work for people? FWIW from what I can tell, the above =
should be relatively easily doable, short cookies in headers, etc. It =
would remove my main concern of accidentally turned on devices becoming =
a security hole. It would also help deployment, as firewalls might =
otherwise default to blocking all kinds of routing headers.
>=20
> WFM, although it sounds an awful lot like a flow label... :)

20 bits is not enough to put the sha1sum of my authetication token in.

>=20


--Apple-Mail=_E7284CEB-BAF6-4FB2-B79F-95D13D6E1CA7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlJYNJ4ACgkQ8AA1q7Z/VrJZegCeI6copBlNdDZzrXKwXYYe+Wd+
QaEAn2SliR0XAGZXseEIiY4LGkSmpCu7
=KXK2
-----END PGP SIGNATURE-----

--Apple-Mail=_E7284CEB-BAF6-4FB2-B79F-95D13D6E1CA7--

From Ted.Lemon@nominum.com  Fri Oct 11 10:15:22 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1D121E808A; Fri, 11 Oct 2013 10:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.601
X-Spam-Level: 
X-Spam-Status: No, score=-106.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zWp2VsmAC+V; Fri, 11 Oct 2013 10:15:15 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 919B521E80E2; Fri, 11 Oct 2013 10:15:14 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUlgyImprnvnQ4K82dbi7ghHS71fSg+1i@postini.com; Fri, 11 Oct 2013 10:15:14 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E857E1B82F0; Fri, 11 Oct 2013 10:15:13 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E112B19005C; Fri, 11 Oct 2013 10:15:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Oct 2013 10:15:13 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
Date: Fri, 11 Oct 2013 13:15:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
To: Jari Arkko 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
X-Mailman-Approved-At: Fri, 11 Oct 2013 10:27:49 -0700
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" , Stewart Bryant 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 17:15:22 -0000

On Oct 11, 2013, at 9:11 AM, Jari Arkko  wrote:
> Would this work for people? FWIW from what I can tell, the above =
should be relatively easily doable, short cookies in headers, etc. It =
would remove my main concern of accidentally turned on devices becoming =
a security hole. It would also help deployment, as firewalls might =
otherwise default to blocking all kinds of routing headers.

WFM, although it sounds an awful lot like a flow label... :)


From Ted.Lemon@nominum.com  Fri Oct 11 11:07:07 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B50311E812B; Fri, 11 Oct 2013 11:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.301
X-Spam-Level: 
X-Spam-Status: No, score=-106.301 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99yBA1m53Emt; Fri, 11 Oct 2013 11:07:01 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4F11E812F; Fri, 11 Oct 2013 11:07:00 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUlg+OB5BRpU2n9R3OakMGG+ObCPT6Rz7@postini.com; Fri, 11 Oct 2013 11:07:00 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 25DE11B82F3; Fri, 11 Oct 2013 11:06:48 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1CFD019005C; Fri, 11 Oct 2013 11:06:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Oct 2013 11:06:48 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon 
In-Reply-To: <8D392CDA-04BC-44DB-9F47-032C29192428@bogus.com>
Date: Fri, 11 Oct 2013 14:06:47 -0400
Content-Transfer-Encoding: 7bit
Message-ID: <674DC600-B5D3-45B0-907A-12BDC52C9B5B@nominum.com>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>  <8D392CDA-04BC-44DB-9F47-032C29192428@bogus.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: Thomas Narten , Stewart Bryant , Jari Arkko , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 18:07:07 -0000

On Oct 11, 2013, at 1:25 PM, joel jaeggli  wrote:
> 20 bits is not enough to put the sha1sum of my authetication token in.

I know, and I didn't say _exactly_ like.   :)


From sprevidi@cisco.com  Fri Oct 11 11:22:54 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9004B21F9CF3; Fri, 11 Oct 2013 11:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-hIa3JjxxSg; Fri, 11 Oct 2013 11:22:47 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00211E8143; Fri, 11 Oct 2013 11:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1344; q=dns/txt; s=iport; t=1381515755; x=1382725355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lz4BYqyU8Rt4IIETMwkczgEJYRujS9p6wuJ84VVeHdA=; b=i/WqslW7MSuMi3FVQVksjIWQkKo9kHIf/BGW0Nfo8AuxkBKRjlw6r2SD mywd1DWZ1Y6TKy/HZfv/PWV4NcdYay3SuzG7XQk+MN6manEgnAYahFTyU dFaRKblv1RfO3fVDXg6Pope2NyoBaJJG3aHWFofaQkO4tCMy32gv72ucL 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAOpAWFKtJV2c/2dsb2JhbABagwc4UsEPS4EkFnSCJQEBAQMBAQEBNzQLBQsCAQgYChQQJwslAgQOBQiHeAYMuxoEjxQCMQeDH4EEA6oHgySCKg
X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208";a="271111962"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 11 Oct 2013 18:22:33 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9BIMWiS012562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Oct 2013 18:22:32 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 13:22:32 -0500
From: "Stefano Previdi (sprevidi)" 
To: Jari Arkko 
Thread-Topic: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
Thread-Index: AQHOxXkJIkUwOMl/ZkqgAR6P0mBC/5nuSWsAgAAuAYCAAA9ngIABSPSAgABWyIA=
Date: Fri, 11 Oct 2013 18:22:31 +0000
Message-ID: 
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
In-Reply-To: <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.164.39]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6C4E28B9AABA0F499D7DF86FFD049A43@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 18:22:54 -0000

Jari,

On Oct 11, 2013, at 3:11 PM, Jari Arkko wrote:
> After some off-line chatting, I have a proposal for text to be added to t=
he charter:
>=20
> There are a number of serious security concerns with source routing at th=
e IP layer [RFC 5095].  As a part of its work, the working group will defin=
e the new IPv6-based routing header in way that blind attacks are never pos=
sible, i.e., attackers will be unable to send source routed packets that ge=
t successfully processed, without being part of the negations for setting u=
p the source routes or being able to eavesdrop legitimate source routed pac=
kets. In some networks this base level security may be complemented with ot=
her mechanisms, such as packet filtering, cryptographic security, etc.
>=20
> Would this work for people?


that would work for me.=20

Thanks.
s.



> FWIW from what I can tell, the above should be relatively easily doable, =
short cookies in headers, etc. It would remove my main concern of accidenta=
lly turned on devices becoming a security hole. It would also help deployme=
nt, as firewalls might otherwise default to blocking all kinds of routing h=
eaders.
>=20
> Jari
>=20
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status


From hannes@juniper.net  Fri Oct 11 11:33:37 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF01521F9CC0; Fri, 11 Oct 2013 11:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.932
X-Spam-Level: 
X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+CUWf7zHsrV; Fri, 11 Oct 2013 11:33:21 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 86C5421F9C9B; Fri, 11 Oct 2013 11:33:08 -0700 (PDT)
Received: from mail15-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE019.bigfish.com (10.236.130.82) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 18:33:03 +0000
Received: from mail15-co9 (localhost [127.0.0.1])	by mail15-co9-R.bigfish.com (Postfix) with ESMTP id 51CAE4C0225; Fri, 11 Oct 2013 18:33:03 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zzdb82h98dIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail15-co9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 1381516381598526_29161; Fri, 11 Oct 2013 18:33:01 +0000 (UTC)
Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.241])	by mail15-co9.bigfish.com (Postfix) with ESMTP id 8DEB426007C; Fri, 11 Oct 2013 18:33:01 +0000 (UTC)
Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 18:33:01 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 18:32:55 +0000
Date: Fri, 11 Oct 2013 20:32:22 +0200
From: Hannes Gredler 
To: Jari Arkko 
Message-ID: <20131011183222.GA30073@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 18:33:37 -0000

On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
| After some off-line chatting, I have a proposal for text to be added to the charter:
| 
| There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
| 
| Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.

jari,

i do not think that packet-filtering is feasible on the default-free-zone
on the internet. - can you take off packet-filtering in favour of security cookies ?

tx,

/hannes


From stbryant@cisco.com  Fri Oct 11 11:52:40 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D311E818C; Fri, 11 Oct 2013 11:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level: 
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzEDzf7flR0f; Fri, 11 Oct 2013 11:52:35 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED411E81A2; Fri, 11 Oct 2013 11:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1649; q=dns/txt; s=iport; t=1381517550; x=1382727150; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iEdF2EOfQEP4OTuuL/7c6+9tCEDnPBKgu2jVnqpbRuA=; b=agavlJ2yb7iNY3WvEK9Ro6y5CQZhlP3b7UeVLoq0ZdUmQ3u9yjrnu4O4 LLUJFKVlsfOaEfmf+Esr5ObhVJ9rkFtILXH6oE9Hehc7SVl+Tq19vstS0 RGb8thXoaWAcPDvMAi3n7517NyH8yDSgMQE7tpUM6LdTxNUKKszsvewpb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAANIWFKQ/khR/2dsb2JhbABagwe/YYMDgSUWdIIlAQEBBDg8BAEQCxgJFg8JAwIBAgFFBg0BBwEBF4dru0uPRweEIwOYBZICgyU
X-IronPort-AV: E=Sophos;i="4.93,477,1378857600"; d="scan'208";a="18223637"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 11 Oct 2013 18:52:27 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BIqM5o029653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 18:52:23 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9BIqHk6002696; Fri, 11 Oct 2013 19:52:18 +0100 (BST)
Message-ID: <525848E1.3000806@cisco.com>
Date: Fri, 11 Oct 2013 19:52:17 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Hannes Gredler 
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>
In-Reply-To: <20131011183222.GA30073@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten , Jari Arkko , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 18:52:40 -0000

On 11/10/2013 19:32, Hannes Gredler wrote:
> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
> | After some off-line chatting, I have a proposal for text to be added to the charter:
> |
> | There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
> |
> | Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
>
> jari,
>
> i do not think that packet-filtering is feasible on the default-free-zone
> on the internet. - can you take off packet-filtering in favour of security cookies ?
>
Packet filtering is prefixed by such as. In some cases it may be 
feasible and better
that a cookie. I can add cookies to the list without requiring any 
particular solution
be picked at this stage. The list is just, I believe to provide 
confidence that a solution
is feasible in the various contexts.

Stewart



From stbryant@cisco.com  Fri Oct 11 12:09:16 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4121E808C; Fri, 11 Oct 2013 12:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.506
X-Spam-Level: 
X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ewTweXr1skM; Fri, 11 Oct 2013 12:09:11 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E07B421E80A8; Fri, 11 Oct 2013 12:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2586; q=dns/txt; s=iport; t=1381518549; x=1382728149; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=uQlmp/ciqvaUmGuRLuTjIK3lGVTa43hjNeNIGyr5ezg=; b=hFQLtuy2fgiBu9+21n+gwZaAsZC+TjqkkrPmKUwBy763fixQMA54d8LL F3W5V3ftDrNhL0QeJlSRRo9sLICddOoQ97r2rzhVIOQu1FmnSfTSdsTgl QEi9zIf3AzbaMucBm6sKU7ewK015zxArA3/EDGYA685nxrgSQ4UmESytW Y=;
X-IronPort-AV: E=Sophos;i="4.93,477,1378857600"; d="scan'208,217";a="18224007"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 11 Oct 2013 19:09:08 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BJ91Cg001845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 19:09:03 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9BJ8wQv003279; Fri, 11 Oct 2013 20:08:59 +0100 (BST)
Message-ID: <52584CCA.8000902@cisco.com>
Date: Fri, 11 Oct 2013 20:08:58 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "status@ietf.org" , Jari Arkko , Benoit Claise 
Content-Type: multipart/alternative; boundary="------------010803050104010606060400"
Cc: "iesg@ietf.org" 
Subject: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 19:09:16 -0000

This is a multi-part message in MIME format.
--------------010803050104010606060400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Version 12 of the charter text has Jari's security text
with Hannes' addition of cookies as a method to be
considered.

I have modified the OAM/Management text to be

o Specify OAM the mechanisms needed to support SPRING

o Publish SPRING management requirements document.

Benoit, please can you take a look at the above and
if this is still not what you are looking for
please provide text. Once we have cleared the Blocking
comments (probably during external review), I propose
that we convert the final list to milestones per
Adrian's comment, in which case the separation is
better.

The latest text as always is at:

https://datatracker.ietf.org/doc/charter-ietf-spring/

If this satisfies Jari and Benoit's concerns I would like
to put this in external review, where it is still available
for comment to polish out any last issues.

- Stewart

--------------010803050104010606060400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Version 12 of the charter text has Jari's security text

    with Hannes' addition of cookies as a method to be

    considered.

    

    I have modified the OAM/Management text to be

    
    
o Specify OAM the mechanisms needed to support SPRING 

o Publish SPRING management requirements document.

Benoit, please can you take a look at the above and
if this is still not what you are looking for
please provide text. Once we have cleared the Blocking 
comments (probably during external review), I propose 
that we convert the final list to milestones per
Adrian's comment, in which case the separation is
better.


    The latest text as always is at:

    

    https://datatracker.ietf.org/doc/charter-ietf-spring/

    

    If this satisfies Jari and Benoit's concerns I would like

    to put this in external review, where it is still available 

    for comment to polish out any last issues.

    

    - Stewart

  


--------------010803050104010606060400--

From rraszuk@gmail.com  Fri Oct 11 12:14:10 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6846621E80A8 for ; Fri, 11 Oct 2013 12:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level: 
X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.424,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBsYWJAJ+Wub for ; Fri, 11 Oct 2013 12:14:09 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 55DF821F92CD for ; Fri, 11 Oct 2013 12:14:02 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so9542624ief.29 for ; Fri, 11 Oct 2013 12:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pjCCk90kWATI8VJsoGciYrSmvaaD7QNz0EZyqXZzs00=; b=RlMdWsbl9NchVhC1tUSDQ5QylFKMC6iVS8JsVvhuuG6RAVN/hrLbgdrHCuLy6K8SGu qsGzmRGTg7No9kem3PqYUCUEO00JMcj56xPB3nEy/mMYc7Hy1c21DMpkqhdx0rttGXCM MY4xsRcaG7Uv2WdKRB9AzuPX4KDhQ9SejLIOlIwO68p/GX3Nh4HN68O4xGfhJkf36EtA S2YbUTBkaeweBGIRF7+X59efSz/vXP7wImYe/oBNHlkN/hYKcgOeX/Zh2R0QTFYgikzp GtkcDb6R+cXysuYD+GyzlBFhzoP+rIzH/6y9alrWWwYeoE3InNc+QEoQKFQvVkWrobSQ wGXA==
MIME-Version: 1.0
X-Received: by 10.50.55.65 with SMTP id q1mr4039144igp.4.1381518841696; Fri, 11 Oct 2013 12:14:01 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 12:14:01 -0700 (PDT)
In-Reply-To: <20131011183222.GA30073@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>
Date: Fri, 11 Oct 2013 21:14:01 +0200
X-Google-Sender-Auth: kIC5V6gleJyndfz2H0Df_bpxdbA
Message-ID: 
From: Robert Raszuk 
To: Hannes Gredler 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 19:14:10 -0000

> i do not think that packet-filtering is feasible on the default-free-zone
> on the internet. - can you take off packet-filtering in favour of security
> cookies ?

What is not feasible ? Do you know any DFZ AS to permit in external
packets towards their infrastructure addresses carried in the
destination IP header ?

If so let's announce those .. I am sure few folks around will be happy
to target it over the weekend and next week there will be no more ;-)

Ref of at least one way to do it: http://goo.gl/dVeI8

r.

From hannes@juniper.net  Fri Oct 11 12:41:46 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EA511E818F for ; Fri, 11 Oct 2013 12:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.67
X-Spam-Level: 
X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=-0.071,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urFmES4qZmMx for ; Fri, 11 Oct 2013 12:41:35 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 30DFA11E8184 for ; Fri, 11 Oct 2013 12:41:29 -0700 (PDT)
Received: from mail83-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 19:41:28 +0000
Received: from mail83-co1 (localhost [127.0.0.1])	by mail83-co1-R.bigfish.com (Postfix) with ESMTP id 4F27A500093; Fri, 11 Oct 2013 19:41:28 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 2
X-BigFish: VPS2(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail83-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=hannes@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail83-co1 (localhost.localdomain [127.0.0.1]) by mail83-co1 (MessageSwitch) id 138152048660374_3971; Fri, 11 Oct 2013 19:41:26 +0000 (UTC)
Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.254])	by mail83-co1.bigfish.com (Postfix) with ESMTP id 0AACF340063; Fri, 11 Oct 2013 19:41:26 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 19:41:25 +0000
Received: from snosikov-sslvpn-nc.jnpr.net (193.110.54.36) by pod51010.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 19:41:24 +0000
MIME-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Hannes Gredler 
In-Reply-To: 
Date: Fri, 11 Oct 2013 21:41:20 +0200
Content-Transfer-Encoding: 7bit
Message-ID: <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> 
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1283)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 19:41:46 -0000

On Oct 11, 2013, at 9:14 PM, Robert Raszuk wrote:

>> i do not think that packet-filtering is feasible on the default-free-zone
>> on the internet. - can you take off packet-filtering in favour of security
>> cookies ?
> 
> What is not feasible ? Do you know any DFZ AS to permit in external
> packets towards their infrastructure addresses carried in the
> destination IP header ?

the attack vector may not just be the infra prefixes but rather
any routed IPv6 prefix that is transiting through an IPv6-SR
capable router.

all an attacker then needs to do is:

1. pick a route which transits an IPv6-SR capable node
2. add a forged extension header

voila - you can get anywhere you want in the IPv6-SR domain;

---

as much as i like the source-routing paradigm,
it really sucks in the IP data planes due to the security
hazards involved.

i fail to see how attempt #4 for IP source routing is any
better than the previous three attempts.

/hannes



From rraszuk@gmail.com  Fri Oct 11 12:49:12 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B611E8155 for ; Fri, 11 Oct 2013 12:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.347,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKeOuslFZw-J for ; Fri, 11 Oct 2013 12:49:12 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 146EA21F9FEE for ; Fri, 11 Oct 2013 12:49:11 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so9636876ief.29 for ; Fri, 11 Oct 2013 12:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UkThk1To/68fIboPwc1CplWqaUUFHOlruxemG/kk0FM=; b=YAwVkHLH/FFprbB9lr9Zvp6dxyE3bprV/wLnN9ybrallXrg6LC/Cro2I9eQOYYdL8z rN5UhwkQEoBRgMpZikwEf+dr+6h2a+lnt9t5mGDzqfNqeC90ygcJlUuLS7KiG/S6QFeO wQAo0w0UlMY2wvWjsU7YtWx3880XdMj/dDNW3ncIpY/Ds8cl9liBIwfWu50rm5gieP/X DmIzoVXhSIU7LI84W9HMMYSa94JfNVvIwD5iyUaGYfcx8d3bm9hJ4GiU4ASKl7gst31x wfzGZPr5RqL5p2SCUrYU5lmvRHNyyjTSdiXzrDG0kEZA5zmgSEJonfOBnz8sDxK6YVa8 VsJQ==
MIME-Version: 1.0
X-Received: by 10.42.40.83 with SMTP id k19mr12285050ice.3.1381520951504; Fri, 11 Oct 2013 12:49:11 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Fri, 11 Oct 2013 12:49:11 -0700 (PDT)
In-Reply-To: <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>  <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net>
Date: Fri, 11 Oct 2013 21:49:11 +0200
X-Google-Sender-Auth: J54qkCbiriL2R_Yu1-5c44t1hT4
Message-ID: 
From: Robert Raszuk 
To: Hannes Gredler 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 19:49:13 -0000

> all an attacker then needs to do is:
>
> 1. pick a route which transits an IPv6-SR capable node
> 2. add a forged extension header
>
> voila - you can get anywhere you want in the IPv6-SR domain;

Not really ...

Yes it will be allowed to get into any network, however it is very
easy not to examine extension headers on such packets hence only
provide v6 transit as any DFZ would provide today without any SR
enabled.

Segment routing != source routing .. perhaps the analogy made by some
folks is really counter productive to the technology at stake. But
your points are great as those issues you bring when addressed by
subsequent drafts will make the solution much more robust for any AF
it is deployed to work with.

Many thx,
R.

From jari.arkko@piuha.net  Fri Oct 11 12:49:47 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393B621E80DA; Fri, 11 Oct 2013 12:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BxBLFqWjdyq; Fri, 11 Oct 2013 12:49:41 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CD75421F9FCA; Fri, 11 Oct 2013 12:49:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9FC422CC64; Fri, 11 Oct 2013 22:49:33 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oboW9RPjKXG4; Fri, 11 Oct 2013 22:49:33 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 993782CC5D; Fri, 11 Oct 2013 22:49:32 +0300 (EEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <525848E1.3000806@cisco.com>
Date: Fri, 11 Oct 2013 22:49:32 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <40195890-D11E-4500-B257-3C760B4F172B@piuha.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> <525848E1.3000806@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
Cc: Thomas Narten , Hannes Gredler , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Oct 2013 19:49:47 -0000

Cookies are one way to do this, but they are part of the base level =
security - not the complements. I don't think we should add them to the =
list.

Jari

On Oct 11, 2013, at 9:52 PM, Stewart Bryant  wrote:

> On 11/10/2013 19:32, Hannes Gredler wrote:
>> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
>> | After some off-line chatting, I have a proposal for text to be =
added to the charter:
>> |
>> | There are a number of serious security concerns with source routing =
at the IP layer [RFC 5095].  As a part of its work, the working group =
will define the new IPv6-based routing header in way that blind attacks =
are never possible, i.e., attackers will be unable to send source routed =
packets that get successfully processed, without being part of the =
negations for setting up the source routes or being able to eavesdrop =
legitimate source routed packets. In some networks this base level =
security may be complemented with other mechanisms, such as packet =
filtering, cryptographic security, etc.
>> |
>> | Would this work for people? FWIW from what I can tell, the above =
should be relatively easily doable, short cookies in headers, etc. It =
would remove my main concern of accidentally turned on devices becoming =
a security hole. It would also help deployment, as firewalls might =
otherwise default to blocking all kinds of routing headers.
>>=20
>> jari,
>>=20
>> i do not think that packet-filtering is feasible on the =
default-free-zone
>> on the internet. - can you take off packet-filtering in favour of =
security cookies ?
>>=20
> Packet filtering is prefixed by such as. In some cases it may be =
feasible and better
> that a cookie. I can add cookies to the list without requiring any =
particular solution
> be picked at this stage. The list is just, I believe to provide =
confidence that a solution
> is feasible in the various contexts.
>=20
> Stewart
>=20
>=20


From stbryant@cisco.com  Fri Oct 11 14:21:21 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DFF21E808F; Fri, 11 Oct 2013 14:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.509
X-Spam-Level: 
X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sv6dDXiCRhr; Fri, 11 Oct 2013 14:21:16 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AFCA221F9DC9; Fri, 11 Oct 2013 14:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2298; q=dns/txt; s=iport; t=1381526473; x=1382736073; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fcy42Cs4KiSL3DsipC18D8Q+ktbDNJccfauCmNNXLqo=; b=hYaxDBlP49AIo2Rp/aIuGp8MHIbszwb+z49iYYe8H5oSUkoGtyFSRj5m iEvBAbZQ7YTd9OFsLCSDCuqXz9mEHA+oERpSRoVaq9pV57VEEpHVho8s2 Cphok2GNQoHDu0ywrqbxEd2adXCqxC2nLN6fCH4F3L5EPnQJ5+rxGol04 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAO9qWFKQ/khL/2dsb2JhbABagwc4wjCBJRZ0giUBAQEEODwEARALGAkWDwkDAgECAUUGAQwBBQIBAReHawy7f49HB4QjA5gFkgKDJQ
X-IronPort-AV: E=Sophos;i="4.93,478,1378857600"; d="scan'208";a="160580342"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Oct 2013 21:21:06 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9BLL2DS017467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 21:21:03 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9BLKx9L008209; Fri, 11 Oct 2013 22:21:00 +0100 (BST)
Message-ID: <52586BBB.2000400@cisco.com>
Date: Fri, 11 Oct 2013 22:20:59 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Jari Arkko , Hannes Gredler 
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> <525848E1.3000806@cisco.com> <40195890-D11E-4500-B257-3C760B4F172B@piuha.net>
In-Reply-To: <40195890-D11E-4500-B257-3C760B4F172B@piuha.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Oct 2013 21:21:21 -0000

I have taken them out of the list. This is after all a list of examples
and if we discover a cookie like thing is both required and sufficiently
secure we can address that later.

Stewart

On 11/10/2013 20:49, Jari Arkko wrote:
> Cookies are one way to do this, but they are part of the base level security - not the complements. I don't think we should add them to the list.
>
> Jari
>
> On Oct 11, 2013, at 9:52 PM, Stewart Bryant  wrote:
>
>> On 11/10/2013 19:32, Hannes Gredler wrote:
>>> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
>>> | After some off-line chatting, I have a proposal for text to be added to the charter:
>>> |
>>> | There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
>>> |
>>> | Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
>>>
>>> jari,
>>>
>>> i do not think that packet-filtering is feasible on the default-free-zone
>>> on the internet. - can you take off packet-filtering in favour of security cookies ?
>>>
>> Packet filtering is prefixed by such as. In some cases it may be feasible and better
>> that a cookie. I can add cookies to the list without requiring any particular solution
>> be picked at this stage. The list is just, I believe to provide confidence that a solution
>> is feasible in the various contexts.
>>
>> Stewart
>>
>>
> .
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


From joelja@bogus.com  Fri Oct 11 17:14:26 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64711E81C1; Fri, 11 Oct 2013 17:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gDv8FX7i603; Fri, 11 Oct 2013 17:14:24 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7151B11E81C5; Fri, 11 Oct 2013 17:14:21 -0700 (PDT)
Received: from mb-aye.lan (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9C0EIFN072160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Oct 2013 00:14:19 GMT (envelope-from joelja@bogus.com)
Content-Type: multipart/signed; boundary="Apple-Mail=_883C2AE2-831A-4D79-B40E-2C48C505889A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: joel jaeggli 
In-Reply-To: <5256E527.1030806@cisco.com>
Date: Fri, 11 Oct 2013 17:14:19 -0700
Message-Id: <7F164648-BC3F-4605-9818-AAA02AB44344@bogus.com>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 Oct 2013 00:14:20 +0000 (UTC)
Cc: Thomas Narten , Jari Arkko , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 00:14:26 -0000

--Apple-Mail=_883C2AE2-831A-4D79-B40E-2C48C505889A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 10, 2013, at 10:34 AM, Stewart Bryant  wrote:

> On 10/10/2013 17:39, Jari Arkko wrote:
>> Thomas,
>>=20
>>> I think a key point is that with IPv6, we are talking (potentially)
>>> end-to-end exposure of an attack vector. You can have arbitrary end
>>> nodes anywhere on the Internet injecting traffic that potentially
>>> directly invokes or impacts source routing. In contrast, one can =
view
>>> MPLS as an L2 technology below IP. That means it's deployed in a =
much
>>> more restricted setting and a normal sender of TCP/IP has a much =
more
>>> restricted attack vector for doing anything that impacts MPLS =
directly
>>> (this is key diffference). That means the threat surface for attacks
>>> on MPLS are very different than for IPv6 more generally.
>> Yes - a good point. That is one of those restricted cases where it is =
possible to provide a reasonably secure solution.
>>=20
>> But my understanding is that SPRING was at IPv6 layer as well as on =
MPLS layer=85 although the charter does not explicitly say it. Just that =
it is not IPv4=85
>>=20
>> If SPRING is expected to run at the IPv6 layer, what is the plan to =
contain the vulnerability?
>>=20
>> Jari
>>=20
>> .
>>=20
> The following was just posted on the STATUS list and clarifies
> intended IPv6 scope.
> All,
>=20
> On the topic of MPLS vs IPv6 - one being L2 hence more secure then the
> other (L3) I would like to observe that any decently managed network
> would already today prohibit to accept any external packets which have
> as destination an infrastructure address of such network. That is the
> basic protection scheme against DOS/DDOS attacks to the
> infrastructure.
>=20
Well=85 not really. we have a lovely document on control-plane =
protection which encapsulates what a number of operators consider good =
if not best practice RFC 6192.

One of the recommendations there is to allow but rate limit icmp =
necessary for for diagnostics. In some circles, icmp is considered an =
OAM diagnostic function. the operative observation though is the =
resource consumption potential is sufficicently trivial to understand =
that it can be managed with rather simple policing.

> When such packet is detected it should be dropped - not "stripped from
> explicit routes" like the above charter update would tend to suggest.
>=20
> As some may recall in the past we have been working on automating such
> ACLs installation based in internal IGP addresses on all border
> routers under same administrative domain within single AS or number of
> ASes to ease operational burden. Not sure if all vendors support such
> automation today.
>=20
> I think what needs to be understood that segment routing is not
> internet wide source routing technology. It is carefully crafted path
> engineering and packet encapsulation technique within controlled set
> of domains which really do not compare to the original issues and
> security concerns of source routing.
>=20
> Best,
> R.
>=20
> I could=20
>=20
> OLD
> The initial data planes that will be considered are MPLS
> and IPv6.
> NEW
> The initial data planes that will be considered are MPLS
> and IPv6 in constrained network scopes.
>=20
> END
>=20
> Stewart
>=20
>=20


--Apple-Mail=_883C2AE2-831A-4D79-B40E-2C48C505889A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlJYlFsACgkQ8AA1q7Z/VrJ0+ACaAkK0HtEByvZqSyECMepRwbEj
80YAnRPyAfn39kSa90GI2v/Gv5TjFl4F
=adkK
-----END PGP SIGNATURE-----

--Apple-Mail=_883C2AE2-831A-4D79-B40E-2C48C505889A--

From xuxiaohu@huawei.com  Fri Oct 11 20:05:59 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6121F9CAF for ; Fri, 11 Oct 2013 20:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level: 
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=-1.926,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRhtk6S9LNmz for ; Fri, 11 Oct 2013 20:05:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 176BC21F9CBF for ; Fri, 11 Oct 2013 20:05:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYZ69792; Sat, 12 Oct 2013 03:05:51 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 04:05:16 +0100
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 04:05:47 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0146.000; Sat, 12 Oct 2013 11:05:33 +0800
From: Xuxiaohu 
To: Hannes Gredler , Robert Raszuk 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxftv4CKyAtw8vUuUlcOO89jTl5nu0g0AgAAfeACAABPvgIABTu/A
Date: Sat, 12 Oct 2013 03:05:33 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net>
In-Reply-To: <20131011141123.GD29526@juniper.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" , AshwoodsmithPeter 
Subject: [Status] =?gb2312?b?tPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 03:05:59 -0000

DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7Iyzogc3RhdHVzLWJvdW5jZXNAaWV0Zi5v
cmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBIYW5uZXMgR3JlZGxl
cg0KPiC3osvNyrG85DogMjAxM8TqMTDUwjExyNUgMjI6MTENCj4gytW8/sjLOiBSb2JlcnQgUmFz
enVrDQo+ILOty806IHN0YXR1c0BpZXRmLm9yZzsgQXNod29vZHNtaXRoUGV0ZXINCj4g1vfM4jog
UmU6IFtTdGF0dXNdIFN0YXR1cyBvZiBTcHJpbmcNCj4gDQo+IE9uIEZyaSwgT2N0IDExLCAyMDEz
IGF0IDAzOjAwOjAyUE0gKzAyMDAsIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+IHwgPiBwbGVhc2Ug
aGF2ZSBhIGxvb2sgYXQNCj4gfCA+DQo+IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvYXBwcy9tZWRp
YXdpa2kvbXBscy1saW51eC9pbmRleC5waHA/dGl0bGU9TWFpbl9QYWdlDQo+IHwNCj4gfCBbIC4u
LiBdIFBsZWFzZSBwb2ludCBtZSB0byBhbnkNCj4gfCBsaW51eCBkaXN0cmlidXRpb24gd2hpY2gg
b2ZmaWNpYWxseSBzdXBwb3J0cyB0aGlzLiBBbHNvIHBsZWFzZSBwb2ludA0KPiB8IG1lIHRvIHRo
ZSBvZmZpY2lhbCBsaW51eCBrZXJuZWwgd2hpY2ggc3VwcG9ydHMgbXBscyBrZXJuZWwgcHJvamVj
dC4NCj4gDQo+IGkgYW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgc3VjaCBhIHRoaW5nIGFzIGFuICJv
ZmZpY2lhbCBsaW51eCBrZXJuZWwiDQo+ICAgb2YgY291cnNlIHRoZXJlIGlzIGxpbnVzJyBhbmQg
aGlzIGxpZXV0ZW5hbnRzIGdpdCB0cmVlcyAtIGhvd2V2ZXINCj4gICBldmVyeSBtYWpvciBsaW51
eCBkaXN0cmlidXRpb24gcHVsbHMgZnJvbSB0aGVyZSBhbmQgYWRkcyBhIHRvbg0KPiAgIG9mIHBh
dGNoZXMgdG8gaXQuIC0gdGhlIGxpbnV4IE1QTFMgZXh0ZW5zaW9ucyBhcmUgYmFzaWNhbGx5DQo+
ICAga2VybmVsIHBhdGNoZXMgcGx1cyB1c2Vyc3BhY2UgdXRpbGl6aXRpZXMgLSBub3RoaW5nIG1v
cmUuDQo+ICAgc28gaWYgeW91IHdhbnQgdG8gZ2V0IGl0IHRvIHdvcmsgLSBnZXQgeW91ciBmYXZv
dXJpdGUNCj4gICAobGludXggZnJvbSBzY3JhdGNoKSBkaXN0cm8gYW5kIGFwcGx5IHRoZSBwYXRj
aGVzIC4uLg0KPiAgIGkgZGlkIGl0IHdpdGggJ2dlbnRvbycgbGludXggYW5kIGFzIGZhciBhcyBp
IGNhbiB0ZWxsIGl0IHdvcmtzIGZpbmUNCj4gICBldmVuIHdpdGggbDJ2cG4gc2VydmljZXMgb24g
dG9wIG9mIHRoZSB0cmFuc3BvcnQgTFNQcy4NCj4gICAgIG5vdGUgdGhhdCB0aGVyZSBhcmUgYWxz
byBwcmUtY29va2VkIGRlYmlhbiBJU08gaW1hZ2VzIHdpdGggZXZlcnl0aGluZw0KPiAgICAgYXBw
bGllZCBpZiB5b3UgZG8gbm90IHdhbnQgdG8gY29tcGlsZSB5b3VyIGtlcm5lbCBieSB5b3Vyc2Vs
Zi4NCj4gDQo+IHwgPiBjYW4geW91IHBvaW50IG1lIHRvIHRoZSB0ZXh0IHdoaWNoIHNheXMgc28u
DQo+IHwgPiBpIGNvdWxkIG5vdCBmaW5kIHN1Y2ggYSBjbGFpbSBpbiByZmMzMDMxID8NCj4gfA0K
PiB8IE5vdCBpbiByZmMzMDMxIGJ1dCBpbiByZmM1MDM2IC4uIHByZXR0eSBtdWNoIHRoZSBvbmx5
IHByYWN0aWNhbA0KPiB8IHNpZ25hbGxpbmcgcHJvdG9jb2wgZm9yIG1wbHMgdHJhbnNwb3J0IChu
b3QgYW4gb3ZlcmxheSBtcGxzDQo+IHwgc2lnbmFsbGluZyk6DQo+IHwNCj4gfCAgICAiUHJlZml4
IFNIT1VMRCBOT1QgdXNlIHRoZSBsYWJlbCBmb3IgZm9yd2FyZGluZyB1bmxlc3MgaXRzIHJvdXRp
bmcNCj4gfCAgICAgdGFibGUgY29udGFpbnMgYW4gZW50cnkgdGhhdCBleGFjdGx5IG1hdGNoZXMg
dGhlIEZFQyBFbGVtZW50LiINCj4gDQo+IG9oIHllcywgYW5kIHRoaXMgaXMgaW5kZWVkIHByb2Js
ZW1hdGljIC4uLiBhbmQgaXRzIGZpeGVkIGhlcmU6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj
L3JmYzUyODMudHh0DQoNCkdyZWF0IHRoYXQgTERQIGhhcyByZW1vdmVkIHRoYXQgbGltaXRhdGlv
bi4gV2hlbiB1c2luZyBJU0lTIG9yIE9TUEYgZm9yIGxhYmVsIGRpc3RyaWJ1dGlvbiBwdXJwb3Nl
LCB3ZSBzaG91bGQgZm9sbG93IHRoZSBzYW1lIHByaW5jaXBsZS4gSW4gdGhpcyB3YXksIHRoZSBz
Y2FsYWJpbGl0eSBvZiBJR1Agd291bGQgbm90IGJlIGltcGFjdGVkIGJ5IHRoZSBTUFJJTkcgYXJj
aGl0ZWN0dXJlLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+
IHN0YXR1c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3N0YXR1cw0K

From rraszuk@gmail.com  Sat Oct 12 00:35:25 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3721E80A1 for ; Sat, 12 Oct 2013 00:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.156
X-Spam-Level: **
X-Spam-Status: No, score=2.156 tagged_above=-999 required=5 tests=[AWL=-3.500,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8OFNycMo3-x for ; Sat, 12 Oct 2013 00:35:24 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 66EDF21E80D0 for ; Sat, 12 Oct 2013 00:35:10 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id qd12so4894532ieb.5 for ; Sat, 12 Oct 2013 00:35:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7cUFKmJJKhOV/VI7/K3IdBBIKIpgzTldYu1/234i93Q=; b=BpjgOCoJNyUqqFcSj+QJzTpyDYkdaisQ8KO9rAsr7+QE/p1geTy4TnKUg/JgxgAPLf 8Nq37SQD9YhwqbCz9YCHXKQg+vFLWz0TuB0HMwwGj5WBassJ7/OoFMNEYvHbJy5vFbDM FKsjV8ZQsb2uiiY1M+bCa1Ng2dmgo4GD0700AGOuW28ccnrbLsZUf7nbTnQUjJNn/mbI 5zNfK38UIVJKBFUmdYbwjAGlVYX3vFOFeg14KBlYRqaDTgb66dyYhLu+/OQJpSZhNALM 4DxeWtfHgTISqQFsfTYQjzVcqg4vOXzCvDNIgjeoLI2zZ05blqqWe3xZKUx9FZFQcMMp 7hUw==
MIME-Version: 1.0
X-Received: by 10.50.107.102 with SMTP id hb6mr5640610igb.55.1381563309915; Sat, 12 Oct 2013 00:35:09 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Sat, 12 Oct 2013 00:35:09 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>
Date: Sat, 12 Oct 2013 09:35:09 +0200
X-Google-Sender-Auth: 5rzmhpfvqsSYDiRAQkMJrIWImtk
Message-ID: 
From: Robert Raszuk 
To: Xuxiaohu 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
Cc: Hannes Gredler , "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] =?gb2312?b?tPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 07:35:25 -0000

LDP has not removed any limitation. If you use MPLS you still need to
send all host FECs in LDP. There is no magic transit nodes are not
aware about your overlay application .. they can not demux on their
own. Label must be specific to the transport endpoint.

RFC5283 just reduces IGP and RIB size - not LDP:

   "Note that LDP re-advertises to its peers the specific FEC element
   FEC1, and not the aggregated prefix found in the IP RIB during the
   longest-match search."

If you use IP encapsulation you don't need any additional signalling
to send your overlay application between any two end points in the
network yet benefit from natural aggregation of IP subnets at any
point.

Likewise when SR SIDs are MPLS labels they can not be aggregated. When
SR SIDs are IP addresses they can be nicely aggregated for example at
the IGP or AS area boundaries.

r.

On Sat, Oct 12, 2013 at 5:05 AM, Xuxiaohu  wrote:
>
>
>> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
>> =B7=A2=BC=FE=C8=CB: status-bounces@ietf.org [mailto:status-bounces@ietf.=
org] =B4=FA=B1=ED
>> Hannes Gredler
>> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA10=D4=C211=C8=D5 22:11
>> =CA=D5=BC=FE=C8=CB: Robert Raszuk
>> =B3=AD=CB=CD: status@ietf.org; AshwoodsmithPeter
>> =D6=F7=CC=E2: Re: [Status] Status of Spring
>>
>> On Fri, Oct 11, 2013 at 03:00:02PM +0200, Robert Raszuk wrote:
>> | > please have a look at
>> | >
>> http://sourceforge.net/apps/mediawiki/mpls-linux/index.php?title=3DMain_=
Page
>> |
>> | [ ... ] Please point me to any
>> | linux distribution which officially supports this. Also please point
>> | me to the official linux kernel which supports mpls kernel project.
>>
>> i am not sure if there is such a thing as an "official linux kernel"
>>   of course there is linus' and his lieutenants git trees - however
>>   every major linux distribution pulls from there and adds a ton
>>   of patches to it. - the linux MPLS extensions are basically
>>   kernel patches plus userspace utilizities - nothing more.
>>   so if you want to get it to work - get your favourite
>>   (linux from scratch) distro and apply the patches ...
>>   i did it with 'gentoo' linux and as far as i can tell it works fine
>>   even with l2vpn services on top of the transport LSPs.
>>     note that there are also pre-cooked debian ISO images with everythin=
g
>>     applied if you do not want to compile your kernel by yourself.
>>
>> | > can you point me to the text which says so.
>> | > i could not find such a claim in rfc3031 ?
>> |
>> | Not in rfc3031 but in rfc5036 .. pretty much the only practical
>> | signalling protocol for mpls transport (not an overlay mpls
>> | signalling):
>> |
>> |    "Prefix SHOULD NOT use the label for forwarding unless its routing
>> |     table contains an entry that exactly matches the FEC Element."
>>
>> oh yes, and this is indeed problematic ... and its fixed here:
>> http://www.ietf.org/rfc/rfc5283.txt
>
> Great that LDP has removed that limitation. When using ISIS or OSPF for l=
abel distribution purpose, we should follow the same principle. In this way=
, the scalability of IGP would not be impacted by the SPRING architecture.
>
> Best regards,
> Xiaohu
>
>> _______________________________________________
>> status mailing list
>> status@ietf.org
>> https://www.ietf.org/mailman/listinfo/status

From xuxiaohu@huawei.com  Sat Oct 12 01:26:29 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8355321F9E36 for ; Sat, 12 Oct 2013 01:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgj9PgJqfTcX for ; Sat, 12 Oct 2013 01:26:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22F5121E80D0 for ; Sat, 12 Oct 2013 01:26:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZA13996; Sat, 12 Oct 2013 08:26:12 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 09:25:29 +0100
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 09:25:54 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Sat, 12 Oct 2013 16:25:40 +0800
From: Xuxiaohu 
To: Robert Raszuk 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxySiOj9W0vX9yEuMWq0FgRYldQ==
Date: Sat, 12 Oct 2013 08:25:40 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Hannes Gredler , "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 08:26:29 -0000

DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogcnJhc3p1a0BnbWFpbC5jb20gW21h
aWx0bzpycmFzenVrQGdtYWlsLmNvbV0gtPqx7SBSb2JlcnQgUmFzenVrDQo+ILeiy83KsbzkOiAy
MDEzxOoxMNTCMTLI1SAxNTozNQ0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IEhhbm5lcyBH
cmVkbGVyOyBzdGF0dXNAaWV0Zi5vcmc7IEFzaHdvb2RzbWl0aFBldGVyDQo+INb3zOI6IFJlOiC0
8Li0OiBbU3RhdHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+IA0KPiBMRFAgaGFzIG5vdCByZW1vdmVk
IGFueSBsaW1pdGF0aW9uLiBJZiB5b3UgdXNlIE1QTFMgeW91IHN0aWxsIG5lZWQgdG8NCg0KSSBt
ZWFudCAiLi4uUHJlZml4IFNIT1VMRCBOT1QgdXNlIHRoZSBsYWJlbCBmb3IgZm9yd2FyZGluZyB1
bmxlc3MgaXRzIHJvdXRpbmcgdGFibGUgY29udGFpbnMgYW4gZW50cnkgdGhhdCBleGFjdGx5IG1h
dGNoZXMgdGhlIEZFQyBFbGVtZW50LiIgYnkgImxpbWl0YXRpb24iLg0KDQo+IHNlbmQgYWxsIGhv
c3QgRkVDcyBpbiBMRFAuIFRoZXJlIGlzIG5vIG1hZ2ljIHRyYW5zaXQgbm9kZXMgYXJlIG5vdA0K
PiBhd2FyZSBhYm91dCB5b3VyIG92ZXJsYXkgYXBwbGljYXRpb24gLi4gdGhleSBjYW4gbm90IGRl
bXV4IG9uIHRoZWlyDQo+IG93bi4gTGFiZWwgbXVzdCBiZSBzcGVjaWZpYyB0byB0aGUgdHJhbnNw
b3J0IGVuZHBvaW50Lg0KDQpFeGFjdGx5LiBGRUNzIGNhbid0IGJlIGFnZ3JlZ2F0ZWQgYW5kIHRo
ZXJlZm9yZSB0aGUgTVBMUyBmb3J3YXJkaW5nIHRhYmxlIHNpemUgaXMgbm90IHJlZHVjZWQuDQoN
Cj4gUkZDNTI4MyBqdXN0IHJlZHVjZXMgSUdQIGFuZCBSSUIgc2l6ZSAtIG5vdCBMRFA6DQo+IA0K
PiAgICAiTm90ZSB0aGF0IExEUCByZS1hZHZlcnRpc2VzIHRvIGl0cyBwZWVycyB0aGUgc3BlY2lm
aWMgRkVDIGVsZW1lbnQNCj4gICAgRkVDMSwgYW5kIG5vdCB0aGUgYWdncmVnYXRlZCBwcmVmaXgg
Zm91bmQgaW4gdGhlIElQIFJJQiBkdXJpbmcgdGhlDQo+ICAgIGxvbmdlc3QtbWF0Y2ggc2VhcmNo
LiINCj4gDQo+IElmIHlvdSB1c2UgSVAgZW5jYXBzdWxhdGlvbiB5b3UgZG9uJ3QgbmVlZCBhbnkg
YWRkaXRpb25hbCBzaWduYWxsaW5nDQo+IHRvIHNlbmQgeW91ciBvdmVybGF5IGFwcGxpY2F0aW9u
IGJldHdlZW4gYW55IHR3byBlbmQgcG9pbnRzIGluIHRoZQ0KPiBuZXR3b3JrIHlldCBiZW5lZml0
IGZyb20gbmF0dXJhbCBhZ2dyZWdhdGlvbiBvZiBJUCBzdWJuZXRzIGF0IGFueQ0KPiBwb2ludC4N
Cg0KVGhlIGNvbmNlcm4gaXMgd2hldGhlciBhIGxpc3Qgb2YgSVB2NiBhZGRyZXNzZXMgb3IgYSBs
aXN0IG9mIHNob3J0IElEcyBpcyB1c2VkIGluIGEgcGFja2V0IHRvIHJlcHJlc2VudCBhbiBleHBs
aWNpdCBzb3VyY2UgcGF0aC4gSWYgdGhlIGZvcm1lciBpcyB0aGUgY2FzZSwgSSBhZ3JlZSB3aXRo
IHlvdS4gSG93ZXZlciwgaXQgc2VlbSB0aGF0IGlzIG5vdCB0aGUgcmVjb21tZW5kZWQgb3B0aW9u
LiBPbiB0aGUgY29udHJhcnksIHRoZSBsYXR0ZXIgaXMuIFNlZSB0aGUgZm9sbG93aW5nIHN0YXRl
bWVudCBxdW90ZWQgZnJvbSBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp
bHNmaWxzLXJ0Z3dnLXNlZ21lbnQtcm91dGluZzoNCg0KIiAuLi5UaGUgbWFpbiBkaWZmZXJlbmNl
cyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBtb2RlbCBhcmU6ICBUaGUgc291cmNlIHJvdXRl
IGlzIGVuY29kZWQgYXMgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGluc3RlYWQgb2YgSVAg
YWRkcmVzc2VzLiAiDQoNCj4gTGlrZXdpc2Ugd2hlbiBTUiBTSURzIGFyZSBNUExTIGxhYmVscyB0
aGV5IGNhbiBub3QgYmUgYWdncmVnYXRlZC4gV2hlbg0KPiBTUiBTSURzIGFyZSBJUCBhZGRyZXNz
ZXMgdGhleSBjYW4gYmUgbmljZWx5IGFnZ3JlZ2F0ZWQgZm9yIGV4YW1wbGUgYXQNCj4gdGhlIElH
UCBvciBBUyBhcmVhIGJvdW5kYXJpZXMuDQoNCkFzIEkgaGFkIGlsbHVzdHJhdGVkIGluIGEgcHJl
dmlvdXMgZW1haWwgd2l0aCBhbiBleGFtcGxlLCBpZiB5b3Ugd2FudCB0byByZWR1Y2UgdGhlIE1Q
TFMgZm9yd2FyZGluZyB0YWJsZSBzaXplLCB5b3UgY291bGQgcmVwbGFjZSB0aGUgaW5uZXJtb3N0
IExTUCB0b3dhcmRzIHRoZSBmaW5hbCB0dW5uZWwgZGVzdGluYXRpb24gKGkuZS4sIHRoZSBsYXN0
IGhvcCBvZiB0aGUgZXhwbGljaXQgcGF0aCkgd2l0aCBhbiBJUC1iYXNlZCB0dW5uZWwgd2hpbGUg
c3RpbGwgdXNpbmcgTFNQcyB0byByZXByZXNlbnQgdGhlIHBhdGhzIHRvIHRoZSByZW1haW5pbmcg
aG9wcyBvZiB0aGUgZXhwbGljaXQgcGF0aC4gSW4gdGhpcyB3YXksIHRoZXJlIGlzIG5vIG5lZWQg
dG8gY3JlYXRlIGxhYmVsIGJpbmRpbmdzIGZvciB0aG9zZSBsYXJnZSBhbW91bnQgb2YgZmluYWwg
dHVubmVsIGVuZHBvaW50cy4NCg0KRm9yIGV4YW1wbGUsIGluIHRoZSBmb2xsb3dpbmcgdG9wb2xv
Z3kgd2hlcmUgdGhlIG1ldHJpY3Mgb2YgYWxsIGxpbmtzIGFyZSB0aGUgc2FtZSwgYXNzdW1lIEEg
d2FudCB0byBzZW5kIGEgcGFja2V0IFggdG8gWiB2aWEgYSBleHBsaWNpdCByb3V0ZSB7QywgRX0s
IHRoZSBwYWNrZXQgc2VudCBmcm9tIEEgd291bGQgbG9vayBhczogfE1QTFMgbGFiZWwgZm9yIEN8
R1JFIHR1bm5lbCB0byBFfHBhY2tldCBYfC4NCg0KQS0tLS0tQi0tLS0tLS1ELS0tLS1FDQogICAg
IFwgICAvDQogICAgICAgQw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiByLg0KPiANCj4g
T24gU2F0LCBPY3QgMTIsIDIwMTMgYXQgNTowNSBBTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdl
aS5jb20+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+ILei
vP7Iyzogc3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzdGF0dXMtYm91bmNlc0BpZXRm
Lm9yZ10gtPqx7Q0KPiA+PiBIYW5uZXMgR3JlZGxlcg0KPiA+PiC3osvNyrG85DogMjAxM8TqMTDU
wjExyNUgMjI6MTENCj4gPj4gytW8/sjLOiBSb2JlcnQgUmFzenVrDQo+ID4+ILOty806IHN0YXR1
c0BpZXRmLm9yZzsgQXNod29vZHNtaXRoUGV0ZXINCj4gPj4g1vfM4jogUmU6IFtTdGF0dXNdIFN0
YXR1cyBvZiBTcHJpbmcNCj4gPj4NCj4gPj4gT24gRnJpLCBPY3QgMTEsIDIwMTMgYXQgMDM6MDA6
MDJQTSArMDIwMCwgUm9iZXJ0IFJhc3p1ayB3cm90ZToNCj4gPj4gfCA+IHBsZWFzZSBoYXZlIGEg
bG9vayBhdA0KPiA+PiB8ID4NCj4gPj4NCj4gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9hcHBzL21l
ZGlhd2lraS9tcGxzLWxpbnV4L2luZGV4LnBocD90aXRsZT1NYWluX1BhZ2UNCj4gPj4gfA0KPiA+
PiB8IFsgLi4uIF0gUGxlYXNlIHBvaW50IG1lIHRvIGFueQ0KPiA+PiB8IGxpbnV4IGRpc3RyaWJ1
dGlvbiB3aGljaCBvZmZpY2lhbGx5IHN1cHBvcnRzIHRoaXMuIEFsc28gcGxlYXNlIHBvaW50DQo+
ID4+IHwgbWUgdG8gdGhlIG9mZmljaWFsIGxpbnV4IGtlcm5lbCB3aGljaCBzdXBwb3J0cyBtcGxz
IGtlcm5lbCBwcm9qZWN0Lg0KPiA+Pg0KPiA+PiBpIGFtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIHN1
Y2ggYSB0aGluZyBhcyBhbiAib2ZmaWNpYWwgbGludXgga2VybmVsIg0KPiA+PiAgIG9mIGNvdXJz
ZSB0aGVyZSBpcyBsaW51cycgYW5kIGhpcyBsaWV1dGVuYW50cyBnaXQgdHJlZXMgLSBob3dldmVy
DQo+ID4+ICAgZXZlcnkgbWFqb3IgbGludXggZGlzdHJpYnV0aW9uIHB1bGxzIGZyb20gdGhlcmUg
YW5kIGFkZHMgYSB0b24NCj4gPj4gICBvZiBwYXRjaGVzIHRvIGl0LiAtIHRoZSBsaW51eCBNUExT
IGV4dGVuc2lvbnMgYXJlIGJhc2ljYWxseQ0KPiA+PiAgIGtlcm5lbCBwYXRjaGVzIHBsdXMgdXNl
cnNwYWNlIHV0aWxpeml0aWVzIC0gbm90aGluZyBtb3JlLg0KPiA+PiAgIHNvIGlmIHlvdSB3YW50
IHRvIGdldCBpdCB0byB3b3JrIC0gZ2V0IHlvdXIgZmF2b3VyaXRlDQo+ID4+ICAgKGxpbnV4IGZy
b20gc2NyYXRjaCkgZGlzdHJvIGFuZCBhcHBseSB0aGUgcGF0Y2hlcyAuLi4NCj4gPj4gICBpIGRp
ZCBpdCB3aXRoICdnZW50b28nIGxpbnV4IGFuZCBhcyBmYXIgYXMgaSBjYW4gdGVsbCBpdCB3b3Jr
cyBmaW5lDQo+ID4+ICAgZXZlbiB3aXRoIGwydnBuIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgdHJh
bnNwb3J0IExTUHMuDQo+ID4+ICAgICBub3RlIHRoYXQgdGhlcmUgYXJlIGFsc28gcHJlLWNvb2tl
ZCBkZWJpYW4gSVNPIGltYWdlcyB3aXRoIGV2ZXJ5dGhpbmcNCj4gPj4gICAgIGFwcGxpZWQgaWYg
eW91IGRvIG5vdCB3YW50IHRvIGNvbXBpbGUgeW91ciBrZXJuZWwgYnkgeW91cnNlbGYuDQo+ID4+
DQo+ID4+IHwgPiBjYW4geW91IHBvaW50IG1lIHRvIHRoZSB0ZXh0IHdoaWNoIHNheXMgc28uDQo+
ID4+IHwgPiBpIGNvdWxkIG5vdCBmaW5kIHN1Y2ggYSBjbGFpbSBpbiByZmMzMDMxID8NCj4gPj4g
fA0KPiA+PiB8IE5vdCBpbiByZmMzMDMxIGJ1dCBpbiByZmM1MDM2IC4uIHByZXR0eSBtdWNoIHRo
ZSBvbmx5IHByYWN0aWNhbA0KPiA+PiB8IHNpZ25hbGxpbmcgcHJvdG9jb2wgZm9yIG1wbHMgdHJh
bnNwb3J0IChub3QgYW4gb3ZlcmxheSBtcGxzDQo+ID4+IHwgc2lnbmFsbGluZyk6DQo+ID4+IHwN
Cj4gPj4gfCAgICAiUHJlZml4IFNIT1VMRCBOT1QgdXNlIHRoZSBsYWJlbCBmb3IgZm9yd2FyZGlu
ZyB1bmxlc3MgaXRzIHJvdXRpbmcNCj4gPj4gfCAgICAgdGFibGUgY29udGFpbnMgYW4gZW50cnkg
dGhhdCBleGFjdGx5IG1hdGNoZXMgdGhlIEZFQyBFbGVtZW50LiINCj4gPj4NCj4gPj4gb2ggeWVz
LCBhbmQgdGhpcyBpcyBpbmRlZWQgcHJvYmxlbWF0aWMgLi4uIGFuZCBpdHMgZml4ZWQgaGVyZToN
Cj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTI4My50eHQNCj4gPg0KPiA+IEdyZWF0
IHRoYXQgTERQIGhhcyByZW1vdmVkIHRoYXQgbGltaXRhdGlvbi4gV2hlbiB1c2luZyBJU0lTIG9y
IE9TUEYgZm9yIGxhYmVsDQo+IGRpc3RyaWJ1dGlvbiBwdXJwb3NlLCB3ZSBzaG91bGQgZm9sbG93
IHRoZSBzYW1lIHByaW5jaXBsZS4gSW4gdGhpcyB3YXksIHRoZQ0KPiBzY2FsYWJpbGl0eSBvZiBJ
R1Agd291bGQgbm90IGJlIGltcGFjdGVkIGJ5IHRoZSBTUFJJTkcgYXJjaGl0ZWN0dXJlLg0KPiA+
DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+IFhpYW9odQ0KPiA+DQo+ID4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHN0YXR1cyBtYWlsaW5nIGxp
c3QNCj4gPj4gc3RhdHVzQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vc3RhdHVzDQo=

From xuxiaohu@huawei.com  Sat Oct 12 01:32:47 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB0E21E80DB for ; Sat, 12 Oct 2013 01:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.688
X-Spam-Level: *
X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[AWL=-2.300,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3,  MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq+MV5orEsc1 for ; Sat, 12 Oct 2013 01:32:43 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0311121E80AF for ; Sat, 12 Oct 2013 01:32:42 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZA14316; Sat, 12 Oct 2013 08:32:42 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 09:32:09 +0100
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 09:32:41 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0146.000; Sat, 12 Oct 2013 16:32:30 +0800
From: Xuxiaohu 
To: Xuxiaohu , Robert Raszuk 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxyWW9BewZxauYES7bPxS7YMw4w==
Date: Sat, 12 Oct 2013 08:32:29 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B64@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.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.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Hannes Gredler , "status@ietf.org" , AshwoodsmithPeter 
Subject: [Status] =?gb2312?b?tPC4tDogIFN0YXR1cyBvZiBTcHJpbmc=?=
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 08:32:47 -0000

DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqxvOQ6
IDIwMTPE6jEw1MIxMsjVIDE2OjI2DQo+IMrVvP7IyzogJ1JvYmVydCBSYXN6dWsnDQo+ILOty806
IEhhbm5lcyBHcmVkbGVyOyBzdGF0dXNAaWV0Zi5vcmc7IEFzaHdvb2RzbWl0aFBldGVyDQo+INb3
zOI6IHJlOiBbU3RhdHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+IA0KPiANCj4gDQo+ID4gLS0tLS3T
yrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6
dWtAZ21haWwuY29tXSC0+rHtIFJvYmVydA0KPiBSYXN6dWsNCj4gPiC3osvNyrG85DogMjAxM8Tq
MTDUwjEyyNUgMTU6MzUNCj4gPiDK1bz+yMs6IFh1eGlhb2h1DQo+ID4gs63LzTogSGFubmVzIEdy
ZWRsZXI7IHN0YXR1c0BpZXRmLm9yZzsgQXNod29vZHNtaXRoUGV0ZXINCj4gPiDW98ziOiBSZTog
tPC4tDogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiA+DQo+ID4gTERQIGhhcyBub3QgcmVt
b3ZlZCBhbnkgbGltaXRhdGlvbi4gSWYgeW91IHVzZSBNUExTIHlvdSBzdGlsbCBuZWVkIHRvDQo+
IA0KPiBJIG1lYW50ICIuLi5QcmVmaXggU0hPVUxEIE5PVCB1c2UgdGhlIGxhYmVsIGZvciBmb3J3
YXJkaW5nIHVubGVzcyBpdHMgcm91dGluZw0KPiB0YWJsZSBjb250YWlucyBhbiBlbnRyeSB0aGF0
IGV4YWN0bHkgbWF0Y2hlcyB0aGUgRkVDIEVsZW1lbnQuIiBieSAibGltaXRhdGlvbiIuDQo+IA0K
PiA+IHNlbmQgYWxsIGhvc3QgRkVDcyBpbiBMRFAuIFRoZXJlIGlzIG5vIG1hZ2ljIHRyYW5zaXQg
bm9kZXMgYXJlIG5vdA0KPiA+IGF3YXJlIGFib3V0IHlvdXIgb3ZlcmxheSBhcHBsaWNhdGlvbiAu
LiB0aGV5IGNhbiBub3QgZGVtdXggb24gdGhlaXINCj4gPiBvd24uIExhYmVsIG11c3QgYmUgc3Bl
Y2lmaWMgdG8gdGhlIHRyYW5zcG9ydCBlbmRwb2ludC4NCj4gDQo+IEV4YWN0bHkuIEZFQ3MgY2Fu
J3QgYmUgYWdncmVnYXRlZCBhbmQgdGhlcmVmb3JlIHRoZSBNUExTIGZvcndhcmRpbmcgdGFibGUg
c2l6ZQ0KPiBpcyBub3QgcmVkdWNlZC4NCj4gDQo+ID4gUkZDNTI4MyBqdXN0IHJlZHVjZXMgSUdQ
IGFuZCBSSUIgc2l6ZSAtIG5vdCBMRFA6DQo+ID4NCj4gPiAgICAiTm90ZSB0aGF0IExEUCByZS1h
ZHZlcnRpc2VzIHRvIGl0cyBwZWVycyB0aGUgc3BlY2lmaWMgRkVDIGVsZW1lbnQNCj4gPiAgICBG
RUMxLCBhbmQgbm90IHRoZSBhZ2dyZWdhdGVkIHByZWZpeCBmb3VuZCBpbiB0aGUgSVAgUklCIGR1
cmluZyB0aGUNCj4gPiAgICBsb25nZXN0LW1hdGNoIHNlYXJjaC4iDQo+ID4NCj4gPiBJZiB5b3Ug
dXNlIElQIGVuY2Fwc3VsYXRpb24geW91IGRvbid0IG5lZWQgYW55IGFkZGl0aW9uYWwgc2lnbmFs
bGluZw0KPiA+IHRvIHNlbmQgeW91ciBvdmVybGF5IGFwcGxpY2F0aW9uIGJldHdlZW4gYW55IHR3
byBlbmQgcG9pbnRzIGluIHRoZQ0KPiA+IG5ldHdvcmsgeWV0IGJlbmVmaXQgZnJvbSBuYXR1cmFs
IGFnZ3JlZ2F0aW9uIG9mIElQIHN1Ym5ldHMgYXQgYW55DQo+ID4gcG9pbnQuDQo+IA0KPiBUaGUg
Y29uY2VybiBpcyB3aGV0aGVyIGEgbGlzdCBvZiBJUHY2IGFkZHJlc3NlcyBvciBhIGxpc3Qgb2Yg
c2hvcnQgSURzIGlzIHVzZWQgaW4gYQ0KPiBwYWNrZXQgdG8gcmVwcmVzZW50IGFuIGV4cGxpY2l0
IHNvdXJjZSBwYXRoLiBJZiB0aGUgZm9ybWVyIGlzIHRoZSBjYXNlLCBJIGFncmVlIHdpdGgNCj4g
eW91LiBIb3dldmVyLCBpdCBzZWVtIHRoYXQgaXMgbm90IHRoZSByZWNvbW1lbmRlZCBvcHRpb24u
IE9uIHRoZSBjb250cmFyeSwNCj4gdGhlIGxhdHRlciBpcy4gU2VlIHRoZSBmb2xsb3dpbmcgc3Rh
dGVtZW50IHF1b3RlZCBmcm9tDQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtZmlsc2ZpbHMtcnRnd2ctc2VnbWVudC1yb3V0aW5nOg0KPiANCj4gIiAuLi5UaGUgbWFpbiBk
aWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBtb2RlbCBhcmU6ICBUaGUgc291
cmNlDQo+IHJvdXRlIGlzIGVuY29kZWQgYXMgYW4gb3JkZXJlZCBsaXN0IG9mIHNlZ21lbnRzIGlu
c3RlYWQgb2YgSVAgYWRkcmVzc2VzLiAiDQo+IA0KPiA+IExpa2V3aXNlIHdoZW4gU1IgU0lEcyBh
cmUgTVBMUyBsYWJlbHMgdGhleSBjYW4gbm90IGJlIGFnZ3JlZ2F0ZWQuIFdoZW4NCj4gPiBTUiBT
SURzIGFyZSBJUCBhZGRyZXNzZXMgdGhleSBjYW4gYmUgbmljZWx5IGFnZ3JlZ2F0ZWQgZm9yIGV4
YW1wbGUgYXQNCj4gPiB0aGUgSUdQIG9yIEFTIGFyZWEgYm91bmRhcmllcy4NCj4gDQo+IEFzIEkg
aGFkIGlsbHVzdHJhdGVkIGluIGEgcHJldmlvdXMgZW1haWwgd2l0aCBhbiBleGFtcGxlLCBpZiB5
b3Ugd2FudCB0byByZWR1Y2UNCj4gdGhlIE1QTFMgZm9yd2FyZGluZyB0YWJsZSBzaXplLCB5b3Ug
Y291bGQgcmVwbGFjZSB0aGUgaW5uZXJtb3N0IExTUCB0b3dhcmRzDQo+IHRoZSBmaW5hbCB0dW5u
ZWwgZGVzdGluYXRpb24gKGkuZS4sIHRoZSBsYXN0IGhvcCBvZiB0aGUgZXhwbGljaXQgcGF0aCkg
d2l0aCBhbg0KPiBJUC1iYXNlZCB0dW5uZWwgd2hpbGUgc3RpbGwgdXNpbmcgTFNQcyB0byByZXBy
ZXNlbnQgdGhlIHBhdGhzIHRvIHRoZSByZW1haW5pbmcNCj4gaG9wcyBvZiB0aGUgZXhwbGljaXQg
cGF0aC4gSW4gdGhpcyB3YXksIHRoZXJlIGlzIG5vIG5lZWQgdG8gY3JlYXRlIGxhYmVsIGJpbmRp
bmdzDQo+IGZvciB0aG9zZSBsYXJnZSBhbW91bnQgb2YgZmluYWwgdHVubmVsIGVuZHBvaW50cy4N
Cj4gDQo+IEZvciBleGFtcGxlLCBpbiB0aGUgZm9sbG93aW5nIHRvcG9sb2d5IHdoZXJlIHRoZSBt
ZXRyaWNzIG9mIGFsbCBsaW5rcyBhcmUgdGhlDQo+IHNhbWUsIGFzc3VtZSBBIHdhbnQgdG8gc2Vu
ZCBhIHBhY2tldCBYIHRvIFogdmlhIGEgZXhwbGljaXQgcm91dGUge0MsIEV9LCB0aGUNCj4gcGFj
a2V0IHNlbnQgZnJvbSBBIHdvdWxkIGxvb2sgYXM6IHxNUExTIGxhYmVsIGZvciBDfEdSRSB0dW5u
ZWwgdG8gRXxwYWNrZXQgWHwuDQoNCnMvWi9FDQoNCj4gQS0tLS0tQi0tLS0tLS1ELS0tLS1FDQo+
ICAgICAgXCAgIC8NCj4gICAgICAgIEMNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+
IA0KPiA+IHIuDQo+ID4NCj4gPiBPbiBTYXQsIE9jdCAxMiwgMjAxMyBhdCA1OjA1IEFNLCBYdXhp
YW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4NCj4gPiA+PiAt
LS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+PiC3orz+yMs6IHN0YXR1cy1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86c3RhdHVzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4gPiA+PiBIYW5uZXMgR3Jl
ZGxlcg0KPiA+ID4+ILeiy83KsbzkOiAyMDEzxOoxMNTCMTHI1SAyMjoxMQ0KPiA+ID4+IMrVvP7I
yzogUm9iZXJ0IFJhc3p1aw0KPiA+ID4+ILOty806IHN0YXR1c0BpZXRmLm9yZzsgQXNod29vZHNt
aXRoUGV0ZXINCj4gPiA+PiDW98ziOiBSZTogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiA+
ID4+DQo+ID4gPj4gT24gRnJpLCBPY3QgMTEsIDIwMTMgYXQgMDM6MDA6MDJQTSArMDIwMCwgUm9i
ZXJ0IFJhc3p1ayB3cm90ZToNCj4gPiA+PiB8ID4gcGxlYXNlIGhhdmUgYSBsb29rIGF0DQo+ID4g
Pj4gfCA+DQo+ID4gPj4NCj4gPg0KPiBodHRwOi8vc291cmNlZm9yZ2UubmV0L2FwcHMvbWVkaWF3
aWtpL21wbHMtbGludXgvaW5kZXgucGhwP3RpdGxlPU1haW5fUGFnZQ0KPiA+ID4+IHwNCj4gPiA+
PiB8IFsgLi4uIF0gUGxlYXNlIHBvaW50IG1lIHRvIGFueQ0KPiA+ID4+IHwgbGludXggZGlzdHJp
YnV0aW9uIHdoaWNoIG9mZmljaWFsbHkgc3VwcG9ydHMgdGhpcy4gQWxzbyBwbGVhc2UgcG9pbnQN
Cj4gPiA+PiB8IG1lIHRvIHRoZSBvZmZpY2lhbCBsaW51eCBrZXJuZWwgd2hpY2ggc3VwcG9ydHMg
bXBscyBrZXJuZWwgcHJvamVjdC4NCj4gPiA+Pg0KPiA+ID4+IGkgYW0gbm90IHN1cmUgaWYgdGhl
cmUgaXMgc3VjaCBhIHRoaW5nIGFzIGFuICJvZmZpY2lhbCBsaW51eCBrZXJuZWwiDQo+ID4gPj4g
ICBvZiBjb3Vyc2UgdGhlcmUgaXMgbGludXMnIGFuZCBoaXMgbGlldXRlbmFudHMgZ2l0IHRyZWVz
IC0gaG93ZXZlcg0KPiA+ID4+ICAgZXZlcnkgbWFqb3IgbGludXggZGlzdHJpYnV0aW9uIHB1bGxz
IGZyb20gdGhlcmUgYW5kIGFkZHMgYSB0b24NCj4gPiA+PiAgIG9mIHBhdGNoZXMgdG8gaXQuIC0g
dGhlIGxpbnV4IE1QTFMgZXh0ZW5zaW9ucyBhcmUgYmFzaWNhbGx5DQo+ID4gPj4gICBrZXJuZWwg
cGF0Y2hlcyBwbHVzIHVzZXJzcGFjZSB1dGlsaXppdGllcyAtIG5vdGhpbmcgbW9yZS4NCj4gPiA+
PiAgIHNvIGlmIHlvdSB3YW50IHRvIGdldCBpdCB0byB3b3JrIC0gZ2V0IHlvdXIgZmF2b3VyaXRl
DQo+ID4gPj4gICAobGludXggZnJvbSBzY3JhdGNoKSBkaXN0cm8gYW5kIGFwcGx5IHRoZSBwYXRj
aGVzIC4uLg0KPiA+ID4+ICAgaSBkaWQgaXQgd2l0aCAnZ2VudG9vJyBsaW51eCBhbmQgYXMgZmFy
IGFzIGkgY2FuIHRlbGwgaXQgd29ya3MgZmluZQ0KPiA+ID4+ICAgZXZlbiB3aXRoIGwydnBuIHNl
cnZpY2VzIG9uIHRvcCBvZiB0aGUgdHJhbnNwb3J0IExTUHMuDQo+ID4gPj4gICAgIG5vdGUgdGhh
dCB0aGVyZSBhcmUgYWxzbyBwcmUtY29va2VkIGRlYmlhbiBJU08gaW1hZ2VzIHdpdGgNCj4gZXZl
cnl0aGluZw0KPiA+ID4+ICAgICBhcHBsaWVkIGlmIHlvdSBkbyBub3Qgd2FudCB0byBjb21waWxl
IHlvdXIga2VybmVsIGJ5IHlvdXJzZWxmLg0KPiA+ID4+DQo+ID4gPj4gfCA+IGNhbiB5b3UgcG9p
bnQgbWUgdG8gdGhlIHRleHQgd2hpY2ggc2F5cyBzby4NCj4gPiA+PiB8ID4gaSBjb3VsZCBub3Qg
ZmluZCBzdWNoIGEgY2xhaW0gaW4gcmZjMzAzMSA/DQo+ID4gPj4gfA0KPiA+ID4+IHwgTm90IGlu
IHJmYzMwMzEgYnV0IGluIHJmYzUwMzYgLi4gcHJldHR5IG11Y2ggdGhlIG9ubHkgcHJhY3RpY2Fs
DQo+ID4gPj4gfCBzaWduYWxsaW5nIHByb3RvY29sIGZvciBtcGxzIHRyYW5zcG9ydCAobm90IGFu
IG92ZXJsYXkgbXBscw0KPiA+ID4+IHwgc2lnbmFsbGluZyk6DQo+ID4gPj4gfA0KPiA+ID4+IHwg
ICAgIlByZWZpeCBTSE9VTEQgTk9UIHVzZSB0aGUgbGFiZWwgZm9yIGZvcndhcmRpbmcgdW5sZXNz
IGl0cyByb3V0aW5nDQo+ID4gPj4gfCAgICAgdGFibGUgY29udGFpbnMgYW4gZW50cnkgdGhhdCBl
eGFjdGx5IG1hdGNoZXMgdGhlIEZFQyBFbGVtZW50LiINCj4gPiA+Pg0KPiA+ID4+IG9oIHllcywg
YW5kIHRoaXMgaXMgaW5kZWVkIHByb2JsZW1hdGljIC4uLiBhbmQgaXRzIGZpeGVkIGhlcmU6DQo+
ID4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMvcmZjNTI4My50eHQNCj4gPiA+DQo+ID4gPiBH
cmVhdCB0aGF0IExEUCBoYXMgcmVtb3ZlZCB0aGF0IGxpbWl0YXRpb24uIFdoZW4gdXNpbmcgSVNJ
UyBvciBPU1BGIGZvcg0KPiBsYWJlbA0KPiA+IGRpc3RyaWJ1dGlvbiBwdXJwb3NlLCB3ZSBzaG91
bGQgZm9sbG93IHRoZSBzYW1lIHByaW5jaXBsZS4gSW4gdGhpcyB3YXksIHRoZQ0KPiA+IHNjYWxh
YmlsaXR5IG9mIElHUCB3b3VsZCBub3QgYmUgaW1wYWN0ZWQgYnkgdGhlIFNQUklORyBhcmNoaXRl
Y3R1cmUuDQo+ID4gPg0KPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gWGlhb2h1DQo+ID4gPg0K
PiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gPj4gc3RhdHVzIG1haWxpbmcgbGlzdA0KPiA+ID4+IHN0YXR1c0BpZXRmLm9yZw0KPiA+ID4+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3RhdHVzDQo=

From xuxiaohu@huawei.com  Sat Oct 12 03:01:46 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F7C11E8192 for ; Sat, 12 Oct 2013 03:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.505
X-Spam-Level: 
X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=0.352,  BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, J_CHICKENPOX_16=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf-ZYUN94VD8 for ; Sat, 12 Oct 2013 03:01:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC9CC11E8144 for ; Sat, 12 Oct 2013 03:01:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWS91293; Sat, 12 Oct 2013 10:01:40 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 11:01:08 +0100
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 12 Oct 2013 11:01:39 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0146.000; Sat, 12 Oct 2013 18:01:29 +0800
From: Xuxiaohu 
To: Robert Raszuk 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxyWW9BewZxauYES7bPxS7YMw45nwT6Gg
Date: Sat, 12 Oct 2013 10:01:28 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B94@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B64@NKGEML512-MBS.china.huawei.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B64@NKGEML512-MBS.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.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Hannes Gredler , "status@ietf.org" , AshwoodsmithPeter 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 10:01:46 -0000

SW4gZmFjdCwgdGhlIGlkZWEgYXMgbWVudGlvbmVkIGJlZm9yZSAoaS5lLiwgcmVwbGFjaW5nIHRo
ZSBpbm5lcm1vc3QgTFNQIG9mIGEgc3RhY2tlZCBMU1AgdHVubmVsIHdpdGggYW4gSVAtYmFzZWQg
dHVubmVsKSBpcyBub3Qgb25seSBzdWl0YWJsZSBmb3IgU1BSSU5HLCBidXQgYWxzbyB1c2VmdWwg
Zm9yIHRoZSB0cmFkaXRpb25hbCBNUExTIHBhcmFkaWdtIGluIG11bHRpLWFyZWEvbGV2ZWwgb3Ig
ZXZlbiBtdWx0aS1kb21haW4gc2NlbmFyaW9zLg0KDQpGb3IgZXhhbXBsZSwgYXMgc3RhdGVkIGlu
IHNlY3Rpb24gNS4xLjYuIEludGVyLUFyZWEgUm91dGluZyBvZiB0aGUgc2VhbWxlc3MgTVBMUyBk
cmFmdCAoaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtc2Vh
bWxlc3MtbXBscy8/aW5jbHVkZV90ZXh0PTEpLA0KDQogICAiVGhpcyBhcmNoaXRlY3R1cmUgcmVz
dWx0cyBpbiBjYXJyeWluZyBhbGwgbG9vcGJhY2tzIG9mIGFsbCBub2Rlcw0KICAgZXhjZXB0IHB1
cmUgUCBub2RlcyAoQU4sIEFHTiwgQUJSIGFuZCBjb3JlIFBFKSBpbiBsYWJlbGVkIEJHUCwgZS5n
Lg0KICAgdGhlcmUgd2lsbCBiZSBpbiB0aGUgb3JkZXIgb2YgMTAwLjAwMCByb3V0ZXMgaW4gbGFi
ZWxlZCBCR1Agd2hlbg0KICAgYXBwcm9hY2hpbmcgdGhlIHN0YXRlZCBzY2FsYWJpbGl0eSBnb2Fs
LiINCg0Kd2l0aCB0aGUgYWJvdmUgaWRlYSwgdGhlcmUgaXMgbm8gbmVlZCB0byBhZHZlcnRpc2Ug
c3VjaCBhIGxhcmdlIGFtb3VudCBvZiBsYWJlbGVkIEJHUCBob3N0IHJvdXRlcyBhY3Jvc3MgYXJl
YS9sZXZlbCBib3VuZGFyaWVzIGFueW1vcmUuIEluc3RlYWQsIGl0IG9ubHkgcmVxdWlyZXMgdG8g
YWR2ZXJ0aXNlIGFnZ3JlZ2F0ZWQgQkdQIHJvdXRlcyAody9vIGxhYmVsKSBhY3Jvc3MgYXJlYS9s
ZXZlbCBib3VuZGFyaWVzLiANCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+
1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqxvOQ6IDIwMTPE6jEw1MIxMsjV
IDE2OjMyDQo+IMrVvP7IyzogWHV4aWFvaHU7IFJvYmVydCBSYXN6dWsNCj4gs63LzTogSGFubmVz
IEdyZWRsZXI7IHN0YXR1c0BpZXRmLm9yZzsgQXNod29vZHNtaXRoUGV0ZXINCj4g1vfM4jogtPC4
tDogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiANCj4gDQo+IA0KPiA+IC0tLS0t08q8/tSt
vP4tLS0tLQ0KPiA+ILeivP7IyzogWHV4aWFvaHUNCj4gPiC3osvNyrG85DogMjAxM8TqMTDUwjEy
yNUgMTY6MjYNCj4gPiDK1bz+yMs6ICdSb2JlcnQgUmFzenVrJw0KPiA+ILOty806IEhhbm5lcyBH
cmVkbGVyOyBzdGF0dXNAaWV0Zi5vcmc7IEFzaHdvb2RzbWl0aFBldGVyDQo+ID4g1vfM4jogcmU6
IFtTdGF0dXNdIFN0YXR1cyBvZiBTcHJpbmcNCj4gPg0KPiA+DQo+ID4NCj4gPiA+IC0tLS0t08q8
/tStvP4tLS0tLQ0KPiA+ID4gt6K8/sjLOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6
dWtAZ21haWwuY29tXSC0+rHtIFJvYmVydA0KPiA+IFJhc3p1aw0KPiA+ID4gt6LLzcqxvOQ6IDIw
MTPE6jEw1MIxMsjVIDE1OjM1DQo+ID4gPiDK1bz+yMs6IFh1eGlhb2h1DQo+ID4gPiCzrcvNOiBI
YW5uZXMgR3JlZGxlcjsgc3RhdHVzQGlldGYub3JnOyBBc2h3b29kc21pdGhQZXRlcg0KPiA+ID4g
1vfM4jogUmU6ILTwuLQ6IFtTdGF0dXNdIFN0YXR1cyBvZiBTcHJpbmcNCj4gPiA+DQo+ID4gPiBM
RFAgaGFzIG5vdCByZW1vdmVkIGFueSBsaW1pdGF0aW9uLiBJZiB5b3UgdXNlIE1QTFMgeW91IHN0
aWxsIG5lZWQgdG8NCj4gPg0KPiA+IEkgbWVhbnQgIi4uLlByZWZpeCBTSE9VTEQgTk9UIHVzZSB0
aGUgbGFiZWwgZm9yIGZvcndhcmRpbmcgdW5sZXNzIGl0cyByb3V0aW5nDQo+ID4gdGFibGUgY29u
dGFpbnMgYW4gZW50cnkgdGhhdCBleGFjdGx5IG1hdGNoZXMgdGhlIEZFQyBFbGVtZW50LiIgYnkN
Cj4gImxpbWl0YXRpb24iLg0KPiA+DQo+ID4gPiBzZW5kIGFsbCBob3N0IEZFQ3MgaW4gTERQLiBU
aGVyZSBpcyBubyBtYWdpYyB0cmFuc2l0IG5vZGVzIGFyZSBub3QNCj4gPiA+IGF3YXJlIGFib3V0
IHlvdXIgb3ZlcmxheSBhcHBsaWNhdGlvbiAuLiB0aGV5IGNhbiBub3QgZGVtdXggb24gdGhlaXIN
Cj4gPiA+IG93bi4gTGFiZWwgbXVzdCBiZSBzcGVjaWZpYyB0byB0aGUgdHJhbnNwb3J0IGVuZHBv
aW50Lg0KPiA+DQo+ID4gRXhhY3RseS4gRkVDcyBjYW4ndCBiZSBhZ2dyZWdhdGVkIGFuZCB0aGVy
ZWZvcmUgdGhlIE1QTFMgZm9yd2FyZGluZyB0YWJsZQ0KPiBzaXplDQo+ID4gaXMgbm90IHJlZHVj
ZWQuDQo+ID4NCj4gPiA+IFJGQzUyODMganVzdCByZWR1Y2VzIElHUCBhbmQgUklCIHNpemUgLSBu
b3QgTERQOg0KPiA+ID4NCj4gPiA+ICAgICJOb3RlIHRoYXQgTERQIHJlLWFkdmVydGlzZXMgdG8g
aXRzIHBlZXJzIHRoZSBzcGVjaWZpYyBGRUMgZWxlbWVudA0KPiA+ID4gICAgRkVDMSwgYW5kIG5v
dCB0aGUgYWdncmVnYXRlZCBwcmVmaXggZm91bmQgaW4gdGhlIElQIFJJQiBkdXJpbmcgdGhlDQo+
ID4gPiAgICBsb25nZXN0LW1hdGNoIHNlYXJjaC4iDQo+ID4gPg0KPiA+ID4gSWYgeW91IHVzZSBJ
UCBlbmNhcHN1bGF0aW9uIHlvdSBkb24ndCBuZWVkIGFueSBhZGRpdGlvbmFsIHNpZ25hbGxpbmcN
Cj4gPiA+IHRvIHNlbmQgeW91ciBvdmVybGF5IGFwcGxpY2F0aW9uIGJldHdlZW4gYW55IHR3byBl
bmQgcG9pbnRzIGluIHRoZQ0KPiA+ID4gbmV0d29yayB5ZXQgYmVuZWZpdCBmcm9tIG5hdHVyYWwg
YWdncmVnYXRpb24gb2YgSVAgc3VibmV0cyBhdCBhbnkNCj4gPiA+IHBvaW50Lg0KPiA+DQo+ID4g
VGhlIGNvbmNlcm4gaXMgd2hldGhlciBhIGxpc3Qgb2YgSVB2NiBhZGRyZXNzZXMgb3IgYSBsaXN0
IG9mIHNob3J0IElEcyBpcyB1c2VkIGluIGENCj4gPiBwYWNrZXQgdG8gcmVwcmVzZW50IGFuIGV4
cGxpY2l0IHNvdXJjZSBwYXRoLiBJZiB0aGUgZm9ybWVyIGlzIHRoZSBjYXNlLCBJIGFncmVlDQo+
IHdpdGgNCj4gPiB5b3UuIEhvd2V2ZXIsIGl0IHNlZW0gdGhhdCBpcyBub3QgdGhlIHJlY29tbWVu
ZGVkIG9wdGlvbi4gT24gdGhlIGNvbnRyYXJ5LA0KPiA+IHRoZSBsYXR0ZXIgaXMuIFNlZSB0aGUg
Zm9sbG93aW5nIHN0YXRlbWVudCBxdW90ZWQgZnJvbQ0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHMtcnRnd2ctc2VnbWVudC1yb3V0aW5nOg0KPiA+DQo+
ID4gIiAuLi5UaGUgbWFpbiBkaWZmZXJlbmNlcyBmcm9tIHRoZSBJUHY2IHNvdXJjZSByb3V0ZSBt
b2RlbCBhcmU6ICBUaGUgc291cmNlDQo+ID4gcm91dGUgaXMgZW5jb2RlZCBhcyBhbiBvcmRlcmVk
IGxpc3Qgb2Ygc2VnbWVudHMgaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMuICINCj4gPg0KPiA+ID4g
TGlrZXdpc2Ugd2hlbiBTUiBTSURzIGFyZSBNUExTIGxhYmVscyB0aGV5IGNhbiBub3QgYmUgYWdn
cmVnYXRlZC4gV2hlbg0KPiA+ID4gU1IgU0lEcyBhcmUgSVAgYWRkcmVzc2VzIHRoZXkgY2FuIGJl
IG5pY2VseSBhZ2dyZWdhdGVkIGZvciBleGFtcGxlIGF0DQo+ID4gPiB0aGUgSUdQIG9yIEFTIGFy
ZWEgYm91bmRhcmllcy4NCj4gPg0KPiA+IEFzIEkgaGFkIGlsbHVzdHJhdGVkIGluIGEgcHJldmlv
dXMgZW1haWwgd2l0aCBhbiBleGFtcGxlLCBpZiB5b3Ugd2FudCB0byByZWR1Y2UNCj4gPiB0aGUg
TVBMUyBmb3J3YXJkaW5nIHRhYmxlIHNpemUsIHlvdSBjb3VsZCByZXBsYWNlIHRoZSBpbm5lcm1v
c3QgTFNQIHRvd2FyZHMNCj4gPiB0aGUgZmluYWwgdHVubmVsIGRlc3RpbmF0aW9uIChpLmUuLCB0
aGUgbGFzdCBob3Agb2YgdGhlIGV4cGxpY2l0IHBhdGgpIHdpdGggYW4NCj4gPiBJUC1iYXNlZCB0
dW5uZWwgd2hpbGUgc3RpbGwgdXNpbmcgTFNQcyB0byByZXByZXNlbnQgdGhlIHBhdGhzIHRvIHRo
ZSByZW1haW5pbmcNCj4gPiBob3BzIG9mIHRoZSBleHBsaWNpdCBwYXRoLiBJbiB0aGlzIHdheSwg
dGhlcmUgaXMgbm8gbmVlZCB0byBjcmVhdGUgbGFiZWwgYmluZGluZ3MNCj4gPiBmb3IgdGhvc2Ug
bGFyZ2UgYW1vdW50IG9mIGZpbmFsIHR1bm5lbCBlbmRwb2ludHMuDQo+ID4NCj4gPiBGb3IgZXhh
bXBsZSwgaW4gdGhlIGZvbGxvd2luZyB0b3BvbG9neSB3aGVyZSB0aGUgbWV0cmljcyBvZiBhbGwg
bGlua3MgYXJlIHRoZQ0KPiA+IHNhbWUsIGFzc3VtZSBBIHdhbnQgdG8gc2VuZCBhIHBhY2tldCBY
IHRvIFogdmlhIGEgZXhwbGljaXQgcm91dGUge0MsIEV9LCB0aGUNCj4gPiBwYWNrZXQgc2VudCBm
cm9tIEEgd291bGQgbG9vayBhczogfE1QTFMgbGFiZWwgZm9yIEN8R1JFIHR1bm5lbCB0byBFfHBh
Y2tldA0KPiBYfC4NCj4gDQo+IHMvWi9FDQo+IA0KPiA+IEEtLS0tLUItLS0tLS0tRC0tLS0tRQ0K
PiA+ICAgICAgXCAgIC8NCj4gPiAgICAgICAgQw0KPiA+DQo+ID4gQmVzdCByZWdhcmRzLA0KPiA+
IFhpYW9odQ0KPiA+DQo+ID4gPiByLg0KPiA+ID4NCj4gPiA+IE9uIFNhdCwgT2N0IDEyLCAyMDEz
IGF0IDU6MDUgQU0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gPiA+
ID4NCj4gPiA+ID4NCj4gPiA+ID4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+ID4gPj4gt6K8/sjL
OiBzdGF0dXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnN0YXR1cy1ib3VuY2VzQGlldGYub3Jn
XSC0+rHtDQo+ID4gPiA+PiBIYW5uZXMgR3JlZGxlcg0KPiA+ID4gPj4gt6LLzcqxvOQ6IDIwMTPE
6jEw1MIxMcjVIDIyOjExDQo+ID4gPiA+PiDK1bz+yMs6IFJvYmVydCBSYXN6dWsNCj4gPiA+ID4+
ILOty806IHN0YXR1c0BpZXRmLm9yZzsgQXNod29vZHNtaXRoUGV0ZXINCj4gPiA+ID4+INb3zOI6
IFJlOiBbU3RhdHVzXSBTdGF0dXMgb2YgU3ByaW5nDQo+ID4gPiA+Pg0KPiA+ID4gPj4gT24gRnJp
LCBPY3QgMTEsIDIwMTMgYXQgMDM6MDA6MDJQTSArMDIwMCwgUm9iZXJ0IFJhc3p1ayB3cm90ZToN
Cj4gPiA+ID4+IHwgPiBwbGVhc2UgaGF2ZSBhIGxvb2sgYXQNCj4gPiA+ID4+IHwgPg0KPiA+ID4g
Pj4NCj4gPiA+DQo+ID4NCj4gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9hcHBzL21lZGlhd2lraS9t
cGxzLWxpbnV4L2luZGV4LnBocD90aXRsZT1NYWluX1BhZ2UNCj4gPiA+ID4+IHwNCj4gPiA+ID4+
IHwgWyAuLi4gXSBQbGVhc2UgcG9pbnQgbWUgdG8gYW55DQo+ID4gPiA+PiB8IGxpbnV4IGRpc3Ry
aWJ1dGlvbiB3aGljaCBvZmZpY2lhbGx5IHN1cHBvcnRzIHRoaXMuIEFsc28gcGxlYXNlIHBvaW50
DQo+ID4gPiA+PiB8IG1lIHRvIHRoZSBvZmZpY2lhbCBsaW51eCBrZXJuZWwgd2hpY2ggc3VwcG9y
dHMgbXBscyBrZXJuZWwgcHJvamVjdC4NCj4gPiA+ID4+DQo+ID4gPiA+PiBpIGFtIG5vdCBzdXJl
IGlmIHRoZXJlIGlzIHN1Y2ggYSB0aGluZyBhcyBhbiAib2ZmaWNpYWwgbGludXgga2VybmVsIg0K
PiA+ID4gPj4gICBvZiBjb3Vyc2UgdGhlcmUgaXMgbGludXMnIGFuZCBoaXMgbGlldXRlbmFudHMg
Z2l0IHRyZWVzIC0gaG93ZXZlcg0KPiA+ID4gPj4gICBldmVyeSBtYWpvciBsaW51eCBkaXN0cmli
dXRpb24gcHVsbHMgZnJvbSB0aGVyZSBhbmQgYWRkcyBhIHRvbg0KPiA+ID4gPj4gICBvZiBwYXRj
aGVzIHRvIGl0LiAtIHRoZSBsaW51eCBNUExTIGV4dGVuc2lvbnMgYXJlIGJhc2ljYWxseQ0KPiA+
ID4gPj4gICBrZXJuZWwgcGF0Y2hlcyBwbHVzIHVzZXJzcGFjZSB1dGlsaXppdGllcyAtIG5vdGhp
bmcgbW9yZS4NCj4gPiA+ID4+ICAgc28gaWYgeW91IHdhbnQgdG8gZ2V0IGl0IHRvIHdvcmsgLSBn
ZXQgeW91ciBmYXZvdXJpdGUNCj4gPiA+ID4+ICAgKGxpbnV4IGZyb20gc2NyYXRjaCkgZGlzdHJv
IGFuZCBhcHBseSB0aGUgcGF0Y2hlcyAuLi4NCj4gPiA+ID4+ICAgaSBkaWQgaXQgd2l0aCAnZ2Vu
dG9vJyBsaW51eCBhbmQgYXMgZmFyIGFzIGkgY2FuIHRlbGwgaXQgd29ya3MgZmluZQ0KPiA+ID4g
Pj4gICBldmVuIHdpdGggbDJ2cG4gc2VydmljZXMgb24gdG9wIG9mIHRoZSB0cmFuc3BvcnQgTFNQ
cy4NCj4gPiA+ID4+ICAgICBub3RlIHRoYXQgdGhlcmUgYXJlIGFsc28gcHJlLWNvb2tlZCBkZWJp
YW4gSVNPIGltYWdlcyB3aXRoDQo+ID4gZXZlcnl0aGluZw0KPiA+ID4gPj4gICAgIGFwcGxpZWQg
aWYgeW91IGRvIG5vdCB3YW50IHRvIGNvbXBpbGUgeW91ciBrZXJuZWwgYnkgeW91cnNlbGYuDQo+
ID4gPiA+Pg0KPiA+ID4gPj4gfCA+IGNhbiB5b3UgcG9pbnQgbWUgdG8gdGhlIHRleHQgd2hpY2gg
c2F5cyBzby4NCj4gPiA+ID4+IHwgPiBpIGNvdWxkIG5vdCBmaW5kIHN1Y2ggYSBjbGFpbSBpbiBy
ZmMzMDMxID8NCj4gPiA+ID4+IHwNCj4gPiA+ID4+IHwgTm90IGluIHJmYzMwMzEgYnV0IGluIHJm
YzUwMzYgLi4gcHJldHR5IG11Y2ggdGhlIG9ubHkgcHJhY3RpY2FsDQo+ID4gPiA+PiB8IHNpZ25h
bGxpbmcgcHJvdG9jb2wgZm9yIG1wbHMgdHJhbnNwb3J0IChub3QgYW4gb3ZlcmxheSBtcGxzDQo+
ID4gPiA+PiB8IHNpZ25hbGxpbmcpOg0KPiA+ID4gPj4gfA0KPiA+ID4gPj4gfCAgICAiUHJlZml4
IFNIT1VMRCBOT1QgdXNlIHRoZSBsYWJlbCBmb3IgZm9yd2FyZGluZyB1bmxlc3MgaXRzIHJvdXRp
bmcNCj4gPiA+ID4+IHwgICAgIHRhYmxlIGNvbnRhaW5zIGFuIGVudHJ5IHRoYXQgZXhhY3RseSBt
YXRjaGVzIHRoZSBGRUMgRWxlbWVudC4iDQo+ID4gPiA+Pg0KPiA+ID4gPj4gb2ggeWVzLCBhbmQg
dGhpcyBpcyBpbmRlZWQgcHJvYmxlbWF0aWMgLi4uIGFuZCBpdHMgZml4ZWQgaGVyZToNCj4gPiA+
ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzUyODMudHh0DQo+ID4gPiA+DQo+ID4gPiA+
IEdyZWF0IHRoYXQgTERQIGhhcyByZW1vdmVkIHRoYXQgbGltaXRhdGlvbi4gV2hlbiB1c2luZyBJ
U0lTIG9yIE9TUEYgZm9yDQo+ID4gbGFiZWwNCj4gPiA+IGRpc3RyaWJ1dGlvbiBwdXJwb3NlLCB3
ZSBzaG91bGQgZm9sbG93IHRoZSBzYW1lIHByaW5jaXBsZS4gSW4gdGhpcyB3YXksIHRoZQ0KPiA+
ID4gc2NhbGFiaWxpdHkgb2YgSUdQIHdvdWxkIG5vdCBiZSBpbXBhY3RlZCBieSB0aGUgU1BSSU5H
IGFyY2hpdGVjdHVyZS4NCj4gPiA+ID4NCj4gPiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiBY
aWFvaHUNCj4gPiA+ID4NCj4gPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gPiA+PiBzdGF0dXMgbWFpbGluZyBsaXN0DQo+ID4gPiA+PiBz
dGF0dXNAaWV0Zi5vcmcNCj4gPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vc3RhdHVzDQo=

From rraszuk@gmail.com  Sat Oct 12 09:30:52 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16A21E8180 for ; Sat, 12 Oct 2013 09:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.37
X-Spam-Level: 
X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.525,  BAYES_00=-2.599, DIET_1=0.083, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSF7nWKR4UGz for ; Sat, 12 Oct 2013 09:30:52 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C86FC21E8197 for ; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so8201142iec.20 for ; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Oe7rTVqCBYOMNUPbhKe8sX+W1CbY99TF8RAZEFiBEkQ=; b=dm9UKTF9UYDyhZPUHmRSxEtx03oJm8Qk60HPldmVd8QRbPKZ/8q2UQXAbeSjpsSw6L 39S2exRHbKt0SenCLO2VQwFJcDd2DLGyVbpPZ0x+KLOvzc7iG8nRsLXg19ZQy99m0yU1 +G9QBVYqYu90Q9h+T35OXnxMWs9ecQsKztp24BJiQkoTU6jeRp1WF/12G5lAPo/LWisr v0iYFXWHZG0euciUQxMqF4PQFVZ+2xg0e9gseXb4vxADI5TsxPiaknWtAVCccd8BKc0I ARhScPsF8Nz3TU8mHW+mP1YPD3OgxBpsgFz9mM2vxqEEuFlcV2lcRAY8TUACYSJ7sA8F N03g==
MIME-Version: 1.0
X-Received: by 10.50.27.9 with SMTP id p9mr6884216igg.53.1381595448132; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Sat, 12 Oct 2013 09:30:48 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com>
Date: Sat, 12 Oct 2013 18:30:48 +0200
X-Google-Sender-Auth: fQQMI8Z0ki7cpq-36qNmfyZdaFc
Message-ID: 
From: Robert Raszuk 
To: Xuxiaohu 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Oct 2013 16:30:52 -0000

Hi Xuxiahou,

> As I had illustrated in a previous email with an example, if you want to
> reduce the MPLS forwarding table size, you could replace the innermost
> LSP towards the final tunnel destination (i.e., the last hop of the explicit
> path) with an IP-based tunnel while still using LSPs to represent the paths
> to the remaining hops of the explicit path. In this way, there is no need to
> create label bindings for those large amount of final tunnel endpoints.


And my observation is that if you already remove inner most LSP and
replace it with IP encapsulation there is no need to add any
subsequent LSPs as well .. just in the case of need for steering or
service chaining add few extension headers.

Why would I run LDP if I IP encapsulation provides me with the
functional alternative and less control plane state ?

All compatible with each other, no need for extra heavy weight
signalling like you would need with RSVP-TE for path engineering.

Cheers,
R.

From xuxiaohu@huawei.com  Sun Oct 13 18:43:08 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7B21E8148 for ; Sun, 13 Oct 2013 18:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level: 
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=0.879,  BAYES_00=-2.599, CN_BODY_35=0.339, DIET_1=0.083, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1sOyi7MiLop for ; Sun, 13 Oct 2013 18:43:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2493E21E8098 for ; Sun, 13 Oct 2013 18:42:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWT83440; Mon, 14 Oct 2013 01:42:59 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 02:42:21 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 14 Oct 2013 02:42:57 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.24]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Mon, 14 Oct 2013 09:42:48 +0800
From: Xuxiaohu 
To: Robert Raszuk 
Thread-Topic: [Status] Status of Spring
Thread-Index: AQHOxySiOj9W0vX9yEuMWq0FgRYldZnwvGoAgAKr+0A=
Date: Mon, 14 Oct 2013 01:42:47 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215CEF@NKGEML512-MBS.china.huawei.com>
References: <52569169.20404@cisco.com>  <5256F76D.9080905@cisco.com> <7AE6A4247B044C4ABE0A5B6BF427F8E209913009@dfweml513-mbb.china.huawei.com> <339a1b4a20e74d719c7669a4f09ac337@BY2PR05MB142.namprd05.prod.outlook.com>  <7AE6A4247B044C4ABE0A5B6BF427F8E20991312A@dfweml513-mbb.china.huawei.com>  <20131011110724.GB29384@juniper.net>  <20131011141123.GD29526@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215A89@NKGEML512-MBS.china.huawei.com>  <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08215B4F@NKGEML512-MBS.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "status@ietf.org" 
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 01:43:08 -0000

Um9iZXJ0LA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IHJyYXN6dWtAZ21haWwu
Y29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dILT6se0gUm9iZXJ0IFJhc3p1aw0KPiC3osvN
yrG85DogMjAxM8TqMTDUwjEzyNUgMDozMQ0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOty806IHN0
YXR1c0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW1N0YXR1c10gU3RhdHVzIG9mIFNwcmluZw0KPiAN
Cj4gSGkgWHV4aWFob3UsDQo+IA0KPiA+IEFzIEkgaGFkIGlsbHVzdHJhdGVkIGluIGEgcHJldmlv
dXMgZW1haWwgd2l0aCBhbiBleGFtcGxlLCBpZiB5b3Ugd2FudCB0bw0KPiA+IHJlZHVjZSB0aGUg
TVBMUyBmb3J3YXJkaW5nIHRhYmxlIHNpemUsIHlvdSBjb3VsZCByZXBsYWNlIHRoZSBpbm5lcm1v
c3QNCj4gPiBMU1AgdG93YXJkcyB0aGUgZmluYWwgdHVubmVsIGRlc3RpbmF0aW9uIChpLmUuLCB0
aGUgbGFzdCBob3Agb2YgdGhlIGV4cGxpY2l0DQo+ID4gcGF0aCkgd2l0aCBhbiBJUC1iYXNlZCB0
dW5uZWwgd2hpbGUgc3RpbGwgdXNpbmcgTFNQcyB0byByZXByZXNlbnQgdGhlIHBhdGhzDQo+ID4g
dG8gdGhlIHJlbWFpbmluZyBob3BzIG9mIHRoZSBleHBsaWNpdCBwYXRoLiBJbiB0aGlzIHdheSwg
dGhlcmUgaXMgbm8gbmVlZCB0bw0KPiA+IGNyZWF0ZSBsYWJlbCBiaW5kaW5ncyBmb3IgdGhvc2Ug
bGFyZ2UgYW1vdW50IG9mIGZpbmFsIHR1bm5lbCBlbmRwb2ludHMuDQo+IA0KPiANCj4gQW5kIG15
IG9ic2VydmF0aW9uIGlzIHRoYXQgaWYgeW91IGFscmVhZHkgcmVtb3ZlIGlubmVyIG1vc3QgTFNQ
IGFuZA0KPiByZXBsYWNlIGl0IHdpdGggSVAgZW5jYXBzdWxhdGlvbiB0aGVyZSBpcyBubyBuZWVk
IHRvIGFkZCBhbnkNCj4gc3Vic2VxdWVudCBMU1BzIGFzIHdlbGwgLi4ganVzdCBpbiB0aGUgY2Fz
ZSBvZiBuZWVkIGZvciBzdGVlcmluZyBvcg0KPiBzZXJ2aWNlIGNoYWluaW5nIGFkZCBmZXcgZXh0
ZW5zaW9uIGhlYWRlcnMuDQoNCkFyZSB5b3Ugc3VnZ2VzdGluZyBjb250YWluaW5nIGFuIG9yZGVy
ZWQgbGlzdCBvZiBJUHY2IGFkZHJlc3NlcywgcmF0aGVyIHRoYW4gc2hvcnQgc2VnbWVudCBJRHMg
aW4gYSBwYWNrZXQgdG8gaW5kaWNhdGUgYW4gZXhwbGljaXQgcGF0aD8gDQoNCj4gV2h5IHdvdWxk
IEkgcnVuIExEUCBpZiBJIElQIGVuY2Fwc3VsYXRpb24gcHJvdmlkZXMgbWUgd2l0aCB0aGUNCj4g
ZnVuY3Rpb25hbCBhbHRlcm5hdGl2ZSBhbmQgbGVzcyBjb250cm9sIHBsYW5lIHN0YXRlID8NCg0K
T3V0ZXIgTFNQcyBjb3VsZCBiZSBSU1ZQLVRFIExTUHMgb3IgU1BSSU5HLWJhc2VkIExTUHMgYXMg
d2VsbCB3aGljaCBwcm92aWRlIHlvdSBtb3JlIGZlYXR1cmVzIGluIGFkZGl0aW9uIHRvIHBhdGgg
Y29ubmVjdGl2aXR5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBBbGwgY29tcGF0aWJs
ZSB3aXRoIGVhY2ggb3RoZXIsIG5vIG5lZWQgZm9yIGV4dHJhIGhlYXZ5IHdlaWdodA0KPiBzaWdu
YWxsaW5nIGxpa2UgeW91IHdvdWxkIG5lZWQgd2l0aCBSU1ZQLVRFIGZvciBwYXRoIGVuZ2luZWVy
aW5nLg0KDQo+IENoZWVycywNCj4gUi4NCg==

From hannes@juniper.net  Mon Oct 14 00:31:09 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF0F21F8266; Mon, 14 Oct 2013 00:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.162
X-Spam-Level: 
X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgBzeh8rF7d4; Mon, 14 Oct 2013 00:31:03 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id A1B0621E80C4; Mon, 14 Oct 2013 00:31:02 -0700 (PDT)
Received: from mail13-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 07:31:01 +0000
Received: from mail13-db9 (localhost [127.0.0.1])	by mail13-db9-R.bigfish.com (Postfix) with ESMTP id B4A224040A; Mon, 14 Oct 2013 07:31:01 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zzbb2dIdb82h98dI9371Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275bhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail13-db9: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT002.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail13-db9 (localhost.localdomain [127.0.0.1]) by mail13-db9 (MessageSwitch) id 1381735859282904_13638; Mon, 14 Oct 2013 07:30:59 +0000 (UTC)
Received: from DB9EHSMHS013.bigfish.com (unknown [10.174.16.234])	by mail13-db9.bigfish.com (Postfix) with ESMTP id 358402A0041; Mon, 14 Oct 2013 07:30:59 +0000 (UTC)
Received: from BLUPRD0512HT002.namprd05.prod.outlook.com (132.245.1.149) by DB9EHSMHS013.bigfish.com (10.174.14.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 07:30:59 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.163) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 07:30:57 +0000
Date: Mon, 14 Oct 2013 09:30:51 +0200
From: Hannes Gredler 
To: Jari Arkko 
Message-ID: <20131014073051.GE31855@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> <525848E1.3000806@cisco.com> <40195890-D11E-4500-B257-3C760B4F172B@piuha.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <40195890-D11E-4500-B257-3C760B4F172B@piuha.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 07:31:09 -0000

jari,

its the other way around - 
we should take-off packet filters ... they are not deployable at internet level scale,

in contrast cookie based schemes fundamentally address the
'packet injection from anywhere in the internet' problem.

/hannes

On Fri, Oct 11, 2013 at 10:49:32PM +0300, Jari Arkko wrote:
| Cookies are one way to do this, but they are part of the base level security - not the complements. I don't think we should add them to the list.
| 
| Jari
| 
| On Oct 11, 2013, at 9:52 PM, Stewart Bryant  wrote:
| 
| > On 11/10/2013 19:32, Hannes Gredler wrote:
| >> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
| >> | After some off-line chatting, I have a proposal for text to be added to the charter:
| >> |
| >> | There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
| >> |
| >> | Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
| >> 
| >> jari,
| >> 
| >> i do not think that packet-filtering is feasible on the default-free-zone
| >> on the internet. - can you take off packet-filtering in favour of security cookies ?
| >> 
| > Packet filtering is prefixed by such as. In some cases it may be feasible and better
| > that a cookie. I can add cookies to the list without requiring any particular solution
| > be picked at this stage. The list is just, I believe to provide confidence that a solution
| > is feasible in the various contexts.
| > 
| > Stewart
| > 
| > 
| 
| 
| 


From hannes@juniper.net  Mon Oct 14 00:36:25 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FBE11E8176 for ; Mon, 14 Oct 2013 00:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CymLqRnembu for ; Mon, 14 Oct 2013 00:36:17 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF211E8178 for ; Mon, 14 Oct 2013 00:36:08 -0700 (PDT)
Received: from mail81-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.22; Mon, 14 Oct 2013 07:36:06 +0000
Received: from mail81-am1 (localhost [127.0.0.1])	by mail81-am1-R.bigfish.com (Postfix) with ESMTP id 99C3C4024A; Mon, 14 Oct 2013 07:36:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:132.245.1.149; KIP:(null); UIP:(null); IPV:NLI; H:BLUPRD0512HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -1
X-BigFish: VPS-1(zz98dIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1c0dh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
Received-SPF: pass (mail81-am1: domain of juniper.net designates 132.245.1.149 as permitted sender) client-ip=132.245.1.149; envelope-from=hannes@juniper.net; helo=BLUPRD0512HT003.namprd05.prod.outlook.com ; .outlook.com ; 
Received: from mail81-am1 (localhost.localdomain [127.0.0.1]) by mail81-am1 (MessageSwitch) id 1381736164656262_16585; Mon, 14 Oct 2013 07:36:04 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.234])	by mail81-am1.bigfish.com (Postfix) with ESMTP id 9C36E3E0082; Mon, 14 Oct 2013 07:36:04 +0000 (UTC)
Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by AM1EHSMHS020.bigfish.com (10.3.207.158) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 14 Oct 2013 07:36:04 +0000
Received: from juniper.net (193.110.54.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 14 Oct 2013 07:36:02 +0000
Date: Mon, 14 Oct 2013 09:35:57 +0200
From: Hannes Gredler 
To: Robert Raszuk 
Message-ID: <20131014073556.GF31855@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>  <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [193.110.54.36]
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 07:36:25 -0000

On Fri, Oct 11, 2013 at 09:49:11PM +0200, Robert Raszuk wrote:
| > all an attacker then needs to do is:
| >
| > 1. pick a route which transits an IPv6-SR capable node
| > 2. add a forged extension header
| >
| > voila - you can get anywhere you want in the IPv6-SR domain;
| 
| Not really ...
| 
| Yes it will be allowed to get into any network, however it is very
| easy not to examine extension headers on such packets hence only
| provide v6 transit as any DFZ would provide today without any SR
| enabled.

so you are advovating that internet DFZ router MUST NOT support IPv6-SR
based forwarding as a consequence of your statement above ?

| [ ... ] But your points are great as those issues you bring when addressed by
| subsequent drafts will make the solution much more robust for any AF
| it is deployed to work with.

i am not sure those things can get fixed at a architectual
level at all, given the amount of failed attempts so far.

/hannes


From rraszuk@gmail.com  Mon Oct 14 01:41:08 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877E721E814C for ; Mon, 14 Oct 2013 01:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level: 
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.487,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22v2o3kC1W6C for ; Mon, 14 Oct 2013 01:41:07 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E83CC21E8158 for ; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so2710028iec.14 for ; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ANCvK0V/P8+XY5swthdernFpSR6zY42iZcFQvKa8gPQ=; b=IzcoRArMTIgIl2uEgwNSu+ab5zg9z1I5/in0DdDvKVMb9u4FwlYKrECkNbpnKeSHno KYMR+8SPuhfcoHA4QZRLpfHFFFK3GYOIt6URkt7tESFN4TSiwQ/v+3fa0xSQJL8P95JO DCLUQMDab9/Y/yhFa3OvhDbm/Inw5qhFBdivH5Sm6dvMbrjD07BcI038DFd3SErkQXMm MYWVZlyT6XQJnc0XzO2/3RDWgRumiHDUUiJj8CXoslIsGLycWwSqPPm51Uj6AMSRu7bJ 2la88XzDgFgSsWDNv0pTzSlk4ZYoie/0UCHerVFy9MPv+RJ8RPtoVaxvPX/q4Z2X8ne0 5Spw==
MIME-Version: 1.0
X-Received: by 10.50.97.35 with SMTP id dx3mr12181013igb.55.1381740061429; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
In-Reply-To: <20131014073556.GF31855@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>  <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net>  <20131014073556.GF31855@juniper.net>
Date: Mon, 14 Oct 2013 10:41:01 +0200
X-Google-Sender-Auth: qTreFutx0oKWwdx7EZEO5gpOYSQ
Message-ID: 
From: Robert Raszuk 
To: Hannes Gredler 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 08:41:09 -0000

Hi Hannes,

> | Yes it will be allowed to get into any network, however it is very
> | easy not to examine extension headers on such packets hence only
> | provide v6 transit as any DFZ would provide today without any SR
> | enabled.
>
> so you are advovating that internet DFZ router MUST NOT support IPv6-SR
> based forwarding as a consequence of your statement above ?

No .. not at all. DFZ routers will first check if the v6 header
belongs to infrastructure subnets. (Those will be filtered on the
edges perhaps with the exception of some heavy rate limited ICMPs - in
fact I am not sure if ICMP should support SR at all).

If the v6 header belongs to infrastructure range SID lookup will
follow if not outer v6 header will be used for forwarding (as today).

/* Now I am expecting few emails with complains ..Ohhh my ASICs can
not choose switching vector based on the outer IP header address at
line rate ;) */

> i am not sure those things can get fixed at a architectual
> level at all, given the amount of failed attempts so far.

Do we have a list or wiki page of those "failed attempts" ? In fact so
far I think the focus has been on the charter discussion which is
quite orthogonal to the SR architecture ..

Best,
r.

From jari.arkko@piuha.net  Mon Oct 14 02:53:07 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C354421E8164; Mon, 14 Oct 2013 02:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkH1hYA9w3M2; Mon, 14 Oct 2013 02:52:18 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 66FED11E8182; Mon, 14 Oct 2013 02:51:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 896C12CCBE; Mon, 14 Oct 2013 12:50:45 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z78kuR4enh7s; Mon, 14 Oct 2013 12:50:45 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7043C2CC48; Mon, 14 Oct 2013 12:50:44 +0300 (EEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
Date: Mon, 14 Oct 2013 12:45:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <79861846-6F26-4F18-B645-21E11C25F341@piuha.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
Cc: Thomas Narten , "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 09:53:07 -0000

We've had some tweaks to the text in the discussion, Stewart has placed =
the necessary text in the charter and I'm ready to clear. Still =
wondering if the WG is OK or if you need more discussion.

Jari


From stbryant@cisco.com  Mon Oct 14 05:59:36 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4A21F93BF; Mon, 14 Oct 2013 05:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.506
X-Spam-Level: 
X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8tadoehfsJI; Mon, 14 Oct 2013 05:59:31 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 42AD721F923D; Mon, 14 Oct 2013 05:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2037; q=dns/txt; s=iport; t=1381755571; x=1382965171; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rPVH8PupsTtFXgvmBm8ksTEl8136uib+jzasGQ1CUq8=; b=mKzWCpvbJv81yVkZk5o7+ABkz647tBHhqcjgRasNyA4mEZ/JPzOM7M4J jCBOKwtdu1S3Tzbtlzk6MXLBjmA8ri7BHY7sDIH2uZ43MXRAFvh/f37Sm QcVNqimw9VY7melzM94wkWD1Js0mEEF5ks5Sd9bJoiy6aVLpY9WYKUQJA U=;
X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="87393129"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Oct 2013 12:59:29 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9ECxNOw019403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 12:59:25 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9ECxDWd029364; Mon, 14 Oct 2013 13:59:15 +0100 (BST)
Message-ID: <525BEAA1.8060709@cisco.com>
Date: Mon, 14 Oct 2013 13:59:13 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Benoit Claise 
References: <52584CCA.8000902@cisco.com> <525A75FB.6010409@cisco.com>
In-Reply-To: <525A75FB.6010409@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 12:59:36 -0000

Benoit

Please can you look at the latest version of the charter.

You now has your text. Are you able to clear?

Stewart

On 13/10/2013 11:29, Benoit Claise wrote:
> Stewart,
>
> The following two paragraphs are redundant
>
>     SPRING should both provide support for its use as
>     an OAM tool in SPRING enabled networks, and the
>     necessary OAM and other management tools needed to
>     manage a SPRING enabled network.
>
>     The SPRING WG should provide OAM and the
>     management needed to manage  SPRING enabled networks.
>     The SPRING protocol itself may also be used as a tool for OAM
>     in SPRING enabled networks.
>
> Keep the second one.
>
> OLD:
> 	o Specify OAM the mechanisms needed to support SPRING
>
> 	o Publish SPRING management requirements document.
>
> NEW:
>
> 	o Publish SPRING management requirements document.
>
> 	o Specify_the OAM_  mechanisms needed to support SPRING.
>
> Regards, Benoit
>> Version 12 of the charter text has Jari's security text
>> with Hannes' addition of cookies as a method to be
>> considered.
>>
>> I have modified the OAM/Management text to be
>> o Specify OAM the mechanisms needed to support SPRING
>>
>> o Publish SPRING management requirements document.
>>
>> Benoit, please can you take a look at the above and
>> if this is still not what you are looking for
>> please provide text. Once we have cleared the Blocking
>> comments (probably during external review), I propose
>> that we convert the final list to milestones per
>> Adrian's comment, in which case the separation is
>> better.
>> The latest text as always is at:
>>
>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>
>> If this satisfies Jari and Benoit's concerns I would like
>> to put this in external review, where it is still available
>> for comment to polish out any last issues.
>>
>> - Stewart
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


From stbryant@cisco.com  Mon Oct 14 06:01:12 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2F21F9399; Mon, 14 Oct 2013 06:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.508
X-Spam-Level: 
X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do1nn69qxB2w; Mon, 14 Oct 2013 06:01:06 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 45B9011E8127; Mon, 14 Oct 2013 06:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=114; q=dns/txt; s=iport; t=1381755663; x=1382965263; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=W4hj32ziAzgSEq7qo5vYArQM3GUZbHiwqksXwrWiGwY=; b=Ena0o9nmUeW/2pwcTcSPrxvxlgTy3pb7JbECmgsXZV81HJBRnwKeOjSM qEyhEUW+M6O5sfFBhju/l+vRyVU3dI4aDrmP7MUgyJ5PKcLptigIDikeM jiKRCsMN/eS/5D/oFWqupm/i07fnCyAyvXDgatyFxNe7eY2h/vvfIocRH Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAKzpW1KQ/khL/2dsb2JhbABZgwfCd4EiFnSCJgEBBDhAARALIRYPCQMCAQIBRQYNAQcBAYgCvV+PUgeEIwOYBZICgyU
X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="87393169"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Oct 2013 13:01:02 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9ED0vpa019476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 13:00:59 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9ED0sG0029488; Mon, 14 Oct 2013 14:00:55 +0100 (BST)
Message-ID: <525BEB06.1050002@cisco.com>
Date: Mon, 14 Oct 2013 14:00:54 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Jari Arkko 
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> <525848E1.3000806@cisco.com> <40195890-D11E-4500-B257-3C760B4F172B@piuha.net> <52586BBB.2000400@cisco.com>
In-Reply-To: <52586BBB.2000400@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 13:01:12 -0000

Jari

The latest version of the charter now has your security
text. Are you now able to clear?

- Stewart

From bclaise@cisco.com  Sun Oct 13 03:29:30 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDB21E809C; Sun, 13 Oct 2013 03:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.575
X-Spam-Level: 
X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0DFheT6YrfL; Sun, 13 Oct 2013 03:29:26 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id EABF121E80AF; Sun, 13 Oct 2013 03:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4474; q=dns/txt; s=iport; t=1381660165; x=1382869765; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=9visfsjfiYnbfjqyun0II+MtqNrjofQXOLfsarhUtLg=; b=QyIJRqOqhrZeQV8LvqHiW1iMqMBA4e7/M0kMCJwwuRPiZ341EYRsV668 wihx/1een9Z3EhYiWVPje7U3yohsLWhV6IKrDSVT9pjrZs9u8Oan2ALCl nnwzI0kHeRDitA9uEJvA8Bu9TD87XRQnnYPDv2Vznck/+FYGBaTQTjCCR k=;
X-IronPort-AV: E=Sophos;i="4.93,485,1378857600"; d="scan'208,217";a="18722946"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 13 Oct 2013 10:29:23 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9DATFNh000580; Sun, 13 Oct 2013 10:29:18 GMT
Message-ID: <525A75FB.6010409@cisco.com>
Date: Sun, 13 Oct 2013 12:29:15 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: stbryant@cisco.com
References: <52584CCA.8000902@cisco.com>
In-Reply-To: <52584CCA.8000902@cisco.com>
Content-Type: multipart/alternative; boundary="------------070605050908090204070706"
X-Mailman-Approved-At: Mon, 14 Oct 2013 14:39:16 -0700
Cc: Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Oct 2013 10:29:30 -0000

This is a multi-part message in MIME format.
--------------070605050908090204070706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stewart,

The following two paragraphs are redundant

    SPRING should both provide support for its use as
    an OAM tool in SPRING enabled networks, and the
    necessary OAM and other management tools needed to
    manage a SPRING enabled network.

    The SPRING WG should provide OAM and the
    management needed to manage  SPRING enabled networks.
    The SPRING protocol itself may also be used as a tool for OAM
    in SPRING enabled networks.

Keep the second one.

OLD:

	o Specify OAM the mechanisms needed to support SPRING

	o Publish SPRING management requirements document.

NEW:

	o Publish SPRING management requirements document.

	o Specify_the OAM_  mechanisms needed to support SPRING.

Regards, Benoit
> Version 12 of the charter text has Jari's security text
> with Hannes' addition of cookies as a method to be
> considered.
>
> I have modified the OAM/Management text to be
> o Specify OAM the mechanisms needed to support SPRING
>
> o Publish SPRING management requirements document.
>
> Benoit, please can you take a look at the above and
> if this is still not what you are looking for
> please provide text. Once we have cleared the Blocking
> comments (probably during external review), I propose
> that we convert the final list to milestones per
> Adrian's comment, in which case the separation is
> better.
> The latest text as always is at:
>
> https://datatracker.ietf.org/doc/charter-ietf-spring/
>
> If this satisfies Jari and Benoit's concerns I would like
> to put this in external review, where it is still available
> for comment to polish out any last issues.
>
> - Stewart


--------------070605050908090204070706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Stewart,

      

      The following two paragraphs are redundant

      

        
SPRING should both provide support for its use as 
an OAM tool in SPRING enabled networks, and the 
necessary OAM and other management tools needed to 
manage a SPRING enabled network.

The SPRING WG should provide OAM and the 
management needed to manage  SPRING enabled networks. 
The SPRING protocol itself may also be used as a tool for OAM
in SPRING enabled networks.


      

      Keep the second one.

      

      OLD:

      
	o Specify OAM the mechanisms needed to support SPRING 

	o Publish SPRING management requirements document.

NEW:

	o Publish SPRING management requirements document.

	o Specify the OAM mechanisms needed to support SPRING.



      Regards, Benoit

    

    

      
      Version 12 of the charter text has Jari's security text

      with Hannes' addition of cookies as a method to be

      considered.

      

      I have modified the OAM/Management text to be

      
o Specify OAM the mechanisms needed to support SPRING 

o Publish SPRING management requirements document.

Benoit, please can you take a look at the above and
if this is still not what you are looking for
please provide text. Once we have cleared the Blocking 
comments (probably during external review), I propose 
that we convert the final list to milestones per
Adrian's comment, in which case the separation is
better.


      The latest text as always is at:

      

      https://datatracker.ietf.org/doc/charter-ietf-spring/

      

      If this satisfies Jari and Benoit's concerns I would like

      to put this in external review, where it is still available 

      for comment to polish out any last issues.

      

      - Stewart

    

    

  


--------------070605050908090204070706--

From bclaise@cisco.com  Mon Oct 14 06:11:49 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931FA11E818A; Mon, 14 Oct 2013 06:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.577
X-Spam-Level: 
X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMpbqc0iuc9P; Mon, 14 Oct 2013 06:11:45 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B92F311E8185; Mon, 14 Oct 2013 06:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2181; q=dns/txt; s=iport; t=1381756305; x=1382965905; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BIV8KsAyBWLznHsOs9Cu0dIeSWep9bQX3AxEzy40DzM=; b=BEUJ9R//xkz0PtaFo/8MyOt1aAmr4A2epEn4Re8KDWrxbaMrkavSykU2 Us0P/E/OB0eASUVwNTs5KrorDrmo7ZmZL68BKuvuJNBzOrn1PEzAi6EBN fM/u/N6Dfk5t8uFIsu8D8EEAM0D+UURGqdz59UNgE50yPRu7POLJ8oeqS g=;
X-IronPort-AV: E=Sophos;i="4.93,492,1378857600"; d="scan'208";a="87393356"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Oct 2013 13:11:43 +0000
Received: from [10.61.108.110] (dhcp-10-61-108-110.cisco.com [10.61.108.110]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9EDBbtJ022329; Mon, 14 Oct 2013 13:11:39 GMT
Message-ID: <525BED88.1010006@cisco.com>
Date: Mon, 14 Oct 2013 15:11:36 +0200
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: stbryant@cisco.com
References: <52584CCA.8000902@cisco.com> <525A75FB.6010409@cisco.com> <525BEAA1.8060709@cisco.com>
In-Reply-To: <525BEAA1.8060709@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 14 Oct 2013 14:39:17 -0700
Cc: Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 13:11:49 -0000

Stewart,

Yes, I cleared
For the sake of completeness, one COMMENT left at 
https://datatracker.ietf.org/doc/charter-ietf-spring/ballot/#benoit-claise

Regards, Benoit

> Benoit
>
> Please can you look at the latest version of the charter.
>
> You now has your text. Are you able to clear?
>
> Stewart
>
> On 13/10/2013 11:29, Benoit Claise wrote:
>> Stewart,
>>
>> The following two paragraphs are redundant
>>
>>     SPRING should both provide support for its use as
>>     an OAM tool in SPRING enabled networks, and the
>>     necessary OAM and other management tools needed to
>>     manage a SPRING enabled network.
>>
>>     The SPRING WG should provide OAM and the
>>     management needed to manage  SPRING enabled networks.
>>     The SPRING protocol itself may also be used as a tool for OAM
>>     in SPRING enabled networks.
>>
>> Keep the second one.
>>
>> OLD:
>>     o Specify OAM the mechanisms needed to support SPRING
>>
>>     o Publish SPRING management requirements document.
>>
>> NEW:
>>
>>     o Publish SPRING management requirements document.
>>
>>     o Specify_the OAM_  mechanisms needed to support SPRING.
>>
>> Regards, Benoit
>>> Version 12 of the charter text has Jari's security text
>>> with Hannes' addition of cookies as a method to be
>>> considered.
>>>
>>> I have modified the OAM/Management text to be
>>> o Specify OAM the mechanisms needed to support SPRING
>>>
>>> o Publish SPRING management requirements document.
>>>
>>> Benoit, please can you take a look at the above and
>>> if this is still not what you are looking for
>>> please provide text. Once we have cleared the Blocking
>>> comments (probably during external review), I propose
>>> that we convert the final list to milestones per
>>> Adrian's comment, in which case the separation is
>>> better.
>>> The latest text as always is at:
>>>
>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>
>>> If this satisfies Jari and Benoit's concerns I would like
>>> to put this in external review, where it is still available
>>> for comment to polish out any last issues.
>>>
>>> - Stewart
>>
>
>


From stbryant@cisco.com  Mon Oct 14 15:43:00 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9179721E80FA; Mon, 14 Oct 2013 15:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.514
X-Spam-Level: 
X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHy97F8tC45k; Mon, 14 Oct 2013 15:42:55 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5616621E811B; Mon, 14 Oct 2013 15:42:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1381790575; x=1383000175; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=u5mbMMBpq9og87qw0IMKKfes05lzhSCAowCaXVbdGso=; b=mhUUj6AM9gz+rN8syTg25b5gzH0w8QVvQZivTi6Xpmkc2I9/yJCLg+v+ 2Wlyc2o3yAkQhEMGY+fLxzF8+RF/r3pZ6fCj8PoGtT2bT8FYBCHjOCTio Tk4eA8cZm8IupIIGU9AIv+p6e9aQxWhjg8Neh6Rz6BmXUQgq7fgB2I/1L M=;
X-IronPort-AV: E=Sophos;i="4.93,494,1378857600"; d="scan'208";a="160654042"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2013 22:42:53 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9EMgmnK028527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 22:42:49 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9EMgjW9000433; Mon, 14 Oct 2013 23:42:46 +0100 (BST)
Message-ID: <525C7365.9050103@cisco.com>
Date: Mon, 14 Oct 2013 23:42:45 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Benoit Claise 
References: <52584CCA.8000902@cisco.com> <525A75FB.6010409@cisco.com> <525BEAA1.8060709@cisco.com> <525BED88.1010006@cisco.com>
In-Reply-To: <525BED88.1010006@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Oct 2013 22:43:00 -0000

Hi Benoit

Technically it is per packet, and I can see applications where that 
might be
useful. Not too far from your home :) an OAM back to yourself is a flow,
but you might want to explore a different path on each packet.

It would be unfortunate if we lost the generality.

Stewart

On 14/10/2013 14:11, Benoit Claise wrote:
> Stewart,
>
> Yes, I cleared
> For the sake of completeness, one COMMENT left at 
> https://datatracker.ietf.org/doc/charter-ietf-spring/ballot/#benoit-claise
>
> Regards, Benoit
>
>> Benoit
>>
>> Please can you look at the latest version of the charter.
>>
>> You now has your text. Are you able to clear?
>>
>> Stewart
>>
>> On 13/10/2013 11:29, Benoit Claise wrote:
>>> Stewart,
>>>
>>> The following two paragraphs are redundant
>>>
>>>     SPRING should both provide support for its use as
>>>     an OAM tool in SPRING enabled networks, and the
>>>     necessary OAM and other management tools needed to
>>>     manage a SPRING enabled network.
>>>
>>>     The SPRING WG should provide OAM and the
>>>     management needed to manage  SPRING enabled networks.
>>>     The SPRING protocol itself may also be used as a tool for OAM
>>>     in SPRING enabled networks.
>>>
>>> Keep the second one.
>>>
>>> OLD:
>>>     o Specify OAM the mechanisms needed to support SPRING
>>>
>>>     o Publish SPRING management requirements document.
>>>
>>> NEW:
>>>
>>>     o Publish SPRING management requirements document.
>>>
>>>     o Specify_the OAM_  mechanisms needed to support SPRING.
>>>
>>> Regards, Benoit
>>>> Version 12 of the charter text has Jari's security text
>>>> with Hannes' addition of cookies as a method to be
>>>> considered.
>>>>
>>>> I have modified the OAM/Management text to be
>>>> o Specify OAM the mechanisms needed to support SPRING
>>>>
>>>> o Publish SPRING management requirements document.
>>>>
>>>> Benoit, please can you take a look at the above and
>>>> if this is still not what you are looking for
>>>> please provide text. Once we have cleared the Blocking
>>>> comments (probably during external review), I propose
>>>> that we convert the final list to milestones per
>>>> Adrian's comment, in which case the separation is
>>>> better.
>>>> The latest text as always is at:
>>>>
>>>> https://datatracker.ietf.org/doc/charter-ietf-spring/
>>>>
>>>> If this satisfies Jari and Benoit's concerns I would like
>>>> to put this in external review, where it is still available
>>>> for comment to polish out any last issues.
>>>>
>>>> - Stewart
>>>
>>
>>
>
> .
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


From sriganeshkini@gmail.com  Mon Oct 14 16:57:06 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BF321E80DD for ; Mon, 14 Oct 2013 16:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG-tIPhYfDW0 for ; Mon, 14 Oct 2013 16:57:05 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14C21E8120 for ; Mon, 14 Oct 2013 16:57:03 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id v10so8017680pde.24 for ; Mon, 14 Oct 2013 16:56:59 -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:content-type; bh=oF9ilw+yZhbuDOqmoNxmn4nb7eCPSWU0PctRM3nVJqA=; b=DBPOlobJ17qKVxdniou7LDaeYa3aYc72CpxUAoRSxvtRaOPlxYJAbSBLJq3xaTVwAJ od0d1BMMRvL7GyE8K3bUFK6knWvgzGlbgkm1AHEs9GGWCgeqa0kWPwNMJfm1pUvDB2bx 1ULnpWzDT2xT0zM7P2df8EI2dbiEpXDmQ6AVXbamPPJktU2byoWtDoOxdiBzFm7xw9pw kEyWgFyIJJ7tEp/BAZsI8dqlPSWSPD8QWridX0Yx2AhAXf98p6fpvyHYmkHRZhhVXJPq pGhPou7o9LFZkrv3Yia9GRkw1Es1hNfqSisfNn1F8JHjjiQf5N6ClWUuliY5RIu7IPEH Plzw==
X-Received: by 10.68.13.104 with SMTP id g8mr39005346pbc.33.1381795019393; Mon, 14 Oct 2013 16:56:59 -0700 (PDT)
MIME-Version: 1.0
Sender: sriganeshkini@gmail.com
Received: by 10.70.0.225 with HTTP; Mon, 14 Oct 2013 16:56:29 -0700 (PDT)
In-Reply-To: 
References: 
From: Sriganesh Kini 
Date: Mon, 14 Oct 2013 16:56:29 -0700
X-Google-Sender-Auth: AiSTJSir1gzcG0uHT6scKH_lrio
Message-ID: 
To: "Stewart Bryant (stbryant)" , "status@ietf.org" 
Content-Type: multipart/alternative; boundary=bcaec520ea7948933a04e8bc3938
Subject: Re: [Status] Include service application to the packet in the charter (-06)
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Oct 2013 23:57:06 -0000

--bcaec520ea7948933a04e8bc3938
Content-Type: text/plain; charset=UTF-8

Hi Stewart,

Can you comment on the proposed addition to the charter.

Thanks
- Sri


On Thu, Oct 10, 2013 at 12:25 AM, Sriganesh Kini <
sriganesh.kini@ericsson.com> wrote:

> The charter should explicitly mention that services may be applied to the
> packet along the steered explicit route. The application of services along
> the explicit route and its subsequent forwarding using information that was
> in the packet before the service was applied, is fundamentally different
> than just steering the packet.
>
> Suggested modification to charter (-06)
>
> The SPRING working group will define procedures that
> will allow a node to steer a packet along an explicit
> route using information attached to the packet and
> without the need for per-flow state information to be
> held at transit nodes.* The attached information in the packet may additionally specify services that are to be applied to the packet at the intermediate hops of the explicit route.*
>
>
> - Sri
>
>
>

--bcaec520ea7948933a04e8bc3938
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Stewart,

Can you comment on the =
proposed addition to the charter.

Thanks
- Sri


On Thu, Oct 10, =
2013 at 12:25 AM, Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:



The charter should explicit=
ly mention that services may be applied to the packet along the steered exp=
licit route. The application of services along the explicit route and its s=
ubsequent forwarding using information that was in the packet before the se=
rvice was applied, is fundamentally different than just steering the packet=
.




Suggested modification to charter (-06)

The SPRING working group =
will define procedures that=20
will allow a node to steer a packet along an explicit=20
route using information attached to the packet and
without the need for per-flow state information to be
held at transit nodes. The attached information in the packet may additi=
onally specify services that are to be applied to the packet at the interme=
diate hops of the explicit route.


- Sri










--bcaec520ea7948933a04e8bc3938--

From stbryant@cisco.com  Mon Oct 14 17:59:05 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9058D21E813F; Mon, 14 Oct 2013 17:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.515
X-Spam-Level: 
X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eyb9xNcsTej; Mon, 14 Oct 2013 17:59:00 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7366C21E8100; Mon, 14 Oct 2013 17:58:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1045; q=dns/txt; s=iport; t=1381798740; x=1383008340; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=2s5/mND3ZD8KLqlJTkM0h9FiByiRd1FY/+BpT34Qmdc=; b=QhwhTereiidh59bxQiHstMyCSi1D6GNExUfi5xnyP7U1J/jQpqKY7Ita pFxtZFSLd0+H4XjwkmBm/da85U5/BcMEJUgx9bmz8QUEQOlz9vp797J6g xYBTFifJ1qH4Bn5WfJZ/vh9Dp0y0Zlr5/hmh9ai1HZIaJZpFB1aIY7oJr I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADaSXFKQ/khM/2dsb2JhbABZgweKELkYgScWdIIcgQgBHgECGxYYAwIBAgFLDQEHAQGIAqMfmkyPSoQsA5gEkgKDJQ
X-IronPort-AV: E=Sophos;i="4.93,495,1378857600";  d="scan'208,217";a="160656677"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2013 00:58:58 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9F0wr6l001281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 00:58:55 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9F0wpH4007500; Tue, 15 Oct 2013 01:58:52 +0100 (BST)
Message-ID: <525C934B.6070003@cisco.com>
Date: Tue, 15 Oct 2013 01:58:51 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: IETF-IESG-Support via RT 
Content-Type: multipart/alternative; boundary="------------010706050604090704060008"
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: [Status] The SPRING Charter - ready for external review
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 00:59:05 -0000

This is a multi-part message in MIME format.
--------------010706050604090704060008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The SPRING Charter:

Source Packet Routing in Networking
charter-ietf-spring-00-15

is now ready for external review. Please can you
send this out.

Thanks

Stewart

--------------010706050604090704060008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    
    The SPRING Charter:

    

    Source Packet Routing in Networking

    charter-ietf-spring-00-15

    

    is now ready for external review. Please can you

    send this out.

    

    Thanks

    

    Stewart

  


--------------010706050604090704060008--

From narten@us.ibm.com  Tue Oct 15 06:46:45 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC2621E8128 for ; Tue, 15 Oct 2013 06:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQtBX8FYxWTx for ; Tue, 15 Oct 2013 06:46:39 -0700 (PDT)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 0E89321E80E8 for ; Tue, 15 Oct 2013 06:46:38 -0700 (PDT)
Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Tue, 15 Oct 2013 07:46:35 -0600
Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Tue, 15 Oct 2013 07:46:33 -0600
Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id A1A033E40026; Tue, 15 Oct 2013 07:46:32 -0600 (MDT)
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9FDkWat395284; Tue, 15 Oct 2013 07:46:32 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9FDkVIi004954; Tue, 15 Oct 2013 07:46:31 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-214-137.mts.ibm.com [9.65.214.137]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9FDkTfZ004703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 07:46:30 -0600
Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9FDkSIl023262; Tue, 15 Oct 2013 09:46:28 -0400
Message-Id: <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
To: stbryant@cisco.com
In-reply-to: <52584CCA.8000902@cisco.com>
References: <52584CCA.8000902@cisco.com>
Comments: In-reply-to Stewart Bryant  message dated "Fri, 11 Oct 2013 20:08:58 +0100."
Date: Tue, 15 Oct 2013 09:46:28 -0400
From: Thomas Narten 
X-TM-AS-MML: No
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13101513-0928-0000-0000-0000028E8F24
Cc: Benoit Claise , Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Oct 2013 13:46:45 -0000

Looking at the most recent charter proposal (-15), I have the
following questions/observations:

> The SPRING working group will define procedures that 
> will allow a node to steer a packet along an explicit 
> route using information attached to the packet and
> without the need for per-path state information to be
> held at transit nodes.

Who adds these "segment routes" (or whatever we call them -- I'll call
the SRs in this message)? Can an originating end node add them, or is
their an assumption that only network nodes add them?

My assumption is that it is network nodes (not the originating hosts)
that do that. Certainly, that is the case in MPLS and for many of the
use cases (as I understand them).

When it comes to IPv6, however, the question of who is capable of
adding these "segment routes" becomes very significant. If the
originating end node can add SRs, the attack surface for exploiting
SRs becomes much more complicated and hard to defend against. And if
end nodes can add these SRs, its hard for me not to see this problem
as equivalent to source routes as IPv6 originally had them and then
deprecated. Also, architecturally, having middle boxes (including for
SR purposes) add/modify/remove headers raises pretty significant
architectural issues. IPv6 had generally not done this and frowned on
doing so. Having network nodes *add* SRs would raise questions in this
regard.

On the other hand, if only network nodes can add SRs, it also raises
the question of whether the right way to do this is by adding SRs to
the *original* packet as originated by an end host, or whether a new
outer header should be added, in which case we are tunneling within a
region where SRs are in use. A tunneling approach changes the attack
surface considerably, and probably makes it much easier to ensure that
SRs can only be originated within the domain in which they are used.

I think it would be good to clarify this in the charter, given that
the IPv6 and MPLS assumptions are so different.

Also, this item:

>  Definition of requirements and/or any new data plane 
>    encodings and procedures, required to implement 
>    the use cases. Such procedures must include the 
>    necessary security considerations.

Suggests to me that SPRING is being given the go ahead to define IPv6
mechanisms to do SR. IMO, any IPv6 protocol work should be done in
6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work
needs to be done where the IPv6 expertise is. Or at the very least
with very close coordination.

Thomas


From jgs@juniper.net  Tue Oct 15 08:39:19 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D0021E8161 for ; Tue, 15 Oct 2013 08:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5N34GHB9hmf for ; Tue, 15 Oct 2013 08:39:13 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 007D021E8174 for ; Tue, 15 Oct 2013 08:39:12 -0700 (PDT)
Received: from mail209-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Oct 2013 15:39:12 +0000
Received: from mail209-va3 (localhost [127.0.0.1])	by mail209-va3-R.bigfish.com (Postfix) with ESMTP id 356F4A00087; Tue, 15 Oct 2013 15:39:12 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 7
X-BigFish: VPS7(zz148cIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail209-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52604005)(189002)(199002)(54316002)(33656001)(56776001)(62966002)(85306002)(81686001)(76482001)(65816001)(82746002)(66066001)(80022001)(74366001)(79102001)(23726002)(77982001)(47776003)(63696002)(59766001)(81816001)(46406003)(57306001)(74876001)(50466002)(74706001)(83072001)(53416003)(69226001)(47736001)(49866001)(50986001)(47976001)(42186004)(53806001)(46102001)(51856001)(4396001)(74662001)(47446002)(83322001)(74502001)(50226001)(80976001)(31966008)(81542001)(76796001)(76786001)(36756003)(81342001)(76176001)(77096001)(77156001)(56816003)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail209-va3 (localhost.localdomain [127.0.0.1]) by mail209-va3 (MessageSwitch) id 1381851550915141_18401; Tue, 15 Oct 2013 15:39:10 +0000 (UTC)
Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.254])	by mail209-va3.bigfish.com (Postfix) with ESMTP id D14FB9C0041; Tue, 15 Oct 2013 15:39:10 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Oct 2013 15:39:10 +0000
Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 15 Oct 2013 15:39:10 +0000
Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 15 Oct 2013 15:39:08 +0000
From: "John G. Scudder" 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Oct 2013 11:38:50 -0400
Message-ID: <4EF0CE45-8E8C-4F87-B585-C4CB175F6BF1@juniper.net>
To: Stewart Bryant 
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Originating-IP: [66.129.232.2]
X-ClientProxiedBy: BN1PR01CA003.prod.exchangelabs.com (10.242.217.161) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151)
X-Forefront-PRVS: 00003DBFE7
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "status@ietf.org" 
Subject: [Status] Comments on -15
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Oct 2013 15:39:19 -0000

This looks pretty well-baked, thanks. Some nits below.

--John

1. Thanks for fixing "negation", but even "negotiation" could be =
clearer:

"are never possible, i.e., attackers will be unable to=20
send source routed packets that get successfully=20
processed, without being part of the negotiation for=20
setting up the source routes or being able to eavesdrop"

Perhaps what you mean is "... without being able to participate in the =
relevant control plane(s)"?

2. This text seems to have produced significant confusion among the =
IESG:

"Initial work will focus on SPRING within in a single AS,=20
however design decisions must not preclude operation=20
of SPRING across AS boundaries."

Possibly it would be worth spelling out explicitly that the =
previously-stated trust model continues to apply for multi-AS, e.g. by =
appending

"In such multi-AS deployments, the previously-stated trust model would =
still apply. This is relevant in the context of multiple ASes operated =
by a single entity."

3. This could be rewritten more concisely:

"The SPRING WG should provide OAM and the=20
management needed to manage  SPRING enabled networks."

It becomes especially evident if you consider what the "M" in "OAM" =
stands for. (Does anyone know where the nearest ATM Machine is? :-)

Perhaps just

"The SPRING WG should address OAM for SPRING enabled networks"

Although one might argue even this is redundant and you could perfectly =
well get by with

"The SPRING WG should address OAM."

4. This makes an unwarranted presupposition:

"The SPRING protocol itself may also be used as a tool for OAM
in SPRING enabled networks."

I'm actually not sure what "the SPRING protocol" is, especially given =
the WG isn't being chartered to produce a "SPRING protocol" per se. =
Maybe,

"SPRING procedures may themselves also be used..."

5. s/architecture/architectures/ in:

"o Specification of a high-level abstract architecture for=20
   SPRING and requirements for modifications to existing=20
   architecture to support SPRING use cases."

6. The word "source" is sprinkled liberally around the charter without =
taking care to define what it means in this context -- whether it's the =
packet's originator (the usual meaning) or something else. One approach =
would be to rewrite all uses of "source" to be more explicit, but for =
expedience we might just insert a statement like "in the context of this =
charter, 'source' means 'the point at which the explicit route was =
imposed'."

7. s/mechanism/mechanisms/ in:

"o Definition of requirements and/or management  plane=20
   mechanism needed to manage and operate a=20
   SPRING enabled network."




From jgs@juniper.net  Tue Oct 15 08:46:27 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562F921E81CA; Tue, 15 Oct 2013 08:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.939
X-Spam-Level: 
X-Spam-Status: No, score=-4.939 tagged_above=-999 required=5 tests=[AWL=1.660,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0IIRDNmN1Xy; Tue, 15 Oct 2013 08:46:19 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3721E80CC; Tue, 15 Oct 2013 08:46:18 -0700 (PDT)
Received: from mail161-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Oct 2013 15:46:17 +0000
Received: from mail161-tx2 (localhost [127.0.0.1])	by mail161-tx2-R.bigfish.com (Postfix) with ESMTP id 79AA91A0041; Tue, 15 Oct 2013 15:46:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 6
X-BigFish: VPS6(zz98dI9371Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097h8275bhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail161-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(377454003)(199002)(189002)(69226001)(53416003)(49866001)(47736001)(50986001)(42186004)(53806001)(47976001)(74706001)(50466002)(83072001)(36756003)(81542001)(76796001)(76786001)(56816003)(77156001)(77096001)(81342001)(50226001)(4396001)(46102001)(51856001)(47446002)(74662001)(74502001)(19580405001)(83322001)(19580395003)(31966008)(80976001)(76482001)(81686001)(65816001)(82746002)(56776001)(54316002)(33656001)(62966002)(85306002)(59766001)(74876001)(57306001)(81816001)(46406003)(80022001)(66066001)(47776003)(63696002)(23726002)(79102001)(74366001)(77982001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:jgs-sslvpn-nc.jnpr.net; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail161-tx2 (localhost.localdomain [127.0.0.1]) by mail161-tx2 (MessageSwitch) id 1381851975729164_31186; Tue, 15 Oct 2013 15:46:15 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.242])	by mail161-tx2.bigfish.com (Postfix) with ESMTP id A83472C004C; Tue, 15 Oct 2013 15:46:15 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Oct 2013 15:46:15 +0000
Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 15 Oct 2013 15:46:14 +0000
Received: from jgs-sslvpn-nc.jnpr.net (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 15 Oct 2013 15:46:12 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: "John G. Scudder" 
In-Reply-To: <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
Date: Tue, 15 Oct 2013 11:45:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <6F483334-A2CB-4775-A3D5-41C7B6F64D41@juniper.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
To: Thomas Narten 
X-Mailer: Apple Mail (2.1510)
X-Originating-IP: [66.129.232.2]
X-ClientProxiedBy: BN1PR01CA009.prod.exchangelabs.com (10.242.217.167) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151)
X-Forefront-PRVS: 00003DBFE7
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Benoit Claise , "iesg@ietf.org" , Jari Arkko , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Oct 2013 15:46:27 -0000

Thomas,

On Oct 15, 2013, at 9:46 AM, Thomas Narten  wrote:

> When it comes to IPv6, however, the question of who is capable of
> adding these "segment routes" becomes very significant. If the
> originating end node can add SRs, the attack surface for exploiting
> SRs becomes much more complicated

Do you think if the document set said "a host SHALL NOT add an explicit =
route" it would make the attack surface less complicated? Why?

FWIW I think the draft charter addresses this concern here:

"There is an assumed trust model such that any node=20
imposing an explicit route on a packet is assumed to=20
be allowed to do so, however administrative and trust=20
boundaries may strip explicit routes from a packet."

Some hosts may be part of the trust domain. Others may not.

--John=


From iesg-secretary@ietf.org  Tue Oct 15 09:47:09 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9737D21E812D; Tue, 15 Oct 2013 09:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.435
X-Spam-Level: 
X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmTNenpxOC4l; Tue, 15 Oct 2013 09:47:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD86321E8155; Tue, 15 Oct 2013 09:46:54 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.80.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131015164653.2118.61260.idtracker@ietfa.amsl.com>
Date: Tue, 15 Oct 2013 09:46:53 -0700
X-Mailman-Approved-At: Tue, 15 Oct 2013 09:58:13 -0700
Cc: spring WG 
Subject: [Status] WG Review: Source Packet Routing in Networking (spring)
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Oct 2013 16:47:09 -0000

A new IETF working group has been proposed in the Routing Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-22.

Source Packet Routing in Networking (spring)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Stewart Bryant 

Mailing list
  Address: status@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/status
  Archive:
http://www.ietf.org/mail-archive/web/status/current/maillist.html

Charter:

The ability for a node to specify a forwarding path, other 
than the normal shortest path, that a particular packet 
will traverse, benefits a number of network functions, 
for example:

o    Some types of network virtualization, including multi-
     topology networks and the partitioning of network 
     resources for VPNs
o    Network path and node protection such as fast re-route
o    Network programmability
o    New OAM techniques
o    Simplification and reduction of network signalling 
     components
o    Load balancing and traffic engineering

Source-based routing mechanisms have previously been 
specified for network protocols, but have not seen 
widespread adoption other than in MPLS traffic engineering. 
These applications may require greater flexibility and 
per packet source imposed routing than can be achieved 
through the use of the previously defined methods.

The SPRING working group will define procedures that 
will allow a node to steer a packet along an explicit 
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose
or strict path specification) can be achieved in a network 
comprising only SPRING nodes, however SPRING must 
inter-operate through loose routing in existing networks
and may find it advantageous to use loose routing for
for other network applications. 

The initial data planes that will be considered are MPLS
and IPv6.

There is an assumed trust model such that any node 
imposing an explicit route on a packet is assumed to 
be allowed to do so, however administrative and trust 
boundaries may strip explicit routes from a packet.
For each data plane technology that SPRING specifies, 
a security analysis must be provided showing how protection 
is provided against an attacker disrupting the network by 
for example, maliciously injecting SPRING packets.
There are a number of serious security concerns with 
source routing at the IP layer [RFC 5095].  As a part 
of its work, the working group will define the new 
IPv6-based routing header in way that blind attacks 
are never possible, i.e., attackers will be unable to 
send source routed packets that get successfully 
processed, without being part of the negotiation for 
setting up the source routes or being able to eavesdrop 
legitimate source routed packets. In some networks 
this base level security may be complemented with 
other mechanisms, such as packet filtering,  cryptographic 
security, etc.

Initial work will focus on SPRING within in a single AS, 
however design decisions must not preclude operation 
of SPRING across AS boundaries.

SPRING should support both centralised and distributed 
path computation.  

The SPRING WG should provide OAM and the 
management needed to manage  SPRING enabled networks. 
The SPRING protocol itself may also be used as a tool for OAM
in SPRING enabled networks.

SPRING should avoid modification to existing data 
planes that would make them incompatible with 
existing deployments. Where possible, existing control
and management plane protocols must be used within existing 
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or control or management plane protocols 
must be carried out in the working groups responsible 
for the architecture, data plane, or control or 
management plane protocol being modified and in 
co-ordination with this working group, but may be 
done in this working group after agreement with 
all the relevant WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following 
list of items:

o Identification and evaluation of use cases for SPRING. 
   These use cases must include a definition of the 
   data plane for the environment in which they are to be 
   deployed.

o Definition of requirements and/or any new data plane 
   encodings and procedures, required to implement 
   the use cases. Such procedures must include the 
   necessary security considerations.

o Definition of requirements and/or any new control plane 
   mechanism needed to enable the use cases.

o Definition of requirements and/or management  plane 
   mechanism needed to manage and operate a 
   SPRING enabled network.

The SPRING working group will not work on any 
mechanisms for use in networks that forward IPv4 packets.
 
[ Following to be replaced by milestones before final review]
The working group will develop the following documents:

o One or more documents describing SPRING use cases.

o Specification of a high-level abstract architecture for 
   SPRING and requirements for modifications to existing 
   architecture to support SPRING use cases.

o Specification of any required new procedures to support 
   SPRING use cases.

o One or more data plane extension requirements documents, 
   including documenting the impact on existing deployments
   of the existing data plane.

o One or more control protocol extensions requirements 
   documents.

o Publish SPRING management requirements document.

o Specify the OAM mechanisms needed to support SPRING.

o Document inter-working and co-existence between the 
   new procedures and the existing signalling and routing 
   protocols.

o Inter-operability reports pertaining to the implementation 
   of extensions supporting SPRING.


Milestones:

TBD


From narten@us.ibm.com  Tue Oct 15 11:28:16 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0668311E8150 for ; Tue, 15 Oct 2013 11:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8rb3s2EgUmW for ; Tue, 15 Oct 2013 11:28:09 -0700 (PDT)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 81AA011E8144 for ; Tue, 15 Oct 2013 11:28:08 -0700 (PDT)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Tue, 15 Oct 2013 14:28:07 -0400
Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Tue, 15 Oct 2013 14:28:04 -0400
Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id E8DDEC90076; Tue, 15 Oct 2013 14:27:54 -0400 (EDT)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9FIRrNk54657160; Tue, 15 Oct 2013 18:27:53 GMT
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9FIRrc5008585; Tue, 15 Oct 2013 14:27:53 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-65-214-137.mts.ibm.com [9.65.214.137]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9FIRq7T008498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Oct 2013 14:27:52 -0400
Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9FIRnEN030512; Tue, 15 Oct 2013 14:27:49 -0400
Message-Id: <201310151827.r9FIRnEN030512@cichlid.raleigh.ibm.com>
To: "John G. Scudder" 
In-reply-to: <6F483334-A2CB-4775-A3D5-41C7B6F64D41@juniper.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <6F483334-A2CB-4775-A3D5-41C7B6F64D41@juniper.net>
Comments: In-reply-to "John G. Scudder"  message dated "Tue, 15 Oct 2013 11:45:49 -0400."
Date: Tue, 15 Oct 2013 14:27:48 -0400
From: Thomas Narten 
X-TM-AS-MML: No
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 13101518-0320-0000-0000-0000015E1ADE
Cc: Benoit Claise , "iesg@ietf.org" , Jari Arkko , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Oct 2013 18:28:16 -0000

Hi John.

> Thomas,

> On Oct 15, 2013, at 9:46 AM, Thomas Narten  wrote:

> > When it comes to IPv6, however, the question of who is capable of
> > adding these "segment routes" becomes very significant. If the
> > originating end node can add SRs, the attack surface for exploiting
> > SRs becomes much more complicated

> Do you think if the document set said "a host SHALL NOT add an
>  explicit route" it would make the attack surface less complicated?
>  Why?

Not at all. We all know Bad Guys don't follow the rules. If the
architecture allows for an end host to add stuff to a packet header
(like an SR) that the other nodes have to deal with, someone wanting
to exploit the system will use such a capability to do so.

On the other hand, if the architecture didn't make it possible for an
end host to do this, that would be much better. MPLS effectively
acheives this because arbitrary end hosts don't have access to the
MPLS layer. They can only generate IP packets...

Hence, I'd see a much safer/verifiable way to do this architecturally
in IPv6 if it was used in conjunction with tunneling, where the tunnel
entry/exit points were controlled by network admin.

Thomas


From mark@townsley.net  Wed Oct 16 04:15:05 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9611E8235 for ; Wed, 16 Oct 2013 04:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEQeZXMGB67q for ; Wed, 16 Oct 2013 04:15:00 -0700 (PDT)
Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2958611E81BC for ; Wed, 16 Oct 2013 04:14:58 -0700 (PDT)
Received: by mail-ea0-f170.google.com with SMTP id q10so218654eaj.15 for ; Wed, 16 Oct 2013 04:14:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NxquyLu2e3AVvXnsZWnyDSe6w9JvN9sHPWB6LznfznQ=; b=UP17dQAKPo5/9LNOkjZ2AVvC6lyp8W4VFjhSFAzfqnfPTdVQKZNfcxHSfJ7T5+/j9i ErgBCOJGk3/eqBU12HnZMEvKYp/I7TO0U42PFeH7AbjRa2GZk45Gbxy3IdZfZGFkZjhO Ii+CEONa99ES5yfXssUPS/DZWeJuT2u2SAyZQD55GWpCVA5//kt/rx1Nx+yoTeJzDqr2 dtfMZrDBsNlvNY7zt9VR1TGHDs3RgXwtuXQUjU5OflxkwIMMJKaVElnDpmhJTqeZw7qi pSHfcDC5i5PvfoozR8lNQt3ln55NAgz+EmNW6MqzCONyvGa6KyeJ3BEU7VEM7F7Qq4c0 7KLg==
X-Gm-Message-State: ALoCoQn9t3c29oBzOuJUfyxC2oKm0yJU//Jm7kwVu6tbd3MzY3XE4y+mk9sMR4IMCk4gASCUtUOg
X-Received: by 10.15.61.73 with SMTP id h49mr3736331eex.57.1381922098148; Wed, 16 Oct 2013 04:14:58 -0700 (PDT)
Received: from dhcp-10-61-106-25.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id z12sm178350265eev.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Oct 2013 04:14:56 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <201310151827.r9FIRnEN030512@cichlid.raleigh.ibm.com>
Date: Wed, 16 Oct 2013 14:14:53 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <41EF17D4-92FF-4FB7-9FDE-D8311C44585C@townsley.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <6F483334-A2CB-4775-A3D5-41C7B6F64D41@juniper.net> <201310151827.r9FIRnEN030512@cichlid.raleigh.ibm.com>
To: Thomas Narten 
X-Mailer: Apple Mail (2.1283)
Cc: Jari Arkko , "iesg@ietf.org" , Benoit Claise , "John G. Scudder" , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 11:15:05 -0000

Thomas,

On Oct 15, 2013, at 9:27 PM, Thomas Narten wrote:

> Hi John.
>=20
>> Thomas,
>=20
>> On Oct 15, 2013, at 9:46 AM, Thomas Narten  wrote:
>=20
>>> When it comes to IPv6, however, the question of who is capable of
>>> adding these "segment routes" becomes very significant. If the
>>> originating end node can add SRs, the attack surface for exploiting
>>> SRs becomes much more complicated
>=20
>> Do you think if the document set said "a host SHALL NOT add an
>> explicit route" it would make the attack surface less complicated?
>> Why?
>=20
> Not at all. We all know Bad Guys don't follow the rules. If the
> architecture allows for an end host to add stuff to a packet header
> (like an SR) that the other nodes have to deal with, someone wanting
> to exploit the system will use such a capability to do so.

I really don't think banking on an architectural designation of router =
vs. host is the best approach here. In particular when it comes to =
anything that resembles tunneling.

>=20
> On the other hand, if the architecture didn't make it possible for an
> end host to do this, that would be much better. MPLS effectively
> acheives this because arbitrary end hosts don't have access to the
> MPLS layer. They can only generate IP packets...

If there is demand for SR beyond the traditional boundaries of an MPLS =
core network, it will find its way. I'd much rather develop this =
thoughtfully from the get-go than deal with the pressure to expand SR =
beyond the presumed boundaries of MPLS (as we have already had to do in =
the past with various MPLS over IP encapsulations).=20

> Hence, I'd see a much safer/verifiable way to do this architecturally
> in IPv6 if it was used in conjunction with tunneling, where the tunnel
> entry/exit points were controlled by network admin.

I think Jari's text captures your higher-level point, without =
presupposing a particular solution:

"attackers will be unable to send source routed packets that get =
successfully=20
processed, without being part of the negotiation for setting up the =
source routes"

- Mark

>=20
> Thomas
>=20
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status


From aretana@cisco.com  Wed Oct 16 05:48:02 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173A11E81D6; Wed, 16 Oct 2013 05:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cAcJlyHJKeJ; Wed, 16 Oct 2013 05:47:57 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6433411E81D1; Wed, 16 Oct 2013 05:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1150; q=dns/txt; s=iport; t=1381927673; x=1383137273; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qIz9jFz/ivoTacW3qZPv+0bt0FzlNHJyvvxH4dbfCFI=; b=VvlRZhoGV/6Kcs60B3VMBtpofSu42HDX3GjHpSnYSOpAA+knokXi7/0C NM0s0tCI5W0wRNmZuXdm1/CjJP02fbKuncJr2ggffKdZnzSWWayKvfA5m Xfgp6+8V9E0zTp5p5YRlc+ZEGHJ1mh43ZvKoUtP9MtiP4s2pLMQvmZ+XK U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAJmKXlKtJV2Z/2dsb2JhbABagweBCsIPgR0WdIInAQQ6LQQOEgEIEhAUQhcOAgQOBQiHfr8GjyAxB4MfgQYDqgaDJIIp
X-IronPort-AV: E=Sophos;i="4.93,507,1378857600"; d="scan'208";a="269754124"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 16 Oct 2013 12:47:46 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9GClkQC015012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 12:47:46 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 07:47:46 -0500
From: "Alvaro Retana (aretana)" 
To: Thomas Narten 
Thread-Topic: [Status] SPRING Charter
Thread-Index: AQHOxrVkUYi6pW/k1kW1dQ64aj+T65n2IEsAgAGjcwA=
Date: Wed, 16 Oct 2013 12:47:45 +0000
Message-ID: 
In-Reply-To: <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.209.13]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <669F048E8735444F9C29CFE65E6AFFFE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 12:48:02 -0000

On 10/15/13 3:46 PM, "Thomas Narten"  wrote:

Thomas:

Hi!

>Also, this item:
>
>>  Definition of requirements and/or any new data plane
>>    encodings and procedures, required to implement
>>    the use cases. Such procedures must include the
>>    necessary security considerations.
>
>Suggests to me that SPRING is being given the go ahead to define IPv6
>mechanisms to do SR. IMO, any IPv6 protocol work should be done in
>6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work
>needs to be done where the IPv6 expertise is. Or at the very least
>with very close coordination.

The charter also reads:

"Any modification of or extension to existing architectures,
data planes, or control or management plane protocols
must be carried out in the working groups responsible
for the architecture, data plane, or control or
management plane protocol being modified and in
co-ordination with this working group, but may be
done in this working group after agreement with
all the relevant WG chairs and responsible Area Directors."

So I think we're in agreement.

Thanks!

Alvaro.


From aretana@cisco.com  Wed Oct 16 06:14:06 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25CD11E82AB for ; Wed, 16 Oct 2013 06:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLh6ILMoVlgr for ; Wed, 16 Oct 2013 06:14:01 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E54A911E82A3 for ; Wed, 16 Oct 2013 06:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4067; q=dns/txt; s=iport; t=1381929239; x=1383138839; h=from:to:subject:date:message-id:mime-version; bh=M71rXkUMjw37tM/Gbg5N+sXcPZSL5NSDzAqlDEJ5kWI=; b=luJ/2NNWFMM8d3qGSxNZ+ARNWtbtn8YhyG4fXs9zalqd/JDNhy2UIl5F J4qM/kpTnKmBFk2LWd3OO2ZpNsyCFqHGtDmHKrlOzJY+DAEG5dliLZU/S uj2HAVwxw59BOTDbvLiC21LeohavCS0ue/Za6kl94f4T5Rt5qbdM5Lzx0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8GADyQXlKtJV2a/2dsb2JhbABZAYJDRIEKwg+BHRZtB4InAQSBCwEMDhAPAQFFFxAEGxOHa50toV2PIFsEAYJ3gQYDqgaDJIIp
X-IronPort-AV: E=Sophos;i="4.93,507,1378857600";  d="scan'208,217";a="272768045"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 16 Oct 2013 13:13:58 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GDDwiD010506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 16 Oct 2013 13:13:58 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 08:13:58 -0500
From: "Alvaro Retana (aretana)" 
To: "status@ietf.org" 
Thread-Topic: IETF 88 Agenda Items
Thread-Index: AQHOynGSXDdMesgLNkyT5jtq/G06Pw==
Date: Wed, 16 Oct 2013 13:13:57 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.209.13]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3964149Exmbalnx15ciscoc_"
MIME-Version: 1.0
Subject: [Status] IETF 88 Agenda Items
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 13:14:06 -0000

--_000_BBD66FD99311804F80324E8139B3C94E3964149Exmbalnx15ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi!

We have a 2 1/2 hour slot in Vancouver on Monday afternoon:

1450-1720  Afternoon Session II
Regency B               RTG     spring          Source Packet Routing in Ne=
tworking WG


Even though the agenda already lists us as the 'spring WG', the process has=
n't finished and we're still a BOF.  Because of that, the first part of the=
 agenda will be to resolve any issues that still remain.  If spring does be=
come a WG before the meeting we will clearly not need that time.

We would like to start collecting proposals for agenda items at this time. =
 Please send your request to John and I.  We will prioritize the items alre=
ady listed as milestones in the charter: use cases, architecture, solutions=
, etc.  Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the fina=
l agenda: (1) your draft MUST have been published already, and (2) you MUST=
 provide the chairs with your slides by EOD on Friday, November 1st, 2013.

Keep the following dates in mind:

Oct/21: cut-ff date for ID submission.  It would be very nice if your draft=
s are published with the -spring=96 name in them.
Oct/23: Draft WG agendas are due
Oct/28: Revised WG agendas are due

Thanks!

Alvaro + John

--_000_BBD66FD99311804F80324E8139B3C94E3964149Exmbalnx15ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi!







We have a 2 1/2 hour slot in Vancouver=
 on Monday afternoon:



Date: Wed, 16 Oct 2013 18:16:55 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Thomas Narten 
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
In-Reply-To: <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Benoit Claise , Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:17:20 -0000

On 15/10/2013 14:46, Thomas Narten wrote:
> Looking at the most recent charter proposal (-15), I have the
> following questions/observations:
>
>> The SPRING working group will define procedures that
>> will allow a node to steer a packet along an explicit
>> route using information attached to the packet and
>> without the need for per-path state information to be
>> held at transit nodes.
> Who adds these "segment routes" (or whatever we call them -- I'll call
> the SRs in this message)? Can an originating end node add them, or is
> their an assumption that only network nodes add them?
My assumption is that only a "trusted" node can add them.

A few months ago I would have said that only a router could add
the SR, but the interest in network virtulazation is blurring the
line between routers and hosts.

However the architecture will need to include the facility to
segregate trusted and untrusted traffic, and my assumption
has always been that untrusted traffic will need to be
encapsulated on entry to an SR network to ensure that any
band intent is appropriately neutralized.

> My assumption is that it is network nodes (not the originating hosts)
> that do that. Certainly, that is the case in MPLS and for many of the
> use cases (as I understand them).
That is what I have seen.
> When it comes to IPv6, however, the question of who is capable of
> adding these "segment routes" becomes very significant. If the
> originating end node can add SRs, the attack surface for exploiting
> SRs becomes much more complicated and hard to defend against. And if
> end nodes can add these SRs, its hard for me not to see this problem
> as equivalent to source routes as IPv6 originally had them and then
> deprecated.
We really have two types of node - trusted nodes an untrusted
nodes. Consider an example other than NFV. Would it be OK
of a provider's radius server to issue such packets inside the
network. This is certainly a trusted node and it would be difficult
to justify the complexity of an intermediate router to put the
encap on. On the other hand you would be insane to allow
a BYOD on the guest network to also do so.

> Also, architecturally, having middle boxes (including for
> SR purposes) add/modify/remove headers raises pretty significant
> architectural issues.
Well tunnel headers are certainly OK, but modifying the
client header causes all sorts of problems.
> IPv6 had generally not done this and frowned on
> doing so. Having network nodes *add* SRs would raise questions in this
> regard.
In the native header I agree.
> On the other hand, if only network nodes can add SRs, it also raises
> the question of whether the right way to do this is by adding SRs to
> the *original* packet as originated by an end host, or whether a new
> outer header should be added, in which case we are tunneling within a
> region where SRs are in use. A tunneling approach changes the attack
> surface considerably, and probably makes it much easier to ensure that
> SRs can only be originated within the domain in which they are used.
We agree on this point.
> I think it would be good to clarify this in the charter, given that
> the IPv6 and MPLS assumptions are so different.
Looking at John's note

> "There is an assumed trust model such that any node
> imposing an explicit route on a packet is assumed to
> be allowed to do so, however administrative and trust
> boundaries may strip explicit routes from a packet."
>
> Some hosts may be part of the trust domain. Others may not.

Could we perhaps say:

"There is an assumed trust model such that any node
imposing an explicit route on a packet is assumed to
be allowed to do so. Some hosts may be part of the
trust domain, but others may not. SPRING must provide
the means to distinguish between these two classes
of host and prevent untrusted hosts from imposing
a route on its packets. Administrative and trust
boundaries may strip explicit routes from a packet."

> Also, this item:
>
>>   Definition of requirements and/or any new data plane
The deliverable should actually be

"Definition of requirements for any new data plane"


>>     encodings and procedures, required to implement
>>     the use cases. Such procedures must include the
>>     necessary security considerations.
> Suggests to me that SPRING is being given the go ahead to define IPv6
> mechanisms to do SR. IMO, any IPv6 protocol work should be done in
> 6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work
> needs to be done where the IPv6 expertise is. Or at the very least
> with very close coordination.
Yes

- Stewart
>
> Thomas
>
> .
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html


From stbryant@cisco.com  Wed Oct 16 10:20:05 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD6611E8182; Wed, 16 Oct 2013 10:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level: 
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODJHvXZtNZhq; Wed, 16 Oct 2013 10:19:59 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8450411E8118; Wed, 16 Oct 2013 10:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1367; q=dns/txt; s=iport; t=1381943995; x=1383153595; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PV/vNaWGuN0yF1Ggc0BWMV0C0cC+ltcTJheaPwsWe1Q=; b=fGlKwRjHkvCN24z+8bpl400iER9C/Lk46c3MYcuVVc6jA3+8dYPis2BV LTWTj2GZ6vqiRWfDV3ZflRJYKwCJFzOiecPuhxO08Sk0AZY2aHps+9fXp tVgqiO/EIBAInFhXV6Me6P+yIEDJl3nonexgQ+PHcC06P/WvhlP5et4gv k=;
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="18322033"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 16 Oct 2013 17:19:54 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GHJmCJ007723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 17:19:50 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9GHJksh026109; Wed, 16 Oct 2013 18:19:47 +0100 (BST)
Message-ID: <525ECAB2.6030302@cisco.com>
Date: Wed, 16 Oct 2013 18:19:46 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "Alvaro Retana (aretana)" , Thomas Narten 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Oct 2013 17:20:05 -0000

On 16/10/2013 13:47, Alvaro Retana (aretana) wrote:
> On 10/15/13 3:46 PM, "Thomas Narten"  wrote:
>
> Thomas:
>
> Hi!
>
>> Also, this item:
>>
>>>   Definition of requirements and/or any new data plane
>>>     encodings and procedures, required to implement
>>>     the use cases. Such procedures must include the
>>>     necessary security considerations.
>> Suggests to me that SPRING is being given the go ahead to define IPv6
>> mechanisms to do SR. IMO, any IPv6 protocol work should be done in
>> 6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work
>> needs to be done where the IPv6 expertise is. Or at the very least
>> with very close coordination.
> The charter also reads:
>
> "Any modification of or extension to existing architectures,
> data planes, or control or management plane protocols
> must be carried out in the working groups responsible
> for the architecture, data plane, or control or
> management plane protocol being modified and in
> co-ordination with this working group, but may be
> done in this working group after agreement with
> all the relevant WG chairs and responsible Area Directors."
>
> So I think we're in agreement.
>
Yes, but it looks like the deliverables text is slight out of
alignment - hence my proposed slight tweek

s/and\/or/for/

Stewart

From jgs@juniper.net  Wed Oct 16 10:33:49 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7827011E82FD; Wed, 16 Oct 2013 10:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.716
X-Spam-Level: 
X-Spam-Status: No, score=-3.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWuEsT-2HsXf; Wed, 16 Oct 2013 10:33:43 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0544E11E8192; Wed, 16 Oct 2013 10:33:42 -0700 (PDT)
Received: from mail128-va3-R.bigfish.com (10.7.14.232) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Wed, 16 Oct 2013 17:33:42 +0000
Received: from mail128-va3 (localhost [127.0.0.1])	by mail128-va3-R.bigfish.com (Postfix) with ESMTP id E95F820006C; Wed, 16 Oct 2013 17:33:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: 5
X-BigFish: VPS5(zz98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1de097h8275bhz2fh2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e23h1fe8h1ff5h2052h20b3m1155h)
Received-SPF: pass (mail128-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jgs@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(189002)(199002)(24454002)(33656001)(62966002)(85306002)(54316002)(65816001)(81686001)(76482001)(56776001)(82746002)(66066001)(80022001)(79102001)(23726002)(74366001)(77982001)(47776003)(63696002)(59766001)(57306001)(81816001)(46406003)(74876001)(83072001)(69226001)(47736001)(49866001)(50986001)(47976001)(42186004)(53806001)(46102001)(51856001)(4396001)(50226001)(31966008)(80976001)(74662001)(19580405001)(74502001)(47446002)(19580395003)(83322001)(50466002)(74706001)(76796001)(76786001)(36756003)(81342001)(81542001)(77096001)(56816003)(77156001)(83716002)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB527; H:[172.28.132.71]; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail128-va3 (localhost.localdomain [127.0.0.1]) by mail128-va3 (MessageSwitch) id 1381944755574479_19105; Wed, 16 Oct 2013 17:32:35 +0000 (UTC)
Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.229])	by mail128-va3.bigfish.com (Postfix) with ESMTP id 7AFD718004C; Wed, 16 Oct 2013 17:32:35 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 16 Oct 2013 17:32:33 +0000
Received: from DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 16 Oct 2013 17:32:33 +0000
Received: from [172.28.132.71] (66.129.232.2) by DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 16 Oct 2013 17:32:30 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: "John G. Scudder" 
In-Reply-To: <525ECA07.2070207@cisco.com>
Date: Wed, 16 Oct 2013 13:31:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com>
To: 
X-Mailer: Apple Mail (2.1510)
X-Originating-IP: [66.129.232.2]
X-ClientProxiedBy: BLUPR07CA017.namprd07.prod.outlook.com (10.255.223.170) To DM2PR05MB527.namprd05.prod.outlook.com (10.141.99.151)
X-Forefront-PRVS: 0001227049
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Thomas Narten , Benoit Claise , Jari Arkko , "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 17:33:49 -0000

On Oct 16, 2013, at 1:16 PM, Stewart Bryant  wrote:

> Could we perhaps say:
>=20
> "There is an assumed trust model such that any node
> imposing an explicit route on a packet is assumed to
> be allowed to do so. Some hosts may be part of the
> trust domain, but others may not. SPRING must provide
> the means to distinguish between these two classes
> of host and prevent untrusted hosts from imposing
> a route on its packets. Administrative and trust
> boundaries may strip explicit routes from a packet."

As you observe elsewhere in your note, the distinction between "hosts" =
and "routers" is blurry at best, and from the point of view of the trust =
model I think there's neither a need nor a value to draw the distinction =
at all. For example, a BYOD router is just as much of a potential =
problem as a BYOD host.

Insofar as the added text really says "all the stuff we said you have to =
do for a 'node' applies equally to the special class of node called =
'host'", it's harmless, but it's also unnecessary. I guess one might =
even argue it to be mildly harmful insofar as a casual reader might =
suppose that if hosts are called out specially, the listed =
considerations don't apply to other types of node. ("The exception that =
proves the rule" and all that.)

I'd be inclined to leave it as you had it.

--John=


From aretana@cisco.com  Wed Oct 16 11:26:12 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0921F9E46; Wed, 16 Oct 2013 11:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzG5-TQQDzpK; Wed, 16 Oct 2013 11:26:04 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0E21F9D2B; Wed, 16 Oct 2013 11:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=747; q=dns/txt; s=iport; t=1381947962; x=1383157562; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VpEaS8oUez2Wr/GrE/lsf4ytwLZ7ZyTo67gs77Zio7o=; b=KZlbOwHvVHNlDtmn3nwdRZqeZBOW/wUabWgdpD8LDRrSQw9MWxOc4MSJ vWDdm58CpEyjelv/II9eaTf34Y0yHEA6jJQZUupzREUMv2j9cjAIp+/tc XMbwEZSDCb5X+J7K1FnX01J+SliFITY5wU2S9tHm7tWMJNak13yc6GcuP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcFAAnZXlKtJXG+/2dsb2JhbABagweBCr1xgR4WdIInAQQ6LRISAQgSEBRCFw4CBAENBQiHfr9KjyAxB4MfgQYDqgaDJIIp
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="273006530"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2013 18:26:02 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GIQ1Vh004401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 18:26:01 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 13:26:01 -0500
From: "Alvaro Retana (aretana)" 
To: "Stewart Bryant (stbryant)" , Thomas Narten 
Thread-Topic: [Status] SPRING Charter
Thread-Index: AQHOxrVkUYi6pW/k1kW1dQ64aj+T65n2IEsAgAGjcwCAACp7AIAANAYA
Date: Wed, 16 Oct 2013 18:26:01 +0000
Message-ID: 
In-Reply-To: <525ECAB2.6030302@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.251.221]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9DE75D4630BEB74B83BAC5778CC16766@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "status@ietf.org" , "iesg@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 18:26:20 -0000

On 10/16/13 7:19 PM, "Stewart Bryant (stbryant)" 
wrote:

>>
>>"Any modification of or extension to existing architectures,
>>data planes, or control or management plane protocols
>>must be carried out in the working groups responsible
>>for the architecture, data plane, or control or
>>management plane protocol being modified and in
>>co-ordination with this working group, but may be
>>done in this working group after agreement with
>>all the relevant WG chairs and responsible Area Directors."
>>
>>So I think we're in agreement.
>>
>Yes, but it looks like the deliverables text is slight out of
>alignment - hence my proposed slight tweek
>
>s/and\/or/for/

That works for me.

Thanks!

Alvaro.


From jari.arkko@piuha.net  Wed Oct 16 11:38:59 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8872F11E8255; Wed, 16 Oct 2013 11:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.579
X-Spam-Level: 
X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQNxqTkEq6K; Wed, 16 Oct 2013 11:38:51 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB6811E8136; Wed, 16 Oct 2013 11:38:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CB9422CCBE; Wed, 16 Oct 2013 21:38:50 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Kr8T-b0D8IJ; Wed, 16 Oct 2013 21:38:50 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 3A0392CC48; Wed, 16 Oct 2013 21:38:50 +0300 (EEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net>
Date: Wed, 16 Oct 2013 21:38:50 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net>
To: John G. Scudder 
X-Mailer: Apple Mail (2.1510)
Cc: Thomas Narten , Benoit Claise , "iesg@ietf.org" , "status@ietf.org" , stbryant@cisco.com
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 18:39:00 -0000

I'd suggest that the distinction between trusted and non-trusted or host =
and router is not as useful as we might expect.

What I was trying to suggest with my text was specifying a requirement =
for a technical mechanism that helps prevent inappropriate headers from =
being believed. Trusted/non-trusted in itself would not be as useful, =
until it results in a similar specific requirement. And I fear that =
somewhere down the line someone would decide all we need is =
inside/outside security model, and I do not think that helps enough in =
this case.

But I don't mind the new text if the old text is still also there=85.

Jari


From rraszuk@gmail.com  Wed Oct 16 11:46:13 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2849B11E8147; Wed, 16 Oct 2013 11:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.527
X-Spam-Level: 
X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.451,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJfxIQi5TO08; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 980CB11E8128; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so2021659iec.6 for ; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=xRFC8/kBnmr+JxKZ+nqCP9Tw2o6hiF/t3rSYbs4n4pY=; b=gBYcT+aUi/6gg59IV/vzbS8scpbcB0NkoUVAM3lcJ0l8cqCYBeo2fmmWl5hOj8Fy+K DgzNEWf72meHmOFFZULNzWGIwcyzTOxCbHcdfMXZkheeUksSukTPz36W5IeISJj2JMH8 P9Kl3X9a92wNGu0QNG8P49BTJgGqzbZ9jvai0eYI6eOrVQv78QnkdrPQ/L1cfjbpNwSZ zXt7o16iaxCTY8zR/KGY2c16mu/GGR7S5IpGip8GHj9hVh5lCRN0f8bi0XMbeeFnC7v/ 1KJSr20R0ZsTm8fWGbE365f457k4O+MgeOy3cXzPRZOMHHpk7ZMU37UBjdRN7xVRhvJM iGYA==
MIME-Version: 1.0
X-Received: by 10.50.107.102 with SMTP id hb6mr3289431igb.55.1381949172048; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Wed, 16 Oct 2013 11:46:11 -0700 (PDT)
In-Reply-To: 
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net> 
Date: Wed, 16 Oct 2013 20:46:11 +0200
X-Google-Sender-Auth: PrSYJa6cEyx0TqZxZcRATKdQLEw
Message-ID: 
From: Robert Raszuk 
To: Jari Arkko 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 18:46:13 -0000

Hi Jari,

> And I fear that somewhere down the line someone would decide all we need =
is
> inside/outside security model, and I do not think that helps enough in th=
is case

For one I am not convinced that inside/outside security model is not
good enough for the problem at hand.

Is your point perhaps more focused towards clear placement of such
boundary ? If so I think it's get more involved indeed as deployment
models may vary. But once such boundary is set I am not sure why it
would not be sufficient for SR architecture.

Specifically we already have defined IGP as the carrier of SIDs. You
normally do not run IGP (passive interfaces excluded) outside of your
domain boundary. That plus ACL towards/against infrastructure
addresses IMHO should provide sufficient isolation.

Best regards,
R.





On Wed, Oct 16, 2013 at 8:38 PM, Jari Arkko  wrote:
> I'd suggest that the distinction between trusted and non-trusted or host =
and router is not as useful as we might expect.
>
> What I was trying to suggest with my text was specifying a requirement fo=
r a technical mechanism that helps prevent inappropriate headers from being=
 believed. Trusted/non-trusted in itself would not be as useful, until it r=
esults in a similar specific requirement. And I fear that somewhere down th=
e line someone would decide all we need is inside/outside security model, a=
nd I do not think that helps enough in this case.
>
> But I don't mind the new text if the old text is still also there=85.
>
> Jari
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status

From jari.arkko@piuha.net  Wed Oct 16 12:11:21 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B1811E8145; Wed, 16 Oct 2013 12:11:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.58
X-Spam-Level: 
X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehmwvs9-JDFL; Wed, 16 Oct 2013 12:11:16 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id CE04211E8144; Wed, 16 Oct 2013 12:11:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3F7192CC6C; Wed, 16 Oct 2013 22:11:13 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb1VLP_1fTQP; Wed, 16 Oct 2013 22:11:12 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id AAD2D2CC48; Wed, 16 Oct 2013 22:11:12 +0300 (EEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko 
In-Reply-To: 
Date: Wed, 16 Oct 2013 22:11:12 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A710072-199D-456D-9DB3-C7DBAC0AA0A2@piuha.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net>  
To: Robert Raszuk 
X-Mailer: Apple Mail (2.1510)
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 19:11:21 -0000

Robert - I think we discussed this previously. One of my issues was that =
it is not just your well-protected network that is in danger. It is also =
my network with thousand machines, with one accidentally turned on to =
accept the new headers. The current text in the charter resolves that =
concern, and I'm not sure I want to have headers that wouldn't be able =
to do protect against this=85 particularly when the cost is minimal.

Jari


From rraszuk@gmail.com  Wed Oct 16 12:28:17 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3827811E8150; Wed, 16 Oct 2013 12:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.429,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4vvLfq92xa; Wed, 16 Oct 2013 12:28:16 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 813CF11E81DB; Wed, 16 Oct 2013 12:28:16 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id u16so2123483iet.7 for ; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=p/2Bx3AVeQ0aBGlZK/zpShhy70ThaaApBf38Pv034WI=; b=NpleWIn+FRt1sKVVG50ip/cADj4Kx3tOGqX29K5X7J1EIe/w9bSUrQnnnCtIb/ZZsA AvzStpAs2XFIWC9WZcpealUw5gnWrM7OxE6EMQ5JqjD0TmP3LWt1K2tShEAx0fQysvFo DrUcdb75B59YxseWkpSZ715/Wu4tOh056owBJSW9HxiUIcFs4mxkg3R77u1cQ12WicGv L14aGNzgUK9PBsxGLQmWwS2FBlojQnefCnc6vSLI/HrOhEq13mh19O5dNHo6FqSsKzpM hZMkGGX1w0ijOMkXZG8K5cBw/2zyz9cn5eRUl6zxhU6diCSEWCrZlS0XNCCGezFqe0dW dvJQ==
MIME-Version: 1.0
X-Received: by 10.42.84.130 with SMTP id m2mr2930330icl.16.1381951695511; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
In-Reply-To: <7A710072-199D-456D-9DB3-C7DBAC0AA0A2@piuha.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net>   <7A710072-199D-456D-9DB3-C7DBAC0AA0A2@piuha.net>
Date: Wed, 16 Oct 2013 21:28:15 +0200
X-Google-Sender-Auth: zn_CVN8foYBh1XL_0eNIjQVFqxA
Message-ID: 
From: Robert Raszuk 
To: Jari Arkko 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" , "status@ietf.org" 
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Oct 2013 19:28:17 -0000

If you accidentally turn on SR then you have no SIDs in your thousand
machine network to forward to hence I do not see the issue. The
packets will be forwarded to the outer destination v6 address (same as
today).

I think perhaps disconnect is that extension header is not to be a
normal v6 header however packet destination (just like today in
transit) could be regular v6 address.

It's however not the charter discussion I think ....

Many thx,
R.




On Wed, Oct 16, 2013 at 9:11 PM, Jari Arkko  wrote:
> Robert - I think we discussed this previously. One of my issues was that =
it is not just your well-protected network that is in danger. It is also my=
 network with thousand machines, with one accidentally turned on to accept =
the new headers. The current text in the charter resolves that concern, and=
 I'm not sure I want to have headers that wouldn't be able to do protect ag=
ainst this=85 particularly when the cost is minimal.
>
> Jari
>

From Ruediger.Geib@telekom.de  Fri Oct 18 01:25:02 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913A211E8163 for ; Fri, 18 Oct 2013 01:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr0nd1aqHusi for ; Fri, 18 Oct 2013 01:24:55 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 62A5211E817D for ; Fri, 18 Oct 2013 01:24:51 -0700 (PDT)
Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 18 Oct 2013 10:24:49 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 18 Oct 2013 10:24:49 +0200
From: 
To: , 
Date: Fri, 18 Oct 2013 10:24:48 +0200
Thread-Topic: New Version Notification for draft-geib-spring-oam-usecase-00.txt
Thread-Index: Ac7LQ58hVpL93FdvTkyz9mehHoQiBwAl0MJA
Message-ID: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: status@ietf.org
Subject: [Status] FW: New Version Notification for draft-geib-spring-oam-usecase-00.txt
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Oct 2013 08:25:03 -0000

Chairs,

please find below as separate SR OAM use case draft.
It covers a single OAM use case rather than all. It
could be merged into a suitable document, if there's
interest.

Regards,

Ruediger


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 17, 2013 4:17 PM
To: Geib, R=FCdiger; Geib, R=FCdiger
Subject: New Version Notification for draft-geib-spring-oam-usecase-00.txt


A new version of I-D, draft-geib-spring-oam-usecase-00.txt
has been successfully submitted by Ruediger Geib and posted to the
IETF repository.

Filename:        draft-geib-spring-oam-usecase
Revision:        00
Title:           Use case for a scalable and topology aware MPLS data plane=
 monitoring system
Creation date:   2013-10-17
Group:           Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-geib-spring-oam-=
usecase-00.txt
Status:          http://datatracker.ietf.org/doc/draft-geib-spring-oam-usec=
ase
Htmlized:        http://tools.ietf.org/html/draft-geib-spring-oam-usecase-0=
0


Abstract:
   This document describes features and a use case of a path monitoring
   system.  Segment based routing enables a scalbale and simple method
   to monitor data plane liveliness of the complete set of paths
   belonging to a single domain.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


From yakov@juniper.net  Sun Oct 20 11:06:05 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835C21F9F19 for ; Sun, 20 Oct 2013 11:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtYoTiV1zPhC for ; Sun, 20 Oct 2013 11:06:01 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id DC7ED11E8426 for ; Sun, 20 Oct 2013 11:04:43 -0700 (PDT)
Received: from mail173-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Sun, 20 Oct 2013 18:04:42 +0000
Received: from mail173-db9 (localhost [127.0.0.1])	by mail173-db9-R.bigfish.com (Postfix) with ESMTP id 93E4F800F3	for ; Sun, 20 Oct 2013 18:04:42 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -21
X-BigFish: VPS-21(zz936eIzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h1155h)
Received-SPF: pass (mail173-db9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=yakov@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; 
Received: from mail173-db9 (localhost.localdomain [127.0.0.1]) by mail173-db9 (MessageSwitch) id 1382292281701144_6974; Sun, 20 Oct 2013 18:04:41 +0000 (UTC)
Received: from DB9EHSMHS002.bigfish.com (unknown [10.174.16.234])	by mail173-db9.bigfish.com (Postfix) with ESMTP id A7AFF46007E	for ; Sun, 20 Oct 2013 18:04:41 +0000 (UTC)
Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB9EHSMHS002.bigfish.com (10.174.14.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 20 Oct 2013 18:04:39 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 20 Oct 2013 11:04:38 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r9KI4bL75842	for ; Sun, 20 Oct 2013 11:04:37 -0700 (PDT)	(envelope-from yakov@juniper.net)
Message-ID: <201310201804.r9KI4bL75842@magenta.juniper.net>
To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <91839.1382292277.1@juniper.net>
Date: Sun, 20 Oct 2013 11:04:37 -0700
From: Yakov Rekhter 
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: [Status] draft-gredler-spring-mpls-01.txt
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Oct 2013 18:06:05 -0000

fyi (and comments)
------- Forwarded Message

Date:    Sun, 20 Oct 2013 11:01:26 -0700
From:    
To:      
Subject: I-D Action: draft-gredler-spring-mpls-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title           : Supporting Source/Explicitly Routed Tunnels via Stack
ed LSPs
	Author(s)       : Hannes Gredler
                          Yakov Rekhter
                          Sriganesh Kini
	Filename        : draft-gredler-spring-mpls-01.txt
	Pages           : 17
	Date            : 2013-10-20

Abstract:
   This document describes how source/explicitly routed tunnels could be
   realized using stacked Label Switched Paths (LSPs).

   This document also describes how use of IS-IS/OSPF as a label
   distribution protocol fits into the MPLS architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-gredler-spring-mpls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-gredler-spring-mpls-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-gredler-spring-mpls-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


------- End of Forwarded Message



From sriganesh.kini@ericsson.com  Mon Oct 21 12:32:44 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD83911E86DD; Mon, 21 Oct 2013 12:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUCeinZqnHso; Mon, 21 Oct 2013 12:32:32 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0125811E86D2; Mon, 21 Oct 2013 12:32:31 -0700 (PDT)
X-AuditID: c6180641-b7fe28e000000d82-5d-5265814f7d4c
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8E.5C.03458.F4185625; Mon, 21 Oct 2013 21:32:31 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 15:32:31 -0400
From: Sriganesh Kini 
To: "status@ietf.org" 
Thread-Topic: New Version Notification for draft-kini-spring-mpls-lsp-ping-00.txt
Thread-Index: AQHOzo1NBAxPx6sKG0+Hk/pOE4NF8Zn/WTQA
Date: Mon, 21 Oct 2013 19:32:30 +0000
Message-ID: <95453A37E413464E93B5ABC0F8164C4D02E90B57@eusaamb101.ericsson.se>
In-Reply-To: <20131021184153.32495.90112.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPlK5/Y2qQQddBDYtbS1eyWrxuvsjk wOSxZMlPpgDGKC6blNSczLLUIn27BK6MT+cOsRe84K64cmYxcwPjVs4uRk4OCQETiUdPr7NA 2GISF+6tZwOxhQSOMkpcb3eBsJczSpw4mQ9iswkYSVy4Ox+sXkRAXaKh8S57FyMHB7OAssSp uzIgYWGBIImfX3vYIEqCJa7/2MQIYRtJrNz3lR3EZhFQlXjw/jsziM0r4Csx6dtMJhCbU8BJ YkH7WbB6RqBzvp9aAxZnFhCXuPVkPhPEmQISS/acZ4awRSVePv7HCmKLCuhJHN7zmhUiriyx 5Ml+FoheHYkFuz+xQdjWEr3Nx6BsbYllC19D3SAocXLmE5YJjOKzkKybhaR9FpL2WUjaZyFp X8DIuoqRo7Q4tSw33chwEyMwjo5JsDnuYFzwyfIQozQHi5I475e3zkFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGFuNeCYW7mLf/fbF6WsnLjKnFW2dGRSUss/h7j8v15tLjv5kUk2yTapM /1tXX7c4ZsG9lqSdki5/D68JWnzYNvZVT1Nx27cffWdTFS7WOD482pguOFly0v0bb9fY+7oq Pg6b/3f//BM7ZwvqCKWqpzNauZm5rIu2TPp/g8tjycYjUoFGi0SY5iuxFGckGmoxFxUnAgAu FZ6AcQIAAA==
Cc: "mpls@ietf.org" 
Subject: [Status] FW: New Version Notification for draft-kini-spring-mpls-lsp-ping-00.txt
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2013 19:32:45 -0000

Hello,

We have submitted a new draft to describe how RFC 4379 (MPLS Ping) can be
applied to SPRING-MPLS.

Comments welcome.

- Sri

On 10/21/13 11:41 AM, "internet-drafts@ietf.org"
 wrote:

>
>A new version of I-D, draft-kini-spring-mpls-lsp-ping-00.txt
>has been successfully submitted by Sriganesh Kini and posted to the
>IETF repository.
>
>Filename:	 draft-kini-spring-mpls-lsp-ping
>Revision:	 00
>Title:		 Detecting Multi-Protocol Label Switching (MPLS) Data Plane
>Failures in Source Routed LSPs
>Creation date:	 2013-10-21
>Group:		 Individual Submission
>Number of pages: 7
>URL:            =20
>http://www.ietf.org/internet-drafts/draft-kini-spring-mpls-lsp-ping-00.txt
>Status:         =20
>http://datatracker.ietf.org/doc/draft-kini-spring-mpls-lsp-ping
>Htmlized:       =20
>http://tools.ietf.org/html/draft-kini-spring-mpls-lsp-ping-00
>
>
>Abstract:
>   MPLS has defined mechanisms for fault detection and isolation and
>   mechanisms for reliably sending an echo reply in RFC 4379.  Source
>   routed MPLS LSPs are a technique being proposed to address new use-
>   cases.  This document describes how mechanisms defined for MPLS fault
>   detection and isolation can be applied for source routed LSPs.
>
>                 =20
>       =20
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>


From naikumar@cisco.com  Mon Oct 21 13:18:42 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D328E11E862E; Mon, 21 Oct 2013 13:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VefpNrb3tR4m; Mon, 21 Oct 2013 13:18:37 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id C1A8011E8427; Mon, 21 Oct 2013 13:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2227; q=dns/txt; s=iport; t=1382386700; x=1383596300; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=421u94N0PGRaO5Vk7VbPWuBiBjBa2U7duEngiklbXU8=; b=lctY6rAtEHdci7L/vatoztn5PfBridIKHMfZDkpCrarJflougV+hIUP7 lnv9iLmoy+cauKsjCIx8iT8qEfz12sHv17tdhXIHTBxKQFlA0WIa+GdSW oAuiqu59f6kIdn8utmC26jSZhBgYubxb8nJtvYZx7wyVyLaQLramW/SXu 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFABKLZVKtJXG+/2dsb2JhbABZgwc4VL4rgS8WdIIlAQEBBAEBATc0CxIBCBIQFDcLFwQBBgMCBAENBQgBh30NujWPKjECBYMfgQoDmTiLJIU0gySCKg
X-IronPort-AV: E=Sophos;i="4.93,542,1378857600"; d="scan'208";a="239711896"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rtp-iport-1.cisco.com with ESMTP; 21 Oct 2013 20:18:18 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9LKII6v022615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 20:18:18 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 15:18:18 -0500
From: "Nagendra Kumar Nainar (naikumar)" 
To: "mpls@ietf.org" , "status@ietf.org" 
Thread-Topic: I-D Action: draft-kumar-mpls-spring-lsp-ping-00.txt
Thread-Index: AQHOzpncStW5zFUiQEe4YaVoI35FI5n/qOqA
Date: Mon, 21 Oct 2013 20:18:17 +0000
Message-ID: <47E76F08F1BCF5458111C1939C7B9C4610468264@xmb-rcd-x03.cisco.com>
In-Reply-To: <20131021201148.32534.32983.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [64.102.156.221]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6660E2178DB21E47943F356D810AC326@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "George Swallow \(swallow\)" , "Carlos Pignataro \(cpignata\)" , "Mach Chen \(mach.chen@huawei.com\)" , "Siva Sivabalan \(msiva\)" , "Nobo Akiya \(nobo\)" , "Tarek Saad \(tsaad\)" 
Subject: [Status] FW: I-D Action: draft-kumar-mpls-spring-lsp-ping-00.txt
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2013 20:18:43 -0000

Hi,

We have the below draft posted that covers LSP Ping machinery and FEC
sub-TLVs on SR network. Please reach and share your comments.

Regards,
Nagendra and other authors

On 10/21/13 4:11 PM, "internet-drafts@ietf.org" 
wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title           : Label Switched Path (LSP) Ping/Trace for Segment
>Routing Networks Using MPLS Dataplane
>	Author(s)       : Nagendra Kumar
>                          George Swallow
>                          Carlos Pignataro
>                          Nobo Akiya
>                          Mach(Guoyi) Chen
>	Filename        : draft-kumar-mpls-spring-lsp-ping-00.txt
>	Pages           : 12
>	Date            : 2013-10-21
>
>Abstract:
>   Segment Routing architecture leverages the source routing and
>   tunneling paradigm and can be directly applied to MPLS dataplane.  A
>   node steers a packet through a controlled set of instructions called
>   segments, by prepending the packet with Segment Routing header.
>
>   The segment assignment and forwarding semantic nature of Segment
>   Routing raises additional consideration for connectivity verification
>   and fault isolation in LSP with SPRING architecture.  This document
>   illustrates the problem and describe a mechanism to perform LSP Ping
>   and Traceroute on Segment Routing network over MPLS dataplane.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp-ping
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-kumar-mpls-spring-lsp-ping-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>I-D-Announce@ietf.org
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From sprevidi@cisco.com  Mon Oct 21 13:29:51 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6111E8439 for ; Mon, 21 Oct 2013 13:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5VAb03e3E4q for ; Mon, 21 Oct 2013 13:29:46 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17311E853E for ; Mon, 21 Oct 2013 13:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=868; q=dns/txt; s=iport; t=1382387364; x=1383596964; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WzZ5Wvcxl9/7QSNJyb4xvmuKlEC08TsaWYqN+C8JBWs=; b=AohIzqWESkDZ9kGWVrTq1NKi9DuRuqMSNPGw4SxLpkn3dTcuHt8IIHZN IMwIQn95yNSVTB13HKESgvaJ24U81KS/XnP8UDKSmvFJr/HSlSTEUV8rb UI7BU0DGB8a30QKRKEPi81Mm9Qe3cN/5VYeu3AKZTSizf1WQ6dXgzyrh/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjkGAHiNZVKtJXHA/2dsb2JhbABZgwc4VL4rgS8WbQeCJwEEOlEBGhAUQhcQBBsBh30NmGqhUY8qg1eBCgOqEIMkgio
X-IronPort-AV: E=Sophos;i="4.93,542,1378857600"; d="scan'208";a="274885070"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2013 20:29:24 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9LKTN28023874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 20:29:23 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 15:29:23 -0500
From: "Stefano Previdi (sprevidi)" 
To: "status@ietf.org" 
Thread-Topic: new/updated segment routing drafts
Thread-Index: AQHOzpw65POrjrg+PkSh0ndWdgteww==
Date: Mon, 21 Oct 2013 20:29:23 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.209.128]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4E3E2AADED4FD2449BFB9AB52751CE49@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Status] new/updated segment routing drafts
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Oct 2013 20:29:51 -0000

Hi,

Following drafts have been published/updated:

Segment Routing Architecture & Use Cases
http://www.ietf.org/internet-drafts/draft-filsfils-rtgwg-segment-routing-01=
.txt
http://www.ietf.org/internet-drafts/draft-filsfils-rtgwg-segment-routing-us=
e-cases-02.txt

Segment Routing with MPLS data-plane and SR/LDP interoperability
http://www.ietf.org/internet-drafts/draft-filsfils-spring-segment-routing-m=
pls-00.txt
http://www.ietf.org/internet-drafts/draft-filsfils-spring-segment-routing-l=
dp-interop-00.txt

Segment Routing Protocol Extensions
http://www.ietf.org/internet-drafts/draft-previdi-isis-segment-routing-exte=
nsions-03.txt
http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-exten=
sions-03.txt
http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-ospfv=
3-extension-00.txt

Thanks.
s.


From naikumar@cisco.com  Wed Oct 23 10:42:17 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0411E81CC for ; Wed, 23 Oct 2013 10:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0Rj2NaN1xMf for ; Wed, 23 Oct 2013 10:41:47 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABB711E8466 for ; Wed, 23 Oct 2013 10:41:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7609; q=dns/txt; s=iport; t=1382550078; x=1383759678; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=6b9RtkjWSzB1AKvP10KurV0+W+W4EIuzUizL/ipYGPc=; b=NeJGOx97+EFaU79kDXQfPRCnLyXoK5KXIo9xiVEQZPHz5aHgcPMTnBTY rz79i2IuK0bqkpJDczPGz6nmjTQNXS1vccdk8HXrM7GrAN0nDyan8J0IV D6YHZr//Fiwp2rGeORPMorDxyQ5vgxjri/9S/raC5U/jhjXBULrS2BHtK g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8IAPcJaFKtJXG+/2dsb2JhbABZgkNEOFSGC69/iEaBLhZtB4InAQR5EgEaEFYXDgIEDg2Hfg27AI8dLQQHgx+BCwOZOJBYgTuBaYIq
X-IronPort-AV: E=Sophos;i="4.93,555,1378857600";  d="scan'208,217";a="275769128"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2013 17:41:11 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9NHfB1j031727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 17:41:11 GMT
Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 12:41:10 -0500
From: "Nagendra Kumar Nainar (naikumar)" 
To: "status@ietf.org" 
Thread-Topic: Time slot request for draft-kumar-mpls-spring-lsp-ping-00
Thread-Index: AQHOz1LNG85AG8tCbEaPqlRUPALWHpoCoDuA
Date: Wed, 23 Oct 2013 17:41:09 +0000
Message-ID: <47E76F08F1BCF5458111C1939C7B9C461046C27C@xmb-rcd-x03.cisco.com>
In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C4610469BE8@xmb-rcd-x03.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [64.102.156.221]
Content-Type: multipart/alternative; boundary="_000_47E76F08F1BCF5458111C1939C7B9C461046C27Cxmbrcdx03ciscoc_"
MIME-Version: 1.0
Cc: "George Swallow \(swallow\)" , "Carlos Pignataro \(cpignata\)" , "Mach Chen \(mach.chen@huawei.com\)" , "Siva Sivabalan \(msiva\)" , "Nobo Akiya \(nobo\)" , "Tarek Saad \(tsaad\)" 
Subject: [Status] Time slot request for draft-kumar-mpls-spring-lsp-ping-00
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Oct 2013 17:42:17 -0000

--_000_47E76F08F1BCF5458111C1939C7B9C461046C27Cxmbrcdx03ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

We would like to request for a time slot to present the idea defined in dra=
ft-kumar-mpls-spring-lsp-ping-00?. Nobo (Co-author) will be presenting the =
same.


Title           : Label Switched Path (LSP) Ping/Trace for Segment
Routing Networks Using MPLS Dataplane
Author(s)       : Nagendra Kumar
                          George Swallow
                          Carlos Pignataro
                          Nobo Akiya
                          Mach(Guoyi) Chen
Filename        : draft-kumar-mpls-spring-lsp-ping-00.txt
Pages           : 12
Date            : 2013-10-21

Abstract:
   Segment Routing architecture leverages the source routing and
   tunneling paradigm and can be directly applied to MPLS dataplane.  A
   node steers a packet through a controlled set of instructions called
   segments, by prepending the packet with Segment Routing header.

   The segment assignment and forwarding semantic nature of Segment
   Routing raises additional consideration for connectivity verification
   and fault isolation in LSP with SPRING architecture.  This document
   illustrates the problem and describe a mechanism to perform LSP Ping
   and Traceroute on Segment Routing network over MPLS dataplane.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp-ping

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-kumar-mpls-spring-lsp-ping-00


Thanks in Advance.

Regards,
Nagendra

--_000_47E76F08F1BCF5458111C1939C7B9C461046C27Cxmbrcdx03ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <0E16AFB82EBBE4418374ABDFDD59F542@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi,












We would like to request for a time slot to present the idea defined i=
n draft-kumar-mpls-spring-lsp-ping-00?. Nobo (Co-author) will be prese=
nting the same.














Title   &n=
bsp;       : Label Switched Path (LSP) Ping/T=
race for Segment


Routing Networks =
Using MPLS Dataplane


Author(s)  &nbs=
p;    : Nagendra Kumar


   =
;            &n=
bsp;          George Swal=
low


   =
;            &n=
bsp;          Carlos Pign=
ataro


   =
;            &n=
bsp;          Nobo Akiya<=
/div>

   =
;            &n=
bsp;          Mach(Guoyi)=
 Chen


Filename   =
;     : draft-kumar-mpls-spring-lsp-ping-00.txt

Pages   &n=
bsp;       : 12


Date   &nb=
sp;        : 2013-10-21







Abstract:


   Segm=
ent Routing architecture leverages the source routing and


   tunn=
eling paradigm and can be directly applied to MPLS dataplane.  A<=
/div>

   node=
 steers a packet through a controlled set of instructions called


   segm=
ents, by prepending the packet with Segment Routing header.







   The =
segment assignment and forwarding semantic nature of Segment


   Rout=
ing raises additional consideration for connectivity verification













Thanks in Advance.







Regards,


Nagendra









--_000_47E76F08F1BCF5458111C1939C7B9C461046C27Cxmbrcdx03ciscoc_--

From aretana@cisco.com  Wed Oct 23 14:07:06 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9811E820D for ; Wed, 23 Oct 2013 14:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N00EbNaZmqjd for ; Wed, 23 Oct 2013 14:07:01 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85A11E81E1 for ; Wed, 23 Oct 2013 14:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2131; q=dns/txt; s=iport; t=1382562421; x=1383772021; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bBOcDPrcgq4wpXddc6juGBAKCr6IZ6CM9yAostmLP3k=; b=AfX7k+l6gQYlsm/2u2Atrlqf3sfP6cxFeT0yvtQpeQOHooqo3eeCqHcI Vh4gZY9uwNptwKxuYxURiw+kxct9Yw0DoHqy/8HQ5rlL8tKj13eq4k53s b5rKXx+3FN6tVm9frZPvVB5KdAX84Gf6JI2PezXgMRyJgnu2+Y+kJAhTs 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAIk5aFKtJV2d/2dsb2JhbABZgkNEgQy+V4EuFnSCJwEEeRIBCAQBHR05FBECBAENBQiHfrtLjx0xB4MfgQsDqhCDJIIq
X-IronPort-AV: E=Sophos;i="4.93,557,1378857600";  d="scan'208,217";a="275920289"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 23 Oct 2013 21:06:43 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9NL6gxv008568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 21:06:42 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 16:06:42 -0500
From: "Alvaro Retana (aretana)" 
To: "Nagendra Kumar Nainar (naikumar)" , "status@ietf.org" 
Thread-Topic: [Status] Time slot request for draft-kumar-mpls-spring-lsp-ping-00
Thread-Index: AQHOz1LNG85AG8tCbEaPqlRUPALWHpoCoDuAgAA5bAA=
Date: Wed, 23 Oct 2013 21:06:42 +0000
Message-ID: 
In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C461046C27C@xmb-rcd-x03.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.15.7]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396BA025xmbalnx15ciscoc_"
MIME-Version: 1.0
Cc: "George Swallow \(swallow\)" , "Carlos Pignataro \(cpignata\)" , "Mach Chen	\(mach.chen@huawei.com\)" , "Siva Sivabalan \(msiva\)" , "Nobo Akiya \(nobo\)" , "Tarek Saad \(tsaad\)" 
Subject: Re: [Status] Time slot request for draft-kumar-mpls-spring-lsp-ping-00
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Oct 2013 21:07:06 -0000

--_000_BBD66FD99311804F80324E8139B3C94E396BA025xmbalnx15ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On 10/23/13 1:41 PM, "Nagendra Kumar Nainar (naikumar)" > wrote:

Nagendra:

Hi!

We would like to request for a time slot to present the idea defined in dra=
ft-kumar-mpls-spring-lsp-ping-00?. Nobo (Co-author) will be presenting the =
same.

We should be able to accommodate you on the agenda.  How much time do you n=
eed?

Alvaro.

--_000_BBD66FD99311804F80324E8139B3C94E396BA025xmbalnx15ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6FAFE830887E3D4B8EB5B1D69E0CEDAA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







On 10/23/13 1:41 PM, "Nagendra Kumar Nainar (naikumar)" <=
naikumar@cisco.com> wrote:






Nagendra:







Hi!












We would like to request for a time slot to present the idea defined i=
n draft-kumar-mpls-spring-lsp-ping-00?. Nobo (Co-author) will be prese=
nting the same.












We should be able to accommodate you on the agenda.  How much tim=
e do you need?







Alvaro.




--_000_BBD66FD99311804F80324E8139B3C94E396BA025xmbalnx15ciscoc_--

From aretana@cisco.com  Wed Oct 23 14:46:19 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645DA11E824C for ; Wed, 23 Oct 2013 14:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGWoPA8ki7hH for ; Wed, 23 Oct 2013 14:46:14 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E985D11E8273 for ; Wed, 23 Oct 2013 14:45:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14967; q=dns/txt; s=iport; t=1382564743; x=1383774343; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=nxxz8WtwWkX5jOG6eESMazXhovgD2bzaghSJbbwn9VM=; b=DnxurasJ0InkzZ2ywrtQNh2v1/fSG8HK+yI4DiX0cBce4Xrij71cl6Or cLktcgRp7HW7jen8MQ79CPa4g4hx0azJlchE/ru8YA7HAKp2Na1evCHAe 74nDJ7Gp72ufOxRRWvlHn5QGhCin7btzcPVv68kHuqUgUNQeqKb6aNh6s A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AioGADpCaFKtJXG//2dsb2JhbABYAYJDRDhUvlaBLhZtB4InAQSBCwEIEhAPAQEMORQDDgIEEwgTh2sNmVWhYI8dOCMEAYJ3gQsDmTiQWIMkgio
X-IronPort-AV: E=Sophos;i="4.93,557,1378857600";  d="scan'208,217";a="275813083"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2013 21:45:31 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9NLjV56002582 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 23 Oct 2013 21:45:31 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.40]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 16:45:30 -0500
From: "Alvaro Retana (aretana)" 
To: "status@ietf.org" 
Thread-Topic: [Status] IETF 88 Agenda Items
Thread-Index: AQHOynGSXDdMesgLNkyT5jtq/G06P5oC7kAA
Date: Wed, 23 Oct 2013 21:45:30 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.117.15.7]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E396BA73Bxmbalnx15ciscoc_"
MIME-Version: 1.0
Subject: Re: [Status] IETF 88 Agenda Items
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Oct 2013 21:46:19 -0000

--_000_BBD66FD99311804F80324E8139B3C94E396BA73Bxmbalnx15ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi!

For some reason I don't have access to publish the agenda..while I get it f=
ixed, here is the draft agenda (below).  The revised agenda is due on Monda=
y.

Thanks!

Alvaro.


Source Packet Routing in Networking WG (spring)

IETF 88 (Vancouver) Agenda


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


CHAIR(s):  John Scudder 

           Alvaro Retana 


MONDAY, November 4, 2013

1450-1720  Afternoon Session II

Regency B


o Administrivia

  Chairs                                               15 minutes

                                         (or as long as it takes)

  - Note Well

  - Scribe

  - Blue Sheets

  - BOF/WG Status + Charter Review



o Segment Routing Use Cases

  http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases

  TBD                                                  15 minutes


o Performance Engineered LSPs using the Segment Routing Data-Plane

  http://tools.ietf.org/html/draft-shakir-rtgwg-sr-performance-engineered-l=
sps

  TBD                                                  10 minutes


o Analysis of the Overhead of Source Routing in SP Networks

  http://tools.ietf.org/html/draft-ashwood-sdnrg-state-reduction

  Peter Ashwook-Smith                                   5 minutes


o Segment Routing Architecture

  http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases

  Stefano Previdi                                      10 minutes


o Segment Routing Fast Reroute

  http://tools.ietf.org/html/draft-francois-sr-frr

  Pierre Francois                                      10 minutes


o Advertising Global Labels Using IGP

  http://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv

  Xiaohu Xu                                            10 minutes


o Signaling Entropy Label Capability Using Interior Gateway Protocols

  http://tools.ietf.org/html/draft-xu-mpls-el-capability-signaling-igp

  Xiaohu Xu                                             5 minutes


o Label Switched Path (LSP) Ping/Trace for Segment

  http://tools.ietf.org/html/draft-kumar-mpls-spring-lsp-ping

  Nobo Akiya                                            ? minutes

On 10/16/13 3:13 PM, "Alvaro Retana (aretana)" > wrote:

Hi!

We have a 2 1/2 hour slot in Vancouver on Monday afternoon:

1450-1720  Afternoon Session II
Regency B               RTG     spring          Source Packet Routing in Ne=
tworking WG


Even though the agenda already lists us as the 'spring WG', the process has=
n't finished and we're still a BOF.  Because of that, the first part of the=
 agenda will be to resolve any issues that still remain.  If spring does be=
come a WG before the meeting we will clearly not need that time.

We would like to start collecting proposals for agenda items at this time. =
 Please send your request to John and I.  We will prioritize the items alre=
ady listed as milestones in the charter: use cases, architecture, solutions=
, etc.  Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the fina=
l agenda: (1) your draft MUST have been published already, and (2) you MUST=
 provide the chairs with your slides by EOD on Friday, November 1st, 2013.

Keep the following dates in mind:

Oct/21: cut-ff date for ID submission.  It would be very nice if your draft=
s are published with the -spring=96 name in them.
Oct/23: Draft WG agendas are due
Oct/28: Revised WG agendas are due

Thanks!

Alvaro + John

--_000_BBD66FD99311804F80324E8139B3C94E396BA73Bxmbalnx15ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3B5E14E586C53649976210FB807E17DF@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi!







For some reason I don't have access to publish the agenda..while I get=
 it fixed, here is the draft agenda (below).  The revised agenda is du=
e on Monday.







Thanks!







Alvaro.









Source Pa=
cket Routing in Networking WG (spring)


IETF 88 (=
Vancouver) Agenda








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









CHAIR(s):=
  John Scudder <jgs@juniper.net>


 &nb=
sp;         Alvaro Retana <aretana@cisco.com>








MONDAY, N=
ovember 4, 2013


1450-1720=
  Afternoon Session II


Regency B=
 








o Adminis=
trivia


  Ch=
airs                     =
                     =
;     15 minutes


 &nb=
sp;                     &=
nbsp;                 (or as long a=
s it takes)


  - =
Note Well


  - =
Scribe


  - =
Blue Sheets


  - =
BOF/WG Status + Charter Review



  


o Segment=
 Routing Use Cases


  ht=
tp://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases


  TB=
D                    &nbs=
p;                     &n=
bsp;       15 minutes








o Perform=
ance Engineered LSPs using the Segment Routing Data-Plane


  ht=
tp://tools.ietf.org/html/draft-shakir-rtgwg-sr-performance-engineered-lsps<=
/p>

  TB=
D                    &nbs=
p;                     &n=
bsp;       10 minutes








o Analysi=
s of the Overhead of Source Routing in SP Networks


  ht=
tp://tools.ietf.org/html/draft-ashwood-sdnrg-state-reduction


  Pe=
ter Ashwook-Smith                 &=
nbsp;                 5 minutes








o Segment=
 Routing Architecture


  ht=
tp://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases


  St=
efano Previdi                 =
                     10 m=
inutes








o Segment=
 Routing Fast Reroute


  ht=
tp://tools.ietf.org/html/draft-francois-sr-frr


  Pi=
erre Francois                 =
                     10 m=
inutes








o Adverti=
sing Global Labels Using IGP


  ht=
tp://tools.ietf.org/html/draft-xu-rtgwg-global-label-adv


  Xi=
aohu Xu                   =
;                     &nb=
sp;   10 minutes








o Signali=
ng Entropy Label Capability Using Interior Gateway Protocols


  ht=
tp://tools.ietf.org/html/draft-xu-mpls-el-capability-signaling-igp


  Xi=
aohu Xu                   &nbs=
p;                     &n=
bsp;   5 minutes








o Label S=
witched Path (LSP) Ping/Trace for Segment


  ht=
tp://tools.ietf.org/html/draft-kumar-mpls-spring-lsp-ping


  No=
bo Akiya                  &nbs=
p;                     &n=
bsp;   ? minutes












On 10/16/13 3:13 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:















Hi!







We have a 2 1/2 hour slot in Vancouver=
 on Monday afternoon:



Date: Thu, 24 Oct 2013 19:37:14 +0100
From: Stewart Bryant 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: "status@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alvaro Retana , "John G. Scudder" 
Subject: [Status] SPRING WG now approved.
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Oct 2013 18:37:46 -0000

The IESG approved the SPRING WG this evening.

The chairs will be Alvaro Retana and John Scudder.

The announcement should be out on Monday.

For the moment discussion should continue on the STATUS
list, but the secretariat will take steps to migrate the members,
archive etc to SPRING. Please continue to use this list until
you see an email saying to move to SPRING. I am
hoping that this is a fully automated process, but we
will see.

- Stewart




From iesg-secretary@ietf.org  Fri Oct 25 10:12:46 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7521211E81BD; Fri, 25 Oct 2013 10:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level: 
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdbmC68Z8KIK; Fri, 25 Oct 2013 10:12:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4911E8327; Fri, 25 Oct 2013 10:12:43 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.81
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131025171243.20802.23761.idtracker@ietfa.amsl.com>
Date: Fri, 25 Oct 2013 10:12:43 -0700
Cc: spring WG 
Subject: [Status] WG Action: Formed Source Packet Routing in Networking (spring)
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Oct 2013 17:12:46 -0000

A new IETF working group has been formed in the Routing Area. For
additional information please contact the Area Directors or the WG
Chairs.

Source Packet Routing in Networking (spring)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Alvaro Retana 
  John Scudder 

Assigned Area Director:
  Stewart Bryant 

Mailing list
  Address: status@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/status
  Archive:
http://www.ietf.org/mail-archive/web/status/current/maillist.html

Charter:

The ability for a node to specify a forwarding path, other 
than the normal shortest path, that a particular packet 
will traverse, benefits a number of network functions, 
for example:

o    Some types of network virtualization, including multi-
     topology networks and the partitioning of network 
     resources for VPNs
o    Network path and node protection such as fast re-route
o    Network programmability
o    New OAM techniques
o    Simplification and reduction of network signalling 
     components
o    Load balancing and traffic engineering

Source-based routing mechanisms have previously been 
specified for network protocols, but have not seen 
widespread adoption other than in MPLS traffic engineering. 
These network functions may require greater flexibility and 
per packet source imposed routing than can be achieved 
through the use of the previously defined methods. In the 
context of this charter, 'source' means 'the point at 
which the explicit route is imposed'.

The SPRING working group will define procedures that 
will allow a node to steer a packet along an explicit 
route using information attached to the packet and
without the need for per-path state information to be
held at transit nodes. Full explicit control (through loose
or strict path specification) can be achieved in a network 
comprising only SPRING nodes, however SPRING must 
inter-operate through loose routing in existing networks
and may find it advantageous to use loose routing for
for other network applications. 

The initial data planes that will be considered are MPLS
and IPv6.

There is an assumed trust model such that any node 
imposing an explicit route on a packet is assumed to 
be allowed to do so, however administrative and trust 
boundaries may strip explicit routes from a packet.
For each data plane technology that SPRING specifies, 
a security analysis must be provided showing how protection 
is provided against an attacker disrupting the network by 
for example, maliciously injecting SPRING packets.
There are a number of serious security concerns with 
source routing at the IP layer [RFC 5095].  As a part 
of its work, the working group will define the new 
IPv6-based routing header in way that blind attacks 
are never possible, i.e., attackers will be unable to 
send source routed packets that get successfully 
processed, without being part of the negotiation for 
setting up the source routes or being able to eavesdrop 
legitimate source routed packets. In some networks 
this base level security may be complemented with 
other mechanisms, such as packet filtering, cryptographic 
security, etc.

Initial work will focus on SPRING within in a single AS, 
however design decisions must not preclude operation 
of SPRING across AS boundaries. In such multi-AS 
deployments, the previously-stated trust model would 
still apply. 

SPRING should support both centralised and distributed 
path computation.  

The SPRING WG should provide OAM and the 
management needed to manage SPRING enabled networks. 
The SPRING procedures may also be used as a tool for OAM
in SPRING enabled networks.

SPRING should avoid modification to existing data 
planes that would make them incompatible with 
existing deployments. Where possible, existing control
and management plane protocols must be used within existing 
architectures to implement the SPRING function. Any
modification of or extension to existing architectures,
data planes, or control or management plane protocols 
must be carried out in the working groups responsible 
for the architecture, data plane, or control or 
management plane protocol being modified and in 
co-ordination with this working group, but may be 
done in this working group after agreement with 
all the relevant WG chairs and responsible Area Directors.

The SPRING working group is chartered for the following 
list of items:

o Identification and evaluation of use cases for SPRING. 
   These use cases must include a definition of the 
   data plane for the environment in which they are to be 
   deployed.

o Definition of requirements for any new data plane 
   encodings and procedures, required to implement 
   the use cases. Such procedures must include the 
   necessary security considerations.

o Definition of requirements and if necessary any 
   new control plane mechanism needed to enable 
   the use cases.

o Definition of requirements and if necessary management  
   plane mechanisms needed to manage and operate a 
   SPRING enabled network.

The SPRING working group will not work on any 
mechanisms for use in networks that forward IPv4 packets.
 


Milestones:
  Jul 2014 - One or more documents describing SPRING use cases.
  Nov 2014 - Specification of a high-level abstract architecture for
SPRING.
  Dec 2014 - Requirements for modifications if any to MPLS architecture
to support SPRING use cases.
  Jan 2015 - Requirements for modifications if any to IPv6 architecture
to support SPRING use cases.
  Mar 2015 - Specification of any required new procedures to support
SPRING use cases.
  Jul 2015 - One or more data plane extension requirements documents,
including documenting the impact on existing deployments of the existing
data planes.
  Jul 2015 - One or more control protocol extensions requirements
documents. 
  Jul 2015 - Management requirements document.
  Nov 2015 - Specify the OAM mechanisms needed to support SPRING.
  Nov 2015 - Document inter-working and co-existence between the new
procedures and the existing signalling and routing protocols.
  Jan 2016 - Inter-operability reports pertaining to the implementation
of extensions supporting SPRING.
  Feb 2016 - Recharter or close WG.



From aretana@cisco.com  Wed Oct 30 11:58:38 2013
Return-Path: 
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6034621F9E51 for ; Wed, 30 Oct 2013 11:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy3w3nUrT3Le for ; Wed, 30 Oct 2013 11:58:31 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6621F9DD5 for ; Wed, 30 Oct 2013 11:58:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6675; q=dns/txt; s=iport; t=1383159510; x=1384369110; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=LBbD44N2icHhjPqiVzri6I+x0z5N3bcagtzsQEGbEZw=; b=L0gKWosTlcskpu5F34grxGR0N6lAGI9beGRKQwUrBR2XfT5J6A3BZT3K ysJhq8ERNP6e510zlbIhzVYK8X5hWCcl+HDdTX+alcQV1/LCC6IMzdd6V 39ROE1pTgkKWlMbbrMyZG0iTsBoGsxbxcfcvpi+0ngKEr5K9vCp7alN5w g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAFAItWcVKtJV2b/2dsb2JhbABYAYJDRDhUv1SBKBZtB4InAQSBCwEIEhAPAQEMORQDDgIEEwgTh2wNmQ2hWQSPHi0KASMEAYJ3gQ0DqhODJoIq
X-IronPort-AV: E=Sophos;i="4.93,603,1378857600";  d="scan'208,217";a="278652176"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 30 Oct 2013 18:58:30 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UIwSxC003566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Oct 2013 18:58:28 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.171]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Wed, 30 Oct 2013 13:58:28 -0500
From: "Alvaro Retana (aretana)" 
To: "status@ietf.org" 
Thread-Topic: [Status] IETF 88 Agenda Items
Thread-Index: AQHOynGSXDdMesgLNkyT5jtq/G06P5oNv+cA
Date: Wed, 30 Oct 2013 18:58:28 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.254.89]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3971DA12xmbalnx15ciscoc_"
MIME-Version: 1.0
Subject: Re: [Status] IETF 88 Agenda Items
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2013 18:58:39 -0000

--_000_BBD66FD99311804F80324E8139B3C94E3971DA12xmbalnx15ciscoc_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi!

The final agenda is published here:  https://datatracker.ietf.org/meeting/8=
8/agenda/spring

As it says below, we need the slides by EOD on Friday November 1st (this Fr=
iday!).  Everyone on the agenda requested a slot, so this shouldn't be a su=
rprise..but since I'm posting the agenda a little late, then we'll still ac=
cept slides on Saturday.   The objective is to share the slides from our co=
mputer and not have to switch.

We want to focus on on the earlier milestones in the charter first.  To tha=
t end, we will take advantage of the face-to-face meeting to facilitate the=
 discussion of drafts related to those earlier milestones.  This means that=
 (while the agenda shows enough time to cover all the topics) we may not ha=
ve time to hear every presentation.

Thanks!

Alvaro.

On 10/16/13 3:13 PM, "Alvaro Retana (aretana)" > wrote:

Hi!

We have a 2 1/2 hour slot in Vancouver on Monday afternoon:

1450-1720  Afternoon Session II
Regency B               RTG     spring          Source Packet Routing in Ne=
tworking WG


Even though the agenda already lists us as the 'spring WG', the process has=
n't finished and we're still a BOF.  Because of that, the first part of the=
 agenda will be to resolve any issues that still remain.  If spring does be=
come a WG before the meeting we will clearly not need that time.

We would like to start collecting proposals for agenda items at this time. =
 Please send your request to John and I.  We will prioritize the items alre=
ady listed as milestones in the charter: use cases, architecture, solutions=
, etc.  Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the fina=
l agenda: (1) your draft MUST have been published already, and (2) you MUST=
 provide the chairs with your slides by EOD on Friday, November 1st, 2013.

Keep the following dates in mind:

Oct/21: cut-ff date for ID submission.  It would be very nice if your draft=
s are published with the -spring=96 name in them.
Oct/23: Draft WG agendas are due
Oct/28: Revised WG agendas are due

Thanks!

Alvaro + John

--_000_BBD66FD99311804F80324E8139B3C94E3971DA12xmbalnx15ciscoc_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1F6918D1F58973418171C1C76EC9E2A4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi!







The final agenda is published here:  https://datatracker.ietf.org/meeting/=
88/agenda/spring







As it says below, we need the slides by EOD on Friday November 1st =
(this Friday!).  Everyone on the agenda requested a slot, so this =
shouldn't be a surprise..but since I'm posting the agenda a little late, th=
en we'll still accept slides on Saturday.
   The objective is to share the slides from our computer and not have=
 to switch.







We want to focus on on the earlier milestones in the charter first. &n=
bsp;To that end, we will take advantage of the face-to-face meeting to faci=
litate the discussion of drafts related to those earlier milestones.  =
This means that (while the agenda shows enough
 time to cover all the topics) we may not have time to hear every presentat=
ion.







Thanks!







Alvaro.










On 10/16/13 3:13 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:















Hi!







We have a 2 1/2 hour slot in Vancouver=
 on Monday afternoon:


; Thu, 31 Oct 2013 20:55:11 GMT
Received: from xmb-aln-x15.cisco.com ([169.254.9.171]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 15:55:10 -0500
From: "Alvaro Retana (aretana)" 
To: "status@ietf.org" 
Thread-Topic: Note Taker and Jabber Scribe
Thread-Index: AQHO1nt81zTo1j8t/EaWHTKIXzVPYw==
Date: Thu, 31 Oct 2013 20:55:10 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.244.219]
Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E3972B4A7xmbalnx15ciscoc_"
MIME-Version: 1.0
Subject: [Status] Note Taker and Jabber Scribe
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
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, 31 Oct 2013 20:55:33 -0000

--_000_BBD66FD99311804F80324E8139B3C94E3972B4A7xmbalnx15ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi!

We need volunteers to take notes and be the Jabber scribe for next week's m=
eeting.

Thanks!

Alvaro.


--_000_BBD66FD99311804F80324E8139B3C94E3972B4A7xmbalnx15ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-ID: <33145C3BDFCF7E4189A5210D97DC6BEE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi!







We need volunteers to take notes and be the Jabber scribe for next wee=
k's meeting.







Thanks!







Alvaro.






--_000_BBD66FD99311804F80324E8139B3C94E3972B4A7xmbalnx15ciscoc_--