Hello Prasad,
Thanks a lot for your review comments.
> 1. The current document talks about both BFD and S-BFD - would it be
> beneficial to make separate documents for BFD and SBFD to maintain
> consistency with the current set of documents.
There are lot less content for S-BFD to be a separate document but we are ok
with this being separate document if WG thinks so.
> 2. Motivation: It would be nice to state the requirements or motivation that
> this draft addresses, i.e. what problems does this draft address that cannot
> be solved using the existing BFD/ SBFD protocol treating the VxLAN as a
> tunnel/ underlay transport transparent to BFD.
We have added use case scenarios which would explain why we need BFD for VXLAN.
As you suggested I also can capture motivation as well in the document.
>I would submit that BFD over
> VxLAN not be treated along the same lines of BFD over MPLS or BFD for PW
> (VCCV) given the differences in the nature of the transport between MPLS
> and VxLAN.
I am not sure if I understood this comment? We not treating VXLAN as MPLS or
BFD VCCV tunnel all we are trying to do is run BFD to monitor VXLAN tunnel.
> 3. Inner Ethernet header: The document does not address the contents of
> the Inner Ethernet header (present after the VxLAN header). This needs to
> be specified.
Since we did not modify the contents of inner Ethernet header we did not
mention that in draft. In NOV3 working group the same question came up and we
will be doing that in next version.
> 4. Destination IP: The document mandates that this needs to be 127/8. What
> disadvantages do you observe if the DIP were to be the IP of the destination
> VTEP? When using 127/8 as the DIP. one problem is that there is no indication
> of the intended DIP of the BFD session by using 127/8. What if the node at
> which the VxLAN tunnel is (prematurely) terminated happens to support
> BFD? It may be better to use the IP address of the Destination VTEP as the
> DIP.
Since this is a tunnel we do not want to the packet to be routed to VTEP if
there is a leak in tunnel. Hence we recommend 127/8 range, the same principle
applies for MPLS as well.
> 5. Inner TTL: For the same reasons discussed in (2), why does the document
> mandate this to be set to 1?
There are two ways to absorb the packet on VTEP's.
1. The above said method where we say set TTL to 1 so that when TTL expires
process the packet locally?
2. Set the inner MAC destination MAC address to VTEP's or dedicated MAC address
so that packet is consumed by VTEP.
> 6. It may be beneficial to run a spell-checker to fix typos in the document.
Hmmm I did this exercise :) will do it again.
Thanks
Santosh P K
> -----Original Message-----
> From: Rtg-bfd [mailto:[email protected]] On Behalf Of Santosh P K
> Sent: Monday, May 04, 2015 10:55 PM
> To: [email protected]
> Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
>
> Hello All,
> A new BFD for VXLAN draft has been submitted. Please do review and get
> back to us with any comments/feedback.
>
> Thanks
> Santosh P K
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Monday, May 04, 2015 9:29 PM
> > To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;
> > Basil Saji; Sudarsan Paragiri Mohan
> > Subject: New Version Notification for
> > draft-spallagatti-bfd-vxlan-00.txt
> >
> >
> > A new version of I-D, draft-spallagatti-bfd-vxlan-00.txt
> > has been successfully submitted by Santosh Pallagatti and posted to
> > the IETF repository.
> >
> > Name: draft-spallagatti-bfd-vxlan
> > Revision: 00
> > Title: BFD for VXLAN
> > Document date: 2015-05-04
> > Group: Individual Submission
> > Pages: 9
> > URL: https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-
> vxlan-
> > 00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
> > Htmlized: https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00
> >
> >
> > Abstract:
> > This document describes use of Bidirectional Forwarding Detection
> > (BFD) protocol for VXLAN . Comments on this draft should be directed
> > to [email protected].
> >
> >
> >
> >
> >
> > 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
