Subject: [nvo3] Fwd: New Version Notification for draft-jain-nvo3-overlay-oam-03.txt

From: Diego Garcia del Rio <[email-masked]>
Date: Mon, 16 Mar 2015 18:56:50 -0700

Sorry for the late notification. We have updated the OAM draft that
dicusses the use-case of tunnel testing and the inclusion of a Router-Alert
flag as part of the VXLAN reserved bits.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sat, Mar 7, 2015 at 4:26 PM
Subject: New Version Notification for draft-jain-nvo3-overlay-oam-03.txt
To: Pradeep Jain <[email-masked]>, Vinay Bannai <
[email-masked]>, Diego Garcia del Rio <[email-masked]>, Ravi
Shekhar <[email-masked]>, Kanwar Singh <[email-masked]>,
Wim Henderickx <[email-masked]>, Anil Lohiya <
[email-masked]>

A new version of I-D, draft-jain-nvo3-overlay-oam-03.txt
has been successfully submitted by Diego Garcia del Rio and posted to the
IETF repository.

Name:           draft-jain-nvo3-overlay-oam
Revision:       03
Title:          Generic Overlay OAM and Datapath Failure Detection
Document date:  2015-03-06
Group:          Individual Submission
Pages:          37
URL:
http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-03.txt
Status:
https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/
Htmlized:       http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-03

Abstract:
   This proposal describes a mechanism that can be used to detect Data
   Path Failures of various overlay technologies as VXLAN, NVGRE,
   MPLSoGRE and MPLSoUDP and verifying/sanity of their Control and Data
   Plane for given Overlay Segment.  This document defines the following
   for each of the above Overlay Technologies:

   o  Encapsulation of OAM Packet, such that it has same Outer and
      Overlay Header as any End-System's data going over the same
      Overlay Segment.

   o  The mechanism to trace the Underlay that is exercised by any
      Overlay Segment.

   o  Procedure to verify presence of any given Tenant VM or End-System
      within a given Overlay Segment at Overlay End-Point.

   Even though the present proposal addresses Overlay OAM for VXLAN,
   NVGRE, MPLSoGRE and MPLSoUDP, but the procedures described are
   generic enough to accommodate OAM for any other Overlay Technology.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 23 Mar 2015 16:02:33 +0000

Hi,

In case of this draft

I am seeing that Packet is Tx  with

Transport header + vxlan header (bit to mark identification of OAM, "RA"), (unique DAMC or unique Destination IP again for identification), (OAM specific information).

Whyn't work done in TRILL is used as OAM channel which maps to "Transport header + nvo3 header shim (o bit identifcation, f bit if payload fragment present), Payload fragment (user defined, optional), OAM channel (TRILL).

Now payload fragment doesn't need to be there only required for older hardware where "o" bit punt won't be possible like VXLAN, also this paylaod fragment allows in Inter DC scenario to not terminate the OAM but to reach end to end.

eg:-

L1 ---N/w ---- DC1 ---- DC2---- N/2 ----- L2
                 |
                 L3
In this scenario L1 and L3 are in same DC but L1 and L2 are inter DC and even if NV can terminate on DCI but using payload fragment it can get forward over DCI as normal packet and get terminated on L2 to get host to host real verification in inter DC scenario.
In the solution proposed in draft TLV proposed for 9.1.1 – 9.1.4 is not required if payload fragment is used as payload fragment act as real host information. Also If required multiple level of OAM can be done one which runs L1 to DC1 and another at higher level from L1 to L2.

Other Benefit of TRILL is Path Trace which can interact with underlay to give complete path instead of just ip address of switches in middle also in case of DCI scenario give information regarding the terminating VTEP/NVE interfaces on the DCI switches.

eg:- Underlay device if they understand Nv03 OAM can return

Ingress Information – I.e. Ingress interface and state on which OAM packet in underlay is received
Egress Information- I.e. If same packet is forwarded which path or egress interface it will take
Switch Information – IP address, mgmt ip address, etc.

This allow debug the scenario if underlay is full of ECMP like below

L1--- R1 --- R2 — R3 --- L2

Now Traceroute get success from R1 but failed from R2, we have no way of knowing which path R1 –> R2 will take.

Another thing in this draft is we are trying to use overlay as a control protocol and use TLV to verify the host, instead of keeping the Maintenance point in actual data path of traffic.

Similarly we might want to test the Tx of Encap also in forwarding by sending packet with host information and let forwarding decide how the Nv03 header, Transport Header gets added. In this draft packet is always getting generated from the cpu and no support of verifying Tx forwarding.

Thanks,
Deepak

From: Diego Garcia del Rio <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 16, 2015 8:56 PM
To: <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] Fwd: New Version Notification for draft-jain-nvo3-overlay-oam-03.txt

Sorry for the late notification. We have updated the OAM draft that dicusses the use-case of tunnel testing and the inclusion of a Router-Alert flag as part of the VXLAN reserved bits.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sat, Mar 7, 2015 at 4:26 PM
Subject: New Version Notification for draft-jain-nvo3-overlay-oam-03.txt
To: Pradeep Jain <[email-masked]<mailto:[email-masked]>>, Vinay Bannai <[email-masked]<mailto:[email-masked]>>, Diego Garcia del Rio <[email-masked]<mailto:[email-masked]>>, Ravi Shekhar <[email-masked]<mailto:[email-masked]>>, Kanwar Singh <[email-masked]<mailto:[email-masked]>>, Wim Henderickx <[email-masked]<mailto:[email-masked]>>, Anil Lohiya <[email-masked]<mailto:[email-masked]>>

Name:           draft-jain-nvo3-overlay-oam
Revision:       03
Title:          Generic Overlay OAM and Datapath Failure Detection
Document date:  2015-03-06
Group:          Individual Submission
Pages:          37
URL:            http://www.ietf.org/internet-drafts/draft-jain-nvo3-overlay-oam-03.txt
Status:         https://datatracker.ietf.org/doc/draft-jain-nvo3-overlay-oam/
Htmlized:       http://tools.ietf.org/html/draft-jain-nvo3-overlay-oam-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-jain-nvo3-overlay-oam-03

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Diego Garcia del Rio <[email-masked]>
Date: Tue, 24 Mar 2015 22:54:42 -0500

Hi Deepak,

thanks for the comments. Indeed, I was a bit torn on the use of
non-forwarding headers for the inner payload as it would be good to be able
to use the end-system's IP/MAC to better test the lookup. at the same time,
the use of non-forwardable MAC/IP as specified makes the OAM packet "safer"
in that even older, non RA-bit compliant boxes, would not forward this to
the end-points.

Also, the possibility of using pure IP for the return path allows one to
better diagnose unidirectional link problems/unidirectional encapsulation
problems.

The incorporation of part of the user-payload (the user-payload fragment)
would be interesting, but I am afraid it might make the PDU very very big
and prevent hardware implementations from doing hardware assisted
time-stamps if we include up to 128bytes from the user's payload ahead of
any other OAM headers.

As for the underlay interaction, its always interesting and useful to see,
but since most of the transit swtiches/routers will NOT be vxlan aware, I'd
try my best to add additional requirments there. Today, with a TTL expired
message including most of the user's payload (in this case, the full vxlan
packet), quite a bit of troubleshooting information can be sent back to the
origin.

We can discuss some of these topics tomorrow during the NVO3 session if
you're around.

Best Regards,

On Mon, Mar 23, 2015 at 11:02 AM, Deepak Kumar (dekumar) <[email-masked]>
wrote:

>  Transport header + vxlan header (bit to mark identification of OAM,
> "RA"), (unique DAMC or unique Destination IP again for identification),
> (OAM specific information).
>
>  Whyn't work done in TRILL is used as OAM channel which maps to
> "Transport header + nvo3 header shim (o bit identifcation, f bit if payload
> fragment present), Payload fragment (user defined, optional), OAM channel
> (TRILL).
>
>  Now payload fragment doesn't need to be there only required for older
> hardware where "o" bit punt won't be possible like VXLAN, also this paylaod
> fragment allows in Inter DC scenario to not terminate the OAM but to reach
> end to end.
>
>  eg:-
>
>
> In this scenario L1 and L3 are in same DC but L1 and L2 are inter DC and
> even if NV can terminate on DCI but using payload fragment it can get
> forward over DCI as normal packet and get terminated on L2 to get host to
> host real verification in inter DC scenario.
> In the solution proposed in draft TLV proposed for 9.1.1 – 9.1.4 is not
> required if payload fragment is used as payload fragment act as real host
> information. Also If required multiple level of OAM can be done one which
> runs L1 to DC1 and another at higher level from L1 to L2.
>
>  Other Benefit of TRILL is Path Trace which can interact with underlay to
> give complete path instead of just ip address of switches in middle also in
> case of DCI scenario give information regarding the terminating VTEP/NVE
> interfaces on the DCI switches.
>
>  Another thing in this draft is we are trying to use overlay as a control
> protocol and use TLV to verify the host, instead of keeping the Maintenance
> point in actual data path of traffic.
>
>  Similarly we might want to test the Tx of Encap also in forwarding by
> sending packet with host information and let forwarding decide how the Nv03
> header, Transport Header gets added. In this draft packet is always getting
> generated from the cpu and no support of verifying Tx forwarding.
>
>  Thanks,
> Deepak
>
>   From: Diego Garcia del Rio <[email-masked]>
> To: <[email-masked]>