Hello Shahram,
Thanks a lot for your comments. Indeed "VXLAN tunnel" is confusing, what
we are trying to do here is address the requirement from draft "
https://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.txt";.
Here we have a requirement for running proactive OAM between NV edge to NV edge
per VNI. This is an individual draft for now.
Thanks
Santosh P K
> -----Original Message-----
> From: Shahram Davari [mailto:[email protected]]
> Sent: Thursday, June 25, 2015 8:18 PM
> To: Santosh P K; Gregory Mirsky; Vengada Prasad Govindan (venggovi);
> MALLIK MUDIGONDA (mmudigon)
> Cc: [email protected]
> 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 protected]] 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 protected]
> 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 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]
> 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]>
> Date: Wednesday, 6 May 2015 9:39 am
> To: Santosh P K <[email protected]>, "[email protected]" <rtg-
> [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]
> 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]]
> 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].
> 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
>
>
>
