Hi!

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

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. 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 2B1B911E834D for ; Thu, 24 Oct 2013 11:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 5xdojvM23OdY for ; Thu, 24 Oct 2013 11:37:28 -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 49B1611E81CF for ; Thu, 24 Oct 2013 11:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=463; q=dns/txt; s=iport; t=1382639842; x=1383849442; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=QDrKdBC1vndzQcraLxilQWnbnxox5+2RbchGVfVjYT0=; b=RERkDLZYBKLeLj4SMvL7TYePHK7rr3gLvNXqFmlDqPbuYgtMsIK+3AjM oLH5O2SiGf2CDjyls6fOJWMv7+GPt+zg9KGopExBucJTiYufUoxWaOEhC HkF4X9Hd78EcPsCGEgYOGFNpA+bgNVCOjDjPOkS9m24fPfZd3fVrJ8E7v w=; X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="87640092" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 24 Oct 2013 18:37:21 +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 r9OIbFVQ015570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 18:37:17 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9OIbEcD024336; Thu, 24 Oct 2013 19:37:14 +0100 (BST) Message-ID: <526968DA.8070501@cisco.com> 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 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:
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_-- 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

   and = fault isolation in LSP with SPRING architecture.  This document
   illu= strates the problem and describe a mechanism to perform LSP Ping

   and = Traceroute on Segment Routing network over MPLS dataplane.

The IETF datatrac= ker status page for this draft is:

https://datatr= acker.ietf.org/doc/draft-kumar-mpls-spring-lsp-ping

There's also a ht= mlized version available at:

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

Thanks in Advance.

Regards,

Nagendra

--_000_47E76F08F1BCF5458111C1939C7B9C461046C27Cxmbrcdx03ciscoc_-- 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. 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 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 > 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 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 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 > 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 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 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 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. 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= 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 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 E47BF11E8182; Wed, 16 Oct 2013 10:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ummdBGzL2oBU; Wed, 16 Oct 2013 10:17: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 645EF11E81A4; Wed, 16 Oct 2013 10:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4842; q=dns/txt; s=iport; t=1381943825; x=1383153425; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wsRrem2aQ0RCSKVRf4CXomDM7/n5hxu0dR0nAtF4DV8=; b=ZGac8YsnhKL8hm5iAv482g1YqAcA/doRNzGQh5PslQoXAv8YT+ZrDjvU 0RTC4N79Bz3X8GRRgGIttRdRqnnN0P+z8VDRTDGp5QW9wJAsjdSKf5rq+ Id7b0s21xup6DSLXrUpCHQ881g5ed3rPRrYGIr57Wrx6bR5X13DJVs+yA E=; X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="18797683" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 16 Oct 2013 17:17:03 +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 r9GHGvVh007022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 17:16:59 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9GHGtmu025998; Wed, 16 Oct 2013 18:16:56 +0100 (BST) Message-ID: <525ECA07.2070207@cisco.com> 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 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:

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. 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 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 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 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= 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." 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 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-- 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-- 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 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 >> > > 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 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 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 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. 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 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 | > | > | | | 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== 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-- 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. 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= 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= 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= 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 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 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-- 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 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 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. 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 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. 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-- 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 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 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 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. :) 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-- 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... :) 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 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 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. 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 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 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== 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== 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 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== 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-- 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 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.= 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 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 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= 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 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 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 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 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 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 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-- 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 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 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-- 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 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 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-- 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==-- 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 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 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-- 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-- 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 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 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 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. 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-- 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 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 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 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 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 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 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 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 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