Subject: Re: [sfc] NSH and UDP Transport

From: Jeff Tantsura <[email-masked]>
Date: Tue, 30 Jun 2015 04:23:52 +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) <[email-masked]> 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)" <[email-masked]> 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)" <[email-masked]>
>> 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" <[email-masked]> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>>> 
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc
>