Hi Surendra A better set of "efficient" stacks for illustration I replaced Ip-strata is really some form of L2 or L2 and MPLS. MPLS not shown but could follow the MAC [VLAN]
MAC [VLAN]|NSH| L2 or L3 packet [MAC [VLAN]][MPLS]| IP | UDP | NSH |L2 or L3 packet <- Your Proposal [MAC [VLAN][MPLS]| IP | UDP | VXLAN-GPE]| Inner MAC | NSH| L2 or L3 packet And as we point in our draft out there is synergy in using MAC Chaining and NSH MAC_Chain[VLAN]| NSH| L2 or L3 [MAC [VLAN]] | IP | UDP | VXLAN-GPE]| MAC_Chain | NSH|L2 or L3 Cheers Don > -----Original Message----- > From: sfc [mailto:[email protected]] On Behalf Of Surendra Kumar > (smkumar) > Sent: Friday, November 06, 2015 4:00 AM > To: Dino Farinacci; Bottorff, Paul > Cc: [email protected]; <[email protected]>; Lucy Yong; Alia Atlas; [email protected]; > Larry Kreeger (kreeger) > Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport > > 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 > > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
