-----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Friday, November 06, 2015 1:07 AM To: Surendra Kumar (smkumar) <[email protected]>; Dino Farinacci <[email protected]>; Bottorff, Paul <[email protected]> Cc: [email protected]; <[email protected]> <[email protected]>; Lucy Yong <[email protected]>; Alia Atlas <[email protected]>; [email protected]; Larry Kreeger (kreeger) <[email protected]> Subject: Re: [nvo3] [sfc] comment on draft-kumar-sfc-nsh-udp-transport
I am having trouble understanding the conversation. We have a clear agreement that we are not going to standardize on transport for NSH. SK> Is the charter written in stone that it is not amendable, if gaps are found ? And even more that we are not going to pick "one". SK> Charter has a gap here. It is equivalent of designing a car without the wheels. And wheels are not accessories. Surendra. So yes, this draft describes a valid and useful way to transport NSH. there are many such. Yours, Joel On 11/6/15 3:59 AM, Surendra Kumar (smkumar) wrote: > Agree it would run everywhere if NSH is treated as an *application*, as you > point out. > > The conflict is in how NSH wants to be transport independent. It is supposed > to be a feature than violation of layering: proper layering vs. overhead, as > shown below. > > IP-strata | IP | UDP | NSH | > IP-strata | IP | UDP | VXLAN-GPE | IP | UDP | NSH | > > Ignoring, other encapsulation of NSH, carrying NSH directly over UDP does > maintain that layering while removing the overhead. This draft is doing the > right thing. > > Surendra. > > > -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Thursday, November 05, 2015 4:21 PM > To: Bottorff, Paul <[email protected]> > Cc: Lucy Yong <[email protected]>; Surendra Kumar (smkumar) > <[email protected]>; Alia Atlas <[email protected]>; > [email protected]; Larry Kreeger (kreeger) <[email protected]>; > [email protected]; <[email protected]> <[email protected]> > Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport > > 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
