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

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Sat, 27 Jun 2015 10:40:45 +0000

Hello Shahram,
  I hope you agree to the viewpoint that BFD using the VxLAN tunnel provides more coverage of the datapath than just BFD of the IP tunnel without using VxLAN headers. For example, the typical dataplane encapsulation and decapsulation tables that are consulted in originating/ terminating a VxLAN packet are (typically) a superset of the ones used for IP datapath. Hence, there is value in determining the connectivity between two VTEPs than just plain IP datapath connectivity. In terms of link connectivity monitoring, I agree that BFD over VxLAN and BFD over IP provide the same coverage (between the two VTEPs), but BFD could detect more failures than the ones caused by link. Agreed, that scale and the periodicity of the BFD sessions are aspects that can be different between the two but they are different in scope as well.
Another point that may be of (later) interest is the interworking function that can exist between the server and the client layers, but this may not implications in the dataplane in my opinion.
Thanks
Prasad

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

Greg

Could you please provide an example of VNI to VNI failure or degradation that can't be detected by the IP tunnel OAM. 

Regards,
Shahram

> On Jun 26, 2015, at 11:57 AM, Gregory Mirsky <[email-masked]> wrote:
> 
> 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,
> 
> 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,
> 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
>> 
>>> -----Original Message-----
>>> 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]
>>> Subject: RE: New Version Notification for 
>>> draft-spallagatti-bfd-vxlan-00.txt
>>> 
>>> 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]" <rtg- 
>>> [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: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Sat, 27 Jun 2015 13:59:04 +0000

Hello Shahram,
Please find a few replies inlined with GVP1>. Am glad to discuss this further.
Thanks
Prasad

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

Hi Prasad ,

I don't see how you get more coverage having a VXLAN tag. 

Since you are not testing the VXLAN based VFI/VRF forwarding. By that I mean you are not testing (DA, VXLAN ) or (DIP, VXLAN) forwarding.
GVP1> One of the aspects of the next version of the draft will have a valid inner DIP instead of 127/8. This should help address your concern to an extent.
Also you are not testing the mapping from AC (Attachment Circuit) to a VXLAN tag. 
GVP1> Agreed, this aspect has not (yet) been addressed by RFC5884 as well, not using it as an excuse but I am just noting the precedent here.

In my opinion all you are testing, is that at the other end of an IP Tunnel a specific VXLAN exist or not. Which does not require running continuous BFD.
GVP1> There are specific use-cases (see note about Service Node reachability in Sec 2 of the draft) that require continuous monitoring of some special-purpose VTEPs.

In my opinion this is a very in efficient way of getting that information. The controller should be able to get this information much more efficiently. 

It would be good if you can provide an example of what you think is more coverage than BFD. Or at least what extra coverage do you exactly have in mind, since this draft is not capable of more coverage than standard BFD over the IP tunnel. 

Regards,
Shahram

> On Jun 27, 2015, at 3:40 AM, Vengada Prasad Govindan (venggovi) <[email-masked]> wrote:
> 
> Hello Shahram,
> Cc: Shahram Davari; Vengada Prasad Govindan (venggovi); MALLIK 
> MUDIGONDA (mmudigon); Santosh P K; [email-masked]
>>>> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan 
>>>> (venggovi); MALLIK MUDIGONDA (mmudigon)
>>>> Cc: [email-masked]
>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of 
>>>> Santosh P K
>>>> 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.
>>>> 
>>>> particular, BFD may very coarsely localize path failure as we 
>>>> should remember that path and remote peer failure are undistinguishable.
>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of 
>>>> Vengada Prasad Govindan (venggovi)
>>>> 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.
>>>> 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 
>>>> NV Edge  layer operate without using IP from the Tenant layer if 
>>>> the packet is required  to be VxLAN encapsulated?
>>>> Thanks
>>>> Prasad
>>>> 
>>>>> 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?
>>>> 
>>>> 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.
>>>> 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.
>>>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of 
>>>> Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Sat, 27 Jun 2015 14:53:45 +0000

Hi

May be a better way to make this clear is to answer the following question:

Where is the VXLAN tag information used in this BFD forwarding? 

Thx
Shahram

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 29 Jun 2015 10:10:48 +0000

Hello Shahram,
  At the terminating VTEP, VxLAN information is used to consume the BFD packet. In other words, a BFD session increases the confidence of the existence of the VNI-Forwarding Domain mapping and the presence of valid VTEP termination configuration at the terminating VTEP. At the originating VTEP, it is a matter of implementation of how many VxLAN tables are exercised in the datapath (am aware of at least one implementation where it is being exercised to a considerable extent).

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jun 2015 17:39:03 +0000

Hi Prasad,

Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since standard BFD processing does no care where the BFD came from it only looks at "your discriminator" to update BFD state machine.

Also I don't see how many VXLANs can be checked via a single BFD session. Could you please describe?

Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should not require BFD. Just use some query mechanism. Why do you need to run continuous BFD.

What you have to show me to convince me that your draft solves a real problem is to show that VXLAN tag  is  used for BFD forwarding. Otherwise BFD over the outer or Inner IP should give you all coverage needed.

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 29 Jun 2015 20:51:06 +0000

Hi Shahram,
thank you for your comments to this proposal that make the discussion so much alive.
I think that processing of the VXLAN tag by VTEP before validating BFD is sufficient, in my view, level of verification. In VCCV BFD the PW label is not used for BFD forwarding but we find it useful as Service OAM in addition to RFC 5884, BFD over MPLS LSP.

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jun 2015 21:02:20 +0000

Hi Greg,

You are welcome. Could you please clarify which one of the following is the packet format:

1) OuterL2-Outer IP-UDP-VXLAN-Inner L2-Inner IP-UDP-BFD

Or

2) OuterL2-Outer IP-UDP-VXLAN-Inner IP-UDP-BFD

If (2) hen how do you specify the VXLAN payload in IP and not Ethernet?

Also This is different from PW BFD, since in case of PW, there can be MS-PW, where the LSP BFD is not end-to-end. But in this case we don't have MS-VXLAN.
So the span of the VXLAN and the IP tunnel is the same. 

In other words you have to specify in which part of forwarding the BFD the VXLAN Tag is used. If it is not used then it has no effect.

Thx
Shahram

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

Hi Shahram,

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 29 Jun 2015 21:20:33 +0000

Hi Shahram,
I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True, we have case of MS-PW where PW label used (that was discussed in MPLS-TP in particular). But that doesn't mean that VCCV BFD has value only for MS-PW and for SS-PW has no value. Would you agree?

	Regards,
		Greg

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

Hi Greg,

Or

Thx
Shahram

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

Hi Shahram,

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jun 2015 23:14:54 +0000

Hi Greg,

I don't see much value in running BFD for SS-PW compared to running BFD over the LSP. 

Thx
SD

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

Hi Shahram,

	Regards,
		Greg

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

Hi Greg,

Or

Thx
Shahram

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

Hi Shahram,

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 29 Jun 2015 23:32:53 +0000

Hi,

Another question I have is how do you forward these BFD packets from VTEP to VM? Since DIP = 127/8, I assume there is no way to forward such packets past the VTEP.

If you want to do VM to VM connectivity check then I suggest one of the following:

1) if VMs are only L2 aware and VXLAN is L2VPN, the run Ethernet OAM between VMs
2) If VMs are L2 and L3 aware and VXLAN is L2VPN then run BFD over IP/UDP over Ethernet over VXLAN
3) If VMs are L3 aware and VXLAN is L3VPN then you have 2 cases:
          3a) If VTEP and VMs are physically  in the same CPU core then run what you are proposing in this draft (1-hop BFD). Although it should give you same result as running BFD over the outer IP tunnel
          3b) If VTEP and VMs are physically separate (such as VTEP is in TOR and VM is CPU core), then run something similar to what you are proposing but with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP.

I think this draft covers just (3a) and in such case it is pretty much equivalent of running BFD over the outer IP tunnel, since the span of both BFDs are the same and VXLAN is not used for forwarding for BFD processing.

Thx
Shahram

Thx
Shahram

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, June 29, 2015 4:15 PM
To: Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Greg,

Thx
SD

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

Hi Shahram,

	Regards,
		Greg

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

Hi Greg,

Or

Thx
Shahram

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

Hi Shahram,

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 30 Jun 2015 00:10:28 +0000

Hi Shahram,
that may or may not be the case for the proposal we're discussing. I think that operators and time will tell us.

	Regards,
		Greg

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

Hi Greg,

Thx
SD

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

Hi Shahram,

	Regards,
		Greg

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

Hi Greg,

Or

Thx
Shahram

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

Hi Shahram,

	Regards,
		Greg

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

Hi Prasad,

Thx
Shahram

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

Hello Shahram,

Thanks
Prasad

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

Hi

Thx
Shahram

---

From: "S. Davari" <[email-masked]>
Date: Sun, 28 Jun 2015 22:18:25 -0700

Hi

What is a service node?

Thx

Sd

Regards,
Shahram

> On Jun 27, 2015, at 7:06 AM, Shahram Davari <[email-masked]> wrote:
> 
> Hi Prasad ,
>

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Mon, 29 Jun 2015 10:11:57 +0000

By the definition of this draft, a service node is a VTEP designated to perform certain special functionality e.g. handling BUM traffic.
Thanks
Prasad

From: Shahram Davari [mailto:[email-masked]]
Sent: Saturday, June 27, 2015 7:36 PM
To: Vengada Prasad Govindan (venggovi)
Cc: S. Davari; Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

What is a service node?

Regards,
Shahram

On Jun 27, 2015, at 6:59 AM, Vengada Prasad Govindan (venggovi) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Shahram,
Please find a few replies inlined with GVP1>. Am glad to discuss this further.
Thanks
Prasad

-----Original Message-----
From: S. Davari [mailto:[email-masked]]
Sent: Saturday, June 27, 2015 6:46 PM
To: Vengada Prasad Govindan (venggovi)
Cc: Gregory Mirsky; Shahram Davari; MALLIK MUDIGONDA (mmudigon); Santosh P K; [email-masked]<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Prasad ,

Regards,
Shahram

On Jun 27, 2015, at 3:40 AM, Vengada Prasad Govindan (venggovi) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Shahram,

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

Greg

Regards,
Shahram

On Jun 26, 2015, at 11:57 AM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram,

 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>> wrote:

Hello Shahram,
https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement
-

Thanks
Santosh P K

-----Original Message-----
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]<mailto:[email-masked]>
Subject: RE: New Version Notification for
draft-spallagatti-bfd-vxlan-00.txt

Hi Santosh,

Thx
Shahram

-----Original Message-----
Cc: [email-masked]<mailto:[email-masked]>

Greg,

section 2:

section 3:

Perhaps this section could be the right place to discuss and
define
behavior

section 6.1:

Thanks
Santosh P K

-----Original Message-----
Cc: [email-masked]<mailto:[email-masked]>

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

Mallik,

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.

Yes, we can do that.

Thanks
Santosh P K

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]>" <rtg-
[email-masked]<mailto:[email-masked]>>
Subject: RE: New Version Notification for
draft-spallagatti-bfd-vxlan-00.txt

Hello Santosh/ Authors,

-----Original Message-----
To: [email-masked]<mailto:[email-masked]>

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;
 to [email-masked]<mailto:[email-masked]>.
tools.ietf.org<http://tools.ietf.org>.
The IETF Secretariat

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 09:07:41 +0000

Shahram,
    
> If (2) hen how do you specify the VXLAN payload in IP and not Ethernet?

It is 1) we have next version of this draft which address that part. 

Thanks
Santosh P K 

> I think that processing of the VXLAN tag by VTEP before validating BFD is
> sufficient, in my view, level of verification. In VCCV BFD the PW label is not
> used for BFD forwarding but we find it useful as Service OAM in addition to
> RFC 5884, BFD over MPLS LSP.
> 
> 	Regards,
> 		Greg
> 
> Is this a special type of BFD or standard BFD RFC 5880 and 5881)? Since
> standard BFD processing does no care where the BFD came from it only looks
> at "your discriminator" to update BFD state machine.
> 
> Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP should
> not require BFD. Just use some query mechanism. Why do you need to run
> continuous BFD.
> 
> What you have to show me to convince me that your draft solves a real
> problem is to show that VXLAN tag  is  used for BFD forwarding. Otherwise
> BFD over the outer or Inner IP should give you all coverage needed.
> 
> 
> Thx
> Shahram
> 
> 
> 
> 
>   At the terminating VTEP, VxLAN information is used to consume the BFD
> packet. In other words, a BFD session increases the confidence of the
> existence of the VNI-Forwarding Domain mapping and the presence of valid
> VTEP termination configuration at the terminating VTEP. At the originating
> VTEP, it is a matter of implementation of how many VxLAN tables are
> exercised in the datapath (am aware of at least one implementation where it
> is being exercised to a considerable extent).
> 
> Thanks
> Prasad
> 
> Cc: Vengada Prasad Govindan (venggovi); Gregory Mirsky; MALLIK

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 09:12:48 +0000

> Another question I have is how do you forward these BFD packets from VTEP
> to VM? Since DIP = 127/8, I assume there is no way to forward such packets
> past the VTEP.

We don't want to send it past VTEP as BFD will terminate at VTEP itself. Right now use of 127/8 is not really clear as inner IP address. We have again added some text for inner IP address and its use. 

>           3a) If VTEP and VMs are physically  in the same CPU core then run what
> you are proposing in this draft (1-hop BFD). Although it should give you same
> result as running BFD over the outer IP tunnel
>           3b) If VTEP and VMs are physically separate (such as VTEP is in TOR and
> VM is CPU core), then run something similar to what you are proposing but
> with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP.
> 

We are not trying to address VM to VM connectivity check as I believe that does not really need any changes and BFD as it is should run. Proposal is from VTEP to VTEP.

Thanks
Santosh P K 

> I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. True,
> we have case of MS-PW where PW label used (that was discussed in MPLS-
> TP in particular). But that doesn't mean that VCCV BFD has value only for MS-
> PW and for SS-PW has no value. Would you agree?
> 
> 	Regards,
> 		Greg
> 
> Also This is different from PW BFD, since in case of PW, there can be MS-PW,
> where the LSP BFD is not end-to-end. But in this case we don't have MS-
> VXLAN.
> In other words you have to specify in which part of forwarding the BFD the
> VXLAN Tag is used. If it is not used then it has no effect.
> 
> Thx
> Shahram
>

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 09:14:10 +0000

There can be few VTEPs who might have capabilities to multicast the packet. In such a scenario VTEP will send that packet to service node and service node will do a multicast on its behalf.

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of S. Davari
Sent: Monday, June 29, 2015 10:48 AM
To: Shahram Davari; [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

On Jun 27, 2015, at 7:06 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Prasad ,

Regards,
Shahram

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 30 Jun 2015 16:10:22 +0000

Hello Shahram,
  As Santosh mentions below, a revision of this draft will be published shortly mandating the use of a valid inner Destination IP address in the packet.
Thanks
Prasad

-----Original Message-----
From: Santosh P K [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2015 2:43 PM
To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

> Another question I have is how do you forward these BFD packets from 
> VTEP to VM? Since DIP = 127/8, I assume there is no way to forward 
> such packets past the VTEP.

> 
> If you want to do VM to VM connectivity check then I suggest one of 
> the
> following:
> 
>           3a) If VTEP and VMs are physically  in the same CPU core 
> then run what you are proposing in this draft (1-hop BFD). Although it 
> should give you same result as running BFD over the outer IP tunnel
>           3b) If VTEP and VMs are physically separate (such as VTEP is 
> in TOR and VM is CPU core), then run something similar to what you are 
> proposing but with Multi-hop DIP address so that BFD can be forwarded to VM from VTEP.
> 

Thanks
Santosh P K 

> I'll get to VXLAN shorty but wanted to ask quick question about SS-PW. 
> True, we have case of MS-PW where PW label used (that was discussed in 
> MPLS- TP in particular). But that doesn't mean that VCCV BFD has value 
> only for MS- PW and for SS-PW has no value. Would you agree?
> 
> 	Regards,
> 		Greg
> 
> Also This is different from PW BFD, since in case of PW, there can be 
> MS-PW, where the LSP BFD is not end-to-end. But in this case we don't 
> have MS- VXLAN.
> In other words you have to specify in which part of forwarding the BFD 
> the VXLAN Tag is used. If it is not used then it has no effect.
> 
> Thx
> Shahram
> 
> I think that processing of the VXLAN tag by VTEP before validating BFD 
> is sufficient, in my view, level of verification. In VCCV BFD the PW 
> label is not used for BFD forwarding but we find it useful as Service 
> OAM in addition to RFC 5884, BFD over MPLS LSP.
> 
> 	Regards,
> 		Greg
> 
> Is this a special type of BFD or standard BFD RFC 5880 and 5881)? 
> Since standard BFD processing does no care where the BFD came from it 
> only looks at "your discriminator" to update BFD state machine.
> 
> Lastly checking to see a VXLAN/VNI forwarding domain exist in a VTEP 
> should not require BFD. Just use some query mechanism. Why do you need 
> to run continuous BFD.
> 
> problem is to show that VXLAN tag  is  used for BFD forwarding. 
> Otherwise BFD over the outer or Inner IP should give you all coverage needed.
> 
> 
> Thx
> Shahram
> 
> 
> 
> 
>   At the terminating VTEP, VxLAN information is used to consume the 
> BFD packet. In other words, a BFD session increases the confidence of 
> the existence of the VNI-Forwarding Domain mapping and the presence of 
> valid VTEP termination configuration at the terminating VTEP. At the 
> originating VTEP, it is a matter of implementation of how many VxLAN 
> tables are exercised in the datapath (am aware of at least one 
> implementation where it is being exercised to a considerable extent).
> 
> Thanks
> Prasad
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jun 2015 16:22:34 +0000

Santosh,

But your draft says:

" BFD session can be used to run between VM's for VM's connectivity check:"

So, which one is it? VTEP-to-VTEP or VM- to-VM?

Also what is the MAC-DA of inner Ethernet header?

Thx
Shahram

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

Thanks
Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jun 2015 16:30:59 +0000

What kind of lookup happens in these service nodes? Do you do (inner DA, VXLAN/VNI) lookup? Do you keep the VXLAN or do you change it to new VXLAN? Where is this service node operation specified?

Thx
SD

From: Santosh P K [mailto:[email-masked]]
Sent: Tuesday, June 30, 2015 2:14 AM
To: S. Davari; Shahram Davari; [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of S. Davari
Sent: Monday, June 29, 2015 10:48 AM
To: Shahram Davari; [email-masked]<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jun 2015 16:34:33 +0000

Hi,

You can do (1) today. Why do you need a standard?

Thx
Shahram

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

Shahram,

Thanks
Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jun 2015 16:56:18 +0000

Hi,

Assuming you want to do VTEP-to-VTEP connectivity, The only way that I think this draft can provide extra information compared to running BFD over the outer IP tunnel, is when the Inner MAC-DA is the MAC-DA of the VTEP port that connects to the VM. In such case the packet will exercise the VXLAN/VNI forwarding (DA, VXLAN/VNI) and then the inner L2 is terminated at the VTEP port connecting VTEP to VM and BFD is extracted and processed. Basically some kind of UP-MEP on the VTEP.

This can be extended to VM-to-VM connectivity by setting he DA of inner L2 to the MAC address of the VM. 

In both these cases I don't think any standard is needed. It is just running 1-hop BFD over L2, which happens to be carried over VXLAN.

Thx
SD

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Tuesday, June 30, 2015 9:23 AM
To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Santosh,

But your draft says:

Thx
Shahram

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

Thanks
Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 17:19:31 +0000

Shahram,
    Thanks for your comments.

> So, which one is it? VTEP-to-VTEP or VM- to-VM?

There had been confusion on how the use case was written in first version of the draft. This has been corrected in next revision and intent is made clear that BFD session in this draft suggests to run only between VTEP to VTEP. 

> Also what is the MAC-DA of inner Ethernet header?

This was missed in our previous version which is again addressed. MAC-DA would be MAC of the destination VTEP or dedicated MAC address. 

Thanks
Santosh P K 

> We don't want to send it past VTEP as BFD will terminate at VTEP itself. Right
> now use of 127/8 is not really clear as inner IP address. We have again added
> some text for inner IP address and its use.
> 
> 
> >
> We are not trying to address VM to VM connectivity check as I believe that
> does not really need any changes and BFD as it is should run. Proposal is from
> VTEP to VTEP.
> 
> 
> Thanks
> Santosh P K
>

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 17:21:44 +0000

Shahram,

> You can do (1) today. Why do you need a standard?

1) with BFD terminating on VTEP needs changes. For example how a BFD is demuxed when it comes with your_disc = 0. What should be inner MAC-DA, inner dst-IP changes. So we need to specify in document. 

Thanks
Santosh P K

---

From: Santosh P K <[email-masked]>
Date: Tue, 30 Jun 2015 17:27:21 +0000

Shahram,

> Assuming you want to do VTEP-to-VTEP connectivity, The only way that I
> think this draft can provide extra information compared to running BFD over
> the outer IP tunnel, is when the Inner MAC-DA is the MAC-DA of the VTEP
> port that connects to the VM. In such case the packet will exercise the
> VXLAN/VNI forwarding (DA, VXLAN/VNI) and then the inner L2 is terminated
> at the VTEP port connecting VTEP to VM and BFD is extracted and processed.
> Basically some kind of UP-MEP on the VTEP.

When you say that inner DA-MAC should be that of the MAC connecting to VM, you mean the other side of the interface and not the receiving interface on VTEP right?  When we are verifying VTEP to VTEP connectivity packet has to be absorbed by VTEP itself and when it does it needs to demux BFD packet with some key and that would be VNI in the VXLAN header. This is what we are talking about  in the draft, maybe we are much more clear in the next version of the draft which will be published soon. 

Thanks
Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Tue, 30 Jun 2015 17:53:25 +0000

Santosh,

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

Shahram,

> Basically some kind of UP-MEP on the VTEP.

When you say that inner DA-MAC should be that of the MAC connecting to VM, you mean the other side of the interface and not the receiving interface on VTEP right?  

SD>Correct. Doing so ensures VXLAN/VNI is exercised. Otherwise the VXLAN is just a meta-data and it can be carried inside BFD packet (such as adding a TLV). In fact you can create a BFD TLV and add many VXLANs to it and then a single BFD session can test multiple VXLANs that start and terminate on same VTEPs.

SD> Assume there are 10 VXLAN/VNI between VTEP1 and VTEP2. Based on your draft you want to run 1xBFD per VXLAN/VNI. So you have 10xBFD sessions in each direction.  My question is how are these BFD sessions different from each other? In other words is there a case that some of these BFDs show connectivity and some don't?

SD> Instead, why don't you run just 1 BFD session and list all VNI/VXLANs inside the BFD as a list. Basically aggregate. Since you are not using VNI/VXLAN for any forwarding. You are just using it for demultipexing.

When we are verifying VTEP to VTEP connectivity packet has to be absorbed by VTEP itself and when it does it needs to demux BFD packet with some key and that would be VNI in the VXLAN header. This is what we are talking about  in the draft, maybe we are much more clear in the next version of the draft which will be published soon. 

SD> RFC 5881 supports what you need. This RFC applies to any Tunnel:

" 
   This application of BFD can be used by any pair of systems
   communicating via IPv4 and/or IPv6 across a single IP hop that is
   associated with an incoming interface.  This includes, but is not
   limited to, physical media, virtual circuits, and tunnels"

Thx
Shahram

Thanks
Santosh P K

---

From: Shahram Davari <[email-masked]>
Date: Wed, 1 Jul 2015 01:24:47 +0000

Santosh,

Is the BFD you  are describing in your draft unicast or multicast? If unicast then service nodes would not apply.

Also if there is a service node then one can run BFD on the IP tunnel between source VTEP and service node and between service node and the destination VTEP. This is much more scalable than running end-to-end BFD between VTEPs per VNI. You could even use such BFD to switch to a backup service node if there is failure to the main service node.

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram