Prasad,

>   I think there have been no documents or references cited to establish the
> requirements driving the aspects of Destination IP to be 127/8 (discussed in 4
> below) and inner TTL to be 1 (discussed in 5 below).

Thanks for pointing that. We might have missed that and we can add that. 


> Both these observations led to the comment about the parallels of MPLS/
> PW. I think we may need to discuss the merits/ de-merits about the
> alternate possibilities s of the DIP being the VTEP IP (of the intended BFD
> destination) and the TTL being 255 as well.

Sure. We can discuss on this point. 


Thanks
Santosh P K


> -----Original Message-----
> From: Santosh P K [mailto:[email protected]]
> Sent: Wednesday, May 06, 2015 11:08 AM
> To: Vengada Prasad Govindan (venggovi); [email protected]
> Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
> 
> 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

Reply via email to