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. We have IP and it works, Having NSH as an application and a transport (L4) client is not efficient for many transport networks and introduce operation complex. May be, May be not. That is something to be brought forth to make a strong case for. [Lucy] This was discussed in SFC WG extensively. As a result, SFC WG is charted to work on transport independent SFC protocol. Lucy -sam 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]<mailto:[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]<mailto:[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]<mailto:[email protected]>; Larry Kreeger (kreeger); [email protected]<mailto:[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]<mailto:[email protected]>; Larry Kreeger (kreeger); [email protected]<mailto:[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]<mailto:[email protected]>> Date: 2015/11/05 6:18 PM (GMT+09:00) To: Lucy yong <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>, "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[email protected]>> wrote: On Thu, Nov 5, 2015 at 1:10 AM, Larry Kreeger (kreeger) <[email protected]<mailto:[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]<mailto:[email protected]>> on behalf of Lucy yong <[email protected]<mailto:[email protected]>> Date: Wednesday, November 4, 2015 at 11:59 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ sfc mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
