Hi Santosh, Authors, et. al,
what a great discussion of very interesting work, many thanks to Prasad, Mallik
and, of course, Santosh. I'll try not to repeat points they already brought up.
Please find my notes below:
* Introduction:
o you reference RFC 5880 but don't specify which of defined in BFD base
document modes are in scope of this work. I assume that, like in RFC 5884, it
is only Asynchronous mode and Section 7 excludes Echo BFD but Demand mode not
mentioned. Making more explicit statement would be helpful.
* section 2:
o I think that these three cases hardly apply to the proposed solution.
In particular, BFD may very coarsely localize path failure as we should
remember that path and remote peer failure are undistinguishable. Thus failure
detected at one VM, with Tunnel BFD session operational, cannot be interpreted
as peer VM failure.
* section 3:
o what ensures that reverse direction of the BFD session between IP1
(ingress) and IP2 (egress) , i.e. egress transmits BFD control packets toward
the ingress, uses the same tunnel traversed by BFD control packets sent from
ingress toward the egress? Perhaps use of BFD Reverse Path TLV and BFD
Discriminator TLV may be one solution?
o Perhaps this section could be the right place to discuss and define
behavior of the egress in terms of its role in BFD session:
* packet encapsulation;
* failure reporting;
* path selection (discussed above).
o And the issues of the encapsulation, reverse path selection are
relevant for S-BFD scenario as well (I think that Prasad's suggestion to split
into two documents, BFD and S-BFD, is quite reasonable).
* section 6.1:
o considering 5884clarification work, can multiple BFD session operate
between IP1 and IP2 over the same tunnel?
Regards,
Greg
-----Original Message-----
From: Rtg-bfd [mailto:[email protected]] On Behalf Of Vengada Prasad
Govindan (venggovi)
Sent: Friday, May 08, 2015 12:39 AM
To: Santosh P K; MALLIK MUDIGONDA (mmudigon)
Cc: [email protected]
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 protected]]
Sent: Wednesday, May 06, 2015 3:03 PM
To: MALLIK MUDIGONDA (mmudigon)
Cc: Vengada Prasad Govindan (venggovi);
[email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>>
Date: Wednesday, 6 May 2015 9:39 am
To: Santosh P K <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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 protected]] On Behalf Of Santosh P K
Sent: Monday, May 04, 2015 10:55 PM
To: [email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>
[mailto:[email protected]]
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 protected]<mailto:[email protected]>.
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
