On 11/7/14 2:23 AM, David Mozes wrote:
Coerced they have MAC and IP configuration see below :
You think these are only overlay address , not underlay ?
David,
Having default IP and MAC addresses wouldn't make any sense for the
underlay. So I think they are overlay addresses.
Erik
Thx
David
“
*BFD Local Configuration:*
*The HSC writes the key-value pairs in the bfd_config_local
column to*
*specifiy the local configurations to be used for BFD sessions on this*
*tunnel.*
**
*bfd_config_local : bfd_dst_mac: optional string*
*Set to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set*
*the MAC expected as destination for received BFD packets.*
**
*bfd_config_local : bfd_dst_ip: optional string*
*Set to an IPv4 address to set the IP address that is expected as*
*destination for received BFD packets. The default is 169.254.1.0.*
**
*BFD Remote Configuration:*
*The bfd_config_remote column is the remote counterpart of the*
*bfd_config_local column. The NVC writes the key-value pairs in this*
*column.*
**
*bfd_config_remote : bfd_dst_mac: optional string*
*Set to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set*
*the destination MAC to be used for transmitted BFD packets. The*
*default is 00:23:20:00:00:01.*
**
*bfd_config_remote : bfd_dst_ip: optional string*
*Set to an IPv4 address to set the IP address used as destination*
*for transmitted BFD packets. The default is 169.254.1.1.*
**
“
*From:*Erik Nordmark [mailto:[email protected]]
*Sent:* Friday, November 07, 2014 8:16 AM
*To:* David Mozes; Erik Nordmark
*Cc:* [email protected]; Marc Binderberger; Tom Herbert
*Subject:* Re: [nvo3] Concerns about NVO3 dataplane requirements
document +BFD
On 11/6/14 10:37 AM, David Mozes wrote:
Sorry regarding the confusion .
However , I referring to BFD on the dataplane
Ah - sorry for being a bit narrow-minded.
My understanding is that BFD is done by having some BFD-over-foo
documents (BFD over IP, BFD over TRILL, etc).
BFD could potential be run (multi-hop) between a pair of VTEP IPs on
the underlay, or one could define a BFD-over-NVO3-dataplane which
specifies how it would be carried as a NVO3 payload.
I think that implies that the NVO dataplane would need to have some
implicit or explicit way to identify that the payload is BFD.
I'm think the VTEP OVSDB BFD parameters does this implicitly since
it defines MAC addresses and IP addresses used to identify the BFD
packets.
Thanks,
Erik
Thx
David
On Nov 6, 2014, at 8:31 PM, "Erik Nordmark" <[email protected]
<mailto:[email protected]>> wrote:
On 11/6/14 1:42 AM, David Mozes wrote:
Hi ,
Recently I saw that in VTEP OVSDB BFD parameters have added .
Is it align to what we are defining here ?
I'm not sure I understand the context. At one of the interim NVO3
meetings the chairs had a slide suggesting the OVSDB (with
associated schemas I assume) could be considered as a potential
NVO3 *controlplane* protocol (I think they listed LISP and OpFlex
on the same slide.)
But this thread is about the *dataplane* protocol. Hence I
confused about the context.
Eruj
Thx
David
-----Original Message-----
From: nvo3 [mailto:[email protected]] On Behalf Of Erik
Nordmark
Sent: Saturday, October 25, 2014 3:45 AM
To: Marc Binderberger; Erik Nordmark; Tom Herbert
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements
document
On 10/22/14 5:20 PM, Marc Binderberger wrote:
To pick up some of the points:
VNI: we live with "flat" IP addresses and yet they support
the rich
structure in the name space. I don't see why this should
be different
with overlay
headers: the control plane (or the configuration) will
know about any
structure and will program the data plane accordingly;
VNIs are then
just a reference numbers (read: flat).
I guess we still need to have some idea how many bits would be
required up front (24, 32, more?) and whether we think this
field needs to be extensible.
QoS: I would consider additional QoS bits in the NVO3
overlay header
as redundant. Either the tenant frame and underlay header
have some
QoS already, then we have the requirement for the data
plane to be
able to map QoS values (probably some small table). Or the
tenant-frame has no QoS - well, sounds like a fixed
mapping then.
OK
Security: could we re-use IPSEC ESP/AH ? In tunnel mode
as we would
add already an underlay IPv4/IPv6 header?
(I'm no expert in this area but why not re-using other
peoples work)
One question is whether the higher assurance is just for the
VNI or for the whole encapsulated frame. Using something like
ESP/AH takes us down the path of protecting the whole frame,
which might be overkill.
ECMP: with leaf-spine topologies in mind and IP as an
underlay I would say
being able to use already existing IP ECMP methods is a
plus to simplify
deployments. I would make it a requirement.
OK
Meta-Data: I probably missed some discussions (sorry!) but
what data would
this be?
As I tried to clarify in my response to Tom the meta-data
discussion in
the IETF was mostly about vendor-specific service meta-data,
but perhaps
this term is being used for more general extensibility?
I think there should be ways to add better assurance
(checksum, keyed
hashes) for the NVO3 header. But perhaps that can be in fixed
fields in
a fixed length header.
In terms of the overall architecture there is a desire to
carry some
service meta-data with frames. The sfc WG is thinking about
doing that
using a separate NSH header.
It would be good for the NVO3 WG to have a clear understanding
of what
data needs to be carried with each encapsulated frame. That helps
determine how flexible and extensible the packet format needs
to be.
The experience with extensibility for protocols that are in the
dataplane (be it IPv4 options, IPv6 extension headers, TRILL
options,
etc) is that they don't tend to get implemented in hardware.
And the
dataplane protocols tend to have a mixture of hardware and
software
implementations - which is different than TCP which is mostly
software.
One observation is that we (the IETF + industry) seems to be
able to
redefine fixed-fields (e.g., IPv4 TOS->DSCP+ECN, MPLS labels
with new
semantics like the entropy label) a lot easier than
implementing new
options or extension headers.
Anyway, it sounds TLV-like and having a variable overhead
length may be a
problem for the overlay MTU. Assuming that this Meta-Data
is orthogonal to
the VNI, would another "MD-ID" field help? The
control-/config plane could
then map this MD-ID to the Meta-Data and program the data
plane accordingly.
One would have to require that the underlay MTU exceeds the
overlay MTU
by the maximum encapsulation overhead. Thus a large max size of
options/extensions has some cost.
I think another point, which was mentioned on the list, is the
fragmentation/reassembly or MTU problem. For simplicity I
would prefer the
NVO3 header has no support for this. If your tenant frame
is IPv4/v6 then
fragmentation/reassembly should happen on this level. For
Ethernet tenant
frames - no idea but I assume Ethernet networks solve the
MTU problem by
"correct configuration"? So the NVO3 "link" would just be
another interface
with an unusual MTU (?).
That seems to be how the hardware encapsulations handle things.
If it was all software on the endpoints then there would be more
options, but for efficiency we typically want to avoid
fragmentation.
The document also mentions the "learning bridge"
behaviour. I would have seen
the details of MAC learning as "control plane" (albeit not
necessarily the
"centralized authority" of the charter). For the data
plane it is a
requirement to punt packets to the control plane. Well,
actually forward the
packet and punt a copy to control plane. I wonder if we
have other
requirement to trigger such a copy/punt? (e.g. an
OAM/alert flag, as
discussed in VXLAN-gpe)
While the option of "learning bridge" behavior might be useful, it
doesn't have anything to do with the dataplane encapsulation
format.
Your question about OAM/alert flags is a good one. I think it
makes
sense to define some flags.
Perhaps we also want a "drop packet if you don't know about
this flags"
flag; in many cases the control plane can be used to determine the
capabilities hence one can avoid sending dataplane packets
with some new
OAM or other feature to endpoints that don't know about it. In
such a
case it is sufficient to have flags that have the "ignore if
you don't
know about it" semantics.
Erik
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
