Subject: [nvo3] FW: Concerns about NVO3 dataplane requirements document +BFD

From: David Mozes <[email-masked]>
Date: Tue, 3 Nov 2015 04:49:23 +0000

Resend the BFD chain

From: David Mozes
Sent: Saturday, November 08, 2014 11:13 PM
To: Erik Nordmark <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]; Marc Binderberger <[email-masked]>
Subject: Re: [nvo3] Concerns about NVO3 dataplane requirements document +BFD

Erik ,
I agree that is overlay addresses  over what VNI it is running ?

David

On Nov 7, 2014, at 8:35 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>> wrote:
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-masked]]
Sent: Friday, November 07, 2014 8:16 AM
To: David Mozes; Erik Nordmark
Cc: [email-masked]<mailto:[email-masked]>; 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-masked]<mailto:[email-masked]>> 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-masked]] On Behalf Of Erik Nordmark
Sent: Saturday, October 25, 2014 3:45 AM
To: Marc Binderberger; Erik Nordmark; Tom Herbert
Cc: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________

nvo3 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________

nvo3 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nvo3