Need for a new protocol should not be based on how hard or easy it is easy to get ethertype or UDP port. That is procedural pain than technical merit. [Lucy] Agree.
I tend to agree with Dino. If NSH could run as a transport client just like any other application, we should do that. Otherwise authors should provide more stronger reasons on why NSH is different and the need for a new protocol. [Lucy] The reason that SFC WG charter explicitly states to work on transport independent SFC protocol is that SFC can be deployed in different transport networks. Having NSH as an application and a transport (L4) client is not efficient for many transport networks and introduce operation complex. Lucy AFAIK, every protocol started off with being lightweight and simple, till new one came up :D Sam Sent from my iPhone > On Nov 5, 2015, at 4:21 PM, Dino Farinacci <[email protected]> wrote: > > As I mentioned at the mic, if NSH runs over UDP/IP, then it can run over > anything. And then every encapsulation spec doesn’t need to special case NSH. > > Like the analogy I used at the mic … why doest’t VXLAN-GPE have a code > point for DNS? ;-) > > Answer: it makes no sense. Run NSH as a transport layer client and it will > work over everything we have already built and has a good chance to work over > anything we will build. > > NSH is no more an overlay than SMTP is for email. > > Dino > >> On Nov 5, 2015, at 4:10 PM, Bottorff, Paul <[email protected]> wrote: >> >> It is definitely a useful option to run directly over Ethernet to allow for >> small scale environments which don’t need NVO3 overlays. >> >> Cheers, >> >> Paul >> >> From: sfc [mailto:[email protected]] On Behalf Of Lucy yong >> Sent: Thursday, November 05, 2015 5:08 AM >> To: Surendra Kumar (smkumar); Alia Atlas >> Cc: [email protected]; Larry Kreeger (kreeger); [email protected] >> Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport >> >> If SFC is deployed in Ethernet network, do we need NSH over Ethernet? >> >> Lucy >> >> From: Surendra Kumar (smkumar) [mailto:[email protected]] >> Sent: Thursday, November 05, 2015 4:12 AM >> To: Alia Atlas; Lucy yong >> Cc: [email protected]; Larry Kreeger (kreeger); [email protected] >> Subject: RE: [sfc] comment on draft-kumar-sfc-nsh-udp-transport >> >> I did go through the process of getting the ethertype for NSH and I also >> have obtained a UDP port# in the past. I have to agree with Alia. >> >> Lucy, >> I appreciate you guys taking a crack at NSH over GRE over UDP nested >> encapsulation. It simply calls for unnecessary overhead and complexity in >> formulating and processing such a packet along the tunnel path. >> >> I admit i have not read your draft yet, will certainly do. >> >> Regard, >> Surendra. >> >> >> >> Sent from a thumb typed device. >> >> >> -------- Original message -------- >> From: Alia Atlas <[email protected]> >> Date: 2015/11/05 6:18 PM (GMT+09:00) >> To: Lucy yong <[email protected]> >> Cc: [email protected], "Larry Kreeger (kreeger)" <[email protected]>, >> [email protected] >> Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport >> >> <no-hats> >> I think that getting a UDP port is a lot more straightforward than an >> Ethertype. >> Not having extra bytes is also an advantage. >> >> Regards, >> Alia >> </no-hats> >> >> On Thu, Nov 5, 2015 at 4:15 AM, Lucy yong <[email protected]> wrote: >> Hi Larry, >> >> The benefit is to avoid working a UDP transport for NSH. >> >> Thanks, >> Lucy >> >> -----Original Message----- >> From: sfc [mailto:[email protected]] On Behalf Of Larry Kreeger >> (kreeger) >> Sent: Thursday, November 05, 2015 1:45 AM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport >> >> Hi Behcet, >> >> I¹m not sure I¹m following what your point is. It is true that VXLAN-GPE >> also adds additional overhead which may not always be needed. Carrying NSH >> directly over UDP avoids that as well. Lucy brought up a new option that I >> had never heard suggested before, which was to carry NSH in GRE over UDP. >> This adds a GRE header in between the UDP header and NSH, but in my opinion >> doesn¹t bring any benefits - just more overhead and complication. >> >> Thanks, Larry >> >>> On 11/5/15, 4:32 PM, "Behcet Sarikaya" <[email protected]> wrote: >>> >>> On Thu, Nov 5, 2015 at 1:10 AM, Larry Kreeger (kreeger) >>> <[email protected]> wrote: >>>> Hi Lucy, >>>> >>>> One of the motivations for carrying NSH directly on UDP is to avoid >>>> unnecessary overhead or complication. Adding the GRE header in >>>> between does not seem to add any additional benefit that I can see >>>> only additional overhead. >>> >>> The point was not with VXLAN-GPE. >>> >>> Behcet >>>> Thanks, Larry >>>> >>>> From: sfc <[email protected]> on behalf of Lucy yong >>>> <[email protected]> >>>> Date: Wednesday, November 4, 2015 at 11:59 PM >>>> To: "[email protected]" <[email protected]> >>>> Subject: [sfc] comment on draft-kumar-sfc-nsh-udp-transport >>>> >>>> There is a gre/udp tunnel transport >>>> (draft-ietf-tsvwg-gre-in-udp-08) that nsh can use for the >>>> transport; just need to register an Ethertype for nsh. >>>> The gre/udp transport provides all features nsh needs with >>>> additional security capability. >>>> >>>> >>>> >>>> Lucy >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sfc >> >> _______________________________________________ >> sfc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
