Re: [sfc] NSH and UDP Transport

Jeff Tantsura <jeff.tantsura@ericsson.com> Tue, 30 June 2015 04:23 UTC

Return-Path: <jeff.tantsura@ericsson.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84351B3064; Mon, 29 Jun 2015 21:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNXuOZVHAQyn; Mon, 29 Jun 2015 21:23:54 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243C11B308E; Mon, 29 Jun 2015 21:23:54 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-76-5591b2f36ee7
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.F4.07675.3F2B1955; Mon, 29 Jun 2015 23:04:51 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Tue, 30 Jun 2015 00:23:52 -0400
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: "Larry Kreeger (kreeger)" <kreeger@cisco.com>
Subject: Re: [sfc] NSH and UDP Transport
Thread-Topic: [sfc] NSH and UDP Transport
Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAANo+AIAAj+yAgAAsEQCAAAm1gIAHCGGAgABbtYCAALDhAIAhihIAgEBxoAD//+OdHg==
Date: Tue, 30 Jun 2015 04:23:52 +0000
Message-ID: <01A91F3E-8CA6-4E30-AFA6-C0AE2A043B54@ericsson.com>
References: <D15AD3A0.28AD4%smkumar@cisco.com> <55358DFD.2040804@joelhalpern.com> <B959FA17-32A5-45CD-AE55-DA37C881B967@cisco.com> <CC00A8A1-2F37-4C18-B166-BF401F57FC19@alcatel-lucent.com> <AF9EE537-3869-405F-9618-947479FBD247@lucidvision.com> <5538F7F6.9070502@joelhalpern.com> <D15E7733.F18D%jguichar@cisco.com> <D16402E4.146C1C%kreeger@cisco.com> <553F334D.2050907@queuefull.net> <D165151F.296CC%smkumar@cisco.com> <D181326B.2DB45%smkumar@cisco.com>,<D1B7466E.152912%kreeger@cisco.com>
In-Reply-To: <D1B7466E.152912%kreeger@cisco.com>
Accept-Language: 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
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPt+7nTRNDDe5fELdY8GYxi8XNgzOZ LC68+c1s8eTBVnYHFo8pvzeyeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGRN2tzEXzFas eNi+k72B8ZJUFyMnh4SAicTilYvZIGwxiQv31gPZXBxCAkcZJY5sOwyWEBJYDuS8TgOx2QQM JP5/O84CYosIGEq0Xr/OBNLALNDMKLH42XlmkISwgIbEwasz2bsYOYCKNCW+depA1NdJrP7x A6yXRUBV4ualiawgNq+AvcTE6UfYIRb/YJb4dnQjI0iCE2jZyfsP2EFsRqDrvp9awwRiMwuI S9x6Mp8J4moBiSV7IPZKCIhKvHz8jxWiRkdiwe5PbBC2tsSyha+ZIZYJSpyc+YRlAqPoLCSj ZiFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECo+WYBJvjDsYFnywPMQpwMCrx8C5onxgqxJpY VlyZe4hRmoNFSZxX2i8vVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjdpb3OwQ9mMTmyDo7 zZh4Pcb99o19izzsfap2Jim3VHswtNS+8s4vVLmdZWgtrL/t33STg343AtMmyVnMFwp3DmsJ V/sV3ponMGPC3vIpL1fq64XrBe29o5BuYqmsytqsFnCpZl3Dwvuiho4LbSfvW3terMqlo6cp mv8D+1WtX60OvWmCS5RYijMSDbWYi4oTAbYmz9h3AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/Di8ubUQHyQ8QQgUqelhG7APVCaI>
Cc: "rtgwg-chairs@tools.ietf.org" <rtgwg-chairs@tools.ietf.org>, "sfc@ietf.org" <sfc@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2015 04:23:58 -0000

Hi Larry,

Noted, 10 minutes slot has been reserved for you.

Regards,
Jeff

> On Jun 29, 2015, at 7:05 PM, Larry Kreeger (kreeger) <kreeger@cisco.com> wrote:
> 
> Following up on this, we would like to have a slot in Prague (somewhere)
> to present this draft.
> 
> Jeff,
> 
> Can we get on the agenda in RTGWG for this?  Is there someone beside you
> that we should make this request to?
> 
> Thanks, Larry
> 
>> On 5/19/15, 6:58 PM, "Surendra Kumar (smkumar)" <smkumar@cisco.com> wrote:
>> 
>> Dear Chairs,
>> 
>> We submitted the draft on UDP transport for NSH (below)
>> Although we strongly believe it belongs in SFC, we would be happy to
>> present it in RTGWG or NVO3 as suggested by Jeff and Benson.
>> 
>> Also, appreciate your consideration in getting a slot for this at Prague.
>> 
>> Thanks,
>> Surendra.
>> 
>> -------
>> A new version of I-D, draft-kumar-sfc-nsh-udp-transport-00.txt
>> has been successfully submitted by Surendra Kumar and posted to the
>> IETF repository.
>> 
>> Name:        draft-kumar-sfc-nsh-udp-transport
>> Revision:    00
>> Title:        UDP Overlay Transport For Network Service Header
>> Document date:    2015-05-16
>> Group:        Individual Submission
>> Pages:        9
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-udp-transport-00.
>> t
>> xt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/
>> Htmlized:       
>> https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00
>> 
>> 
>> Abstract:
>>  This draft describes the transport encapsulation to carry Network
>>  Service Header (NSH) over UDP protocol.  This enables applications
>>  and services using NSH to communicate over a simple layer-3 network
>>  without topological constraints.  It brings down the barrier to
>>  implement overlay transports by not requiring additional overhead as
>>  is typical of overlay mechanisms designed on top of UDP.
>> 
>>  As a first benefit, this method eases the deployment of Service
>>  Function Chaining (SFC) by allowing SFC components to utilize the
>>  basic UDP/IP stack available in virtually all network elements and
>>  end systems to setup the overlays and realize SFCs.
>> 
>> 
>> 
>> 
>> 
>> 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
>> ------
>> 
>> 
>> On 4/28/15, 10:47 AM, "Surendra Kumar (smkumar)" <smkumar@cisco.com>
>> wrote:
>> 
>>> Thanks Benson, Larry!
>>> 
>>> I will produce a draft for both the UDP port# and the ether-type and
>>> publish it within SFC WG based on the comments so far.
>>> The chairs can move it to the appropriate WG if they think otherwise.
>>> 
>>> Surendra.
>>> 
>>>> On 4/28/15, 12:14 AM, "Benson Schliesser" <bensons@queuefull.net> wrote:
>>>> 
>>>> Hi, Larry and Jim -
>>>> 
>>>> Larry Kreeger (kreeger) wrote:
>>>>> If someone wanted to write a draft specifying how to carry NSH over
>>>>> UDP, what WG would it be submitted to?
>>>> 
>>>> As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example
>>>> of a NSH-capable transport. I think this is a good example of what Jim
>>>> described as a "relevant WG for a given transport".
>>>> 
>>>> But in the case of NSH carried directly in UDP, it seems to me that (as
>>>> Larry described) this is normally described in the protocol document
>>>> itself. Since NSH is intentionally flexible with regards to underlying
>>>> transport, I can imagine this being a companion document rather than
>>>> embedded in the NSH text. But in either case I think it makes the most
>>>> sense for the SFC WG to be the home for such a definition.
>>>> 
>>>> Cheers,
>>>> -Benson
>>>> 
>>>> _______________________________________________
>>>> sfc mailing list
>>>> sfc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>> 
>>> _______________________________________________
>>> sfc mailing list
>>> sfc@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sfc
>