Re: WGLC comments on draft-ietf-bfd-vxlan

Anoop Ghanwani <anoop@alumni.duke.edu> Tue, 13 November 2018 20:30 UTC

Return-Path: <ghanwani@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2E3130DF1; Tue, 13 Nov 2018 12:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.42
X-Spam-Level:
X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxgq92S0jGes; Tue, 13 Nov 2018 12:30:41 -0800 (PST)
Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C846612D4EA; Tue, 13 Nov 2018 12:30:40 -0800 (PST)
Received: by mail-ua1-f51.google.com with SMTP id d21so4841857uap.9; Tue, 13 Nov 2018 12:30:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q7pbKhd5lwUNJGnNx9FGR4t80aRtOFjGMe+x4PRT56Q=; b=Q7wp9zt+h2CzZkzROyf7HVQaee4Oe+Hqzjzi7WD2GkSAIuOpqLO4cpfVMbZkPowPeM tXk/XCqCp1luqmqGtKV4qwlswn9Lq3M4BYywe87ffCZX8tzfbFDGh6+jE6Y6HO6wLfD+ W7jsMTUC3H4WH9ofCDBds8p64a/jWMl/SUcpLR8EP+4GURRVL1tBgr6DxgAD1k5rBDGc S6eOQDOHIh03Xqv4/hJ52mdWTPsTd9p5oejysEzLNKoosaqINfdwjCAa/WqND0GpHQ+I gvZ8P5+3wYPHOlBZAzWF5+rh7P1XWZNusiiTSsacwZzSMolhfoIr0llmGIKcc7u3vDR6 X0xw==
X-Gm-Message-State: AGRZ1gKlldWjRIPRmTd/3iSBufOovWCQ/vh0SCezqKz7lO2OvTJhGX9n 44noZ+1x35AKJbloVU7DlsKdlhsUg7yNWWjXc6DmLA==
X-Google-Smtp-Source: AJdET5d53sToS7GtIHJGldz5g4uWT/jXWGnzmFVC0teOJkBLluMlWP/qYix0DhsC8xJqlYCY2HFG6gcWOsz6OJ688Aw=
X-Received: by 2002:ab0:225a:: with SMTP id z26mr3252424uan.100.1542141039547; Tue, 13 Nov 2018 12:30:39 -0800 (PST)
MIME-Version: 1.0
References: <CA+-tSzxFxtVo6NbfSw4wzb--fSuN4zsSvX7R58iiYFgVF5cA6Q@mail.gmail.com> <CA+RyBmVXeCYAZhWTy-g6U_EJ7NOFQwV4twJaJ-7_LT5_wKFGFw@mail.gmail.com>
In-Reply-To: <CA+RyBmVXeCYAZhWTy-g6U_EJ7NOFQwV4twJaJ-7_LT5_wKFGFw@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tue, 13 Nov 2018 12:30:27 -0800
Message-ID: <CA+-tSzxQp2x0hpAF253b9yKL1aD1J1CaGHs7T6VE8zuvg25R_Q@mail.gmail.com>
Subject: Re: WGLC comments on draft-ietf-bfd-vxlan
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd@ietf.org, nvo3@ietf.org
Content-Type: multipart/alternative; boundary="000000000000db1b2d057a91b0ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/R8tqNdYmLZiblooKDrQ2N1X7OFY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2018 20:30:45 -0000

Hi Greg,

Please see inline prefixed with [ag].

Thanks,
Anoop

On Tue, Nov 13, 2018 at 11:34 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Anoop,
> many thanks for the thorough review and detailed comments. Please find my
> answers, this time for real, in-line tagged GIM>>.
>
> Regards,
> Greg
>
> On Thu, Nov 8, 2018 at 1:58 AM Anoop Ghanwani <anoop@alumni.duke.edu>
> wrote:
>
>>
>> Here are my comments.
>>
>> Thanks,
>> Anoop
>>
>> ==
>>
>> Philosophical
>>
>> Since VXLAN is not an IETF standard, should we be defining a standard for
>> running BFD on it?  Should we define BFD over Geneve instead which is the
>> official WG selection?  Is that going to be a separate document?
>> GIM>> IS-IS is not on the Standard track either but that had not
>> prevented IETF from developing tens of standard track RFCs using RFC 1142
>> as the normative reference until RFC 7142 re-classified it as historical. A
>> similar path was followed with IS-IS-TE by publishing RFC 3784 until it was
>> obsoleted by RFC 5305 four years later. I understand that Down Reference,
>> i.e., using informational RFC as the normative reference, is not an unusual
>> situation.
>>
>
[ag] OK.  I'm not an expert on this part so unless someone else that is an
expert (chairs, AD?) can comment on it, I'll just let it go.


>
>
>>
>> Technical
>>
>> Section 1:
>>
>> This part needs to be rewritten:
>> >>>
>> The individual racks may be part of a different Layer 3 network, or they
>> could be in a single Layer 2 network. The VXLAN segments/overlays are
>> overlaid on top of Layer 3 network. A VM can communicate with another VM
>> only if they are on the same VXLAN segment.
>> >>>
>> It's hard to parse and, given IRB,
>>
> GIM>> Would the following text be acceptable:
> OLD TEXT:
>    VXLAN is typically deployed in data centers interconnecting
>    virtualized hosts, which may be spread across multiple racks.  The
>    individual racks may be part of a different Layer 3 network, or they
>    could be in a single Layer 2 network.  The VXLAN segments/overlays
>    are overlaid on top of Layer 3 network.
> NEW TEXT:
> VXLAN is typically deployed in data centers interconnecting virtualized
> hosts of a tenant. VXLAN addresses requirements of the Layer 2 and
> Layer 3 data center network infrastructure in the presence of VMs in
> a multi-tenant environment, discussed in section 3 [RFC7348], by
>  providing Layer 2 overlay scheme on a Layer 3 network.
>

[ag] This is a lot better.


>
>  A VM can communicate with another VM only if they are on the same
> VXLAN segment.
>>
>> the last sentence above is wrong.
>>
> GIM>> Section 4 in RFC 7348 states:
> Only VMs within the same VXLAN segment can communicate with each other.
>

[ag] VMs on different segments can communicate using routing/IRB, so even
RFC 7348 is wrong.  Perhaps the text should be modified so say -- "In the
absence of a router in the overlay, a VM can communicate...".


>
> Section 3:
>> >>>
>>  Most deployments will have VMs with only L2 capabilities that
>> may not support L3.
>> >>>
>> Are you suggesting most deployments have VMs with no IP
>> addresses/configuration?
>>
> GIM>> Would re-word as follows:
> OLD TEXT:
>  Most deployments will have VMs with only L2 capabilities that
>  may not support L3.
> NEW TEXT:
> Deployments may have VMs with only L2 capabilities that do not support L3.
>

[ag] I still don't understand this.  What does it mean for a VM to not
support L3?  No IP address, no default GW, something else?


>
>> >>>
>> Having a hierarchical OAM model helps localize faults though it requires
>> additional consideration.
>> >>>
>> What are the additional considerations?
>>
> GIM>> For example, coordination of BFD intervals across the OAM layers.
>

[ag] Can we mention them in the draft?


>
>> Would be useful to add a reference to RFC 8293 in case the reader would
>> like to know more about service nodes.
>>
> GIM>> I have to admit that I don't find how RFC 8293  A Framework for
> Multicast in Network Virtualization over Layer 3 is related to this
> document. Please help with additional reference to the text of the
> document.
>

[ag] The RFC discusses the use of service nodes which is mentioned here.


>
>> Section 4
>> >>>
>> Separate BFD sessions can be established between the VTEPs (IP1 and IP2)
>> for monitoring each of the VXLAN tunnels (VNI 100 and 200).
>> >>>
>> IMO, the document should mention that this could lead to scaling issues
>> given that VTEPs can support well in excess of 4K VNIs.  Additionally, we
>> should mention that with IRB, a given VNI may not even exist on the
>> destination VTEP.  Finally, what is the benefit of doing this?  There may
>> be certain corner cases where it's useful (vs a single BFD session between
>> the VTEPs for all VNIs) but it would be good to explain what those are.
>>
> GIM>> Will add text in the Security Considerations section that VTEPs
> should have limit on number of BFD sessions.
>

[ag] I was hoping for two things:
- A mention about the scalability issue right where per-VNI BFD is
discussed.  (Not sure why that is a security issue/consideration.)
- What is the benefit of running BFD per VNI between a pair of VTEPs?


>
>> Sections 5.1 and 6.1
>>
>> In 5.1 we have
>> >>>
>> The inner MAC frame carrying the BFD payload has the
>> following format:
>> ... Source IP: IP address of the originating VTEP. Destination IP: IP
>> address of the terminating VTEP.
>> >>>
>>
>> In 6.1 we have
>> >>>
>>
>> Since multiple BFD sessions may be running between two
>> VTEPs, there needs to be a mechanism for demultiplexing received BF
>>
>> packets to the proper session.  The procedure for demultiplexing
>> packets with Your Discriminator equal to 0 is different from[RFC5880 <https://tools.ietf.org/html/rfc5880>].
>>
>> *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.*
>>
>>
>> >>>
>> How does this work if the source IP and dest IP are the same as specified
>> in 5.1?
>>
> GIM>> You're right, Destination and source IP addresses likely are the
> same in this case. Will add that the source UDP port number, along with the
> pair of IP addresses, MUST be used to demux received BFD control packets.
> Would you agree that will be sufficient?
>

[ag] Yes, I think that should work.

>
>> Editorial
>>
>
[ag] Agree with all comments on this section.

>
>> - Terminology section should be renamed to acronyms.
>>
> GIM>> Accepted
>
>> - Document would benefit from a thorough editorial scrub, but maybe that
>> will happen once it gets to the RFC editor.
>>
> GIM>> Will certainly have helpful comments from ADs and RFC editor.
>
>>
>> Section 1
>> >>>
>> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348
>> <https://tools.ietf.org/html/rfc7348>]. provides an encapsulation scheme
>> that allows virtual machines (VMs) to communicate in a data center network.
>> >>>
>> This is not accurate.  VXLAN allows you to implement an overlay to
>> decouple the address space of the attached hosts from that of the network.
>>
> GIM>> Thank you for the suggested text. Will change as follows:
> OLD TEXT:
>    "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348].  provides
>    an encapsulation scheme that allows virtual machines (VMs) to
>    communicate in a data center network.
> NEW TEXT:
>  "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348].  provides
>    an encapsulation scheme that allows building an overlay network by
>   decoupling the address space of the attached virtual hosts from that of
> the network.
>
>>
>> Section 7
>>
>> VTEP's -> VTEPs
>>
> GIM>> Yes, thank you.
>