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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 2 Jul 2015 01:22:20 +0000

Hi Shahram,

I agree that running BFD between VTEPs per VNI might not scale well. But by just running BFD on the IP tunnel IMO you won’t detect certain problems, maybe hypothetical, such as the UDP port being blocked (e.g. Due to a misconfigured ACL).

Regards,
Reshad.

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 30, 2015 at 9:24 PM
To: Santosh P K <[email-masked]<mailto:[email-masked]>>, "S. Davari" <[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

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

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

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]<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 ,

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
Regards,
Shahram

On Jun 27, 2015, at 7:06 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
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

---

From: Shahram Davari <[email-masked]>
Date: Wed, 1 Jul 2015 21:25:22 -0700

Hi Reshad,

You don’t need to run continuous  BFD session per VNI to detect UDP port configuration issue. To justify running BFD per VNI, one needs to show that the forwarding of each of those BFD sessions depends on specific VNI value.   

Thx
Shahram

> On Jul 1, 2015, at 6:22 PM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Hi Shahram,
> 
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> on behalf of Shahram Davari <[email-masked] <mailto:[email-masked]>>
> To: Santosh P K <[email-masked] <mailto:[email-masked]>>, "S. Davari" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Santosh P K [mailto:[email-masked] <mailto:[email-masked]>] 
> To: S. Davari; Shahram Davari; [email-masked] <mailto:[email-masked]>
> From: Rtg-bfd [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of S. Davari
> To: Shahram Davari; [email-masked] <mailto:[email-masked]>
> On Jun 27, 2015, at 7:06 AM, Shahram Davari <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Prasad ,
>>

---

From: Santosh P K <[email-masked]>
Date: Thu, 2 Jul 2015 07:14:07 +0000

Shahram,

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

It is unicast and multicast is future study. Can you please tell me why would unicast does not apply for service node? Between VTEP and service node it would be a unicast communication right? 

Thanks
Santosh P K

From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, July 01, 2015 6:55 AM
To: Santosh P K; S. Davari; [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Santosh,

Thx
Shahram

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]
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]> wrote:
Hi Prasad ,

Regards,
Shahram

---

From: Santosh P K <[email-masked]>
Date: Thu, 2 Jul 2015 07:22:36 +0000

Shahram,
   Please see inline reply tagged [SPK].

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

[SPK] Or with VNI 0 a special VNI so that it covers all VNI between those VTEP? In case it is decided one BFD session which takes the same path in underlay as that of data packet between two VTEPs. 

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

[SPK] Demux is one of the topic we are touching upon we are also discussing other fields of complete VXLAN packet which is carrying BFD as payload. First version of draft is not so clear all the fields, we have second version of draft which is talking more about those. Will publish the second version of draft in couple of days. 

Thanks
Santosh P K  

> 
> 
> 
> >
> > -----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]
> > 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-----
> > Sent: Tuesday, June 30, 2015 2:13 AM
> > To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi)
> > Cc: [email-masked]
> > > 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.
> >
> >
> > >
> > > 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.
> > >
> >
> > 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
> >
> > > -----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]
> > > 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]
> > > 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-----
> > > Sent: Monday, June 29, 2015 2:02 PM
> > > To: Gregory Mirsky; Vengada Prasad Govindan (venggovi)
> > > Cc: MALLIK MUDIGONDA (mmudigon); Santosh P K; [email-masked]
> > > 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]
> > > 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-----
> > > Sent: Monday, June 29, 2015 10:39 AM
> > > To: Vengada Prasad Govindan (venggovi)
> > > Cc: Gregory Mirsky; MALLIK MUDIGONDA (mmudigon); Santosh P K; rtg-
> > > [email-masked]
> > > 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; rtg-
> > > [email-masked]
> > > 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-----
> > > 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]
> > > 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: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 2 Jul 2015 12:46:07 +0000

Hi Shahram,

Agreed. My point is that running BFD on the tunnel is not good enough for some failures.

Regards,
Reshad.

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 2, 2015 at 12:25 AM
To: Reshad <[email-masked]<mailto:[email-masked]>>
Cc: Shahram Davari <[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

Hi Reshad,

Thx
Shahram

On Jul 1, 2015, at 6:22 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram,

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 2 Jul 2015 18:58:19 +0000

Agree. But we can may be come up with a more efficient solution.

Thx
SD

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 02, 2015 5:46 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Regards,
Reshad.

Hi Reshad,

You don't need to run continuous  BFD session per VNI to detect UDP port configuration issue. To justify running BFD per VNI, one needs to show that the forwarding of each of those BFD sessions depends on specific VNI value.

Thx
Shahram

Hi Shahram,

I agree that running BFD between VTEPs per VNI might not scale well. But by just running BFD on the IP tunnel IMO you won't detect certain problems, maybe hypothetical, such as the UDP port being blocked (e.g. Due to a misconfigured ACL).

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 2 Jul 2015 20:39:11 +0000

Sure.

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, July 02, 2015 11:58 AM
To: Reshad Rahman (rrahman); Shahram Davari
Cc: [email-masked]
Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Thx
SD

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 02, 2015 5:46 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Shahram,

Regards,
Reshad.

Hi Reshad,

Thx
Shahram

Hi Shahram,

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Nobo Akiya <[email-masked]>
Date: Fri, 10 Jul 2015 16:12:24 +0900

Long and interesting thread :)

How about setting the MAC-DA as the MAC of the sender VTEP?

Thanks!

-Nobo

On Fri, Jul 3, 2015 at 5:39 AM, Shahram Davari <[email-masked]> wrote:

>  Sure.
>
>
>
> *From:* Rtg-bfd [mailto:[email-masked]] *On Behalf Of *Shahram
> Davari
> *Sent:* Thursday, July 02, 2015 11:58 AM
> *To:* Reshad Rahman (rrahman); Shahram Davari
> *Cc:* [email-masked]
> *Subject:* RE: New Version Notification for
> draft-spallagatti-bfd-vxlan-00.txt
>
>
>
> *From:* Rtg-bfd [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Reshad Rahman (rrahman)
> *Sent:* Thursday, July 02, 2015 5:46 AM
> *To:* Shahram Davari
> *Cc:* [email-masked]
> *Subject:* Re: New Version Notification for
> draft-spallagatti-bfd-vxlan-00.txt
>
>
>
> Hi Shahram,
>
>
>
> *From: *Rtg-bfd <[email-masked]> on behalf of Shahram Davari <
> [email-masked]>
> *Date: *Thursday, July 2, 2015 at 12:25 AM
> *To: *Reshad <[email-masked]>
> *Cc: *Shahram Davari <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: New Version Notification for
> draft-spallagatti-bfd-vxlan-00.txt
>
>
>
> Hi Reshad,
>
>
>
> You don’t need to run continuous  BFD session per VNI to detect UDP port
> configuration issue. To justify running BFD per VNI, one needs to show that
> the forwarding of each of those BFD sessions depends on specific VNI value.
>
>
>
>
> Thx
>
> Shahram
>
>
>
> I agree that running BFD between VTEPs per VNI might not scale well. But
> by just running BFD on the IP tunnel IMO you won’t detect certain problems,
> maybe hypothetical, such as the UDP port being blocked (e.g. Due to a
> misconfigured ACL).
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Rtg-bfd <[email-masked]> on behalf of Shahram Davari <
> [email-masked]>
> *Date: *Tuesday, June 30, 2015 at 9:24 PM
> *To: *Santosh P K <[email-masked]>, "S. Davari" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: New Version Notification for
> draft-spallagatti-bfd-vxlan-00.txt
>
>
>
> 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
>
>
>
> *From:* Santosh P K [mailto:[email-masked] <[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
>
>
>
> 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]
> <[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 ,
>
> 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.
> 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
>
>  Regards,
>
> Shahram
>
>
>
>
> 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.
> 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
>
>
>

---

From: "S. Davari" <[email-masked]>
Date: Fri, 10 Jul 2015 06:22:20 -0700

Yes that is the solution.

Regards,
Shahram

> On Jul 10, 2015, at 12:12 AM, Nobo Akiya <[email-masked]> wrote:
> 
>> From: Rtg-bfd <[email-masked]> on behalf of Shahram Davari <[email-masked]>
>> To: Reshad <[email-masked]>
>> Cc: Shahram Davari <[email-masked]>, "[email-masked]" <[email-masked]>
>> From: Rtg-bfd <[email-masked]> on behalf of Shahram Davari <[email-masked]>
>> To: Santosh P K <[email-masked]>, "S. Davari" <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Santosh P K <[email-masked]>
Date: Fri, 10 Jul 2015 14:01:26 +0000

Nobo and Sharram,
     I am bit confused did you mean MAC-DA of the receiver VTEP? How would sender VTEP solve the problem?

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of S. Davari
Sent: Friday, July 10, 2015 6:52 PM
To: Nobo Akiya
Cc: Reshad Rahman (rrahman); [email-masked]
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Regards,
Shahram

On Jul 10, 2015, at 12:12 AM, Nobo Akiya <[email-masked]<mailto:[email-masked]>> wrote:
Long and interesting thread :)

Thanks!

-Nobo

On Fri, Jul 3, 2015 at 5:39 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Sure.

From: Rtg-bfd [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shahram Davari

Thx
SD

Hi Shahram,

Regards,
Reshad.

Hi Reshad,

Thx
Shahram

Hi Shahram,

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Nobo Akiya <[email-masked]>
Date: Sat, 18 Jul 2015 10:25:16 +0900

Hi Santosh,

Essentially the sender can periodically send self-destined packets (MAC-DA
= sender VTEP) that gets looped back on the remote VTEP (this better
exercises the VNI forwarding on the remote VTEP). Similar concept as BFD
echo.

Thanks!

-Nobo

On Fri, Jul 10, 2015 at 11:01 PM, Santosh P K <[email-masked]> wrote:

> *From:* Rtg-bfd [mailto:[email-masked]] *On Behalf Of *S. Davari
> *Sent:* Friday, July 10, 2015 6:52 PM
> *To:* Nobo Akiya
> *Cc:* Reshad Rahman (rrahman); [email-masked]
>

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Sat, 18 Jul 2015 01:29:14 +0000

Hello Nobo,
  While I do agree that there could be value in getting a self-destined packet encapsulated in VxLAN as you describe below, the datapath flow of VxLAN decap followed by a L2 lookup and a VxLAN (re)encap is not supported on most silicon (Shahram, please correct me if I am wrong here) and hence difficult to implement. Instead a VxLAN Async is what is proposed in the draft.
Thanks
Prasad

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya
Sent: Friday, July 17, 2015 6:25 PM
To: Santosh P K
Cc: Reshad Rahman (rrahman); [email-masked]; S. Davari
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Santosh,

Essentially the sender can periodically send self-destined packets (MAC-DA = sender VTEP) that gets looped back on the remote VTEP (this better exercises the VNI forwarding on the remote VTEP). Similar concept as BFD echo.

Thanks!

-Nobo

On Fri, Jul 10, 2015 at 11:01 PM, Santosh P K <[email-masked]<mailto:[email-masked]>> wrote:
Nobo and Sharram,
     I am bit confused did you mean MAC-DA of the receiver VTEP? How would sender VTEP solve the problem?

Thanks
Santosh P K

From: Rtg-bfd [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of S. Davari
Sent: Friday, July 10, 2015 6:52 PM
To: Nobo Akiya
Cc: Reshad Rahman (rrahman); [email-masked]<mailto:[email-masked]>

Regards,
Shahram

Thanks!

-Nobo

Thx
SD

Hi Shahram,

Regards,
Reshad.

Hi Reshad,

Thx
Shahram

Hi Shahram,

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Jul 2015 19:56:26 -0700

Hi 

Silicon supports L2 lookup after VXLAN termination, and then re-encapsulation in another VXLAN Tunnel. The self MAC should also work if Split Horizon is not enabled.

Thx
Shahram

> On Jul 17, 2015, at 6:29 PM, Vengada Prasad Govindan (venggovi) <[email-masked]> wrote:
> 
> Hello Nobo,
> On Fri, Jul 10, 2015 at 11:01 PM, Santosh P K <[email-masked] <mailto:[email-masked]>> wrote:
> Nobo and Sharram,
> Cc: Reshad Rahman (rrahman); [email-masked] <mailto:[email-masked]>
> 
> On Jul 10, 2015, at 12:12 AM, Nobo Akiya <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Fri, Jul 3, 2015 at 5:39 AM, Shahram Davari <[email-masked] <mailto:[email-masked]>> wrote:
> Sure.
>  
> From: Rtg-bfd [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Shahram Davari
> Cc: [email-masked] <mailto:[email-masked]>
> From: Rtg-bfd [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Reshad Rahman (rrahman)
> Cc: [email-masked] <mailto:[email-masked]>
> From: Rtg-bfd <[email-masked] <mailto:[email-masked]>> on behalf of Shahram Davari <[email-masked] <mailto:[email-masked]>>
> To: Reshad <[email-masked] <mailto:[email-masked]>>
> Cc: Shahram Davari <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Jul 1, 2015, at 6:22 PM, Reshad Rahman (rrahman) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Shahram,
>

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 18 Jul 2015 09:41:00 +0000

Hi Nobo,
I agree that that will work as long as there’s no poison-reverse policy enforced. We had similar discussion in MPLS WG on self-ping from Ron Bonica recently. BFD Asynchronous mode would not create concern with poison-reverse.

                Regards,
                                Greg

From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya
Sent: Saturday, July 18, 2015 3:25 AM
To: Santosh P K
Cc: Reshad Rahman (rrahman); [email-masked]; S. Davari
Subject: Re: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt

Hi Santosh,

Thanks!

-Nobo

Thanks
Santosh P K

Regards,
Shahram

Thanks!

-Nobo

Thx
SD

Hi Shahram,

Regards,
Reshad.

Hi Reshad,

Thx
Shahram

Hi Shahram,

Regards,
Reshad.

Santosh,

Thx
Shahram

Thanks
Santosh P K

Hi

What is a service node?

Thx

Sd

Hi Prasad ,

Regards,
Shahram
Regards,
Shahram

Regards,
Shahram