Subject: Re: [nvo3] [sfc] comment on draft-kumar-sfc-nsh-udp-transport

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Nov 2015 16:21:27 -0800

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-masked]> 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-masked]] On Behalf Of Lucy yong
> Sent: Thursday, November 05, 2015 5:08 AM
> To: Surendra Kumar (smkumar); Alia Atlas
> Cc: [email-masked]; Larry Kreeger (kreeger); [email-masked]
> 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-masked]] 
> Sent: Thursday, November 05, 2015 4:12 AM
> To: Alia Atlas; Lucy yong
> Cc: [email-masked]; Larry Kreeger (kreeger); [email-masked]
> 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-masked]> 
> Date: 2015/11/05 6:18 PM (GMT+09:00) 
> To: Lucy yong <[email-masked]> 
> Cc: [email-masked], "Larry Kreeger (kreeger)" <[email-masked]>, [email-masked] 
> 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-masked]> wrote:
> Hi Larry,
> 
> The benefit is to avoid working a UDP transport for NSH.
> 
> Thanks,
> Lucy
> 
> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Larry Kreeger (kreeger)
> Sent: Thursday, November 05, 2015 1:45 AM
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]> wrote:
> 
> >On Thu, Nov 5, 2015 at 1:10 AM, Larry Kreeger (kreeger)
> ><[email-masked]> 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-masked]> on behalf of Lucy yong
> >> <[email-masked]>
> >> Date: Wednesday, November 4, 2015 at 11:59 PM
> >> To: "[email-masked]" <[email-masked]>
> >> 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-masked]
> >> https://www.ietf.org/mailman/listinfo/sfc
> >>
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>  
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 5 Nov 2015 16:37:37 -0800

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.

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. 

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-masked]> wrote:
> 
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Fri, 6 Nov 2015 01:28:22 +0000

[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

Sam

Sent from my iPhone

>>>> 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
>>>> 
>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Nov 2015 17:30:56 -0800

Lucy, an IP packet can run over *any* transport network.

Dino

> On Nov 5, 2015, at 5:28 PM, Lucy yong <[email-masked]> wrote:
> 
> 
>

---

From: Lucy yong <[email-masked]>
Date: Fri, 6 Nov 2015 01:34:43 +0000

Lucy, an IP packet can run over *any* transport network.
[Lucy] yes. This dose not justify that SFC run over IP solve all SFC needs.

Lucy  

Dino

>>>>> 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.
>>>>

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 5 Nov 2015 17:35:40 -0800

> [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.

-sam
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sfc <https://www.ietf.org/mailman/listinfo/sfc>

---

From: Lucy yong <[email-masked]>
Date: Fri, 6 Nov 2015 01:50:32 +0000

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

Sam

Sent from my iPhone

On Nov 5, 2015, at 4:21 PM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Like the analogy I used at the mic … why doest’t VXLAN-GPE have a code
point for DNS?  ;-)

Dino

On Nov 5, 2015, at 4:10 PM, Bottorff, Paul <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Paul

Cc: [email-masked]<mailto:[email-masked]>; Larry Kreeger (kreeger); [email-masked]<mailto:[email-masked]>

Lucy

Cc: [email-masked]<mailto:[email-masked]>; Larry Kreeger (kreeger); [email-masked]<mailto:[email-masked]>

Lucy,

Regard,
Surendra.

-------- Original message --------
From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: 2015/11/05 6:18 PM (GMT+09:00)
To: Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>, "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>,
[email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

<no-hats>

Regards,
Alia
</no-hats>

On Thu, Nov 5, 2015 at 4:15 AM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Larry,

Thanks,
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Larry Kreeger
(kreeger)
Sent: Thursday, November 05, 2015 1:45 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

Hi Behcet,

Thanks, Larry

On 11/5/15, 4:32 PM, "Behcet Sarikaya" <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 5, 2015 at 1:10 AM, Larry Kreeger (kreeger)
<[email-masked]<mailto:[email-masked]>> wrote:

Hi Lucy,

Behcet

Thanks, Larry

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Lucy yong
<[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 4, 2015 at 11:59 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

Lucy

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 6 Nov 2015 08:59:41 +0000

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-masked]] 
Sent: Thursday, November 05, 2015 4:21 PM
To: Bottorff, Paul <[email-masked]>
Cc: Lucy Yong <[email-masked]>; Surendra Kumar (smkumar) <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked]; Larry Kreeger (kreeger) <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>
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?  ;-)

Dino

> 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: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 Nov 2015 04:07:00 -0500

I am having trouble understanding the conversation.
We have a clear agreement that we are not going to standardize on 
transport for NSH.
And even more that we are not going to pick "one".

So yes, this draft describes a valid and useful way to transport NSH. 
there are many such.

Yours,
Joel

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Fri, 6 Nov 2015 09:41:58 +0000

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, November 06, 2015 1:07 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Dino Farinacci <[email-masked]>; Bottorff, Paul <[email-masked]>
Cc: [email-masked]; <[email-masked]> <[email-masked]>; Lucy Yong <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked]; Larry Kreeger (kreeger) <[email-masked]>
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.

Yours,
Joel

On 11/6/15 3:59 AM, Surendra Kumar (smkumar) wrote:
> Cc: Lucy Yong <[email-masked]>; Surendra Kumar (smkumar) 
> <[email-masked]>; Alia Atlas <[email-masked]>; 
> [email-masked]; Larry Kreeger (kreeger) <[email-masked]>; 
> [email-masked]; <[email-masked]> <[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Nov 2015 21:36:10 +0900

I'm having problems parsing your text. 

But what I can say is that if NSH is to run over an overlay, then VXLAN can be colocated with an NSH hop, be the next hop, or be many hops away. 

If there is no overlay in the network, NSH doesn't need VXLAN. 

There is no reason to have this coupling. 

When does DNS use VXLAN? Answer: when there is an overlay in the network. When does DNS use MPLS? Answer: when packets traverse a core network with MPLS network. 

That doesn't mean DNS  is spec'ed to run over VXLAN or MPLS. But DNS is transport independent. 

Dino

> On Nov 6, 2015, at 5:59 PM, Surendra Kumar (smkumar) <[email-masked]> wrote:
>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 6 Nov 2015 14:00:48 +0000

> On Nov 6, 2015, at 4:07 AM, Joel M. Halpern <[email-masked]> wrote:
> 

I agree.  It seems that we are trying to solve a problem that doesn't need to be solved.  

If an operator wants to use UDP/NSH in their environment, so be it.  Similarly, if they chose to use VXLAN-GPE or something else, so be it.  NSH doesn't care, and nor should we.

> So yes, this draft describes a valid and useful way to transport NSH. there are many such.
> 
> Yours,
> Joel

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 6 Nov 2015 21:49:04 +0000

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 

> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar
> (smkumar)
> Sent: Friday, November 06, 2015 4:00 AM
> To: Dino Farinacci; Bottorff, Paul
> Cc: [email-masked]; <[email-masked]>; Lucy Yong; Alia Atlas; [email-masked];
> Larry Kreeger (kreeger)
> 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.
> 
> 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.
> 
> 
> <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked];
> Larry Kreeger (kreeger) <[email-masked]>; [email-masked];
> <[email-masked]> <[email-masked]>
> 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.
> 
> 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.
> 
> > 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
> >
> > 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¹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
> >

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 7 Nov 2015 01:36:12 +0000

Don,

I was not proposing anything, just contrasting the packet layout when NSH is purely over IP/UDP. 

Surendra.

-----Original Message-----
From: Fedyk, Don [mailto:[email-masked]] 
Sent: Friday, November 06, 2015 1:49 PM
To: Surendra Kumar (smkumar) <[email-masked]>; Dino Farinacci <[email-masked]>; Bottorff, Paul <[email-masked]>
Cc: [email-masked]; <[email-masked]> <[email-masked]>; Lucy Yong <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked]; Larry Kreeger (kreeger) <[email-masked]>
Subject: RE: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

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

Cheers
Don 

> Cc: [email-masked]; <[email-masked]>; Lucy Yong; Alia Atlas; 
> [email-masked]; Larry Kreeger (kreeger)
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> encapsulation. It simply calls for unnecessary overhead and complexity 
> in formulating and processing such a packet along the tunnel path.
> >
> > I think that getting a UDP port is a lot more straightforward than 
> > an
> Ethertype.
> 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.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 7 Nov 2015 01:51:16 +0000

Inline.

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Friday, November 06, 2015 4:36 AM
To: Surendra Kumar (smkumar) <[email-masked]>
Cc: Bottorff, Paul <[email-masked]>; Lucy Yong <[email-masked]>; Alia Atlas <[email-masked]>; [email-masked]; Larry Kreeger (kreeger) <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>
Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

If there is no overlay in the network, NSH doesn't need VXLAN. 
SK> fully agree, this is the point we have been trying to make as well!

That doesn't mean DNS  is spec'ed to run over VXLAN or MPLS. But DNS is transport independent. 
SK> It is spec'ed to work on IP/UDP, understood and makes sense.

Surendra.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 7 Nov 2015 12:03:44 +0900

> On Nov 7, 2015, at 10:51 AM, Surendra Kumar (smkumar) <[email-masked]> wrote:
> 

It should be spec'ed to work ONLY over UDP/IP. Everything else comes for free (or at the cost of what these NSH packets run over). 

Dino

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 7 Nov 2015 19:06:13 +0000

We had a similar discussion a while back and there was general agreement to purge section 9 from NSH draft to avoid picking transports. Seems like it did not make the last revision. Filed a ticket to track the removal: http://trac.tools.ietf.org/wg/sfc/trac/ticket/17

Regards,
Surendra.

---

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 9 Nov 2015 18:21:42 +0000

All:

Directly over Ethernet is the lowest overhead encapsulation (less than UDP) and does not come for free with the direct over UDP proposal. In addition, supporting NSH over VxLAN is also an L2 encapsulation. Both of these support MAC Chains as in https://datatracker.ietf.org/doc/draft-fedyk-sfc-mac-chain/  as well as NSH tuple match and MPLS forwarding. At very least we would need both direct Ethernet and direct UDP to cover all the proposals.

The NSH header is a tag header used to steer packets to intermediate destinations (which are SFs). The proper layering is between the L2 and L3 headers not at L3 or L4.

Cheers,

Paul

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Friday, November 06, 2015 7:04 PM
To: Surendra Kumar (smkumar)
Cc: Bottorff, Paul; Lucy Yong; Alia Atlas; [email-masked]; Larry Kreeger (kreeger); [email-masked]; <[email-masked]>
Subject: Re: [sfc] comment on draft-kumar-sfc-nsh-udp-transport

Dino