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