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.

-----Original Message-----
From: Paul Quinn (paulq) 
Sent: Friday, November 06, 2015 6:01 AM
To: Joel M. Halpern <[email protected]>
Cc: Surendra Kumar (smkumar) <[email protected]>; Dino Farinacci 
<[email protected]>; Bottorff, Paul <[email protected]>; [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


> On Nov 6, 2015, at 4:07 AM, Joel M. Halpern <[email protected]> wrote:
> 
> 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".
> 

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

_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to