Lucy, an IP packet can run over *any* transport network. Dino
> On Nov 5, 2015, at 5:28 PM, Lucy yong <[email protected]> wrote: > > > > 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 > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
