The attacks performed on both control plane and data plane should be
considered.
[Zu Qiang] Two questions:
- is there a control plane between TS and NVO3 defined by framework draft or
architecture draft?
- is there any TS data security requirement added in your draft? If yes, which
one can
There was a question on why payload sample is needed in OAM.
Firstly it is an optional field and not always required.
It is expected to be useful when using L2VNI + L3VNI at the same NVE to provide
L3 gateway services to clients on L2VNI. Reference is
draft-ietf-nvo3-dataplane-requirements-02,
HI Tissa:
My understanding of at least one of the proposed NVO3 encaps (VxLAN), is that
the entropy has already been encoded in the source port. I would assume any L3
VNI encap would require a similar property for ECMP to perform useful load
spreading as ECMP would only examine the outer
[Could not finish my question at the open-mic in consideration to fellow IETFrs
behind me]
Author's stand on the metadata from the presentation and responses:
1. Metadata is for innovating and future-proofing
2. Metadata is indeed tied to the transport
3. Metadata will be standardized
Just a clarification, author's stand is that transport provides a way to carry
meta-data.
Let us take NSH example, how would you carry NSH in a protocol that doesn't
have ETYPE for NextProtocol? If you think about it, then it would make sense
that in one way or the other, you would need to
Hi Anton,
What you are describing is header data split which is where a device
splits header and data portions of packet into two buffers so that
data can be page aligned (or as least in a different cache line as you
pointed out). Several NICs have already implemented this with TCP to
split out
HI Tissa:
Thanks for the response and raising a very important point.
At GW NVE , we need L3 information to select the NVE on the L3 cloud to forward
the packet.
Yes. And a GW would need to examine the client payload of frames received from
x-space to determine the L3 destination of
Inline.
From: Pankaj Garg garg.pan...@microsoft.commailto:garg.pan...@microsoft.com
Date: Monday, March 3, 2014 8:43 AM
To: Surendra Kumar smku...@cisco.commailto:smku...@cisco.com,
jgr...@vmware.commailto:jgr...@vmware.com
jgr...@vmware.commailto:jgr...@vmware.com
Cc:
发件人: Zu Qiang [zu.qi...@ericsson.com]
发送时间: 2014年3月3日 23:52
收件人: Zhangdacheng (Dacheng); nvo3@ietf.org
主题: RE: [nvo3] I-D Action: draft-ietf-nvo3-security-requirements-02.txt
The attacks performed on both control plane and data plane should be
considered.
Hi Pankaj,
I think the key point here is that it is one thing to indicate in the transport
encapsulation that metadata is being carried but it is an entirely different
thing to actually carry that metadata in the transport encapsulation itself.
From: Pankaj Garg
Hi David
Please see in-line
From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: Monday, March 03, 2014 8:50 AM
To: Tissa Senevirathne (tsenevir); nvo3@ietf.org
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm
HI Tissa:
Thanks for the response and raising a very important point.
Yves,
Just a minor correction that the following EVPN draft covers both VXLAN and
NVGRE encapsulation for DC applications and it has been around for over a year
with multiple vendors implementing it.
http://tools.ietf.org/id/draft-sd-l2vpn-evpn-overlay-02.txt
I agree with rest of the things
The attacks performed on both control plane and data plane should be
considered.
[Zu Qiang] Two questions:
- is there a control plane between TS and NVO3 defined by framework draft
or architecture draft?
Dacheng: No. In the security requirement work, the control/plane
protection between NVEs
Dacheng: No. In the security requirement work, the control/plane
protection between NVEs and hypervisors are discussed.
[Zu Qiang] this is how it is confused. In the draft you have a statement that
Attacks from malicious TSes and here you explained it means an attack on the
14 matches
Mail list logo
