Hi Authors,
In NVO3 architecture doc, it specifies that a Tenant System can be a network
appliance system such as firewall. If an NVE (say ingress) receives packets
from an attached TS and need to send them to a Network appliance that is
attached to another NVE (say egress), it is very
Hi All,
GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE defects
for Network Virtualization Overlay (NVO) technology were extensively discussed
on nvo3 mailing list last year
(http://www.ietf.org/mail-archive/web/nvo3/current/msg02779.html) and the
enhancements on VXLAN
Requirements draft? For metadata?
Document id please?
A.
On 10/03/14 16:32, Lucy yong wrote:
Hi All,
GROSS brings a lot of attentions in this IETF meeting. VXLAN and NVGRE defects
for Network Virtualization Overlay (NVO) technology were extensively discussed
on nvo3 mailing list last year
Sorry, Gross in my previous mail means draft-gross-geneve-00.
The metadata is what is described in this draft.
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Anton Ivanov (antivano)
Sent: Monday, March 10, 2014 11:46 AM
To: nvo3@ietf.org
Subject: Re: [nvo3] enhancing VXLAN/NVGRE vs
On 10/03/14 17:04, Lucy yong wrote:
Sorry, “Gross” in my previous mail means draft-gross-geneve-00.
The metadata is what is described in this draft.
That is a ready-baked solution. It is not requirements.
In order to face off GRE, VXLAN, Geneve (and L2TPv3 for that matter) you need
to set the
Lucy,
Thanks for sending this mail. It contains a lot of useful
information.
My understanding is that, if we decide to use a new
encapsulation
- instead of making the simplest changes possible to existing/deployed NVO
encapsulations - we will already be
Hi Authors,
Transit device. A forwarding element along the path of the tunnel.
A transit device MAY be capable of understanding the Geneve frame
format but does not originate or terminate Geneve packets.
Could you give an example of such transit device? I do not call a firewall
device
Hi Lucy,
I am completely against any new encapsulation such as Geneve. We already have 2
deployed solutions, which is more than enough. I think your drafts to enhance
them is the best way forward. Especially the VXLAN enhancement looks very
practical and in my opinion pain-free since it is
On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong lucy.y...@huawei.com wrote:
Hi Authors,
“Transit device. A forwarding element along the path of the tunnel.
A transit device MAY be capable of understanding the Geneve frame
format but does not originate or terminate Geneve packets.”
Why does the header need to indicate how the packet is to be forwarded?
Since the packet is terminated, how to forward it or process it is an
otherwise local decision.
OAM would be better served to be expressed in an EtherType to eliminate
awkward semantics of the bit,
so then all geneve
Please see in-line below w/ [Lucy1]
-Original Message-
From: Tom Herbert [mailto:therb...@google.com]
Sent: Monday, March 10, 2014 3:23 PM
To: Lucy yong
Cc: draft-gross-gen...@tools.ietf.org; nvo3@ietf.org
Subject: Re: [nvo3] question and comment on gross-geneve draft
On Mon, Mar 10,
On Mon, Mar 10, 2014 at 1:29 PM, Lucy yong lucy.y...@huawei.com wrote:
Please see in-line below w/ [Lucy1]
-Original Message-
From: Tom Herbert [mailto:therb...@google.com]
Sent: Monday, March 10, 2014 3:23 PM
To: Lucy yong
Cc: draft-gross-gen...@tools.ietf.org; nvo3@ietf.org
Hi Shahram,
Thank you for voicing up your opinion. Yes, starting a new encapsulation is a
pain for some vendors. Is it not for others? Love to hear feedback on this.
Thanks,
Lucy
From: nvo3 [mailto:nvo3-boun...@ietf.org] On Behalf Of Shahram Davari
Sent: Monday, March 10, 2014 2:02 PM
To: Lucy
Hi Lucy,
It is often preferred to enhance an implementation than design and test a new
one. Also the fact that VXLAN enhancement is backward compatible, means that
existing HW can be reused and does not need to be replaced.
Thx
Shahram
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent:
Hi Tom,
I read this draft. It is interesting proposal. It is indeed another tunneling
encapsulation proposal and aims in applying to NVO as well (not limited to).
Regarding the semantics, it suggests using the flag on the header to indicate
the option field presence in the header. Three flags
On 3/4/14 11:18 PM, Anton Ivanov (antivano) wrote:
The security key portion needs to go to SFC for definition where it
belongs. The security meaning needs are real security use case and
security assessment. Otherwise it is RFC 3514 just expanded to an
arbitrarily large size of [do no] evil. Lots
Snip..
I'm not at all sure. For a layer 2 appliance (e.g., firewall), it suffices for
the destination MAC to be reachable only through the firewall; the NVA can set
up the appropriate address mapping so that the firewall NVE is chosen.
[Lucy] Yes, that is good for ingress NVE. How about egress
Hi Lucy, thanks for the comments!
On Mon, Mar 10, 2014 at 2:51 PM, Lucy yong lucy.y...@huawei.com wrote:
Hi Tom,
I read this draft. It is interesting proposal. It is indeed another
tunneling encapsulation proposal and aims in applying to NVO as well (not
limited to).
Regarding the
From: Lucy yong [mailto:lucy.y...@huawei.com]
Sent: Monday, March 10, 2014 7:29 PM
To: Black, David; draft-ietf-nvo3-dataplane-requireme...@tools.ietf.org
Cc: nvo3@ietf.org
Subject: RE: needed data plane encap requirement in
draft-ietf-nvo3-dataplane-requirements
Snip..
I'm not at all sure. For
I know yoiu referred to SFC earlier.
But I am really m,issing why this is NVO3s problem rather than SFCs.
The topic seems to be precisely matched to the SFC charter and problem
statement.
From where I sit, I expect that the SFC solutions will be applicable to
both domains. That is one of
20 matches
Mail list logo
