Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

From: Santosh P K <[email-masked]>
Date: Mon, 4 May 2015 17:24:58 +0000

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-masked] [mailto:[email-masked]]
> 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-masked].
> 
> 
> 
> 
> 
> 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: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 6 May 2015 04:09:53 +0000

Hello Santosh/ Authors,
Thanks for sharing the document, please find a few thoughts below.
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.
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. 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.
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.
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.
5. Inner TTL: For the same reasons discussed in (2), why does the document mandate this to be set to 1?
6. It may be beneficial to run a spell-checker to fix typos in the document.
I request the authors/ WG to comment on the above aspects.
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K 

> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K; 
> Basil Saji; Sudarsan Paragiri Mohan
> has been successfully submitted by Santosh Pallagatti and posted to 
> the IETF repository.
> 
> 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: Santosh P K <[email-masked]>
Date: Wed, 6 May 2015 05:37:45 +0000

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. 

> 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

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wed, 6 May 2015 06:54:51 +0000

Hello Santosh,
  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). 
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.
Thanks
Prasad

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

Hello Prasad,

> 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.

> (VCCV) given the differences in the nature of the transport between 
>MPLS  and VxLAN.

> 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.

> 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.

Thanks
Santosh  P K 
 
>     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
>

---

From: Santosh P K <[email-masked]>
Date: Wed, 6 May 2015 06:58:58 +0000

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

> 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.
> 
> 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 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.
> 
> 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.
> 
> 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.
> 
> 2. Set the inner MAC destination MAC address to VTEP's or dedicated MAC
> address so that packet is consumed by VTEP.
>

---

From: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Wed, 6 May 2015 09:18:27 +0000

Hi Santosh/Authors,

A couple of questions:

  1.  It is not clear if this draft is addressing both VM to VM and VTEP to VTEP verification through BFD. I assume it is both.
  2.  If the VMs are Layer 2 only, then what is the inner IP address (especially source IP)? I understand that outer IP is going to carry the VTEPs addresses.
  3.  Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/104? I understand that it is to avoid the packet being routed but, how can an IP packet addressed to a particular VTEP be consumed by any other node in the network and then route the inner payload?
  4.  The service node’s use case is not very clear. Mat be you can add a little bit of details here.
  5.  I understand that VTEP knows that the packet is to be terminated at the VTEP based on TTL being 1. What about the case of VM to VM BFD? What should be the TTL value here?   Is it 255 or something different? It is hardcoded to “1" in the draft.
  6.  Since we are using a destination UDP port of 3784, shouldn’t the TTL be 255 to be consistent with the RFC 5880?

If you have these covered in the draft already, please point me to the appropriate sections.

Thanks

Regards
Mallik

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 6 May 2015 9:39 am
To: Santosh P K <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Monday, May 04, 2015 9:29 PM
To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;
Subject: New Version Notification for
draft-spallagatti-bfd-vxlan-00.txt
    to [email-masked]<mailto:[email-masked]>.

---

From: Santosh P K <[email-masked]>
Date: Wed, 6 May 2015 09:33:09 +0000

Mallik,
   Thanks for your review comments. 

>1. It is not clear if this draft is addressing both VM to VM and VTEP to VTEP verification through BFD. I assume it is both.

Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 aware) BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of any tunnel. Draft talks about tunnel verification which terminates at VTEP's.

>2. If the VMs are Layer 2 only, then what is the inner IP address (especially source IP)? I understand that outer IP is going to carry the VTEPs addresses. 

As mentioned in the draft it would be outgoing interface IP sending VTEP. 

>3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/104? I understand that it is to avoid the packet being routed but, how can an IP packet addressed to a particular VTEP be consumed by any other node in the network and then route the inner >payload?

The same argument holds true for MPLS as well right? The motivation for using the address range 127/8 is the same as described in Section 2.1 of RFC4379.

>4. The service node's use case is not very clear. Mat be you can add a little bit of details here.

Yes, we can do that. 

>5. I understand that VTEP knows that the packet is to be terminated at the VTEP based on TTL being 1. What about the case of VM to VM BFD? What should be the TTL value here?   Is it 255 or something different? It is hardcoded to "1" in the draft.

VM's will use normal Async BFD so will use TTL 255. 

>6. Since we are using a destination UDP port of 3784, shouldn't the TTL be 255 to be consistent with the RFC 5880? 

Section 7 of RFC 5884 also mentions use of IP TTL set to 1 whereas UDP port number set to 3784. 

Thanks
Santosh P K

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Wednesday, 6 May 2015 9:39 am
To: Santosh P K <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 8 May 2015 07:39:28 +0000

Hello Santosh/ Authors,
Thanks for your prompt considerations of the comments submitted in this thread. I request you to consider the following points for discussion:
1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for OAM layering in NVO3. Though, an individual draft at the moment, I submit that we consider this for providing more context to the discussion here. 
2) Per my understanding of your proposal, the intent is to use BFD for OAM at the NV edge layer. Please let me know if this understanding is incorrect.
3) The clarifications requested earlier this thread concern about the inner IP address (SIP in particular) of the BFD packet . Would they be used from the overlay IP address space (belonging to the tenant). If this is the case, what would the difference between a BFD session using the tenant IP (at the NV edge), a particular VNI, and that of a service layer OAM session that can be run using single-hop BFD (RFC 5880). 
In other words, how can the OAM (BFD in this case) operating at the NV Edge layer operate without using IP from the Tenant layer if the packet is required to be VxLAN encapsulated?
Thanks
Prasad

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2015 3:03 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: Vengada Prasad Govindan (venggovi); [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Mallik,

>2. If the VMs are Layer 2 only, then what is the inner IP address 
>(especially source IP)? I understand that outer IP is going to carry the VTEPs addresses.

Yes, we can do that. 

>6. Since we are using a destination UDP port of 3784, shouldn't the TTL 
>be 255 to be consistent with the RFC 5880?

Thanks
Santosh P K

Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
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
has been successfully submitted by Santosh Pallagatti and posted to the IETF repository.
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: Gregory Mirsky <[email-masked]>
Date: Sat, 9 May 2015 04:46:19 +0000

Hi Santosh, Authors, et. al,
what a great discussion of very interesting work, many thanks to Prasad, Mallik and, of course, Santosh. I'll try not to repeat points they already brought up. Please find my notes below:
*       Introduction:
o       you reference RFC 5880 but don't specify which of defined in BFD base document modes are in scope of this work. I assume that, like in RFC 5884, it is only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode not mentioned. Making more explicit statement would be helpful.
*       section 2:
o       I think that these three cases hardly apply to the proposed solution. In particular, BFD may very coarsely localize path failure as we should remember that path and remote peer failure are undistinguishable. Thus failure detected at one VM, with Tunnel BFD session operational, cannot be interpreted as peer VM failure.
*       section 3:
o       what ensures that reverse direction of the BFD session between IP1 (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets toward the ingress, uses the same tunnel traversed by BFD control packets sent from ingress toward the egress? Perhaps use of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution?
o       Perhaps this section could be the right place to discuss and define behavior of the egress in terms of its role in BFD session:
*       packet encapsulation;
*       failure reporting;
*       path selection (discussed above).
o       And the issues of the encapsulation, reverse path selection are relevant for S-BFD scenario as well (I think that Prasad's suggestion to split into two documents, BFD and S-BFD, is quite reasonable).
*       section 6.1:
o       considering 5884clarification work, can multiple BFD session operate between IP1 and IP2 over the same tunnel?

      Regards,
        Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Friday, May 08, 2015 12:39 AM
To: Santosh P K; MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Santosh/ Authors,

-----Original Message-----
From: Santosh P K [mailto:[email-masked]]
Sent: Wednesday, May 06, 2015 3:03 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: Vengada Prasad Govindan (venggovi); [email-masked]<mailto:[email-masked]>
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Mallik,

Yes, we can do that.

Thanks
Santosh P K

Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Sat, 9 May 2015 06:19:20 +0000

Hello Greg, Prasad and MALLIK,
    Thanks for review comments. I will go through your review comments and get back on this in some time.

Thanks
Santosh P K

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Saturday, May 09, 2015 10:16 AM
To: Vengada Prasad Govindan (venggovi); Santosh P K; MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Santosh, Authors, et. al,
what a great discussion of very interesting work, many thanks to Prasad, Mallik and, of course, Santosh. I'll try not to repeat points they already brought up. Please find my notes below:
*         Introduction:
*         you reference RFC 5880 but don't specify which of defined in BFD base document modes are in scope of this work. I assume that, like in RFC 5884, it is only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode not mentioned. Making more explicit statement would be helpful.
*         section 2:
*         I think that these three cases hardly apply to the proposed solution. In particular, BFD may very coarsely localize path failure as we should remember that path and remote peer failure are undistinguishable. Thus failure detected at one VM, with Tunnel BFD session operational, cannot be interpreted as peer VM failure.
*         section 3:
*         what ensures that reverse direction of the BFD session between IP1 (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets toward the ingress, uses the same tunnel traversed by BFD control packets sent from ingress toward the egress? Perhaps use of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution?
*         Perhaps this section could be the right place to discuss and define behavior of the egress in terms of its role in BFD session:
*         packet encapsulation;
*         failure reporting;
*         path selection (discussed above).
*         And the issues of the encapsulation, reverse path selection are relevant for S-BFD scenario as well (I think that Prasad's suggestion to split into two documents, BFD and S-BFD, is quite reasonable).
*         section 6.1:
*         considering 5884clarification work, can multiple BFD session operate between IP1 and IP2 over the same tunnel?

Regards,
        Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Friday, May 08, 2015 12:39 AM
To: Santosh P K; MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Santosh/ Authors,

-----Original Message-----
From: Santosh P K [mailto:[email-masked]]
Sent: Wednesday, May 06, 2015 3:03 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: Vengada Prasad Govindan (venggovi); [email-masked]<mailto:[email-masked]>
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Mallik,

Yes, we can do that.

Thanks
Santosh P K

Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]<mailto:[email-masked]>
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello All,

Thanks
Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Mon, 25 May 2015 12:36:26 +0000

Prasad,
    Thanks for your review comments. Please see inline comments. 

> 1) Fig 3 of draft-ashwood-nvo3-oam-requirements provides the context for
> OAM layering in NVO3. Though, an individual draft at the moment, I submit
> that we consider this for providing more context to the discussion here.

Sure but how? Do you think having layer diagram in the BFD for VXLAN document and show where it really works? 

> 2) Per my understanding of your proposal, the intent is to use BFD for OAM
> at the NV edge layer. Please let me know if this understanding is incorrect.

Yes that correct BFD will be working at NV edge layer and not at tenant layer. 

> 3) The clarifications requested earlier this thread concern about the inner IP
> address (SIP in particular) of the BFD packet . Would they be used from the
> overlay IP address space (belonging to the tenant). If this is the case, what
> would the difference between a BFD session using the tenant IP (at the NV
> edge), a particular VNI, and that of a service layer OAM session that can be
> run using single-hop BFD (RFC 5880).

We are not using tenant IP address in the inner IP header and we will be using 127/8 range address. I think question was w.r.t inner MAC address which is not clear in the draft. Correct me if I am wrong. 

> In other words, how can the OAM (BFD in this case) operating at the NV Edge
> layer operate without using IP from the Tenant layer if the packet is required
> to be VxLAN encapsulated?

BFD packet should not be routed and hence the use of non-routable address in inner IP address.  With the help of VXLAN header (VNI) we should be able to associate the BFD packet with a tunnel. 

Thanks
Santosh P K 

> >1. It is not clear if this draft is addressing both VM to VM and VTEP to VTEP
> verification through BFD. I assume it is both.
> 
> Draft is applicable only for VTEP to VTEP, for VM to VM (if VM is L3 aware)
> BFD as per RFC 5880/5881 should work as it is. VM's will not be aware of any
> tunnel. Draft talks about tunnel verification which terminates at VTEP's.
> 
> >3. Why is the inner IP destination address 127/8 or 0:0:0:0:0:FFFF:7F00/104?
> I understand that it is to avoid the packet being routed but, how can an IP
> packet addressed to a particular VTEP be consumed by any other node in the
> network and then route the inner >payload?
> 
> The same argument holds true for MPLS as well right? The motivation for
> using the address range 127/8 is the same as described in Section 2.1 of
> RFC4379.
> 
> >5. I understand that VTEP knows that the packet is to be terminated at the
> VTEP based on TTL being 1. What about the case of VM to VM BFD? What
> should be the TTL value here?   Is it 255 or something different? It is
> hardcoded to "1" in the draft.
> 
> tunnel/ underlay transport transparent to BFD. I would submit that BFD over

---

From: Santosh P K <[email-masked]>
Date: Mon, 25 May 2015 12:42:51 +0000

Greg,
   Thanks a lot for your review comments. Please see my inline comments.  

>you reference RFC 5880 but don't specify which of defined in BFD base document modes are in scope of this work. I assume that, like in RFC 5884, it is only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode not mentioned. >Making >more explicit statement would be helpful.

Sure we can add text for Demand mode as well. 

>section 2:
>I think that these three cases hardly apply to the proposed solution. In particular, BFD may very coarsely localize path failure as we should remember that path and remote peer failure are undistinguishable. Thus failure detected at one VM, with Tunnel >BFD session operational, cannot be interpreted as peer VM failure.

I am sorry I did not understand this, can you please elaborate more on this? 

>section 3:
>what ensures that reverse direction of the BFD session between IP1 (ingress) and IP2 (egress) , i.e. egress transmits BFD control packets toward the ingress, uses the same tunnel traversed by BFD control packets sent from ingress toward the egress? >Perhaps use of BFD Reverse Path TLV and BFD Discriminator TLV may be one solution?

In case of IP if reverse path has multiple paths to a destination then taking a particular path means IP header stacking? Correct me if I am wrong.  

>Perhaps this section could be the right place to discuss and define behavior of the egress in terms of its role in BFD session:
>packet encapsulation;
>failure reporting;
>path selection (discussed above).
>And the issues of the encapsulation, reverse path selection are relevant for S-BFD scenario as well (I think that Prasad's suggestion to split into two documents, BFD and S-BFD, is quite reasonable).

If all the above point has different methods for BFD and S-BFD then of course we should spilt the draft in to two. 

>section 6.1:
>considering 5884clarification work, can multiple BFD session operate between IP1 and IP2 over the same tunnel?

I do not see a case where we need multiple BFD session between IP pair when BFD session terminates at VTEP itself. 

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Vengada Prasad Govindan (venggovi)
Sent: Friday, May 08, 2015 12:39 AM
To: Santosh P K; MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
 
Hello Santosh/ Authors,
 
-----Original Message-----
From: Santosh P K [mailto:[email-masked]]
Sent: Wednesday, May 06, 2015 3:03 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: Vengada Prasad Govindan (venggovi); [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
 
Mallik,

 

 

Yes, we can do that. 

 

Thanks
Santosh P K

 
Hello Santosh/ Authors,

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email-masked]
Subject: FW: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt
 
Hello All,
 
Thanks
Santosh P K