Hi Stantosh, I don't agree with the requirements draft you mentioned. I don't think it is required or makes sense to run OAM for a VNI.
Thx Shahram -----Original Message----- From: Santosh P K [mailto:[email protected]] Sent: Friday, June 26, 2015 12:20 AM To: Shahram Davari; Gregory Mirsky; Vengada Prasad Govindan (venggovi); MALLIK MUDIGONDA (mmudigon) Cc: [email protected] Subject: RE: New Version Notification for draft-spallagatti-bfd-vxlan-00.txt 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 > > >
