From adrian@olddog.co.uk Mon Jun 17 10:49:40 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0CA21F9C78 for ; Mon, 17 Jun 2013 10:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 TM7JfRJ7T996 for ; Mon, 17 Jun 2013 10:49:31 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2D321F9970 for ; Mon, 17 Jun 2013 10:49:30 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5HHnUpm029811 for ; Mon, 17 Jun 2013 18:49:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5HHnTdm029802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Jun 2013 18:49:29 +0100 From: "Adrian Farrel" To: Subject: New non-WG mailing list : Network Service Chaining (NSC) Date: Mon, 17 Jun 2013 18:49:29 +0100 Message-ID: <02a801ce6b83$0485abc0$0d910340$@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: Ac5rgwA2us4OLNYEQrCadV2h7kpQ8A== Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:49:40 -0000 There is a new non-working group mailing list for discussion of Network Service Chaining (NSC) The web page for users is: https://www.ietf.org/mailman/listinfo/nsc There is also an email-based interface for users. You can get info about using it by sending a message with just the word `help' as subject or in the body, to: nsc-request@ietf.org The mailing list is configured with a public archive which can be found at: http://www.ietf.org/mail-archive/web/nsc The purpose of the list Network services are widely deployed and essential in many networks. The services provide a range of functions such as security, WAN acceleration, and server load balancing. Service functions that form part of the overall service may be physically located at different points in the network infrastructure such as the wide area network, data center, campus, and so forth. New data center network and Internet cloud architectures require more flexible network service deployment models. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic service delivery, the movement of service functions and application workloads in the network and the ability to easily bind service policy to granular information such as per-subscriber state. Service chaining is a broad term used to describe a common model for delivering multiple services in a specific order. Service chaining de-couples service delivery from the underlying network topology and creates a dynamic services plane that addresses the requirements of cloud and virtual application delivery. Traffic that requires service chaining is classified, and context is shared between the network and the services. This list is for discussion of aspects of Network Service Chaining (NSC) that impact upon the IETF's work, the applicability of IETF protocols to NSC, as well as new protocols and changes to IETF protocols that might be required. A BoF has been proposed for NSC in Berlin. This list also serves to discuss that BoF proposal. See the proposal at http://trac.tools.ietf.org/bof/trac/ Thanks, Adrian From stbryant@cisco.com Thu Jun 20 12:07:11 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26DE21F9ACD; Thu, 20 Jun 2013 12:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.355 X-Spam-Level: X-Spam-Status: No, score=-110.355 tagged_above=-999 required=5 tests=[AWL=0.243, 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 9AW1P5YPMcN0; Thu, 20 Jun 2013 12:07:01 -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 EAB2621F99E9; Thu, 20 Jun 2013 12:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6146; q=dns/txt; s=iport; t=1371755214; x=1372964814; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=IA+7nYcMs409zHiUVU8+v0ePwREaMGri/hOhtieeZFg=; b=Tb6MfTn3DjQ26P1nqNa8aI0OEpU7GVPs8+xAX3tL9RYrbFCORLmG0Pba vebrnzoaP1Ou4WMUsQhD+liz1Obsjk9UPtIInz9pLubVVD047lkbv+SNm lorCOoTRFRecqzF1u53vB6R7z2dSutAzBgKW1Zcvwa84JhaLJYunTVGJQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FALpRw1GQ/khL/2dsb2JhbABbgwkxiSm2Vn0WdIIlAQUBAWsKATwWGAMCAQIBFUMBBwEBF4dzDKJpmUaNfoFLg2gDl0OBKZAbgxA X-IronPort-AV: E=Sophos;i="4.87,906,1363132800"; d="scan'208,217";a="14872298" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 20 Jun 2013 19:06:52 +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 r5KJ6ocM006922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 19: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 r5KJ6oQZ029147; Thu, 20 Jun 2013 20:06:50 +0100 (BST) Message-ID: <51C352CA.6000307@cisco.com> Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Status BOF in Berlin Content-Type: multipart/alternative; boundary="------------010101050308070806090301" Cc: status@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 19:07:11 -0000 This is a multi-part message in MIME format. --------------010101050308070806090301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart --------------010101050308070806090301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

STATUS

  • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
  • Status: Approved
  • Description

The IETF has two packet-based forwarding technologies: IP and MPLS.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

Further details can be found  at http://trac.tools.ietf.org/bof/trac/wiki

- Stewart

--------------010101050308070806090301-- From narten@us.ibm.com Thu Jun 20 13:27:22 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA821F9DD4 for ; Thu, 20 Jun 2013 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.824 X-Spam-Level: X-Spam-Status: No, score=-109.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 5wk7YY3msi9L for ; Thu, 20 Jun 2013 13:27:15 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 057B611E811F for ; Thu, 20 Jun 2013 13:27:05 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 20 Jun 2013 14:26:45 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 20 Jun 2013 14:26:42 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 21EE73E4003F; Thu, 20 Jun 2013 14:26:22 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5KKQVQN278436; Thu, 20 Jun 2013 14:26:37 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5KKQSVg027441; Thu, 20 Jun 2013 14:26:29 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-159-14.mts.ibm.com [9.76.159.14]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r5KKQRWD027272; Thu, 20 Jun 2013 14:26:28 -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 r5KKQQom022376; Thu, 20 Jun 2013 16:26:26 -0400 Message-Id: <201306202026.r5KKQQom022376@cichlid.raleigh.ibm.com> To: stbryant@cisco.com Subject: Re: Status BOF in Berlin In-reply-to: <51C352CA.6000307@cisco.com> References: <51C352CA.6000307@cisco.com> Comments: In-reply-to Stewart Bryant message dated "Thu, 20 Jun 2013 20:06:50 +0100." Date: Thu, 20 Jun 2013 16:26:26 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13062020-7606-0000-0000-00000CA9DC37 Cc: status@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 20:27:22 -0000 Hi Stewart. One thing that might be worth clarifying up front. Is there already a sense at this point whether the BOF is intended to form a WG post-berlin? Or is this really exploratory, with an assumption that a lot more work would need to be done with a followup BOF in Vancouver for formal WG creation (assuming things work out, of course)? FWIW, I assume it's exploratory. In any case, clearly laying out expectations would help level-set things. Looking at the BOF wiki, there is no draft with a problem statement. Reading the description, I don't quite understand if this is "MPLS only" or whether it really is broader and impacts IP. There is an explicit mention of IPv6 in the text (which caught my attention), but I don't see right off what that means. Are there additional drafts in the works that will clarify all this? What's the thinking here? Thanks! Thomas From stbryant@cisco.com Fri Jun 21 05:28:09 2013 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B07921E80FA; Fri, 21 Jun 2013 05:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.365 X-Spam-Level: X-Spam-Status: No, score=-110.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 T9LD5wZY+W7Q; Fri, 21 Jun 2013 05:28:03 -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 6911721E8105; Fri, 21 Jun 2013 05:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2629; q=dns/txt; s=iport; t=1371817683; x=1373027283; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6SDkDld4eTbwGpi/csNFoxh+O92Al1428+U5PZEhkw4=; b=F+gOCOhC1ZQCeQ05N6dgrXIgjItFTXNa7cZuPll180mld7wH6DF5YCOQ fbeKkhrKzVTFChJrdJerhpbKUt1a5YYv7CjTJkto+Nre86qrxHUBd7ycU M5KRhcmA3VO3la49Fmgg48MGz+12PbR4NW0gj6mPwphDvgd/0NWEkKfDu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADZGxFGQ/khL/2dsb2JhbABbgwm9OYJ1gQAWdIIjAQEBAwE4MBABEAsSBgkWDwkDAgECATcOBg0BBwEBEId0BrxfjhWBNAeDYQOXQ5FEgxA X-IronPort-AV: E=Sophos;i="4.87,912,1363132800"; d="scan'208";a="155613671" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2013 12:28:00 +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 r5LCRxeO031432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 12:27:59 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r5LCRwgx017838; Fri, 21 Jun 2013 13:27:59 +0100 (BST) Message-ID: <51C446CE.2020305@cisco.com> Date: Fri, 21 Jun 2013 13:27:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Status BOF in Berlin References: <51C352CA.6000307@cisco.com> <201306202026.r5KKQQom022376@cichlid.raleigh.ibm.com> In-Reply-To: <201306202026.r5KKQQom022376@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: status@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 12:28:09 -0000 On 20/06/2013 21:26, Thomas Narten wrote: > Hi Stewart. > > One thing that might be worth clarifying up front. > > Is there already a sense at this point whether the BOF is intended to > form a WG post-berlin? Or is this really exploratory, with an > assumption that a lot more work would need to be done with a followup > BOF in Vancouver for formal WG creation (assuming things work out, of > course)? Hi Thomas That is one of the questions that we need to answer over the next few weeks. The technique has had a quiet resurgence in a number of companies over the past few years. One of the tasks of the BOF is to determine whether this something that the IETF should work on and if so, on what timescale we should consider a WG. I know that you know the options, but for those that do not, we could emerge in position where we think that there is more work to do and may have a BOF in Vancouver or London to form a WG. On the other hand we may leave the meeting in Berlin with the ADs effectively instructed by the community to immediately work on getting a charter approved. So I am looking for the views of the community on exactly this question. > > FWIW, I assume it's exploratory. In any case, clearly laying out > expectations would help level-set things. > > Looking at the BOF wiki, there is no draft with a problem > statement. Correct, although a number of companies have been working on a use case draft in the background. > Reading the description, I don't quite understand if this > is "MPLS only" or whether it really is broader and impacts IP. There is interest in (re)introducing a constrained form of source routing to IP. Operators that run non-MPLS networks seem to be interested in an IP approach. Others are questioning why we need anything other than MPLS. So this is a matter that we need to investigate. A well designed architecture and control plane would be agnostic to the packet forwarding/encapsulation approach. > There > is an explicit mention of IPv6 in the text (which caught my > attention), but I don't see right off what that means. Yes, but there is currently no draft uploaded, although the there has been recent discussion at conferences for both IPv6 source routing and of some interesting OAM approaches that rely on a source routing approach. I hope that the advocates of those technologies will be encouraged to write them up in drafts. > > Are there additional drafts in the works that will clarify all this? > > What's the thinking here? > > I understand that there will be more drafts in the next week or so. Stewart