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

From: Santosh P K <[email-masked]>
Date: Mon, 4 May 2015 16:13:54 +0000

Hello All,
   We have submitted new BFD for VXLAN draft Please review and get back to us with your comments. 

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: Marc Binderberger <[email-masked]>
Date: Mon, 4 May 2015 21:43:48 -0700

Hello Santosh and authors,

interesting idea to combine VxLAN and BFD - I like it.

But what I do not understand is how VxLAN is supposed to understand that the 
inner frame is an IP packet (you refer to RFC7348, not VxLAN-gpe). At least 
your draft reads like the packet you propose is

   outer-IP, udp, VxLAN-header, inner-IP, udp, BFD

i.e. without any inner Ethernet header. Is the inner Ethernet header kind of 
obvious, so you did not mention it? I would expect:

   outer-IP, udp, VxLAN-header, inner-Ethernet-header, inner-IP, udp, BFD

if we talk about VxLAN RFC7348.

In section "6. Reception of BFD Packet" you refer to section 4.1 of RFC7348 - 
which explicitly talks about the receiving VTEP checking VNI and the MAC of 
the inner Ethernet frame. RFC 7348 is not covering the transport of IP 
packets, it transports Ethernet frames.

You also the say in section "6":

                              Since inner IP TTL is set to 1 packet
   SHOULD be consumed by VTEP and should not be forwarded further to VM.

Hmm, I would not expect the VTEP to do any such inspection of the inner 
frame. If e.g. your VTEP is a switch (TOR) then it would simply forward the 
inner L2 frame on some L2 interface.

But maybe I'm missing something?

Regards, Marc

On Mon, 4 May 2015 16:13:54 +0000, Santosh P K wrote:
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-spallagatti-bfd-vxlan-
>> 00.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Santosh P K <[email-masked]>
Date: Tue, 5 May 2015 04:57:29 +0000

Marc,
   Thanks a lot for review. Please see answers inline tagged [SPK].

> But what I do not understand is how VxLAN is supposed to understand that
> the inner frame is an IP packet (you refer to RFC7348, not VxLAN-gpe). At
> least your draft reads like the packet you propose is
> 

[SPK]Yes, since we did not propose any changes to inner MAC we did not mention about that. I think you are right we should mention that for clarity. 

> if we talk about VxLAN RFC7348.

[SPK]We will do that. 

> inner L2 frame on some L2 interface.

[SPK] If inner VTEP is not L3 capable then BFD should not be established. BFD will be applicable to VTEP's which are L3 aware. 

Thanks
Santosh P K 

> >> To: Basil Saji; Santosh P K; Sudarsan Paragiri Mohan; Santosh P K;
> >> Basil Saji; Sudarsan Paragiri Mohan
> >> has been successfully submitted by Santosh Pallagatti and posted to
> >> the IETF repository.
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> The IETF Secretariat
> >

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 4 May 2015 22:40:27 -0700

Hello Santosh,

thanks for the explanations.

> [SPK] If inner VTEP is not L3 capable then BFD should not be established. 
> BFD will be applicable to VTEP's which are L3 aware. 

well, what do you mean with "L3 aware VTEPs" ?

Even when the VTEP has a layer-3 stack, VxLAN is not talking about any 
layer-3 processing of the inner IP (or at least I haven't found anything).

Naively I would think you need to set the inner destination MAC to an address 
that belongs to the VTEP, so the VTEP accepts the frame, strips off the 
Ethernet and processes layer-3.

Otherwise you would need some filter/policy that looks into the Ethernet 
frame, checks for IP, 127/8, UDP, 3784 port and TTL, then consumes the 
frame/packet when the filter triggers - for a packet that is not addressed to 
the VTEP. I don't think this is the transparent L2 service one would expect 
from VxLAN.

Not sure I understand the draft yet :-)

Regards, Marc

On Tue, 5 May 2015 04:57:29 +0000, Santosh P K wrote:
> [SPK]Yes, since we did not propose any changes to inner MAC we did not 
> mention about that. I think you are right we should mention that for 
> clarity. 
> 
>> 
> [SPK] If inner VTEP is not L3 capable then BFD should not be established. 
> BFD will be applicable to VTEP's which are L3 aware. 
> 
> 
> Thanks
> Santosh P K 
> 
>> 
>> 
>>>> Htmlized:       
>>>> https://tools.ietf.org/html/draft-spallagatti-bfd-vxlan-00
>>>> 
>>>> 
>>>> Abstract:

---

From: Santosh P K <[email-masked]>
Date: Tue, 5 May 2015 05:49:11 +0000

Marc,

> layer-3 processing of the inner IP (or at least I haven't found anything).

Yes, but this is a special case as BFD will terminate on VTEP itself. So VTEP's has to process L3 packet in BFD case. 

> 
> Naively I would think you need to set the inner destination MAC to an
> address that belongs to the VTEP, so the VTEP accepts the frame, strips off
> the Ethernet and processes layer-3.

Hmmm I think this is right way to do as we intend to terminate BFD which monitors BFD at VTEP's. 

> the VTEP. I don't think this is the transparent L2 service one would expect

I agree with this. We don't want to go filter way. I think your suggestion of setting MAC address for VTEP to process L3 packet would be right thing to do. 

> Not sure I understand the draft yet :-)

I think you do :).

Thanks
Santosh P K 

> >> But what I do not understand is how VxLAN is supposed to understand
> >> that the inner frame is an IP packet (you refer to RFC7348, not
> >> VxLAN-gpe). At least your draft reads like the packet you propose is
> >>
> >> i.e. without any inner Ethernet header. Is the inner Ethernet header
> >> kind of obvious, so you did not mention it? I would expect:
> >
> >> which explicitly talks about the receiving VTEP checking VNI and the
> >> MAC of the inner Ethernet frame. RFC 7348 is not covering the
> >> transport of IP packets, it transports Ethernet frames.
> >>
> >> Hmm, I would not expect the VTEP to do any such inspection of the
> >> inner frame. If e.g. your VTEP is a switch (TOR) then it would simply
> >> forward the inner L2 frame on some L2 interface.
> >