Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt

On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky wrote: > Dear All, > I hope that this new draft (yes, that's what I wanted to send the first > time) will be of interest to those working on overlay encapsulations. > Appreciate your comments, questions, and suggestions. > Regarding OAM in GUE, the C

Re: [nvo3] WG Last Call and IPR Poll for draft-ietf-nvo3-vmm-03.txt

I don't know of any IPR. Tom On Wed, May 30, 2018, 9:10 AM Bocci, Matthew (Nokia - GB) < matthew.bo...@nokia.com> wrote: > This mail starts an IPR poll on > https://www.ietf.org/id/draft-ietf-nvo3-vmm-03.txt in preparation for WG > last call. > > > > Authors and contributors, are you aware of

Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

, if UDP payloads are being modified in the network, then this introduces the possibility of silent corruption when the port number is misinterpreted. Thanks, Tom > Thanks, > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > >> On Apr 21, 2018, at 11:05, Tom Herbert

Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Fri, Apr 20, 2018 at 12:03 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com> wrote: > Tom, > > On Apr 17, 2018, at 10:22 AM, Tom Herbert <t...@herbertland.com> wrote: > > On Tue, Apr 17, 2018 at 12:51 AM, Frank Brockners (fbrockne) > <fbroc...@cisco.com>

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 19, 2018 at 7:47 AM, Frank Brockners (fbrockne) <fbroc...@cisco.com> wrote: > Tom, > > -Original Message----- > From: Tom Herbert <t...@herbertland.com> > Sent: Donnerstag, 19. April 2018 16:32 > To: Frank Brockners (fbrockne) <fbroc...@cisco.

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Wed, Apr 18, 2018 at 12:51 AM, Frank Brockners (fbrockne) <fbroc...@cisco.com> wrote: > Tom, > > inline... ("...FB") > > -Original Message- > From: Tom Herbert <t...@herbertland.com> > Sent: Dienstag, 17. April 2018 16:23 > To: Frank

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

per (e.g. adding an example might help). > > Frank > > -Original Message- > From: Tianran Zhou <zhoutian...@huawei.com> > Sent: Dienstag, 17. April 2018 03:18 > To: Tom Herbert <t...@herbertland.com> > Cc: Shwetha Bhandari (shwethab) <shwet...@cisco.com&

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

ockners > (fbrockne)<fbroc...@cisco.com>;Mickey > Spiegel<mspie...@barefootnetworks.com>;Tom Herbert<t...@herbertland.com> > 抄送： NVO3<nvo3@ietf.org>;int-area<int-a...@ietf.org>;Service Function > Chaining IETF list<s...@ietf.org>;IETF IPPM WG&l

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Fri, Apr 13, 2018 at 11:22 AM, Mickey Spiegel <mspie...@barefootnetworks.com> wrote: > Tom, > > On Thu, Apr 12, 2018 at 10:17 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> Mickey, >> >> Looking at these ippm drafts more closely, I have a muc

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

gt; wrote: > Tom, > > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com> >> wrote: >> > Hi Frank, >> > thank you for sharing your points. Pleas

Re: [nvo3] [ippm] [Int-area] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 3:31 PM, Mickey Spiegel <mspie...@barefootnetworks.com> wrote: > Tom, > > On Thu, Apr 12, 2018 at 2:46 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com>

Re: [nvo3] [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

rockners-ippm-ioam-geneve-00 for instance. > > Regards, > Greg > > On Thu, Apr 12, 2018 at 11:46 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky <gregimir...@gmail.com> >> wrote: >> > Hi Fra

Re: [nvo3] [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky wrote: > Hi Frank, > thank you for sharing your points. Please find my notes in-line and tagged > GIM>>. I believe that this is very much relevant to work of other working > groups that directly work on the overlay encapsulations

Re: [nvo3] [Int-area] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London

On Thu, Apr 12, 2018 at 9:54 AM, Greg Mirsky wrote: > Hi Frank, > thank you for sharing your points. Please find my notes in-line and tagged > GIM>>. I believe that this is very much relevant to work of other working > groups that directly work on the overlay encapsulations

Re: [nvo3] Poll for WG adoption and IPR call for draft-sarikaya-nvo3-vmm-dmm-pmip-11

I support this draft. Tom ___ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

protocol ossifying DPI helps mechanisms like RFS, then ask them to pony up performance numbers to prove it! ;-) Tom > > > Regards > > Lizhong > > > On Sun, May 7, 2017 at 12:32 AM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Sat, May 6, 2

Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01

On Fri, May 19, 2017 at 7:34 AM, Sami Boutros <sbout...@vmware.com> wrote: > > > > > > On 5/19/17, 7:19 AM, "nvo3 on behalf of Tom Herbert" <nvo3-boun...@ietf.org > on behalf of t...@herbertland.com> wrote: > >>On Thu, May 18, 2017 at 10:50 PM,

Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01

On Thu, May 18, 2017 at 10:50 PM, Erik Nordmark <nordm...@sonic.net> wrote: > On 05/18/2017 01:44 PM, Tom Herbert wrote: >> >> On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <nordm...@acm.org> wrote: >>> >>> >>> Tom, >>> >>

Re: [nvo3] Role of control plane in draft-dt-nvo3-encap-01

On Thu, May 18, 2017 at 10:03 AM, Erik Nordmark <nordm...@acm.org> wrote: > > Tom, > > I'm trying to make sure we capture the discussion about the control plane > accurately. > > On 04/15/2017 03:19 PM, Tom Herbert wrote: >> >> - I do not believe this is at

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Mon, May 15, 2017 at 12:02 PM, Joe Touch <to...@isi.edu> wrote: > > > On 5/6/2017 8:24 AM, Tom Herbert wrote: >> Using the entropy in the UDP port number works perfectly well to get >> ECMP or RSS for any UDP encapsulation including Geneve, VXLAN, GUE, >> etc

Re: [nvo3] Review of draft-dt-nvo3-encap-01

- The combinatorics of TLVs and sequential processing requirements are hard to make efficient in both software and hardware implementations. Bit-fields do not have this problem DT: This is not true according to the HW vendors presented in the design team. So the long standing known

Re: [nvo3] Review of draft-dt-nvo3-encap-01

- As I mentioned in a rebuttal to this objection the flag-fields can be extended with for flags. This has already been implemented, the objection is not valid. DT: We are documenting the concerns based on what is already out there – a mailing list rebuttal or how it can be sorted out with “this

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

options (modifiable bit set). They are designed for this purpose, eliminate the need for DPI, and work with any protocol not just a specific UDP encapsulation. Tom > Regards, > Greg > > On Sat, May 6, 2017 at 8:24 AM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Fr

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Sat, May 6, 2017 at 9:15 AM, lizho.jin <lizho@gmail.com> wrote: > Tom, see inline below. > > > Regards > Lizhong > > On 05/6/2017 23:45，Tom Herbert<t...@herbertland.com> wrote： > > On Sat, May 6, 2017 at 8:37 AM, lizho.jin <lizho@gmail.com&

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

hash is reasonably consistent for a flow. The host should never need to reverse engineer the hash a NIC does. Tom > Sorry for the misunderstanding. > > > Regards > Lizhong > > On 05/6/2017 23:24，Tom Herbert<t...@herbertland.com> wrote： > > On Fri, May 5, 2017 at 6:3

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

On Fri, May 5, 2017 at 6:39 PM, lizho.jin <lizho@gmail.com> wrote: > Tom, thanks for the reply, see inline below. > > Regards > Lizhong > > On 05/6/2017 00:14，Tom Herbert<t...@herbertland.com> wrote： > > [Lizhong] Total option length will not solve the pars

Re: [nvo3] One comment for draft-dt-nvo3-encap-01

[Lizhong] Total option length will not solve the parser buffer issue. The parser buffer is located before parser, and for Geneve, implement 512Byte is the only way since the longest of Geneve header is 260Bytes. At least in some implementations as I know, hardware will firstly receive enough

Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

this new text > and whether my suggestion for changing the protocol are acceptable. > Strategic silence does not make problems go away... :-) > > Tom > > On Mon, Mar 27, 2017 at 6:08 AM, Tom Herbert <t...@herbertland.com>; wrote: >> The new section "Constraints on Protocol F

[nvo3] Review of draft-dt-nvo3-encap-01

FWIW here is some feedback on that draft. Comments on sections I looked at indicated by '-'. 2. Design Team Goals As communicated by WG Chairs, the design team should take one of the proposed encapsulations and enhance it to address the technical concerns. Backwards compatibility with

Re: [nvo3] I-D Action: draft-ietf-nvo3-geneve-04.txt

not make problems go away... :-) Tom On Mon, Mar 27, 2017 at 6:08 AM, Tom Herbert <t...@herbertland.com> wrote: > The new section "Constraints on Protocol Features" seems to be punting > the issues that were raised concerning processing of TLVs to a control > plane

Re: [nvo3] Consensus call on Encapsulation Design Team recommendation

On Wed, Apr 5, 2017 at 3:00 AM, Bocci, Matthew (Nokia - GB) wrote: > WG, > > > > During the Thursday NVO3 meeting in Chicago, we tested the sense of the room > to see if there was consensus with the encapsulation design team > recommendation to move forward with

Re: [nvo3] Comments on draft-ietf-nvo3-gue-05

Hi Murray, Thanks for the detailed reviewed! I've cc'ed int-area WG list also since GUE in a WG item there now. A few replies are inline... On Wed, Mar 8, 2017 at 1:07 AM, Murray S. Kucherawy wrote: > Hi all, > > Tom asked me to review this and some related drafts. These

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

>> I agree with that, however there are fewer unknowns to deal with when >> using bit-fields as opposed to TLVs. Once the sender and receiver >> agree on options to be used, with bit-fields the order and length are >> fixed. > > I gave an example above where that's not the case. A value in a

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Thu, Feb 16, 2017 at 4:48 PM, Joe Touch <to...@isi.edu> wrote: > > > On 2/16/2017 4:39 PM, Tom Herbert wrote: >> The operational issues we see with TLVs in terms of performance and >> DDOS are not aberrations, they are fundamental issues we face in >> deployment

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Thu, Feb 16, 2017 at 4:20 PM, Joe Touch <to...@isi.edu> wrote: > Hi Tom, > > > On 2/16/2017 4:10 PM, Tom Herbert wrote: > > But, as I said this idea creates a new dependency on a control plane > which is TBD. I'm afraid this could be a opening a Pandora's box of >

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Thu, Feb 16, 2017 at 3:30 PM, Joe Touch <to...@isi.edu> wrote: > > > On 2/16/2017 3:26 PM, Tom Herbert wrote: >> Admittedly, without any actual TLVs defined in Geneve all of this is >> all just speculation on my part! >> >> Tom > Agreed, and more s

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Thu, Feb 16, 2017 at 1:21 PM, Joe Touch <to...@isi.edu> wrote: > > > On 2/16/2017 1:14 PM, Tom Herbert wrote: >> On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch <to...@isi.edu> wrote: >>> >>> On 2/16/2017 12:27 PM, Tom Herbert wrote: >>>> T

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Thu, Feb 16, 2017 at 1:11 PM, Joe Touch <to...@isi.edu> wrote: > > > On 2/16/2017 12:27 PM, Tom Herbert wrote: >> The problems of TLVs, particularly that they are unordered, require >> iterative processing, > That's trivially avoided by forcing the ord

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

> In the security section you provided text for, we talked about the > possibility of authenticating the tunnel header and payload via extensions > to address concern of spoofing VNI and payload security. Please look at draft-herbert-gue-extensions, that draft realizes the "possibility of

Re: [nvo3] [nvo3-dt-encap] Encap draft published by design team

On Wed, Feb 15, 2017 at 9:36 AM, Sami Boutros wrote: > Hi Tom, > > > >>The Security Considerations section needs content. First and foremost, >>in a multi-tenant data center ensuring strict isolation between >>different tenants traffic seems fundamental and the mechanisms for

Re: [nvo3] Encap draft published by design team

Hi Sam and DT, Thanks for the work. A few comments: >From section 6.6: "...if options are added over time and different subsets of options are likely to be implemented in different pieces of hardware, then it would be hard for the IETF to specify which options should get the early bit fields."

Re: [nvo3] Encap draft published by design team

On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch wrote: > Hi, all, > > I found this document to have useful context for discussion for the most > part. > > Some notes below: > > - it would be useful to provide a summary of the unique requirements of NVO3 > that necessitate a new

Re: [nvo3] Encap draft published by design team

On Thu, Feb 9, 2017 at 9:03 AM, Sam Aldrin wrote: > Hello NVo3 WG, > > NVo3 Design Team for encap has put in quite a bit of effort to meet, discuss > and hashout various requirements and issues and coming up with a draft on > proposed encap. Thanks to all who have

Re: [nvo3] Encap draft published by design team

On Thu, Feb 9, 2017 at 11:42 AM, Joe Touch <to...@isi.edu> wrote: > Hi, Tom, > > > On 2/9/2017 11:33 AM, Tom Herbert wrote: >> On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch <to...@isi.edu> wrote: >>> ... >>> >>> - the discussion o

Re: [nvo3] Encap draft published by design team

On Thu, Feb 9, 2017 at 10:46 AM, Joe Touch wrote: > Hi, all, > > I found this document to have useful context for discussion for the most > part. > > Some notes below: > > - it would be useful to provide a summary of the unique requirements of NVO3 > that necessitate a new

[nvo3] Fwd: New Version Notification for draft-herbert-gue-extensions-01.txt

, 2016 at 2:58 PM Subject: New Version Notification for draft-herbert-gue-extensions-01.txt To: Tom Herbert <t...@herbertland.com>, Lucy Yong <lucy.y...@huawei.com>, "Fred L. Templin" <fltemp...@acm.org> A new version of I-D, draft-herbert-gue-extensions-01.txt has

Re: [nvo3] I-D Action: draft-ietf-nvo3-gue-05.txt

lable from the on-line Internet-Drafts > directories. > This draft is a work item of the Network Virtualization Overlays of the IETF. > > Title : Generic UDP Encapsulation > Authors : Tom Herbert > Lucy Yo

[nvo3] DT and Encapsulation Considerations

As I mentioned in the virtual meeting this morning the "Encapsulation Considerations" document provides list of items that should be considered when designing an encapsulation protocol for IETF. The DT that produced that document included authors from all three nvo3 WG encapsulation proposals and

Re: [nvo3] Update on encapsulation design team

On Mon, Oct 24, 2016 at 5:46 PM, Fabio Maino wrote: > Hi Alia, > please see below. > > On 10/24/16 1:44 PM, Alia Atlas wrote: > > Fabio, > > On Mon, Oct 24, 2016 at 3:54 PM, Fabio Maino wrote: >> >> >> I think it will be useful for the design team to

Re: [nvo3] Review ptC redesign of parts: draft-ietf-nvo3-gue-04

Hi Bob, I think most "redesign" has been discussed in review a (Pta). Just a few comments inline for completeness Thanks, Tom On Sat, Aug 13, 2016 at 6:26 AM, Bob Briscoe wrote: > Tom, Lucy, Osama, > > A) Technical Review of GUE 'As-is' > B) Editorial Review > C)

Re: [nvo3] Review ptA: Technical draft-ietf-nvo3-gue-04

Hi Bob, Thanks for the detailed review. Comments are inline. > > A/ TECHNICAL PROBLEMS/COMMENTS > > 1/ ADDRESSING ARCHITECTURE > > 1.1/ Inferring Connection Semantics: the rule not the exception > > The draft assumes that, as a general rule, the UDP dst. port of a GUE packet > will be fixed

Re: [nvo3] Discussion on encapsulation formats and next steps

and raise objections? Tom > Anoop > > On Thu, Oct 6, 2016 at 2:13 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Thu, Oct 6, 2016 at 1:54 AM, Anoop Ghanwani <an...@alumni.duke.edu> >> wrote: >> > Sam, >> > >> > My lack of i

Re: [nvo3] Discussion on encapsulation formats and next steps

On Thu, Oct 6, 2016 at 1:54 AM, Anoop Ghanwani wrote: > Sam, > > My lack of interest in a new encap is because I think it's too late to > converge them. At this point, there are business issues (as opposed to > technical ones) that would limit the effectiveness of a new

Re: [nvo3] Alignment and Ethernet encapsulation

On Tue, Sep 20, 2016 at 10:55 AM, Joe Touch <to...@isi.edu> wrote: > > > On 9/20/2016 10:47 AM, Tom Herbert wrote: >> On Tue, Sep 20, 2016 at 10:35 AM, Joe Touch <to...@isi.edu> wrote: >>> ... >>> If you've been handed Ethernet to encapsulate, then that

[nvo3] Alignment and Ethernet encapsulation

Hello, This issue came up on the Linux netdev list. The Oracle engineers are trying to deal with the ramifications of unaligned IP headers (not aligned to four bytes) when doing Ethernet encapsulation (VXLAN, GRE with TEB for instance). The problem is that certain CPU architectures, such as SPARC

[nvo3] ILA mobility for next Hackathon

Hello all, I added a project proposal for next Hackathon in Seoul. It would consist in implementing an ILA mobility solution (https://tools.ietf.org/html/draft-mueller-ila-mobility-00). What I am envisioning is that we would emulate at least two carrier networks and demonstrate ILA mobility of

Re: [nvo3] WG last call for draft-ietf-nvo3-use-case-09

I support this draft and believe it is ready for publication. Tom On Tue, Sep 6, 2016 at 3:14 AM, Bocci, Matthew (Nokia - GB) wrote: > This email begins a two week working group last call for > draft-ietf-nvo3-use-case-09.txt. > > > > Please review the draft and post

Re: [nvo3] Consensus call on encap proposals

On Thu, Jul 21, 2016 at 7:56 AM, Bocci, Matthew (Nokia - GB) wrote: > WG > > There was a discussion in the NVO3 WG meeting in Berlin following strong > advice from our Area Director that we need to come to a consensus on > converging on a common encapsulation. Two sets

Re: [nvo3] Extensions in nvo3 encapsulations

Hi Lizhong, thanks for the feedback! Some replies inline. On Fri, Aug 19, 2016 at 8:07 AM, Lizhong Jin wrote: > Hi Tom, > Thank >> Six fundamental extensions have been defined for GUE >> >> 1) VNID (draft-hy-nvo3-gue-4-nvo-03) >> 2) Checksum (draft-herbert-gue-extensions-00)

[nvo3] Extensions in nvo3 encapsulations

Alia has asked that we provide some more information as to what the motivations for extensions are for nvo3 and to what form they should take. Here is some high level explanation with respect to GUE. Six fundamental extensions have been defined for GUE 1) VNID (draft-hy-nvo3-gue-4-nvo-03) 2)

Re: [nvo3] Review ptA: Technical draft-ietf-nvo3-gue-04

Bob, Thanks for the very detailed and insightful comments! It will take a while to got through all of it. I do want to comment first on the extensibility method of GUE since that is the most salient feature relative to other proposals. > 2.8/ Extensibility of the flags and optional fields

Re: [nvo3] Call for interest on NVO3 use case draft

On Fri, Aug 12, 2016 at 9:27 AM, Bocci, Matthew (Nokia - GB) wrote: > WG > > > > As discussed in Berlin, the NVO3 use cases draft > (https://www.ietf.org/id/draft-ietf-nvo3-use-case-08.txt) is reaching > maturity and potentially ready for WG last call. However, there have

Re: [nvo3] Consensus call on encap proposals

On Fri, Aug 12, 2016 at 10:59 AM, Joe Touch <to...@isi.edu> wrote: > > > On 8/12/2016 10:54 AM, Tom Herbert wrote: >> On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch <to...@isi.edu> wrote: >>> >>> On 8/11/2016 4:59 PM, Jesse Gross wrote: >>> >

Re: [nvo3] Consensus call on encap proposals

On Fri, Aug 12, 2016 at 10:21 AM, Joe Touch wrote: > > > On 8/11/2016 4:59 PM, Jesse Gross wrote: > > The most common example given in this area is the use of IP options. At the > time that routing was moving to hardware implementations, options were not > widely used and so were

Re: [nvo3] Consensus call on encap proposals

On Thu, Aug 11, 2016 at 5:20 PM, Alia Atlas wrote: > Jesse, > > It's a question of the benefit of the change versus the cost to modify the > hardware. > Changing one FPGA or ASIC or reprogramming a network processor is > significantly cheaper > than redesigning a system

Re: [nvo3] questions about PMTU discovery and encapsulations

On Thu, Aug 11, 2016 at 5:53 PM, Alia Atlas wrote: > I have been reviewing the three encapsulations and have several comments on > each. > One aspect, however, seems to have not been discussed at all and I would > like to highlight it here. > This primarily applies to Geneve

Re: [nvo3] Consensus call on encap proposals

On Tue, Aug 9, 2016 at 7:41 PM, Alia Atlas <akat...@gmail.com> wrote: > Tom, > > On Tue, Aug 9, 2016 at 10:27 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Tue, Aug 9, 2016 at 6:54 PM, Alia Atlas <akat...@gmail.com> wrote: >> > Joe, >

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] [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)

On Tue, Aug 9, 2016 at 12:02 PM, Carlos Pignataro (cpignata) <cpign...@cisco.com> wrote: > >> On Aug 9, 2016, at 12:28 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Tue, Aug 9, 2016 at 9:07 AM, Greg Mirsky <gregimir...@gmail.com> wrote: >>>

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

timestamp could also be used to measure RTT if it is reflected by the destination end point (like how TCP timestamp is used) Tom > Regards, Greg > > On Tue, Aug 9, 2016 at 9:28 AM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Tue, Aug 9, 2016 at 9:07 AM, Greg M

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 <gregimir...@gmail.com> 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 <t...@herbert

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

there serious technical objections (and specifically what are they) to >> moving forward with GENEVE as the standards-track protocol? >> >> Are there serious technical objections (and specifically what are they) to >> moving forward with GUE as the standards-track protocol? >> >>

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

s technical objections (and specifically what are they) to >> moving forward with GENEVE as the standards-track protocol? >> >> Are there serious technical objections (and specifically what are they) to >> moving forward with GUE as the standards-track protocol? >> &

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

> Tom, > it's more than just infeasibility that should be considered as part of the > technical evaluation, but also the cost/complexity associated with > implementations. > > Encapsulations are not implemented in a vacuum, but compete with other > features for resources available in a given

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

On Wed, Aug 3, 2016 at 3:54 PM, Fabio Maino <fma...@cisco.com> wrote: > On 8/3/16 3:38 PM, Tom Herbert wrote: >> >> On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino <fma...@cisco.com> wrote: >>> >>> On 8/1/16 4:21 PM, Alia Atlas wrote: >>> >

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

On Wed, Aug 3, 2016 at 2:26 PM, Fabio Maino <fma...@cisco.com> wrote: > On 8/1/16 4:21 PM, Alia Atlas wrote: > > > > On Mon, Aug 1, 2016 at 6:35 PM, Tom Herbert <t...@herbertland.com> wrote: >> >> On Mon, Aug 1, 2016 at 2:59 PM, Fabio Maino <fma...@cisco.

Re: [nvo3] GUE extensibility (was Re: Consensus call on encap proposals)

On Fri, Jul 29, 2016 at 5:49 PM, Jesse Gross <jgr...@vmware.com> wrote: > >> On Jul 29, 2016, at 5:16 PM, Tom Herbert <t...@herbertland.com> wrote: >> >>> The only thing that I can say is that over the past several years since the >>> protocol was

Re: [nvo3] GUE extensibility (was Re: Consensus call on encap proposals)

> The only thing that I can say is that over the past several years since the > protocol was defined our experience with this tradeoff has been pretty good. > Both the number of uses of Geneve and implementations have increased and as > time has gone on, the uses have take more advantage of the

Re: [nvo3] GUE extensibility (was Re: Consensus call on encap proposals)

On Fri, Jul 29, 2016 at 3:13 PM, Jesse Gross <jgr...@vmware.com> wrote: > >> On Jul 29, 2016, at 2:59 PM, Tom Herbert <t...@herbertland.com> wrote: >> >>> As a hypothetical question, how would you handle a situation where the >>> security token y

Re: [nvo3] GUE extensibility (was Re: Consensus call on encap proposals)

> As a hypothetical question, how would you handle a situation where the > security token you have defined for GUE is shown to be broken and needs to be > replaced with a new option? I’m sure that in that case, you would feel the > need to react immediately. It seems like the two choices would

Re: [nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

On Fri, Jul 29, 2016 at 12:44 PM, Jesse Gross <jgr...@vmware.com> wrote: > >> On Jul 29, 2016, at 12:17 PM, Fabio Maino <fma...@cisco.com> wrote: >> >> On 7/29/16 11:45 AM, Tom Herbert wrote: >>> On Jul 29, 2016 11:12 AM, "Fabio Maino" <fma..

Re: [nvo3] Consensus call on encap proposals

On Fri, Jul 29, 2016 at 1:34 AM, Naoki Matsuhira wrote: > > > On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote: >> >> WG >> >> There was a discussion in the NVO3 WG meeting in Berlin following strong >> advice from our Area Director that we need to come to a

[nvo3] Security in VXLAN-GPE (was Re: Consensus call on encap proposals)

On Wed, Jul 27, 2016 at 1:15 PM, Fabio Maino <fma...@cisco.com> wrote: > On 7/27/16 12:27 PM, Tom Herbert wrote: >> >> On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino <fma...@cisco.com> wrote: >>> >>> On 7/27/16 10:53 AM, Tom Herbert wrote: >>>&

Re: [nvo3] Consensus call on encap proposals

On Wed, Jul 27, 2016 at 11:00 AM, Fabio Maino <fma...@cisco.com> wrote: > On 7/27/16 10:53 AM, Tom Herbert wrote: >> >> On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci <farina...@gmail.com> >> wrote: >>>> >>>> On Jul 26, 2016, at 3:

Re: [nvo3] Consensus call on encap proposals

On Wed, Jul 27, 2016 at 10:44 AM, Dino Farinacci wrote: >> On Jul 26, 2016, at 3:11 PM, Fabio Maino (fmaino) wrote: >>> >>> On 7/26/16 12:08 PM, Dino Farinacci wrote: > Having VXLAN as an Independent Stream RFC gives a document to be used to >

Re: [nvo3] Consensus call on encap proposals

On Tue, Jul 26, 2016 at 8:33 PM, Xuxiaohu wrote: > I fully agree with Dino's points. Before picking one of the three WG docs as > a candidate to publish, we'd better evaluate whether those already published, > implemented and deployed NVo3 technologies (see below) are good

Re: [nvo3] Consensus call on encap proposals

> I believe that others are in a similar position but opposite with regards to > technical choices. The net result is that there are almost certain to be > multiple formats in the wild regardless of what is decided here. Yes, that > means letting the market decide rather than the IETF. I honestly

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 11:44 AM, "Tom Herbert" <t...@herbertland.com> wrote: > > On Jul 22, 2016 3:38 AM, "Dino Farinacci" <farina...@gmail.com> wrote: > > > > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN p

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 3:38 AM, "Dino Farinacci" wrote: > > > - VXLAN-GPE does not appear compatible with VXLAN-GPE. If a VXLAN host receives a VXLAN packet for some protocol other than Ethern the payload will be misinterpreted. A separate port number was required. I assume that a

Re: [nvo3] Consensus call on encap proposals

On Jul 21, 2016 4:56 PM, "Bocci, Matthew (Nokia - GB)" < matthew.bo...@nokia.com> wrote: > > WG > > There was a discussion in the NVO3 WG meeting in Berlin following strong advice from our Area Director that we need to come to a consensus on converging on a common encapsulation. Two sets of

Re: [nvo3] Consensus call on encap proposals

On Jul 22, 2016 12:13 AM, "Dino Farinacci" wrote: > > > These are data plane functions for ingress/egress processing, which > > already does things like IPsec tunnel mode, IP in IP, IP in UDP in IP, etc. > > All with fix length headers. These packet formats allow the hardware

Re: [nvo3] RTG Dir QA review of draft-ietf-nvo3-gue

>> Yes, security and identifiers are being defined as well known >> extensions. The reason for having a private data section is to allow >> implementations or sites to extend the protocol for their own >> purposes. They may or may not intend standardize. What we don't want >> to happen is that

[nvo3] Fwd: New Version Notification for draft-herbert-gue-extensions-00.txt

;internet-dra...@ietf.org> Date: Tue, Jun 21, 2016 at 11:54 AM Subject: New Version Notification for draft-herbert-gue-extensions-00.txt To: Tom Herbert <t...@herbertland.com>, Lucy Yong <lucy.y...@huawei.com>, "Fred L. Templin" <fltemp...@acm.org> A new version of

Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

On Fri, Jun 17, 2016 at 12:48 AM, Xuxiaohu <xuxia...@huawei.com> wrote: > > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Friday, June 17, 2016 2:57 PM >> To: Xuxiaohu; Tom Herbert >> Cc: nvo3@ietf.org; int-a...@ietf.org

Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

On Thu, Jun 16, 2016 at 2:12 AM, Xuxiaohu <xuxia...@huawei.com> wrote: > > >> -Original Message- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Tom Herbert >> Sent: Saturday, June 11, 2016 1:21 AM >> To: int-a...@ietf.org; nvo3@ietf

[nvo3] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

: <internet-dra...@ietf.org> Date: Fri, Jun 10, 2016 at 10:14 AM Subject: New Version Notification for draft-ietf-nvo3-gue-03.txt To: Tom Herbert <t...@herbertland.com>, Lucy Yong <lucy.y...@huawei.com>, Osama Zia <osa...@microsoft.com> A new version of I-D, draft-ietf-

Re: [nvo3] [Int-area] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.

On Fri, Jun 3, 2016 at 12:38 AM, Xuxiaohu wrote: > > >> -Original Message- >> From: Joe Touch [mailto:to...@isi.edu] >> Sent: Friday, June 03, 2016 12:34 PM >> To: Xuxiaohu; otr...@employees.org >> Cc: Softwires WG; nvo3@ietf.org; int-a...@ietf.org; l...@ietf.org; >>

Re: [nvo3] [Int-area] Is it feasible to perform fragmentation on UDP encapsulated packets.

On Fri, May 27, 2016 at 7:59 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > Hi Tom, > >> -Original Message- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Friday, May 27, 2016 11:06 PM >> To: Xuxiaohu >> Cc: int-a...@ietf.org; Softwir

Re: [nvo3] [Int-area] Is it feasible to perform fragmentation on UDP encapsulated packets.

> The possible side-effect of performing fragmentation on UDP encapsulated > packets is to worsen the reassembly burden on tunnel egress since fragments > of UDP encapsulated packets are more likely to be forwarded across different > paths towards the tunnel egress than those of IP or GRE

  1   2   >