Subject: [nvo3] New draft: Path Detection in VXLAN Overlay Network

From: Dapeng Liu <[email-masked]>
Date: Sun, 21 Jun 2015 01:04:40 +0800

Hello all,

We have submitted a draft for path detection in VXLAN  overlay network. 
http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detection/

The draft proposes a method for path detection in VXLAN network and it defines the path detection packet format by using one reserve bit in the VXLAN header.

Comments & suggestions are welcomed.

-- 
Dapeng Liu

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 Jun 2015 10:21:16 -0400

On Sat, Jun 20, 2015 at 1:04 PM, Dapeng Liu <[email-masked]> wrote:
> The draft proposes a method for path detection in VXLAN network and it
> defines the path detection packet format by using one reserve bit in the
> VXLAN header.
>

"PD (1 bit) - Indicates it is a PD packet and needs to be handled as
specified in this document." This does not seem not forward compatible
since per RFC7348 reserved bits are ignored on receipt. Since the
VXLAN draft purposely is putting valid headers in the VXLAN payload, I
don't see anything that would prevent misinterpretation if such a
packet is sent to a legacy device. Other attempts to extend VXLAN have
hit this same problem, and it is probably also an issue in for nvgre.

Thanks,
Tom

>
> --
> Dapeng Liu
>
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Liyizhou <[email-masked]>
Date: Wed, 24 Jun 2015 01:24:27 +0000

Probably it requires at least the edge nodes to be all upgraded to prevent the leaking to the user. Either the deployment should guarantee that or some mechanism like capability exchange would be used.

IMHO prohibiting any usage of reserved bits is frustrating and goes against the original intention to even having "reserved bits".

Thank,
Yizhou

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Tuesday, June 23, 2015 10:21 PM
To: Dapeng Liu
Cc: [email-masked]
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

On Sat, Jun 20, 2015 at 1:04 PM, Dapeng Liu <[email-masked]> wrote:
> defines the path detection packet format by using one reserve bit in 
> the VXLAN header.
>

"PD (1 bit) - Indicates it is a PD packet and needs to be handled as specified in this document." This does not seem not forward compatible since per RFC7348 reserved bits are ignored on receipt. Since the VXLAN draft purposely is putting valid headers in the VXLAN payload, I don't see anything that would prevent misinterpretation if such a packet is sent to a legacy device. Other attempts to extend VXLAN have hit this same problem, and it is probably also an issue in for nvgre.

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 Jun 2015 22:04:47 -0400

> IMHO prohibiting any usage of reserved bits is frustrating and goes against the original intention to even having "reserved bits".

Indeed it is frustrating. This is precisely why in GUE we require a
receiver do drop any packet with unknown flag bits set-- this avoids
the forward compatibility problem from the get-go.

In any case, this problem should at least be mentioned in the draft
and what steps need to be taken to avoid issues in practice.

Tom

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 29 Jun 2015 13:48:04 +0000

Hi Dapeng Liu,

I support idea of hardware and controller based Path detection and tracking where whole network is OAM capable and packet keeps forwarding in hardware.
I believe you guys presented this solution in ONS summit also.
You should explicitly call out in draft that this solution is not backward compatible and all switches require to be OAM capable in hardware to look at new bit to punt and copy the packet even in underlay.

Thanks,
Deepak

From: Dapeng Liu <[email-masked]<mailto:[email-masked]>>
Date: Saturday, June 20, 2015 at 10:04 AM
To: <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hello all,

--
Dapeng Liu

---

From: Tom Herbert <[email-masked]>
Date: Mon, 29 Jun 2015 08:37:20 -0700

On Mon, Jun 29, 2015 at 6:48 AM, Deepak Kumar (dekumar)
<[email-masked]> wrote:
> Hi Dapeng Liu,
>
> I support idea of hardware and controller based Path detection and tracking
> where whole network is OAM capable and packet keeps forwarding in hardware.
> You should explicitly call out in draft that this solution is not backward
> compatible and all switches require to be OAM capable in hardware to look at
> new bit to punt and copy the packet even in underlay.
>
VXLAN-GPE already defines an OAM bit. If all the hardware needs to be
updated anyway, why not just move to that and avoid having to worry
about the compatibility problem?

Thanks,
Tom

> Thanks,
> Deepak
>
> From: Dapeng Liu <[email-masked]>
> To: <[email-masked]>