Return-Path: 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 BF6A8124C04; Wed, 21 Nov 2018 23:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2O-RLCHQuT4W; Wed, 21 Nov 2018 23:00:11 -0800 (PST) Received: from mail-vk1-f196.google.com (mail-vk1-f196.google.com [209.85.221.196]) (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 54BC9128C65; Wed, 21 Nov 2018 23:00:11 -0800 (PST) Received: by mail-vk1-f196.google.com with SMTP id 197so1788820vkf.4; Wed, 21 Nov 2018 23:00:11 -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=L2HS/M0MNHjKLXGmLM90t9I4wmK2jii+7oAskPmpXH4=; b=kjJVCziCpC7SriSeuwx5UWpw20bZia57bzvjv6QzcgwtT9Rh5dIpNPyyZ8w11jtfBF LiT+pklTHKnwql8ymeZXRrbMxOVozz4k2EoflspSpPTkoDzEDuluEC5HPCI/5OCk/iud RgF48WtgLn9jhS8XRjZLo6EXtTbvHUK4cqljxVUa10ZFUzmYR7TU7DLJ8tV4enzvQ0ko jFSH21UYahi17A/EHnO+tNHlTGEwtivSQthFfEJRSu1D7wPGTrYVb44kf0pRA06qSYRe 0ehzKdsM9AISSBy6wTyFQMs8jEUFJXjuFArOjqNbwJCJdXtIdYmvxKaLNvXqraUfbxrB /BwA== X-Gm-Message-State: AA+aEWbXZIP3tvMT8S+1hs1yDuK2CdERJjt65M8/GNuSgVrJUeJB93Xd 5k72FTpDzT8b2pBan0fhMhdkl2P8KH8x3inFMW4= X-Google-Smtp-Source: AFSGD/UEecJUGBN1PkL6kENGtDwPgV9nt6RL+TDebsUST1zHOv5uJNcTAC+ALkXirAbaM4DuKM0n8QWxVyRoDkEvKrg= X-Received: by 2002:a1f:a04b:: with SMTP id j72mr3945576vke.51.1542870010090; Wed, 21 Nov 2018 23:00:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Anoop Ghanwani Date: Wed, 21 Nov 2018 22:59:56 -0800 Message-ID: Subject: Re: WGLC comments on draft-ietf-bfd-vxlan To: Greg Mirsky Cc: rtg-bfd@ietf.org, nvo3@ietf.org Content-Type: multipart/alternative; boundary="000000000000e2d9b4057b3b6ae9" Archived-At: X-Mailman-Approved-At: Thu, 22 Nov 2018 04:54:47 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 07:00:17 -0000 --000000000000e2d9b4057b3b6ae9 Content-Type: text/plain; charset="UTF-8" Hi Greg, See below prefixed with [ag4]. Thanks, Anoop On Wed, Nov 21, 2018 at 4:36 PM Greg Mirsky wrote: > Hi Anoop, > apologies for the miss. Is it the last outstanding? Let's bring it to the > front then. > > - What is the benefit of running BFD per VNI between a pair of VTEPs? >>>>> >>>> GIM2>> An alternative would be to run CFM between VMs, if there's the >>>> need to monitor liveliness of the particular VM. Again, this is optional. >>>> >>> >>> [ag2] I'm not sure how running per-VNI BFD between the VTEPs allows one >>> to monitor the liveliness of VMs. >>> >> > [ag3] I think you missed responding to this. I'm not sure of the value of > running BFD per VNI between VTEPs. What am I getting that is not covered > by running a single BFD session with VNI 0 between the VTEPs? > > GIM3>> I've misspoken. Non-zero VNI is recommended to be used to > demultiplex BFD sessions between the same VTEPs. In section 6.1: > The procedure for demultiplexing > packets with Your Discriminator equal to 0 is different from > [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. The VNI of the packet SHOULD be used to derive > interface-related information for demultiplexing the packet. > > Hope that clarifies the use of non-zero VNI in VXLAN encapsulation of a > BFD control packet. > [ag4] This tells me how the VNI is used for BFD packets being sent/received. What is the use case/benefit of doing that? I am creating a special interface with VNI 0 just for BFD. Why do I now need to run BFD on any/all of the other VNIs? As a developer, if I read this spec, should I be building this capability or not? Basically what I'm getting at is I think the draft should recommend using VNI 0. If there is a convincing use case for running BFD over other VNIs serviced by that VTEP, then that needs to be explained. But as I mentioned before, this leads to scaling issues. So given the scaling issues, it would be good if an implementation only needed to worry about sending BFD messages on VNI 0. > > Regards, > Greg > > On Tue, Nov 20, 2018 at 12:14 PM Anoop Ghanwani > wrote: > >> Hi Greg, >> >> Please see inline prefixed by [ag3]. >> >> Thanks, >> Anoop >> >> On Fri, Nov 16, 2018 at 5:29 PM Greg Mirsky >> wrote: >> >>> Hi Anoop, >>> thank you for the discussion. Please find my responses tagged GIM3>>. >>> Also, attached diff and the updated working version of the draft. Hope >>> we're converging. >>> >>> Regards, >>> Greg >>> >>> On Wed, Nov 14, 2018 at 11:00 PM Anoop Ghanwani >>> wrote: >>> >>>> Hi Greg, >>>> >>>> Please see inline prefixed with [ag2]. >>>> >>>> Thanks, >>>> Anoop >>>> >>>> On Wed, Nov 14, 2018 at 9:45 AM Greg Mirsky >>>> wrote: >>>> >>>>> Hi Anoop, >>>>> thank you for the expedient response. I am glad that some of my >>>>> responses have addressed your concerns. Please find followup notes in-line >>>>> tagged GIM2>>. I've attached the diff to highlight the updates applied in >>>>> the working version. Let me know if these are acceptable changes. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Nov 13, 2018 at 12:30 PM Anoop Ghanwani >>>>> wrote: >>>>> >>>>>> Hi Greg, >>>>>> >>>>>> Please see inline prefixed with [ag]. >>>>>> >>>>>> Thanks, >>>>>> Anoop >>>>>> >>>>>> On Tue, Nov 13, 2018 at 11:34 AM Greg Mirsky >>>>>> 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 >>>>>>> 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? >>>>>> >>>>> GIM2>> VM communicates with its VTEP which, in turn, originates VXLAN >>>>> tunnel. VM is not required to have IP address as it is VTEP's IP address >>>>> that VM's MAC is associated with. As for gateway, RFC 7348 discusses VXLAN >>>>> gateway as the device that forwards traffice between VXLAN and non-VXLAN >>>>> domains. Considering all that, would the following change be acceptable: >>>>> OLD TEXT: >>>>> Most deployments will have VMs with only L2 capabilities that >>>>> may not support L3. >>>>> NEW TEXT: >>>>> Most deployments will have VMs with only L2 capabilities and not have >>>>> an IP address assigned. >>>>> >>>> >>>> [ag2] Do you have a reference for this (i.e. that most deployments have >>>> VMs without an IP address)? Normally I would think VMs would have an IP >>>> address. It's just that they are segregated into segments and, without an >>>> intervening router, they are restricted to communicate only within their >>>> subnet. >>>> >>> GIM3>> Would the following text be acceptable: >>> >>> Deployments might have VMs with only L2 capabilities and not have an IP >>> address assigned or, >>> in other cases, VMs are assigned IP address but are restricted to >>> communicate only within their subnet. >>> >>> >> [ag3] Yes, this is better. >> >> >>>>>> >>>>>>> >>>>>>>> >>> >>>>>>>> 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.) >>>>>> >>>>> GIM2>> I've added the following sentense in both places: >>>>> The implementation SHOULD have a reasonable upper bound on the number >>>>> of BFD sessions that can be created between the same pair of VTEPs. >>>>> >>>> >>>> [ag2] What is the criteria for determining what is reasonable? >>>> >>> GIM>> I usually understand that as requirement to make it controllable, >>> have configurable limit. Thus it will be up to an network operator to set >>> the limit. >>> >>>> >>>> >>>>> - What is the benefit of running BFD per VNI between a pair of VTEPs? >>>>>> >>>>> GIM2>> An alternative would be to run CFM between VMs, if there's the >>>>> need to monitor liveliness of the particular VM. Again, this is optional. >>>>> >>>> >>>> [ag2] I'm not sure how running per-VNI BFD between the VTEPs allows one >>>> to monitor the liveliness of VMs. >>>> >>> >> [ag3] I think you missed responding to this. I'm not sure of the value >> of running BFD per VNI between VTEPs. What am I getting that is not >> covered by running a single BFD session with VNI 0 between the 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 ]. >>>>>>>> >>>>>>>> *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 >>>>>>>> ]. 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. >>>>>>> >>>>>> --000000000000e2d9b4057b3b6ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

See below prefixed with [ag4].=

Thanks,
Anoop

On Wed, Nov 21, 2018 at 4:36 PM Greg Mirsky <= ;gregimirsky@gmail.com> wro= te:
Hi Anoop,
apologies for the miss. Is it the last outstanding? Let= 9;s bring it to the front then.

- What is the benefit of = running BFD per VNI between a pair of VTEPs?
GIM2>> An alternative would be to run CFM between VMs, if = there's the need to monitor liveliness of the particular VM. Again, thi= s is optional.=C2=A0

[ag2] I'm not sure how running per-VNI BFD between the VTEPs allows o= ne to monitor the liveliness of VMs.=C2=A0

[ag3] I think = you missed responding to this.=C2=A0 I'm not sure of the value of runni= ng BFD per VNI between VTEPs.=C2=A0 What am I getting that is not covered b= y running a single BFD session with VNI 0 between the VTEPs?
=C2= =A0
GIM3>> I've misspoken. Non-zero VNI is recomm= ended to be used to demultiplex BFD sessions between the same VTEPs. In sec= tion 6.1:
=C2=A0 =C2=A0The procedure for demultiplexing
=C2=A0 =C2=A0packets with Your Discriminator equal to 0 is different = from
=C2=A0 =C2=A0[RFC5880].=C2=A0 For such packets, the BFD sess= ion MUST be identified
=C2=A0 =C2=A0using the inner headers, i.e.= , the source IP and the destination IP
=C2=A0 =C2=A0present in th= e IP header carried by the payload of the VXLAN
=C2=A0 =C2=A0enca= psulated packet.=C2=A0 The VNI of the packet SHOULD be used to derive
=
=C2=A0 =C2=A0interface-related information for demultiplexing the pack= et.

Hope that clarifies the use of non-zero = VNI in VXLAN encapsulation of a BFD control packet.

[ag4] This tells me how the VNI is used for BFD = packets being sent/received.=C2=A0 What is the use case/benefit of doing th= at?=C2=A0 I am creating a special interface with VNI 0 just for BFD.=C2=A0 = Why do I now need to run BFD on any/all of the other VNIs?=C2=A0 As a devel= oper, if I read this spec, should I be building this capability or not?=C2= =A0 Basically what I'm getting at is I think the draft should recommend= using VNI 0.=C2=A0 If there is a convincing use case for running BFD over = other VNIs serviced by that VTEP, then that needs to be explained.=C2=A0 Bu= t as I mentioned before, this leads to scaling issues.=C2=A0 So given the s= caling issues, it would be good if an implementation only needed to worry a= bout sending BFD messages on VNI 0.
=C2=A0

Regards= ,
Greg

On Tu= e, Nov 20, 2018 at 12:14 PM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Gre= g,

Please see inline prefixed by [ag3].

Thanks,
Anoop

<= div dir=3D"ltr">On Fri, Nov 16, 2018 at 5:29 PM Greg Mirsky <gregimirsky@gmail.com&g= t; wrote:
Hi Anoop,
thank you for the discussion. Ple= ase find my responses tagged GIM3>>. Also, attached diff and the upda= ted working version of the draft. Hope we're converging.

=
Regards,
Greg

On Wed, Nov 14, 2018 at 11:00 PM Anoop Ghanwani <anoop@alumni.duke.edu&= gt; wrote:
Hi Greg,

Please see inline prefixed with [ag= 2].

Thanks,
Anoop
On Wed, Nov 14, 2018 at 9:45 = AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Anoop,
tha= nk you for the expedient=C2=A0response. I am glad that some=C2=A0of my resp= onses have addressed your concerns. Please find followup notes in-line tagg= ed GIM2>>. I've attached the diff to highlight the updates applie= d in the working version. Let me know if these are acceptable changes.

Regards,
Greg

On Tue, Nov 13, 2018 at 12:30 PM Anoop Ghanwani <= anoop@alumni.duk= e.edu> wrote:
Hi Greg,

Please see inline prefixe= d with [ag].

Thanks,
Anoop

On Tue, Nov 13, 2018 at 11:34 AM Greg= Mirsky <greg= imirsky@gmail.com> wrote:
Hi Anoop,
many th= anks for the thorough review and detailed comments. Please find my answers,= this time for real, in-line tagged GIM>>.

R= egards,
Greg

On Thu, Nov 8, 2018 at 1:58 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
=
Here are my comments.

Thanks,
Ano= op

=3D=3D

Philosophical

Since VXLAN is not an IETF standard, should we be d= efining a standard for running BFD on it?=C2=A0 Should we define BFD over G= eneve instead which is the official WG selection?=C2=A0 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 yea= rs later. I understand that Down Reference, i.e., using informational RFC a= s the normative reference, is not an unusual situation.
=

[ag] OK.=C2=A0 I'm not= an expert on this part so unless someone else that is an expert (chairs, A= D?) can comment on it, I'll just let it go.
=C2=A0
=C2=A0

Technical<= /div>

Section 1:

This part need= s to be rewritten:
>>>
Th= e 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 t= o parse and, given IRB,
GIM>> Would the= following text be acceptable:
OLD TEXT:
=C2=A0 = =C2=A0VXLAN is typically deployed in data centers interconnecting
=C2=A0 =C2=A0virtualized hosts, which may be spread across multiple racks.= =C2=A0 The
=C2=A0 =C2=A0individual racks may be part of a differe= nt Layer 3 network, or they
=C2=A0 =C2=A0could be in a single Lay= er 2 network.=C2=A0 The VXLAN segments/overlays
=C2=A0 =C2=A0are = overlaid on top of Layer 3 network.
NEW TEXT:
VXLAN is typically deployed in data centers interconnect= ing virtualized=C2=A0
hosts of a tenant. VX= LAN addresses requirements of the Layer 2 and=C2=A0
Layer 3 data center network infrastructure in the presence of VMs = in=C2=A0
a multi-tenant environment, discus= sed in section 3 [RFC7348], by
=C2=A0provid= ing Layer 2 overlay scheme on a Layer 3 network.

[ag] This is a lot better.
=C2=A0

=C2=A0A VM can communicate with another VM only if they are on th= e same
VXLAN segment.
the last sentenc= e above is wrong.
GIM>> Section 4 in RFC= 7348 states:
Only VMs within the same VXLAN segment can communic= ate with=C2=A0each other.

[ag] VMs o= n different segments can communicate using routing/IRB, so even RFC 7348 is= wrong.=C2=A0 Perhaps the text should be modified so say -- "In the ab= sence of a router in the overlay, a VM can communicate...".
= =C2=A0
<= div>Section 3:
>>>
=C2=A0= Most deployments will have VMs with only L2 capabilities that
<= span style=3D"color:rgb(0,0,0);font-family:monospace;font-size:13.3333px;wh= ite-space:pre-wrap">may not support L3.
>>>
A= re you suggesting most deployments have VMs with no IP addresses/configurat= ion?
GIM>> Would re-word as follows:
OLD TEXT:
=C2=A0Most deployments will have VMs with only L= 2 capabilities that
=C2=A0may not support L3.
NEW TEXT:=
Deployments may have VMs with only L2 capabilities that do not s= upport L3.=C2=A0
=
<= div dir=3D"ltr">

[ag] I still don't understand this.=C2=A0 What does it mean fo= r a VM to not support L3?=C2=A0 No IP address, no default GW, something els= e?
GIM2>> VM communicates wi= th its VTEP which, in turn, originates VXLAN tunnel. VM is not required to = have IP address as it is VTEP's IP address that VM's MAC is associa= ted with. As for gateway, RFC 7348 discusses VXLAN gateway as the device th= at forwards traffice between VXLAN and non-VXLAN domains. Considering all t= hat, would the following change be acceptable:
OLD TEXT:
=C2=A0Most deployments will have VMs with only L2 capabilities that<= /div>
=C2=A0may not support L3.
NEW TEXT:
=C2=A0Most deployments will have VMs with only L2 capabilities and not ha= ve an IP address assigned.
<= br>
[ag2] Do you have a reference for this (i.e. that most deploy= ments have VMs without an IP address)?=C2=A0 Normally I would think VMs wou= ld have an IP address.=C2=A0 It's just that they are segregated into se= gments and, without an intervening router, they are restricted to communica= te only within their subnet.
GIM3>> Would the following text be acceptable:
Deployments might have VMs with only L2 capabil= ities and not have an IP address assigned or,
in other cases, VMs are assigned IP address but ar= e restricted to communicate only within their subnet.=C2=A0=C2=A0

[ag3] Yes, this= is better.

=C2=A0
<= div dir=3D"ltr">

>>>
Having= a hierarchical OAM model helps localize faults though it requires additional consideration.
&g= t;>>
What are the additional considerations?
GIM>> For example, coordinat= ion of BFD intervals across the OAM layers.=C2=A0=C2=A0
<= /div>

[ag] Can we mention them in the draft?
=C2= =A0

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=C2=A0=C2=A0A= 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.=C2=A0=C2=A0

[ag] The RF= C discusses the use of service nodes which is mentioned here.=C2=A0=C2=A0
=C2=A0
<= div dir=3D"ltr">

Sec= tion 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 l= ead to scaling issues given that VTEPs can support well in excess of 4K VNI= s.=C2=A0 Additionally, we should mention that with IRB, a given VNI may not= even exist on the destination VTEP.=C2=A0 Finally, what is the benefit of = doing this?=C2=A0 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 goo= d to explain what those are.
GIM>> Will add text in the Security Considerations section th= at VTEPs should have limit on number of BFD sessions.=C2=A0

[ag] I was hoping for two things:
- A = mention about the scalability issue right where per-VNI BFD is discussed.= =C2=A0 (Not sure why that is a security issue/consideration.)
GIM2>> I've added the following sente= nse in both places:
The implementation SHOULD have a reasonable u= pper bound on the number of BFD sessions that can be created between the sa= me pair of VTEPs.=C2=A0

=
[ag2] What is the criteria for determining what is reasonable?
GIM>> I usually understand th= at as requirement to make it controllable, have configurable limit. Thus it= will be up to an network operator to set the limit.=C2=A0
=C2=A0
=
- What is the benefit of running BFD p= er VNI between a pair of VTEPs?
GI= M2>> An alternative would be to run CFM between VMs, if there's t= he need to monitor liveliness of the particular VM. Again, this is optional= .=C2=A0

[ag2] I'= ;m not sure how running per-VNI BFD between the VTEPs allows one to monitor= the liveliness of VMs.=C2=A0

[ag3] I think you missed re= sponding to this.=C2=A0 I'm not sure of the value of running BFD per VN= I between VTEPs.=C2=A0 What am I getting that is not covered by running a s= ingle BFD session with VNI 0 between the VTEPs?
=C2=A0
=C2=A0
<= div>=C2=A0

Secti= ons 5.1 and 6.1

In 5.1 we have
>>&= gt;
The inner MAC frame carrying the BFD pay= load 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=C2=A0
>>>
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].
For such packets, the BFD session MUST be identified
using the inner headers, i.e., the source IP and the d=
estination 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 righ= t, Destination and source IP addresses likely are the same in this case. Wi= ll 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?=C2=A0

[ag] Yes, I th= ink that should work.=C2=A0

Editorial

[a= g] Agree with all comments on this section.=C2=A0
<= div dir=3D"ltr">

- Terminology section should be renamed to a= cronyms.
GIM>> Accepted=C2=A0
- Docume= nt would benefit from a thorough editorial scrub, but maybe that will happe= n once it gets to the RFC editor.
GIM>> = Will certainly have helpful comments from ADs and RFC editor.

<= div>Section 1
>>>
"V= irtual eXtensible Local Area Network" (VXLAN) [RFC7348

Section 7
<= br>
VTEP's -> VTEPs
GIM>> Yes, thank you.=C2=A0
 --000000000000e2d9b4057b3b6ae9--