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 protected]> > 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 protected]> 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 protected]> >> 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 protected]> 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 protected] >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
