Hi Marc, many thanks for your excellent comments and the most detailed questions - all much appreciated and the most helpful. Please find my answers, notes in-line and tagged GIM>>,
Regards, Greg On Thu, Sep 13, 2018 at 5:36 PM, Marc Binderberger <[email protected]> wrote: > Hello Greg & Authors, > > great to see this draft progressing! > > > As usual I'm a bit late :-/ but I do have some questions/comments: > > > Q1: the TTL = 1 requirement for the inner IP packet. The explanation for > the > MUST is > > TTL: MUST be set to 1 to ensure that the BFD packet is not > routed within the L3 underlay network. > > > I find this a very implementation-specific reason that may not apply to > many > other implementations. But the demand for TTL = 1 may limit what can be > done > with today's silicon, which is why I question this demand here :-) > > You will find off-the-shelf silicon that offers you BFD RFC5881 "in > hardware". For the ASIC user the usage is typically fixed by the API/SDK > and > RFC5881 uses TTL = 255 for send and check on receive. Using a loopback > port > it would be simple to use this RFC5881 BFD engine to send packets over the > VxLAN tunnel. But the TTL=1 requirements defeats this. Could we drop it? > GIM>> I think that this specification is closer to RFC 5884 case where TTL > for the encapsulated BFD control packet mandated to be set to 1: > The IP TTL or hop limit MUST be set to 1 [RFC4379]. > Q2: in this context of TTL you write > > 10. Security Considerations > > The document recommends setting the inner IP TTL to 1 which could > lead to a DDoS attack. > GIM>> Would s/recommends/requires/ work? > > > First, you don't recommend - you say MUST. But as a non-native speaker > maybe > this is a misinterpretation on my side ;-) > More interesting: how does TTL = 1 raises the DDoS risk? By someone > directly, > i.e. without any VxLAN encapsulation, sending a BFD packet to the VTEP IP ? > GIM>> Agree, the wording is rather confusing. Would the following text make it clearer: OLD TEXT: The document recommends setting the inner IP TTL to 1 which could lead to a DDoS attack. Thus the implementation MUST have throttling in place. Throttling MAY be relaxed for BFD packets based on port number. NEW TEXT: The document requires setting the inner IP TTL to 1 which could be used as DDoS attack vector. Thus the implementation MUST have throttling in place to control the rate of BFD control packets sent to the control plane. > > Q3: for the demultiplexing of incoming BFD packets (section 6.1) you write > > [...] For such packets, the BFD session MUST be identified > using the inner headers, i.e., the source IP and the destination IP > present in the IP header carried by the payload of the VXLAN > encapsulated packet. The VNI of the packet SHOULD be used to derive > interface-related information for demultiplexing the packet. > > > I understand the "MUST" for the source IP, to differentiate a session with > VTEP A from the session with VTEP B. Why is the destination IP, i.e. my > local > IP, of relevance? Support for multiple VTEP? > GIM>> Yes, it is the case. > But my main question is, why the VNI (or related information like the > local > VLAN or VFI) is only a "SHOULD" ? GIM>> An implementation may support only use of VNI 0 and not to use VNI value of the received packet. > In section 4 you say > > [...] Separate BFD > sessions can be established between the VTEPs (IP1 and IP2) for > monitoring each of the VXLAN tunnels (VNI 100 and 200). > > > How would I separate these BFD sessions when src/dst IP are the same? > GIM>> By using different VNI in the VXLAN encapsulation of a BFD Control packets. > > > Finally a nitpick, you write in section 6: > > The UDP destination port and the TTL of the inner Ethernet frame MUST > be validated > > We all understand what you mean but I first stumbled: Ethernet frames have > no > TTL. You mean (of course) the inner IP packet - why not writing it? ;-) > GIM>> Agreed. Would s/inner Ethernet/inner IP packet/ address it? > > > > Anyway, overall very useful standard (as you see from my comments, there > are > feature roadmaps coming ;-) > GIM>> Thank you for your kind words and help to improve the specification, Marc. > > > Thanks & Regards, > Marc > > > > > > On Sat, 18 Aug 2018 13:54:22 -0700, Greg Mirsky wrote: > > Dear All, > > the new version addresses comments and editorial suggestions we've > received > > from Donald. > > > > Your reviews are most welcome, comments, questions, and suggestions much > > appreciated. > > > > As discussed at the meeting in Montreal, the authors believe that this > > document is ready for WGLC. > > > > Regards, > > Greg > > > > ---------- Forwarded message ---------- > > From: <[email protected]> > > Date: Sat, Aug 18, 2018 at 1:09 PM > > Subject: I-D Action: draft-ietf-bfd-vxlan-02.txt > > To: [email protected] > > Cc: [email protected] > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Bidirectional Forwarding Detection WG > of > > the IETF. > > > > Title : BFD for VXLAN > > Authors : Santosh Pallagatti > > Sudarsan Paragiri > > Vengada Prasad Govindan > > Mallik Mudigonda > > Greg Mirsky > > Filename : draft-ietf-bfd-vxlan-02.txt > > Pages : 10 > > Date : 2018-08-18 > > > > Abstract: > > This document describes the use of the Bidirectional Forwarding > > Detection (BFD) protocol in Virtual eXtensible Local Area Network > > (VXLAN) overlay networks. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-02 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > >
