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

From: Shahram Davari <[email-masked]>
Date: Thu, 25 Jun 2015 14:47:33 +0000

Hi Santosh,

I think you probably have misunderstood the use of OAM/BFD in general. VXLAN is not a networking layer, rather it is a service demultiplexer (service identifier). I think the misunderstanding might be from the name "VXLAN tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel that has VXLAN as service identifier.

A single IP tunnel can carry many VXLANs.  Not only doing BFD per VXLAN doesn't make sense, but it is also not scalable. My suggestion is do BFD for the IP tunnel and you can achieve what you want.

Thx
Shahram

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

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,
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,
   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,
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,
    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: Santosh P K <[email-masked]>
Date: Fri, 26 Jun 2015 07:19:46 +0000

Hello Shahram,
    Thanks a lot for your comments. Indeed "VXLAN tunnel"  is confusing, what we are trying to do here is address the requirement from draft " https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.txt". Here we have a requirement for running proactive OAM between NV edge to NV edge per VNI. This is an individual draft for now.

Thanks
Santosh P K 

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, June 25, 2015 8:18 PM
> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi);
> MALLIK MUDIGONDA (mmudigon)
> Cc: [email-masked]
> I think you probably have misunderstood the use of OAM/BFD in general.
> VXLAN is not a networking layer, rather it is a service demultiplexer (service
> identifier). I think the misunderstanding might be from the name "VXLAN
> tunnel". Since VXLAN is not a tunnel. The tunnel is actually an IP tunnel that
> has VXLAN as service identifier.
> 
> A single IP tunnel can carry many VXLANs.  Not only doing BFD per VXLAN
> doesn't make sense, but it is also not scalable. My suggestion is do BFD for
> the IP tunnel and you can achieve what you want.
> 
> Thx
> Shahram
> 
> >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.
> 
> >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.
> 
> >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;
> >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).
> 
> >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
> 
> 
> 
> 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
> 
> >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.
> 
> 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.
> 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: "MALLIK MUDIGONDA (mmudigon)" <[email-masked]>
Date: Fri, 26 Jun 2015 07:32:08 +0000

Hi Shahram,

Agree that running a separate session for each VNI is not going to be
scalable. But the current draft only allows implementations to provide
such a functionality. Implementations may choose to run a separate BFD
session for a select set of VNIs (prioritise a select few) and so we do
not want to preclude this possibility. We will leave it to implementations
on which VNIs require this.

May be we can rephrase the following in the draft under Section Deployment
to avoid confusion.

Replace this 

Separate BFD sessions can be established between the VTEPs (IP1 and IP2)
for monitoring each of the VXLAN tunnels (VNI 100 and 200).

With

Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2)
for monitoring each of the VXLAN tunnels (VNI 100 and 200).

Thanks

Regards
Mallik

On 26/06/15 12:49, "Santosh P K" <[email-masked]> wrote:

>Hello Shahram,
>    Thanks a lot for your comments. Indeed "VXLAN tunnel"  is confusing,
>what we are trying to do here is address the requirement from draft "
>https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.tx
>t". Here we have a requirement for running proactive OAM between NV edge
>to NV edge per VNI. This is an individual draft for now.
>
>Thanks
>Santosh P K 
>
>> 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:
>> >(especially source IP)? I understand that outer IP is going to carry
>>the VTEPs
>> addresses.
>> 
>> >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.
>> 
>> 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
>> 
>> 
>> 
>> 5. Inner TTL: For the same reasons discussed in (2), why does the
>>document
>> mandate this to be set to 1?
>>     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
>> 
>> 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.
>> 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:

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 26 Jun 2015 08:47:24 +0000

Hello Shahram/ BFD WG,
A few points to consider:
1. From a layering perspective, I have the following observation to make:
> My suggestion is do BFD for  the IP tunnel and you can achieve what you want.
Equating IP connectivity between the two VTEPs purely in the underlay space may not be the same as having connectivity in the overlay space. In other words, there is considerable merit in running a BFD session over the VxLAN tunnel (using any subset of VNI(s) provisioned by the operator) than running multi-hop BFD between the VTEPs. Kindly clarify if you differ here.
2. One more aspect that will need to be included in future versions of this draft (in my opinion) is the possibility of having multiple BFD sessions between the two VTEPs. Clearly, the zero-discriminator demux followed by the single-hop approach may not work here, but a mechanism is needed to exercise the connectivity tracking of realizable ECMP paths may be very useful. Needless to say, how these paths are discovered is outside the scope of the BFD specification.
Thanks
Prasad

-----Original Message-----
From: MALLIK MUDIGONDA (mmudigon) 
Sent: Friday, June 26, 2015 1:02 PM
To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Agree that running a separate session for each VNI is not going to be scalable. But the current draft only allows implementations to provide such a functionality. Implementations may choose to run a separate BFD session for a select set of VNIs (prioritise a select few) and so we do not want to preclude this possibility. We will leave it to implementations on which VNIs require this.

May be we can rephrase the following in the draft under Section Deployment to avoid confusion.

Replace this 

Separate BFD sessions can be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200).

With

Separate BFD sessions MAY be established between the VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 and 200).

Thanks

Regards
Mallik

On 26/06/15 12:49, "Santosh P K" <[email-masked]> wrote:

>Hello Shahram,
>    Thanks a lot for your comments. Indeed "VXLAN tunnel"  is 
>confusing, what we are trying to do here is address the requirement from draft "
>https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03
>.tx t". Here we have a requirement for running proactive OAM between NV 
>edge to NV edge per VNI. This is an individual draft for now.
>
>Thanks
>Santosh P K
>
>> VXLAN is not a networking layer, rather it is a service demultiplexer 
>>(service  identifier). I think the misunderstanding might be from the 
>>name "VXLAN  tunnel". Since VXLAN is not a tunnel. The tunnel is 
>>actually an IP tunnel that  has VXLAN as service identifier.
>> 
>> A single IP tunnel can carry many VXLANs.  Not only doing BFD per 
>>VXLAN  doesn't make sense, but it is also not scalable. My suggestion 
>>is do BFD for  the IP tunnel and you can achieve what you want.
>> 
>> Thx
>> Shahram
>> 
>> 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.
>> 
>>failure detected at one VM, with Tunnel >BFD session operational, 
>>cannot be  interpreted as peer VM failure.
>> 
>> (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.
>> 
>> 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:
>> 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
>> 
>> 
>> 
>> 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
>> 
>> >1. It is not clear if this draft is addressing both VM to VM and 
>> >VTEP
>>to VTEP
>> 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.
>> 
>> 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
>> >6. Since we are using a destination UDP port of 3784, shouldn't the 
>> >TTL be 255 to be consistent with the RFC 5880?
>> 
>> 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.
>> 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.
>>document  mandate this to be set to 1?
>>     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
>> 
>>Basil Saji;  Sudarsan Paragiri Mohan
>> 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: Shahram Davari <[email-masked]>
Date: Fri, 26 Jun 2015 18:39:10 +0000

Hi Stantosh,

I don't agree with the requirements draft you mentioned. I don't think it is required or makes sense to run OAM for a VNI.

Thx
Shahram

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 12:20 AM
To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Shahram,

Thanks
Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Fri, 26 Jun 2015 18:42:23 +0000

Hi Mallik,

We have been through this route before in other protocols. Such as LM/DM. believe me customers will run OAM for all flows not a subset.
We can't say yes we know it is not scalable, so please don't run too many of them. A better way is define an OAM that can aggregate many
Of these flows. For example run OAM on the IP tunnel.

Thx
Shahram

-----Original Message-----
From: MALLIK MUDIGONDA (mmudigon) [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 12:32 AM
To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Replace this 

With

Thanks

Regards
Mallik

On 26/06/15 12:49, "Santosh P K" <[email-masked]> wrote:

>>(service
>>5884, it
>>inner IP
>>of any
>>an IP
>>destination
>>submission

---

From: Shahram Davari <[email-masked]>
Date: Fri, 26 Jun 2015 18:46:03 +0000

Hi Vengada,

Yes off course I differ.  Please provide an example of a failure that can only be detected by your draft and can't be detected by a BFD on the IP tunnel.

Thx
Shahram

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 1:47 AM
To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory Mirsky
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Shahram/ BFD WG,

-----Original Message-----
From: MALLIK MUDIGONDA (mmudigon) 
Sent: Friday, June 26, 2015 1:02 PM
To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Replace this 

With

Thanks

Regards
Mallik

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 26 Jun 2015 18:50:05 +0000

Hi Shahram,
I think that requirement to support Service-level OAM is practical and well-justified. I agree that when and how Service-level OAM can and will be used by operators depends upon choice of vendors being made.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 11:42 AM
To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Mallik,

We have been through this route before in other protocols. Such as LM/DM. believe me customers will run OAM for all flows not a subset.
We can't say yes we know it is not scalable, so please don't run too many of them. A better way is define an OAM that can aggregate many Of these flows. For example run OAM on the IP tunnel.

Thx
Shahram

-----Original Message-----
From: MALLIK MUDIGONDA (mmudigon) [mailto:[email-masked]]
Sent: Friday, June 26, 2015 12:32 AM
To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Replace this 

With

Thanks

Regards
Mallik

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 26 Jun 2015 18:57:23 +0000

Hi Shahram,
unless monitoring of IP tunnel complemented by e2e Service-level OAM, which is even more questionable since VMs would have less HW support to OAM, ability to run VTEP-VTEP OAM at Service level seems as very strong requirement.

	Regards,
		Greg

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 11:46 AM
To: Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon); Santosh P K; Gregory Mirsky
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Vengada,

Thx
Shahram

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]]
Sent: Friday, June 26, 2015 1:47 AM
To: MALLIK MUDIGONDA (mmudigon); Santosh P K; Shahram Davari; Gregory Mirsky
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hello Shahram/ BFD WG,

-----Original Message-----
From: MALLIK MUDIGONDA (mmudigon)
Sent: Friday, June 26, 2015 1:02 PM
To: Santosh P K; Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Replace this 

With

Thanks

Regards
Mallik