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 protected]<mailto:[email protected]>>
Date: Monday, March 16, 2015 8:56 PM
To: <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>>,
Vinay Bannai <[email protected]<mailto:[email protected]>>, Diego Garcia del
Rio <[email protected]<mailto:[email protected]>>, Ravi Shekhar
<[email protected]<mailto:[email protected]>>, Kanwar Singh
<[email protected]<mailto:[email protected]>>, Wim Henderickx
<[email protected]<mailto:[email protected]>>,
Anil Lohiya <[email protected]<mailto:[email protected]>>
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<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
