Re: [nvo3] Consensus call on encap proposals

Tom, On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert wrote: > On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas wrote: > > Joe, > > > > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: > >> > >> > >> > >> On 8/9/2016 6:28 PM, Alia Atlas wrote: >

Re: [nvo3] Consensus call on encap proposals

On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas wrote: > Joe, > > On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: >> >> >> >> On 8/9/2016 6:28 PM, Alia Atlas wrote: >> > Joe, >> > >> > In the past 15+ years, I haven't seen this limitation going away. >> >> If you

Re: [nvo3] Consensus call on encap proposals

Joe, On Tue, Aug 9, 2016 at 9:40 PM, Joe Touch wrote: > > > On 8/9/2016 6:28 PM, Alia Atlas wrote: > > Joe, > > > > In the past 15+ years, I haven't seen this limitation going away. > > If you want to base a limitation on a prediction of future hardware, > then do that. > > But

Re: [nvo3] AD review of draft-ietf-nvo3-arch-06

Hi Carlos, Thanks for the input, even if it didn’t make my day ;-). > FWIW, I do not think it is completely appropriate (or useful) for the > (consensus-based) NVO3 Architecture to point to a draft from > a Design Team, not adopted or validated by a WG. Ok, there goes that plan :-(. Some new

Re: [nvo3] HW offload requirements (was Re: Consensus call on encap proposals)

Regards Lizhong On 08/09/2016 22:33, Tom Herbert wrote:On Mon, Aug 8, 2016 at 12:43 AM, Lizhong Jin wrote: > Hi, > With my design experience of NIC and Switch, I prefer VXLAN-GPE. I have the > same concern of HW complicated logic from Fabio,

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Greg, With O bit new encapsulation will Tx them so checking for Oam in receive won't need any hardware changes and very few hardware space and new action of copy and forward to match it, and as its really 100% data it will follow the same hardware pipeline and just on Tx just same oam bit

Re: [nvo3] Consensus call on encap proposals

> On Aug 9, 2016, at 5:55 PM, Lizhong Jin wrote: > > Right, but currently we are discussing which solution is better? Yes, but... > Then it is valuable to consider the existing/potential hardware > implementation, and get pros/cons. Future yes. Existing, no. We those

Re: [nvo3] Consensus call on encap proposals

Right, but currently we are discussing which solution is better? Then it is valuable to consider the existing/potential hardware implementation, and get pros/cons.Regards Lizhong On 08/09/2016 23:56, Joe Touch wrote: FWIW, I don't think we

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Deepak, yours input, experience are very interesting. But doesn't such difference in behavior indicates that HW is not capable of processing entropy in the same manner one can achieve in SW-based (should I assume white-box) solution? If that could be the state of the art, defining behaviors,

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

> Carlos, > > Thanks for the pointer, that looks like a good basis for an extensible > and generic OAM inband measurement mechanism. I assume for IPv6 this > would be appropriate as options in HBH extension headers, have you > defined the formats for that? > > > Thanks — and you are exactly right:

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi, Even in case of Active OAM we need O bit as Overlay splicing or stiching can occur for scalability reason and in that case we need to look inside host payload after overlay de-cap and use it to re-encap to new tunnel and setting the OAM bit and keep the OAM channel deep inside packet. If

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Tom, would add two notes: - being in-band OAM is not exclusively property of iOAM. Active OAM can be in-band if test protocols are treated as data payload (something that all three NVO3 protocols do); - ability to test and/or measure for iOAM limited by presence of the data

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi, Tom, On Aug 9, 2016, at 3:14 PM, Tom Herbert > wrote: On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata) > wrote: On Aug 9, 2016, at 12:28 PM, Tom Herbert

Re: [nvo3] Consensus call on encap proposals

Hi, Patrick, On 8/9/2016 1:02 PM, Patrick Frejborg wrote: > Whoa! > Will indeed have a look on URL you posted, thanks! > > RTP is perhaps the wrong reference, I should have referred the > different overlay tunnels as NVO3 "codecs", the payload inside the > RTP, the audio/video profile

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata) wrote: > >> On Aug 9, 2016, at 12:28 PM, Tom Herbert wrote: >> >> On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky wrote: >>> Hi Tom, >>> many thanks for the most informative

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

> On Aug 9, 2016, at 12:28 PM, Tom Herbert wrote: > > On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky wrote: >> Hi Tom, >> many thanks for the most informative response. I've added mu notes in-line >> under tag GIM>>. >> >> Regards, Greg >> >> On Mon,

Re: [nvo3] [Rtg-ooam-dt] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Dear Greg, On Aug 9, 2016, at 1:22 PM, Greg Mirsky > wrote: Hi Larry, thank you for the most detailed explanation of the choice made for VxLAN-GPE. As experience with MPLS Generic Association Channel shows MPLS does not have an

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Tom, agree, single timestamp may be used as a marker too. But without addition of a sequence number accuracy of your measurement will be affected by packet loss, re-ordering and packet duplication. And I don't think that 32 bits-long timestamp format enables high precision of delay/delay

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

On Tue, Aug 9, 2016 at 9:56 AM, Greg Mirsky wrote: > Hi Tom, > I've read a proposal to apply timestamps to data packets on a fly, I believe > submitted in the SFC WG. I cannot characterize such method as passive as, > per my understanding, it will increase the size of the

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Joe, indeed, I'll continue working on the drafts. Greatly appreciate technical comments and welcome contributions by new authors. Regards, Greg On Tue, Aug 9, 2016 at 8:54 AM, Joe Touch wrote: > Can anyone (Greg in particular, as lead author) explain to me why this > document

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Larry, thank you for the most detailed explanation of the choice made for VxLAN-GPE. As experience with MPLS Generic Association Channel shows, new control, management and OAM functions could be added under the model of the associated channel. And it does allow use of different encapsulations,

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Hi Tom, I've read a proposal to apply timestamps to data packets on a fly, I believe submitted in the SFC WG. I cannot characterize such method as passive as, per my understanding, it will increase the size of the packet to accommodate the timestamps. The advantage of the Alternate Marking method

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky wrote: > Hi Tom, > many thanks for the most informative response. I've added mu notes in-line > under tag GIM>>. > > Regards, Greg > > On Mon, Aug 8, 2016 at 5:44 PM, Tom Herbert wrote: >> >> On Sun, Aug 7,

Re: [nvo3] Consensus call on encap proposals

On 8/8/2016 10:43 PM, Patrick Frejborg wrote: > Hi, > > perhaps we need to take a step back, look on the overall architecture > and see how challenges like this has been solved in the past. www.isi.edu/x-bone > Think > that an NVO3 architecture have many similarities with a communication >

Re: [nvo3] Consensus call on encap proposals

FWIW, I don't think we should be designing ANY protocols in the IETF based solely on the limitations of existing hardware. By the time the doc is issued, this hardware is very likely to be in a recycling bin. Joe On 8/8/2016 12:43 AM, Lizhong Jin wrote: > Hi, > With my design experience of NIC

Re: [nvo3] O-bit vs. OAM as Next Protocol (Re: Consensus call on encap proposals)

Can anyone (Greg in particular, as lead author) explain to me why this document creates an IANA registry for a value that isn't indicated in its header, and why the values in the header (e.g., Msg Type, flags) aren't defined? I.e., this doesn't seem like it proposes much at all... Joe On

[nvo3] HW offload requirements (was Re: Consensus call on encap proposals)

On Mon, Aug 8, 2016 at 12:43 AM, Lizhong Jin wrote: > Hi, > With my design experience of NIC and Switch, I prefer VXLAN-GPE. I have the > same concern of HW complicated logic from Fabio, and additional concern to > GENEVE and GUE is its long size of header. > 1. GENEVE:

[nvo3] more background on consensus

For those of you who might prefer some more nuanced discussion about how the IETF and Routing area do Consensus, you might be interested in watching one of the Routing Area Working Group Chair training sessions that we did about 2 years ago. The wiki that lists all the sessions is at: