From nobody Fri Nov 1 04:51:15 2019 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 087CD120052; Thu, 31 Oct 2019 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 3DG3bStAetCz; Thu, 31 Oct 2019 09:43:29 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A3C120018; Thu, 31 Oct 2019 09:43:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 473rjs3MFrzklwL; Thu, 31 Oct 2019 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572540209; bh=DXQ9OZilrfvQMpy7tqQWM0MocOsv4VxMrC4pw2879uI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ThB12NYBh5OEZZJEqcQu98DKDG6i9b2ThIIVcplA7slFYNlNsNBlwyV8nc8iS3O0R +5VsRKjXvdutbJeg0ZTHDILXtCCHnMS+Wg2WhtHGQVCQp3D2SVxWSREUhj/xXQyUfE FLpDBJBA8xwn81fG9nWEPSJ1ht4RVeEY7KReOGOo= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 473rjq6ZXLzklwN; Thu, 31 Oct 2019 09:43:27 -0700 (PDT) Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP To: Anoop Ghanwani , Jeffrey Haas Cc: Greg Mirsky , Dinesh Dutt , Santosh P K , NVO3 , draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG , "T. Sridhar" , xiao.min2@zte.com.cn References: <1572400778.28051.7@smtp.gmail.com> <1a38424c-6bc1-4414-a7fd-c1e2105b581a@Spark> <1572435956.28051.12@smtp.gmail.com> <20191030203051.GD10145@pfrc.org> <20191030211742.GE10145@pfrc.org> <34b67556-a405-e4d7-7f72-d097f1201860@joelhalpern.com> <51780FD6-DC02-435B-B18C-CA38C7267F67@pfrc.org> From: "Joel M. Halpern" Message-ID: <54bf9f19-f43d-9512-33f6-fb2f048bad09@joelhalpern.com> Date: Thu, 31 Oct 2019 12:43:25 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 01 Nov 2019 04:51:13 -0700 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, 31 Oct 2019 16:43:32 -0000 I do assume there is no chance of forwarding the packet. The reason for specifying it is to be clear what the VTEP is expected to do in that case. (Which does mean the text has marginal, but non-zero value.) Yours, Joel On 10/31/2019 12:33 PM, Anoop Ghanwani wrote: > What is the definition of management VNI?  Is it that there is no VAP > corresponding to that VNI or something else?  If there is no VAP, then > there is no chance of forwarding such packets anyway. > > Anoop > > On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas > wrote: > > I also agree with Joel. > > -- Jeff > > > > On Oct 31, 2019, at 11:59 AM, Joel M. Halpern > > wrote: > > > > Explicitly restricting the discard behavior to the management VNI > takes care of my concern. > > > > Thank you, > > Joel > > > > On 10/31/2019 11:48 AM, Greg Mirsky wrote: > >> Hi Jeff, > >> thank you for the detailed clarification of your questions. > Please find my follow-up notes in-lined tagged GIM2>>. > >> Regards, > >> Greg > >> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas >> wrote: > >>    Greg, > >>    On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote: > >>     > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas > > >>    >> wrote: > >>     > > >>     > > Greg, > >>     > > > >>     > > From the updated text: > >>     > > > >>     > > "At the same time, a service layer BFD session may be used > >>    between the > >>     > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault > >>    management. In > >>     > > such case, for VTEPs BFD Control packets of that session are > >>     > > indistinguishable from data packets.  If end-to-end defect > >>    detection is > >>     > > realized as the set of concatenated OAM domains, e.g., > VM1-1 - > >>    IP1 -- > >>     > > IP2 - VM2-1, then the BFD session over VXLAN between > VTEPs SHOULD > >>     > > follow the procedures described in Section 6.8.17 > [RFC5880]." > >>     > > > >>     > > In the case that two VMs are running BFD to each other > as a user > >>     > > application > >>     > > rather than as part of the virtualized environment, it's > >>    unlikely that > >>     > > they'd be treated as concatenated domains.  To do so, the > >>    tenant VMs would > >>     > > have to have a sense that they are indeed virtual. > >>     > > > >>     > > Is your intent in this text that BFD implementations on the > >>    server should > >>     > > detect BFD sessions between servers and change them to a > >>    concatenated > >>     > > session? > >>     > > > >>     > GIM>> No, we do not suggest that the concatenation of BFD > sessions be > >>     > automagical. That may be controlled via the management > plane though. > >>    Then my suggestion is we may not want this text. > >>    It's fine to say "if tenants want to run BFD to each other, > and that is > >>    standard BFD (RFC 5881) from the perspective of those > tenants" if that's > >>    your intent.  Leave automagic out of the spec. :-) > >> GIM2>> I'd take the passage referring to the concatenated path > out. That will leave it as: > >>    At the same time, a service layer BFD session may be used > between the > >>    tenants of VTEPs IP1 and IP2 to provide end-to-end fault > management. > >>    In such case, for VTEPs BFD Control packets of that session are > >>    indistinguishable from data packets. > >>     > > Section 5 comment: > >>     > > > >>     > > :   The UDP destination port and the TTL of the inner IP > packet > >>    MUST be > >>     > > :   validated to determine if the received packet can be > >>    processed by > >>     > > :   BFD.  BFD Control packets with unknown MAC address > MUST NOT be > >>     > > :   forwarded to VMs. > >>     > > > >>     > > I'd suggest pushing the second sentence into the prior > section > >>    since it > >>     > > deals with MAC addresses rather than the UDP procedures. > >>     > > > >>     > GIM>> Could you please clarify your suggestion - move to > Section > >>    4 or to > >>     > the preceding paragraph? I think it is the latter but > wanted to > >>    make sure. > >>    Full section 5 from your draft-8 candidate: > >>    : 5.  Reception of BFD Packet from VXLAN Tunnel > >>    : > >>    :    Once a packet is received, the VTEP MUST validate the > packet.     If the > >>    :    Destination MAC of the inner Ethernet frame matches one > of the MAC > >>    :    addresses associated with the VTEP the packet MUST be > processed > >>    :    further.  If the Destination MAC of the inner Ethernet frame > >>    doesn't > >>    :    match any of VTEP's MAC addresses, then the processing > of the > >>    :    received VXLAN packet MUST follow the procedures > described in > >>    :    Section 4.1 [RFC7348]. > >>    It's not clear what that procedure is, with respect to BFD. > Section 4.1 > >>    basically says is that when a mapping is discovered, deliver > it to > >>    that VM > >>    with headers removed. > >>    Section 4.1 really doesn't discuss dropping behavior. > >>    : > >>    :    The UDP destination port and the TTL of the inner IP > packet MUST be > >>    :    validated to determine if the received packet can be > processed by > >>    :    BFD. > >>    This is fine. > >>    :    BFD Control packets with unknown MAC address MUST NOT be > >>    :    forwarded to VMs. > >>    This appears to be clarifying the missing point in the prior > >>    paragraph.  If > >>    that's the case, why is this sentence not part of the prior > paragraph? > >> GIM>> So I thought. Moving the sentence to the first paragraph > highlighted the contradiction others had pointed earlier: > >> On the one hand: > >>    If the Destination MAC of the inner Ethernet frame doesn't > >>    match any of VTEP's MAC addresses, then the processing of the > >>    received VXLAN packet MUST follow the procedures described in > >>    Section 4.1 [RFC7348]. > >> To which we add: > >>    BFD Control packets with unknown MAC address > >>    MUST NOT be forwarded to VMs. > >> But the unknown MACs are treated as BUM according to the last > paragraph in Section 4.2 of RFC 7348: > >>    Note that multicast frames and "unknown MAC destination" > frames are > >>    also sent using the multicast tree, similar to the broadcast > frames. > >> In light of that, can this draft require that BFD packets with > unknown MAC be dropped and not flooded over the corresponding to the > VNI domain? I think that in addition to moving the sentence up the > statement must be updated: > >> OLD TEXT: > >>    BFD Control packets with unknown MAC address > >>    MUST NOT be forwarded to VMs. > >> NEW TEXT: > >>    If the BFD session is using the Management VNI (Section 6), > >>    BFD Control packets with unknown MAC address > >>    MUST NOT be forwarded to VMs. > >>  Comments? Suggestions? > >>    -- Jeff > From nobody Fri Nov 1 04:51:22 2019 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 3D20912082D; Thu, 31 Oct 2019 13:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6O3Rh8fxDjGw; Thu, 31 Oct 2019 13:10:05 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 9E46512022C; Thu, 31 Oct 2019 13:10:04 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id y3so7994530ljj.6; Thu, 31 Oct 2019 13:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FuZ/Xbi33I3c2ZzjSAsRakQ+Nz66IE2J6Oo55tg3NfM=; b=pYLlsYGyr0zlN8ScTI8usScRiopuXe4f/5QiGR/zGXMHn4K4iLr4ZbCYKdgx3SKGph 6tI6EKwU7M2SVsKuUHhswu2lrI82FefS/lDkfFImKTQRvH4lcvqfJqvVXPk+Wl01xSkJ OKRcGZBxsRTUjbT2Tigmqu+6FmVb0ATQe93kiGPDMkf01dpTkGRnGlTMZic6uDZv68jh DeWTWyScxqB/C8bgoc94i5wxMs/TP669jJ3Gt9lt2IUZokL8EuSP1dAMDLQHDoh9y3vT AvjyMfBvePN7qW4P3MrTGgLeaOuSKhb7/yS+OK9nUXH0weX/rDFvnCmfk83fWgy5KX+T PiJA== 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=FuZ/Xbi33I3c2ZzjSAsRakQ+Nz66IE2J6Oo55tg3NfM=; b=n2Hy7WO99A6ctGFGBKqFlIcF9V1h5ylNoSJW3a/tNrUy3FmC18XfSRVhU2asMyBJQD jHBprZI171Q98xx+XdmhJddkv0k3ebqq0QWoapyZSxF9ci7QVZIU6yiTP2crYOZzoTiv 0287x5+qSz5L+SJix63nvI4RtE7wsBABnQe4osMc2U0l3LRVG6oKxfqgbS708Tac6O8X tTQoJGCF3mI/xexRKkJb+BjdaDuysVcWOw652qFL7AT9hC+lGhr1C6RoERNbou98RPdY TxQMo7yG4u4pIu51YoA+4AdeYxwO6Ee5d8HsldqEBtNN8mVu5QcUg+EWuKQC70jBXER4 CJPg== X-Gm-Message-State: APjAAAUgK2vxj4b6vPsGqcoP++8rsjxVuYr7vsewThiTl3DNEml4u2HT anyfsitRDk9UiIYcN9EroX4t5xMDo5bgXS/v+3Q= X-Google-Smtp-Source: APXvYqyNsAuVbwuRUG6jE+UNxBxLMmBm4F596E3bNqemqxbZjb+MDBPk1AGwT3LF0Q6E5fwUvYBlT0LWoVbrOL4SPho= X-Received: by 2002:a2e:8146:: with SMTP id t6mr5545186ljg.66.1572552602733; Thu, 31 Oct 2019 13:10:02 -0700 (PDT) MIME-Version: 1.0 References: <1572400778.28051.7@smtp.gmail.com> <1a38424c-6bc1-4414-a7fd-c1e2105b581a@Spark> <1572435956.28051.12@smtp.gmail.com> <20191030203051.GD10145@pfrc.org> <20191030211742.GE10145@pfrc.org> <34b67556-a405-e4d7-7f72-d097f1201860@joelhalpern.com> <51780FD6-DC02-435B-B18C-CA38C7267F67@pfrc.org> In-Reply-To: <51780FD6-DC02-435B-B18C-CA38C7267F67@pfrc.org> From: Greg Mirsky Date: Thu, 31 Oct 2019 13:09:50 -0700 Message-ID: Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP To: Jeffrey Haas Cc: "Joel M. Halpern" , Dinesh Dutt , Anoop Ghanwani , Santosh P K , NVO3 , draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG , "T. Sridhar" , xiao.min2@zte.com.cn Content-Type: multipart/alternative; boundary="00000000000046d92205963a6f41" Archived-At: X-Mailman-Approved-At: Fri, 01 Nov 2019 04:51:13 -0700 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, 31 Oct 2019 20:10:09 -0000 --00000000000046d92205963a6f41 Content-Type: text/plain; charset="UTF-8" Thank you, Joel and Jeff. I'll upload the working version shortly. I hope that updates will address all comments and concerns shared on several threads by Anoop, Dinesh, Joel, and many others. I greatly value and appreciate the time, expertise, and consideration you've given to this work, and have shared with me. Regards, Greg On Thu, Oct 31, 2019 at 9:22 AM Jeffrey Haas wrote: > I also agree with Joel. > > -- Jeff > > > > On Oct 31, 2019, at 11:59 AM, Joel M. Halpern > wrote: > > > > Explicitly restricting the discard behavior to the management VNI takes > care of my concern. > > > > Thank you, > > Joel > > > > On 10/31/2019 11:48 AM, Greg Mirsky wrote: > >> Hi Jeff, > >> thank you for the detailed clarification of your questions. Please find > my follow-up notes in-lined tagged GIM2>>. > >> Regards, > >> Greg > >> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas jhaas@pfrc.org>> wrote: > >> Greg, > >> On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky wrote: > >> > On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Haas >> > wrote: > >> > > >> > > Greg, > >> > > > >> > > From the updated text: > >> > > > >> > > "At the same time, a service layer BFD session may be used > >> between the > >> > > tenants of VTEPs IP1 and IP2 to provide end-to-end fault > >> management. In > >> > > such case, for VTEPs BFD Control packets of that session are > >> > > indistinguishable from data packets. If end-to-end defect > >> detection is > >> > > realized as the set of concatenated OAM domains, e.g., VM1-1 - > >> IP1 -- > >> > > IP2 - VM2-1, then the BFD session over VXLAN between VTEPs > SHOULD > >> > > follow the procedures described in Section 6.8.17 [RFC5880]." > >> > > > >> > > In the case that two VMs are running BFD to each other as a user > >> > > application > >> > > rather than as part of the virtualized environment, it's > >> unlikely that > >> > > they'd be treated as concatenated domains. To do so, the > >> tenant VMs would > >> > > have to have a sense that they are indeed virtual. > >> > > > >> > > Is your intent in this text that BFD implementations on the > >> server should > >> > > detect BFD sessions between servers and change them to a > >> concatenated > >> > > session? > >> > > > >> > GIM>> No, we do not suggest that the concatenation of BFD > sessions be > >> > automagical. That may be controlled via the management plane > though. > >> Then my suggestion is we may not want this text. > >> It's fine to say "if tenants want to run BFD to each other, and that > is > >> standard BFD (RFC 5881) from the perspective of those tenants" if > that's > >> your intent. Leave automagic out of the spec. :-) > >> GIM2>> I'd take the passage referring to the concatenated path out. > That will leave it as: > >> At the same time, a service layer BFD session may be used between the > >> tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. > >> In such case, for VTEPs BFD Control packets of that session are > >> indistinguishable from data packets. > >> > > Section 5 comment: > >> > > > >> > > : The UDP destination port and the TTL of the inner IP packet > >> MUST be > >> > > : validated to determine if the received packet can be > >> processed by > >> > > : BFD. BFD Control packets with unknown MAC address MUST NOT > be > >> > > : forwarded to VMs. > >> > > > >> > > I'd suggest pushing the second sentence into the prior section > >> since it > >> > > deals with MAC addresses rather than the UDP procedures. > >> > > > >> > GIM>> Could you please clarify your suggestion - move to Section > >> 4 or to > >> > the preceding paragraph? I think it is the latter but wanted to > >> make sure. > >> Full section 5 from your draft-8 candidate: > >> : 5. Reception of BFD Packet from VXLAN Tunnel > >> : > >> : Once a packet is received, the VTEP MUST validate the packet. > If the > >> : Destination MAC of the inner Ethernet frame matches one of the > MAC > >> : addresses associated with the VTEP the packet MUST be processed > >> : further. If the Destination MAC of the inner Ethernet frame > >> doesn't > >> : match any of VTEP's MAC addresses, then the processing of the > >> : received VXLAN packet MUST follow the procedures described in > >> : Section 4.1 [RFC7348]. > >> It's not clear what that procedure is, with respect to BFD. Section > 4.1 > >> basically says is that when a mapping is discovered, deliver it to > >> that VM > >> with headers removed. > >> Section 4.1 really doesn't discuss dropping behavior. > >> : > >> : The UDP destination port and the TTL of the inner IP packet > MUST be > >> : validated to determine if the received packet can be processed > by > >> : BFD. > >> This is fine. > >> : BFD Control packets with unknown MAC address MUST NOT be > >> : forwarded to VMs. > >> This appears to be clarifying the missing point in the prior > >> paragraph. If > >> that's the case, why is this sentence not part of the prior > paragraph? > >> GIM>> So I thought. Moving the sentence to the first paragraph > highlighted the contradiction others had pointed earlier: > >> On the one hand: > >> If the Destination MAC of the inner Ethernet frame doesn't > >> match any of VTEP's MAC addresses, then the processing of the > >> received VXLAN packet MUST follow the procedures described in > >> Section 4.1 [RFC7348]. > >> To which we add: > >> BFD Control packets with unknown MAC address > >> MUST NOT be forwarded to VMs. > >> But the unknown MACs are treated as BUM according to the last paragraph > in Section 4.2 of RFC 7348: > >> Note that multicast frames and "unknown MAC destination" frames are > >> also sent using the multicast tree, similar to the broadcast frames. > >> In light of that, can this draft require that BFD packets with unknown > MAC be dropped and not flooded over the corresponding to the VNI domain? I > think that in addition to moving the sentence up the statement must be > updated: > >> OLD TEXT: > >> BFD Control packets with unknown MAC address > >> MUST NOT be forwarded to VMs. > >> NEW TEXT: > >> If the BFD session is using the Management VNI (Section 6), > >> BFD Control packets with unknown MAC address > >> MUST NOT be forwarded to VMs. > >> Comments? Suggestions? > >> -- Jeff > > --00000000000046d92205963a6f41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Joel and Jeff.

I'll uplo= ad the working version shortly. I hope that updates will address all commen= ts and concerns shared on several threads by Anoop, Dinesh, Joel, and many = others. I greatly value and appreciate the time, expertise, and considerati= on you've given to this work, and have shared with me.

Regards,
Greg

=
On Thu, Oct 31, 2019 at 9:22 AM Jeffr= ey Haas <jhaas@pfrc.org> wrote:=
I also agree wi= th Joel.

-- Jeff


> On Oct 31, 2019, at 11:59 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> Explicitly restricting the discard behavior to the management VNI take= s care of my concern.
>
> Thank you,
> Joel
>
> On 10/31/2019 11:48 AM, Greg Mirsky wrote:
>> Hi Jeff,
>> thank you for the detailed clarification of your questions. Please= find my follow-up notes in-lined tagged GIM2>>.
>> Regards,
>> Greg
>> On Wed, Oct 30, 2019 at 2:14 PM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:=
>>=C2=A0 =C2=A0 Greg,
>>=C2=A0 =C2=A0 On Wed, Oct 30, 2019 at 01:58:30PM -0700, Greg Mirsky= wrote:
>>=C2=A0 =C2=A0 =C2=A0> On Wed, Oct 30, 2019 at 1:27 PM Jeffrey Ha= as <jhaas@pfrc.org
>>=C2=A0 =C2=A0 <mailto:jhaas@pfrc.org>> wrote:
>>=C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0> > Greg,
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > From the updated text:
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > "At the same time, a service lay= er BFD session may be used
>>=C2=A0 =C2=A0 between the
>>=C2=A0 =C2=A0 =C2=A0> > tenants of VTEPs IP1 and IP2 to provi= de end-to-end fault
>>=C2=A0 =C2=A0 management. In
>>=C2=A0 =C2=A0 =C2=A0> > such case, for VTEPs BFD Control pack= ets of that session are
>>=C2=A0 =C2=A0 =C2=A0> > indistinguishable from data packets.= =C2=A0 If end-to-end defect
>>=C2=A0 =C2=A0 detection is
>>=C2=A0 =C2=A0 =C2=A0> > realized as the set of concatenated O= AM domains, e.g., VM1-1 -
>>=C2=A0 =C2=A0 IP1 --
>>=C2=A0 =C2=A0 =C2=A0> > IP2 - VM2-1, then the BFD session ove= r VXLAN between VTEPs SHOULD
>>=C2=A0 =C2=A0 =C2=A0> > follow the procedures described in Se= ction 6.8.17 [RFC5880]."
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > In the case that two VMs are running = BFD to each other as a user
>>=C2=A0 =C2=A0 =C2=A0> > application
>>=C2=A0 =C2=A0 =C2=A0> > rather than as part of the virtualize= d environment, it's
>>=C2=A0 =C2=A0 unlikely that
>>=C2=A0 =C2=A0 =C2=A0> > they'd be treated as concatenated= domains.=C2=A0 To do so, the
>>=C2=A0 =C2=A0 tenant VMs would
>>=C2=A0 =C2=A0 =C2=A0> > have to have a sense that they are in= deed virtual.
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > Is your intent in this text that BFD = implementations on the
>>=C2=A0 =C2=A0 server should
>>=C2=A0 =C2=A0 =C2=A0> > detect BFD sessions between servers a= nd change them to a
>>=C2=A0 =C2=A0 concatenated
>>=C2=A0 =C2=A0 =C2=A0> > session?
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> GIM>> No, we do not suggest that the= concatenation of BFD sessions be
>>=C2=A0 =C2=A0 =C2=A0> automagical. That may be controlled via th= e management plane though.
>>=C2=A0 =C2=A0 Then my suggestion is we may not want this text.
>>=C2=A0 =C2=A0 It's fine to say "if tenants want to run BFD= to each other, and that is
>>=C2=A0 =C2=A0 standard BFD (RFC 5881) from the perspective of those= tenants" if that's
>>=C2=A0 =C2=A0 your intent.=C2=A0 Leave automagic out of the spec. := -)
>> GIM2>> I'd take the passage referring to the concatenate= d path out. That will leave it as:
>>=C2=A0 =C2=A0 At the same time, a service layer BFD session may be = used between the
>>=C2=A0 =C2=A0 tenants of VTEPs IP1 and IP2 to provide end-to-end fa= ult management.
>>=C2=A0 =C2=A0 In such case, for VTEPs BFD Control packets of that s= ession are
>>=C2=A0 =C2=A0 indistinguishable from data packets.
>>=C2=A0 =C2=A0 =C2=A0> > Section 5 comment:
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > :=C2=A0 =C2=A0The UDP destination por= t and the TTL of the inner IP packet
>>=C2=A0 =C2=A0 MUST be
>>=C2=A0 =C2=A0 =C2=A0> > :=C2=A0 =C2=A0validated to determine = if the received packet can be
>>=C2=A0 =C2=A0 processed by
>>=C2=A0 =C2=A0 =C2=A0> > :=C2=A0 =C2=A0BFD.=C2=A0 BFD Control = packets with unknown MAC address MUST NOT be
>>=C2=A0 =C2=A0 =C2=A0> > :=C2=A0 =C2=A0forwarded to VMs.
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> > I'd suggest pushing the second se= ntence into the prior section
>>=C2=A0 =C2=A0 since it
>>=C2=A0 =C2=A0 =C2=A0> > deals with MAC addresses rather than = the UDP procedures.
>>=C2=A0 =C2=A0 =C2=A0> >
>>=C2=A0 =C2=A0 =C2=A0> GIM>> Could you please clarify your = suggestion - move to Section
>>=C2=A0 =C2=A0 4 or to
>>=C2=A0 =C2=A0 =C2=A0> the preceding paragraph? I think it is the= latter but wanted to
>>=C2=A0 =C2=A0 make sure.
>>=C2=A0 =C2=A0 Full section 5 from your draft-8 candidate:
>>=C2=A0 =C2=A0 : 5.=C2=A0 Reception of BFD Packet from VXLAN Tunnel<= br> >>=C2=A0 =C2=A0 :
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 Once a packet is received, the VTEP MU= ST validate the packet.=C2=A0 =C2=A0 =C2=A0If the
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 Destination MAC of the inner Ethernet = frame matches one of the MAC
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 addresses associated with the VTEP the= packet MUST be processed
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 further.=C2=A0 If the Destination MAC = of the inner Ethernet frame
>>=C2=A0 =C2=A0 doesn't
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 match any of VTEP's MAC addresses,= then the processing of the
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 received VXLAN packet MUST follow the = procedures described in
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 Section 4.1 [RFC7348].
>>=C2=A0 =C2=A0 It's not clear what that procedure is, with respe= ct to BFD.=C2=A0 Section 4.1
>>=C2=A0 =C2=A0 basically says is that when a mapping is discovered, = deliver it to
>>=C2=A0 =C2=A0 that VM
>>=C2=A0 =C2=A0 with headers removed.
>>=C2=A0 =C2=A0 Section 4.1 really doesn't discuss dropping behav= ior.
>>=C2=A0 =C2=A0 :
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 The UDP destination port and the TTL o= f the inner IP packet MUST be
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 validated to determine if the received= packet can be processed by
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 BFD.
>>=C2=A0 =C2=A0 This is fine.
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 BFD Control packets with unknown MAC a= ddress MUST NOT be
>>=C2=A0 =C2=A0 :=C2=A0 =C2=A0 forwarded to VMs.
>>=C2=A0 =C2=A0 This appears to be clarifying the missing point in th= e prior
>>=C2=A0 =C2=A0 paragraph.=C2=A0 If
>>=C2=A0 =C2=A0 that's the case, why is this sentence not part of= the prior paragraph?
>> GIM>> So I thought. Moving the sentence to the first paragra= ph highlighted the contradiction others had pointed earlier:
>> On the one hand:
>>=C2=A0 =C2=A0 If the Destination MAC of the inner Ethernet frame do= esn't
>>=C2=A0 =C2=A0 match any of VTEP's MAC addresses, then the proce= ssing of the
>>=C2=A0 =C2=A0 received VXLAN packet MUST follow the procedures desc= ribed in
>>=C2=A0 =C2=A0 Section 4.1 [RFC7348].
>> To which we add:
>>=C2=A0 =C2=A0 BFD Control packets with unknown MAC address
>>=C2=A0 =C2=A0 MUST NOT be forwarded to VMs.
>> But the unknown MACs are treated as BUM according to the last para= graph in Section 4.2 of RFC 7348:
>>=C2=A0 =C2=A0 Note that multicast frames and "unknown MAC dest= ination" frames are
>>=C2=A0 =C2=A0 also sent using the multicast tree, similar to the br= oadcast frames.
>> In light of that, can this draft require that BFD packets with unk= nown MAC be dropped and not flooded over the corresponding to the VNI domai= n? I think that in addition to moving the sentence up the statement must be= updated:
>> OLD TEXT:
>>=C2=A0 =C2=A0 BFD Control packets with unknown MAC address
>>=C2=A0 =C2=A0 MUST NOT be forwarded to VMs.
>> NEW TEXT:
>>=C2=A0 =C2=A0 If the BFD session is using the Management VNI (Secti= on 6),
>>=C2=A0 =C2=A0 BFD Control packets with unknown MAC address
>>=C2=A0 =C2=A0 MUST NOT be forwarded to VMs.
>>=C2=A0 Comments? Suggestions?
>>=C2=A0 =C2=A0 -- Jeff

--00000000000046d92205963a6f41-- From nobody Fri Nov 1 08:46:17 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C512092F; Fri, 1 Nov 2019 08:46:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-large-packets-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <157262316031.32059.10374470852114581170@ietfa.amsl.com> Date: Fri, 01 Nov 2019 08:46:00 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 15:46:07 -0000 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 Encapsulated in Large Packets Authors : Jeffrey Haas Albert Fu Filename : draft-ietf-bfd-large-packets-02.txt Pages : 7 Date : 2019-11-01 Abstract: The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-large-packets-02 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-large-packets-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/ From nobody Fri Nov 1 08:49:12 2019 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 CB1A512092D for ; Fri, 1 Nov 2019 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6lw6NF_rJKIA for ; Fri, 1 Nov 2019 08:49:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D531212091F for ; Fri, 1 Nov 2019 08:49:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B415B1E2D3; Fri, 1 Nov 2019 11:52:45 -0400 (EDT) Date: Fri, 1 Nov 2019 11:52:44 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: draft-ietf-bfd-large-packets-02 Message-ID: <20191101155244.GA30539@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Fri, 01 Nov 2019 15:49:11 -0000 Working Group, This version attempts to roll up all discussion points to date. Your further review is appreciated. -- Jeff and Albert ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 01 Nov 2019 08:46:00 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-large-packets-02.txt 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 Encapsulated in Large Packets Authors : Jeffrey Haas Albert Fu Filename : draft-ietf-bfd-large-packets-02.txt Pages : 7 Date : 2019-11-01 Abstract: The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-large-packets-02 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-large-packets-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/ ----- End forwarded message ----- From nobody Fri Nov 1 08:51:48 2019 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 B84DA1208DB for ; Fri, 1 Nov 2019 08:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GRVArlB1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QfAGRLyo 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 twbCcYjRf3re for ; Fri, 1 Nov 2019 08:51:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0FA1208E6 for ; Fri, 1 Nov 2019 08:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3400; q=dns/txt; s=iport; t=1572623504; x=1573833104; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gEMqELaeLmjPkSunD+M1t54HkMI0OUDAiSvcMovEG/E=; b=GRVArlB1ISKItnbU+1wQj+ZPrxhqAChChXhUWRwR0dWAaZ2kV7ADpFJ3 AaKMOGf4fEYnA+7cIe+Ww87wM1UEFpggtV8YXqQvOuXXWQ6T8kJOLNL25 QpgspUk97K/ArlkLjH1kzijGmXGa2O446umbXn5+XKBDW7h72/nQrxVuK E=; IronPort-PHdr: =?us-ascii?q?9a23=3AIVe4phPEWi6rdajYDJQl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAACrU7xd/5xdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFsAgEBAQELAYFKUAVsWCAECyqEKINGA4p2ToI?= =?us-ascii?q?Ql3yCUgNUCQEBAQwBASMKAgEBhEACF4NkJDcGDgIDCwEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhVEBAQEBAxIREQwBATgPAgEIDgMDAQIDAiYCAgIwFQgIAgQBEiKDAAGCRgM?= =?us-ascii?q?uAQ6nMgKBOIhgdYEygn4BAQWBOAIOQUCCThiCFwmBDigBjBAYgUA/gTgfgkw?= =?us-ascii?q?+gmIBAQIBARaBRxeCeTKCLI99nXkKgiSHEY4kG4I8coZoj0+OQIgukSYCBAI?= =?us-ascii?q?EBQIOAQEFgWgjgVhwFRpLAYJBCUcRFIMGg3OFFIU/dIEojUQBAQ?= X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208";a="654065362" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 15:51:43 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1FphZ8006274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 15:51:43 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 10:51:43 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 10:51:42 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 10:51:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J7q0l2vuUSpXHOjaeTYE20SeJeoyBl1y3oS8rl0kGH1it0GlPM9z4JO9exlEGi6qgEHSnfdCOG2SpZHcIS/spZKG6fUgWcLgx/s/6kMk4t3YYhC06fvDeLqPSw3xiocIaKUbnUB8kh8o986eJmDPFMbSzulNUdkhQIXc5ejvG6o/l4jMeHS+jPyIXebww/tyNH7z5K8tGyRcS2cGxpsifEVj5/s5wSegUYCROD3PE/LUBKUnYFHpsIFo3VINVrXziyI78Y5zNWY7od1CDfkhkNbiwf7BztbqpM43Pl4al3TyGx1Yea5RCQNTmQLJBSpMAU1zDVjgGgH1k1kbAWHcCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gEMqELaeLmjPkSunD+M1t54HkMI0OUDAiSvcMovEG/E=; b=nS6+zJK7Tjx7Ttm0sarawYPqa6VI9mBtZymWjYAu/VVJym9MO8cFpYY5/m4VsanTUmXHVs5ViL6q6HIGXLIeEZx1161hFxSc4FB3SrUmM6G3Ky9OVAUYl0K0maPE9GY2AwuIaRwZ1pcOOXv8K6bp6x1aWjMHGwj2loqddQKVHMqZu15w1gPU93cUk0bCTbuy10pv1rGTursrr0Xyxs2bPCe9jxBD1Qk6fAQ+0BlYPzqfP42fKWZzGCxdhJZIuzabzcN3LhM0EvH7mfWcLeN9Ukzvnc7XiRaqo1L23ZwVtSsmFyVVrNrpWL9I+tpNwHFmYqH+j7hyyx/YNFMd+sH4kA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gEMqELaeLmjPkSunD+M1t54HkMI0OUDAiSvcMovEG/E=; b=QfAGRLyobPa8VXRpD+LIwQn8FaflMw9fOOrsGA5nJpz7hd1LSe/pQJ8euGdAueYObugMo8jJRygXfIDS21O6oLVGWGCCxf5sTZdLViGpZ7v6sKrzdR3iNEMgUlcFE/19VpoSH4WWekJgqQlXKySrnGZty/bW9E4/ZJumuoT/6gM= Received: from MN2PR11MB4157.namprd11.prod.outlook.com (10.255.181.213) by MN2PR11MB4127.namprd11.prod.outlook.com (10.255.181.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.25; Fri, 1 Nov 2019 15:51:41 +0000 Received: from MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::88cb:fcc7:df90:124]) by MN2PR11MB4157.namprd11.prod.outlook.com ([fe80::88cb:fcc7:df90:124%5]) with mapi id 15.20.2408.024; Fri, 1 Nov 2019 15:51:41 +0000 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: draft-ietf-bfd-large-packets-02 Thread-Topic: draft-ietf-bfd-large-packets-02 Thread-Index: AQHVkMv1+DnR1SqMLUqXfetwBfFghad2M9oA Date: Fri, 1 Nov 2019 15:51:41 +0000 Message-ID: <3E7EB210-A5C1-4D48-A13F-08731AC8D3B0@cisco.com> References: <20191101155244.GA30539@pfrc.org> In-Reply-To: <20191101155244.GA30539@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:6900:eb73:e481:aee6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2de48774-b316-4bdf-9ac3-08d75ee36344 x-ms-traffictypediagnostic: MN2PR11MB4127: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(376002)(366004)(396003)(189003)(199004)(6486002)(8936002)(66446008)(7736002)(966005)(66574012)(486006)(2616005)(25786009)(46003)(476003)(5660300002)(2906002)(446003)(305945005)(8676002)(6512007)(6306002)(81156014)(11346002)(6436002)(33656002)(110136005)(2501003)(81166006)(186003)(6506007)(102836004)(99286004)(76116006)(76176011)(66946007)(64756008)(6246003)(14454004)(316002)(66556008)(6116002)(86362001)(478600001)(229853002)(66476007)(14444005)(71200400001)(58126008)(71190400001)(256004)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4127; H:MN2PR11MB4157.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5s2A+Sl6yeWuyC/L2YxPrlZLNQoudT/uYWRz3rDQU3nzGGuRXtjtT1nXU0laTqB5/G1GxphXL4fDmv4SL9uKI40pEcTPrvUWX/6syksuzawlb87bgJbOWVqlp67lqR5xBi0+yxil8s8EGX2Xg6rnwUjccVT32vn+pUfQFzlpIhd0zb/o0u/gW4jGqIbDlsJnchKq2naQ3GSt6Q2h2TflMv9tyazXDls85RNQc7+M2KYHUo5NRxHzGk9r0/G3P6t2ImdKa/sCGj9yJgvvKMhigKjQPUzSfRtXeQA0yqUkc6fBwi7IK2+VTFcZIglEC0MjiP5jiGV+D2M8HopwnY8nz76bYT5Uvn27tr6VSfwSkSSCoxuvffcWkoVN1U2weFHjudROjDA5YOesHTJzp1+vBetWhcAYeHjnTU82RBuJEuVKtvZh3JfWrg8IyWMpqhaLMFj4ZTaD9uZVhWWNm4psWzDkOvC4WgCYLmciapoHwEA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8D59383DA1ED1C4BB7A989AF9C46D1E8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2de48774-b316-4bdf-9ac3-08d75ee36344 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 15:51:41.0353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rMF7BBFPP/9cPtVLAw6w3bY9df5elEZOe5bOFowVJVkJkzFG/NOqyS/5XXbMAJXZVuyPf/uULfcA1NJcqJ/JjA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4127 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: 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: Fri, 01 Nov 2019 15:51:47 -0000 DQpUaGFua3MgSmVmZiBhbmQgQWxiZXJ0LiBJIHdpbGwgZ28gdGhyb3VnaCB0aGUgdmFyaW91cyBk aXNjdXNzaW9uIHBvaW50cyBhbmQgd2lsbCByZXZpZXcgdGhlIGxhdGVzdCByZXYuDQoNClJlZ2Fy ZHMsDQpSZXNoYWQuDQoNCu+7v09uIDIwMTktMTEtMDEsIDExOjQ5IEFNLCAiUnRnLWJmZCBvbiBi ZWhhbGYgb2YgSmVmZnJleSBIYWFzIiA8cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQoNCiAgICBXb3JraW5nIEdyb3VwLA0KICAgIA0K ICAgIFRoaXMgdmVyc2lvbiBhdHRlbXB0cyB0byByb2xsIHVwIGFsbCBkaXNjdXNzaW9uIHBvaW50 cyB0byBkYXRlLiAgWW91cg0KICAgIGZ1cnRoZXIgcmV2aWV3IGlzIGFwcHJlY2lhdGVkLg0KICAg IA0KICAgIC0tIEplZmYgYW5kIEFsYmVydA0KICAgIA0KICAgIC0tLS0tIEZvcndhcmRlZCBtZXNz YWdlIGZyb20gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIC0tLS0tDQogICAgDQogICAgRGF0ZTog RnJpLCAwMSBOb3YgMjAxOSAwODo0NjowMCAtMDcwMA0KICAgIEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KICAgIFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCiAgICBDYzogcnRnLWJm ZEBpZXRmLm9yZw0KICAgIFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLWxhcmdl LXBhY2tldHMtMDIudHh0DQogICAgDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K ICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2Fy ZGluZyBEZXRlY3Rpb24gV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBCRkQgRW5jYXBzdWxhdGVkIGluIExhcmdlIFBhY2tldHMNCiAgICAgICAgICAg IEF1dGhvcnMgICAgICAgICA6IEplZmZyZXkgSGFhcw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQWxiZXJ0IEZ1DQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYmZkLWxh cmdlLXBhY2tldHMtMDIudHh0DQogICAgCVBhZ2VzICAgICAgICAgICA6IDcNCiAgICAJRGF0ZSAg ICAgICAgICAgIDogMjAxOS0xMS0wMQ0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoZSBC aWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIGlzIGNvbW1v bmx5DQogICAgICAgdXNlZCB0byB2ZXJpZnkgY29ubmVjdGl2aXR5IGJldHdlZW4gdHdvIHN5c3Rl bXMuICBCRkQgcGFja2V0cyBhcmUNCiAgICAgICB0eXBpY2FsbHkgdmVyeSBzbWFsbC4gIEl0IGlz IGRlc2lyYWJsZSBpbiBzb21lIGNpcmN1bXN0YW5jZXMgdG8ga25vdw0KICAgICAgIHRoYXQgbm90 IG9ubHkgaXMgdGhlIHBhdGggYmV0d2VlbiB0d28gc3lzdGVtcyByZWFjaGFibGUsIGJ1dCBhbHNv DQogICAgICAgdGhhdCBpdCBpcyBjYXBhYmxlIG9mIGNhcnJ5aW5nIGEgcGF5bG9hZCBvZiBhIHBh cnRpY3VsYXIgc2l6ZS4gIFRoaXMNCiAgICAgICBkb2N1bWVudCBkaXNjdXNzZXMgdGhvdWdodHMg b24gaG93IHRvIGltcGxlbWVudCBzdWNoIGEgbWVjaGFuaXNtDQogICAgICAgdXNpbmcgQkZEIGlu IEFzeW5jaHJvbm91cyBtb2RlLg0KICAgIA0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLWxhcmdlLXBhY2tldHMvDQogICAgDQog ICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1sYXJnZS1wYWNrZXRzLTAy DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJm ZC1sYXJnZS1wYWNrZXRzLTAyDQogICAgDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLWJmZC1sYXJnZS1wYWNrZXRzLTAyDQogICAgDQogICAgDQogICAgUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQogICAgDQogICAgLS0tLS0gRW5kIGZvcndhcmRl ZCBtZXNzYWdlIC0tLS0tDQogICAgDQogICAgDQoNCg== From nobody Fri Nov 1 10:45:10 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED62120D93; Fri, 1 Nov 2019 10:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-vxlan-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <157263030397.31830.12398146942141891675@ietfa.amsl.com> Date: Fri, 01 Nov 2019 10:45:04 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 17:45:04 -0000 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-08.txt Pages : 11 Date : 2019-11-01 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 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/ From nobody Fri Nov 1 10:53:54 2019 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 0ADAD120A50; Fri, 1 Nov 2019 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WwrsRyCyLP6e; Fri, 1 Nov 2019 10:53:43 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 6C5A41200B4; Fri, 1 Nov 2019 10:53:43 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id q28so7831340lfa.5; Fri, 01 Nov 2019 10:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v3PMqv0Y/CyamqxeX0BM8lZol9JG8nz/F743rr3LDgQ=; b=Kt4s+ORZy39b+TT6AFaIzjVUs25MyqQHSF6cnEthmlIOFR0n5iVjjKkT5Hgfb7Fjzu visgC7zohyQ8574DzPNVzbcn+m9reJNidSyvPdA91DXZ92YUpBGT9TPn5IadNXv08JvA FbxuXIAKVqTFF7Xu1kTCFk9N6eDVhXjg4IHRTowYfNlU/ubUev13n7TIoiLVvMjAsUHq Y3U7TWJcDNNCwUXMVEnHdKBNFz7lwpdnrz8CMtCKNYxTW/28dwNGdAJaJYvMiOkGD8pE RKGBkDL9dvhNyLBJ9BYsryjH2Cu1HYKzp56ngaOFl8a9rqfrLg4q3z1NRBu2ohBYGPvJ qPMg== 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=v3PMqv0Y/CyamqxeX0BM8lZol9JG8nz/F743rr3LDgQ=; b=qZ75EFVmYB8njRjRRjLo5W1ylZHDtrvRFhLhVOAx9zZBKGFCOhe9TGe6hbfg/JbKN3 ekrV9oToRao4N6RziayPTCta7vikXQmgatJDJo7c6OxfVmUvINtIhf3aIF0sjWqBGNup rtiCpDjHRDZO8fngpzPdUP2cxwmO8FNp2/2/3Fip0r77ERUBXvdZruFIYkLMmxqFVa5f 4hNOnEISv3SkU+Rv8wQDvOaqg9cCz6rtWqlbfiFCzs6yTiabMIGMZZeHVoLtyCeptAil YHpuaPGdZ+eiSKrassbmirfUsvsQMkIKs1C7UOZFfuYK/dR8/9e+6EtdxMoKlIImk8jt vb2w== X-Gm-Message-State: APjAAAVp5pwYhqSPwy98NEXAJV8PEW/4qmZiJCErq8IONULESJErh/+z MDcl+JbZRJdpFV6MvypTkGnjvBsIwXhHE/MEeCAXmQ== X-Google-Smtp-Source: APXvYqx2HmQN7hd5g/oWfhqkWUluDbdSLbthBSvsLI26YOuRzHlbPDw5MyNAh7axoj89vZVJcSA5+Sh7gAsli1zQzC4= X-Received: by 2002:a19:ad0a:: with SMTP id t10mr8118745lfc.113.1572630820738; Fri, 01 Nov 2019 10:53:40 -0700 (PDT) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 1 Nov 2019 10:53:29 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: rtg-bfd WG , NVO3 Cc: Anoop Ghanwani , Dinesh Dutt , Joel Halpern Content-Type: multipart/alternative; boundary="0000000000006edf8705964ca53d" Archived-At: 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: Fri, 01 Nov 2019 17:53:46 -0000 --0000000000006edf8705964ca53d Content-Type: text/plain; charset="UTF-8" Dear All, the new version includes updates resulting from the discussions of Joel's comments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, and Dinesh. On behalf of editors, thank you for your constructive comments and for sharing your expertise, all much appreciated. I hope we've addressed all your comments, and the draft can proceed further. Regards, Greg ---------- Forwarded message --------- From: Date: Fri, Nov 1, 2019 at 10:45 AM Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Gregory Mirsky , Mallik Mudigonda < mmudigon@cisco.com>, Sudarsan Paragiri , Vengada Prasad Govindan , Santosh Pallagatti < santosh.pallagatti@gmail.com> A new version of I-D, draft-ietf-bfd-vxlan-08.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-bfd-vxlan Revision: 08 Title: BFD for VXLAN Document date: 2019-11-01 Group: bfd Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network. 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 --0000000000006edf8705964ca53d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the new version includes updates resulting f= rom the discussions of Joel's comments in the RtrDir review of BFD over= VXLAN draft, comments from Anoop, and Dinesh. On behalf of editors, thank = you for your constructive comments and for sharing your expertise, all much= appreciated.
I hope we've addressed all your comments, and t= he draft can proceed further.

Regards,
G= reg

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Nov 1, 2019 at 10:45 AM
Subject: New Version Notific= ation for draft-ietf-bfd-vxlan-08.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigon= da <mmudigon@cisco.com>, Su= darsan Paragiri <sudarsan.225@= gmail.com>, Vengada Prasad Govindan <venggovi@cisco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>
<= /div>


A new version of I-D, draft-ietf-bfd-vxlan-08.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2019-11-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt<= /a>
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-bfd-vxlan-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-08

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in point-to-point Virtual eXtensible = Local
=C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--0000000000006edf8705964ca53d-- From nobody Fri Nov 1 11:12:02 2019 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 9C75C120FA1 for ; Fri, 1 Nov 2019 11:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 EIg5RTZoF_zw for ; Fri, 1 Nov 2019 11:11:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8592B120F9C for ; Fri, 1 Nov 2019 11:11:59 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A83081E2F2; Fri, 1 Nov 2019 14:15:36 -0400 (EDT) Date: Fri, 1 Nov 2019 14:15:35 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux Subject: IETF-106 agenda? Message-ID: <20191101181535.GA10713@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Fri, 01 Nov 2019 18:12:00 -0000 Working Group, A session request had gone in for IETF 106 to accommodate the need for a possible session. The agenda, to this point, had been left as an open question primarily to accommodate need to close on lingering questions in active work. In particular, this was for two items: - BFD for vxlan - BFD for Large Packets (For transparency, I am an author on BFD for large packets) As of this afternoon, we seem to have drafts submitted that cover the known open issues on both of these drafts. In particular, the work to get us to the latest draft for the vxlan document took over 150 messages. If BFD meets, agenda time was primarily reserved to reconcile open issues on these documents. Discussion on BFDv2 is currently deferred for next IETF to focus the Working Group's limited attention on closing open work. That said, if we have other topics to consider, please submit them for consideration. If we have no such topics, and the discussion on the above two drafts seems likely to conclude well over e-mail, we may consider canceling the session. As a final note, since Reshad is unable to make it to IETF-106, if we do decide to continue with our meeting, we will require the commitment for a minutes taker. Reshad and I often will cover that for each other over the course of a session, but I won't be able to sustain that on my own. -- Jeff, for the chairs. From nobody Fri Nov 1 13:28:37 2019 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 A803D120A31 for ; Fri, 1 Nov 2019 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lwsXn_HSPfw1 for ; Fri, 1 Nov 2019 13:28:33 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 2194F1209A6 for ; Fri, 1 Nov 2019 13:27:21 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id t5so11497364ljk.0 for ; Fri, 01 Nov 2019 13:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NZHFsIgUZnag6os0b+vNZbJG74JtvahZxdutO+cPyP0=; b=cCt5zOUO7UETuw68T0qotinsGF/aUKtcuny8RwzrKP/xq03+G38HkKTMhVwTvxRNwH SfUVKhsMjpS3O7rQeqxOGlEldcOOfdzRGyhTJFzzqlnBWbz5LKvj0cae6JMhcgu37Uf8 fTbBWffB7lDGpEGZC5UFING8eSWGdx/H3CWdhA4CWhPm6WWrm+cs02oLlKXTDLrSCW2z t23WucnLuj+ArxcGRSXQsmwvmA9JPbp8xUzMrIn1Fzpz09XBOEKPkVNdS0ZalLYGxJqo 1bei/jO9KMnjMRxfJVF86PwI1965WQSp+PnDe09vh/Ccez88/MZoli3KZANKHQvu8bNm ++Xw== 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=NZHFsIgUZnag6os0b+vNZbJG74JtvahZxdutO+cPyP0=; b=kEF9mD7YgSx5twkjuP1Yt7RM1jV5OkZvJPUZH1SxcNVvumYeu5t2POE0X+LzFNyP8z fbsItw5WSyX+YLlFcruKHNie8eTQMH1mR5R0iY932aWcBVkSNezIl56ATe3b7Ur2Fho1 9uD0b7GLd1p0g7DuYXpB+cbS6n0owWWAx13E1TWqd+tUUc/x432NumBlWigmh2Gxujtg hldX7XOxxWH1xT7XY+urZHpNStVxal1vevQnzgnduX6QkneKrpX0jl3mNNe/cRB6g9i+ NwjlteBIWVwBonwddA/6rdIMMFldIDy3bzy+UgL1T4mJmYVNK8TB9lFM6Wj2RS3au+Ib M1Jg== X-Gm-Message-State: APjAAAX6kA7ZZGGEf5z/QquZ55WD8pgdNF0skW3nnaJfWtvBIFG0AJse 1EBMTmRqPGx87vYbDJLKOPMYc4Y9VRjCt8SEfeU= X-Google-Smtp-Source: APXvYqy91W/9z58tbU64IRV/teiq5G65vY4hVT0CF3jHNluOt4Fk6yssjKF6H42ovRncVW8d8PMKnYVPQomb7mYpZQM= X-Received: by 2002:a2e:3612:: with SMTP id d18mr9614523lja.222.1572640039120; Fri, 01 Nov 2019 13:27:19 -0700 (PDT) MIME-Version: 1.0 References: <20191101181535.GA10713@pfrc.org> In-Reply-To: <20191101181535.GA10713@pfrc.org> From: Greg Mirsky Date: Fri, 1 Nov 2019 13:27:08 -0700 Message-ID: Subject: Re: IETF-106 agenda? To: Jeffrey Haas Cc: rtg-bfd WG , "Reshad Rahman (rrahman)" Content-Type: multipart/alternative; boundary="000000000000e432f405964eca85" Archived-At: 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: Fri, 01 Nov 2019 20:28:35 -0000 --000000000000e432f405964eca85 Content-Type: text/plain; charset="UTF-8" Hi Jeff, et al., I think that it will be of interest to the group to get an update on the draft-mirmin-bfd-extended. We've added details on the use of the Padding TLV. Also, would appreciate the opportunity to discuss the status of draft-mirsky-bfd-mpls-demand at the meeting. Regards, Greg On Fri, Nov 1, 2019 at 11:12 AM Jeffrey Haas wrote: > Working Group, > > A session request had gone in for IETF 106 to accommodate the need for a > possible session. The agenda, to this point, had been left as an open > question primarily to accommodate need to close on lingering questions in > active work. In particular, this was for two items: > > - BFD for vxlan > - BFD for Large Packets > > (For transparency, I am an author on BFD for large packets) > > As of this afternoon, we seem to have drafts submitted that cover the known > open issues on both of these drafts. In particular, the work to get us to > the latest draft for the vxlan document took over 150 messages. > > If BFD meets, agenda time was primarily reserved to reconcile open issues > on > these documents. > > Discussion on BFDv2 is currently deferred for next IETF to focus the > Working > Group's limited attention on closing open work. > > That said, if we have other topics to consider, please submit them for > consideration. If we have no such topics, and the discussion on the above > two drafts seems likely to conclude well over e-mail, we may consider > canceling the session. > > As a final note, since Reshad is unable to make it to IETF-106, if we do > decide to continue with our meeting, we will require the commitment for a > minutes taker. Reshad and I often will cover that for each other over the > course of a session, but I won't be able to sustain that on my own. > > -- Jeff, for the chairs. > > --000000000000e432f405964eca85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff, et al.,
I think that it will be of interest t= o the group to get an update on the draft-mirmin-bfd-extended. We've ad= ded details on the use of the Padding TLV.
Also, would appreciate= the opportunity to discuss the status of=C2=A0draft-mirsky-bfd-mpls-demand= at the meeting.

Regards,
Greg

On F= ri, Nov 1, 2019 at 11:12 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
Working Group,

A session request had gone in for IETF 106 to accommodate the need for a possible session.=C2=A0 The agenda, to this point, had been left as an open=
question primarily to accommodate need to close on lingering questions in active work.=C2=A0 In particular, this was for two items:

- BFD for vxlan
- BFD for Large Packets

(For transparency, I am an author on BFD for large packets)

As of this afternoon, we seem to have drafts submitted that cover the known=
open issues on both of these drafts.=C2=A0 In particular, the work to get u= s to
the latest draft for the vxlan document took over 150 messages.

If BFD meets, agenda time was primarily reserved to reconcile open issues o= n
these documents.

Discussion on BFDv2 is currently deferred for next IETF to focus the Workin= g
Group's limited attention on closing open work.

That said, if we have other topics to consider, please submit them for
consideration.=C2=A0 If we have no such topics, and the discussion on the a= bove
two drafts seems likely to conclude well over e-mail, we may consider
canceling the session.

As a final note, since Reshad is unable to make it to IETF-106, if we do decide to continue with our meeting, we will require the commitment for a minutes taker.=C2=A0 Reshad and I often will cover that for each other over= the
course of a session, but I won't be able to sustain that on my own.

-- Jeff, for the chairs.

--000000000000e432f405964eca85-- From nobody Fri Nov 1 16:24:23 2019 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 B7524120861; Fri, 1 Nov 2019 16:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 WosGo2C-14EQ; Fri, 1 Nov 2019 16:24:19 -0700 (PDT) Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (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 86696120074; Fri, 1 Nov 2019 16:24:19 -0700 (PDT) Received: by mail-ua1-f49.google.com with SMTP id l38so3400116uad.4; Fri, 01 Nov 2019 16:24:19 -0700 (PDT) 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=ItOmQscO9eMLJrUjca2bfCeriU9efWxllLsWas+OKNg=; b=kOpEk0fKismBA7bMa23VTN2OkCA5cjmo9zUR/sD5eKYTiAev+WeF2EtOgeQzLa5qFV PuRqreYz91wQoajZ1zuYK+9bZiiKAGjzYH0RxQfqQOVCssDTldMPWQRBfDufkWGiiYGL kc2nnuACzUMb/s3+olCfOtzjEW/9GJn5+6FTfO91YqMaBJ1jXHGBy9orSm5GB+qS548t u5Idf9zm9MZR8cjruBTrUjZN3oTkkU9QghvaGifMLvesTeY2+UsHYpvdDsdLMs+wgLVZ GGhO3u2+78Q1swRwJt7Ik+AXuI2mvNqO15OjUNRw2fAzmxveXKFgssw/sBGb4s4RoA+e 2Txw== X-Gm-Message-State: APjAAAXeL+Ud59oFZ9IzxM/U4RpswzMLx69Bhc1QaYCfafvZm2VV4+RZ FPslO3Yg3pzo8Ca1Dpdbg/NXfhVqKfzXTt2+T8o= X-Google-Smtp-Source: APXvYqwHKOjlJUAZnUvMG3d8Ujw4HuJBvnplKRYu9R9qD27+xkf9nH2Vv47WCEucJeWlWQN0OKbZ1oZEkTn6cNmwRd4= X-Received: by 2002:a9f:23ea:: with SMTP id 97mr6597912uao.141.1572650658471; Fri, 01 Nov 2019 16:24:18 -0700 (PDT) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Anoop Ghanwani Date: Fri, 1 Nov 2019 16:24:07 -0700 Message-ID: Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Greg Mirsky Cc: rtg-bfd WG , NVO3 , Dinesh Dutt , Joel Halpern Content-Type: multipart/alternative; boundary="000000000000daa546059651431a" Archived-At: 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: Fri, 01 Nov 2019 23:24:22 -0000 --000000000000daa546059651431a Content-Type: text/plain; charset="UTF-8" Hi Greg, A few comments. The draft has nits, specifically around the way the IPv6 address is written. In section 4: BFD packet MUST be encapsulated -> BFD packets MUST be encapsulated >>> Destination MAC: This MUST NOT be of one of tenant's MAC addresses. The destination MAC address MAY be the address associated with the destination VTEP. The MAC address MAY be configured, or it MAY be learned via a control plane protocol. The details of how the MAC address is obtained are outside the scope of this document. >>> It looks like we have removed the option of using a well-known IANA assigned MAC. If so, why is the above a MAY and not a MUST? What else can it be? One interpretation is that it can be anything unicast, or multicast, as long as it's not a tenant MAC. Is that the intent? If so, it would be better to state it that way. Also (and this is purely editorial), I think it would be better if the first sentence above were moved to the end of the paragraph. "The inner Ethernet frame carrying the BFD Control packet- has the following format:" Extraneous '-' after packet. Thanks, Anoop On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky wrote: > Dear All, > the new version includes updates resulting from the discussions of Joel's > comments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, > and Dinesh. On behalf of editors, thank you for your constructive comments > and for sharing your expertise, all much appreciated. > I hope we've addressed all your comments, and the draft can proceed > further. > > Regards, > Greg > > ---------- Forwarded message --------- > From: > Date: Fri, Nov 1, 2019 at 10:45 AM > Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt > To: Gregory Mirsky , Mallik Mudigonda < > mmudigon@cisco.com>, Sudarsan Paragiri , Vengada > Prasad Govindan , Santosh Pallagatti < > santosh.pallagatti@gmail.com> > > > > A new version of I-D, draft-ietf-bfd-vxlan-08.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-ietf-bfd-vxlan > Revision: 08 > Title: BFD for VXLAN > Document date: 2019-11-01 > Group: bfd > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 > > Abstract: > This document describes the use of the Bidirectional Forwarding > Detection (BFD) protocol in point-to-point Virtual eXtensible Local > Area Network (VXLAN) tunnels forming up an overlay network. > > > > > 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 > > --000000000000daa546059651431a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

A few comments.

=
The draft has nits, specifically around the way the IPv6 address= is written.

In section 4:

BFD packet MUST b=
e encapsulated ->
BFD packets MUST be encapsulated

>>>= 
Destination =
MAC: This MUST NOT be of one of tenant's MAC
         addresses.  The destination MAC address MAY be the address
         associated with the destination VTEP.  The MAC address MAY be
         configured, or it MAY be learned via a control plane protocol.
         The details of how the MAC address is obtained are outside the
         scope of this document.
>>>
It = looks like we have removed the option of using a well-known IANA assigned M= AC.=C2=A0 If so, why is the above a MAY and not a MUST?=C2=A0 What else can= it be?=C2=A0 One interpretation is that it can be anything unicast, or mul= ticast, as long as it's not a tenant MAC.=C2=A0 Is that the intent?=C2= =A0 If so, it would be better to state it that way.=C2=A0 Also (and this is= purely editorial), I think it would be better if the first sentence above = were moved to the end of the paragraph.

"The inner Ethernet frame ca=
rrying the BFD
   Control packet- has the following format:"
Extraneous '-&#= 39; after packet.

Thanks,
Anoop

On = Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
the new ver= sion includes updates resulting from the discussions of Joel's comments= in the RtrDir review of BFD over VXLAN draft, comments from Anoop, and Din= esh. On behalf of editors, thank you for your constructive comments and for= sharing your expertise, all much appreciated.
I hope we've a= ddressed all your comments, and the draft can proceed further.
Regards,
Greg

---------- Forwarded message ---------From: <internet-drafts@ietf.org>
Date: Fri, Nov = 1, 2019 at 10:45 AM
Subject: New Version Notification for draft-ietf-bfd= -vxlan-08.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigonda <= ;mmudigon@cisco.com= >, Sudarsan Paragiri <sudarsan.225@gmail.com>, Vengada Prasad Govindan &l= t;venggovi@cisco.co= m>, Santosh Pallagatti <santosh.pallagatti@gmail.com>

=

A new version of I-D, draft-ietf-bfd-vxlan-08.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2019-11-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-bfd-vxlan-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-08

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in point-to-point Virtual eXtensible = Local
=C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000daa546059651431a-- From nobody Sun Nov 3 18:50:46 2019 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 CC1411208B7; Sun, 3 Nov 2019 18:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8pD-_E9sgkdA; Sun, 3 Nov 2019 18:50:27 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 337CB1208E7; Sun, 3 Nov 2019 18:50:27 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id j5so11027917lfh.10; Sun, 03 Nov 2019 18:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biyyDYCCRFNPfOlj02aoCHy3Pgq7W62SAjpx8Rfu8u0=; b=TlcxcppnLVbdj3kbE6idrCpRIwiv0EngDGXYlNiRqLH36Pdkqg+rAUVf44NmMkxyox +DTAbWbG+zXLwPC0Boj98K4KQhNuTpAsr8oZiS3V1iuq4dx7x71vU6bgcWOYTk3tzxYv 2DwfuP9/z7Kes/JYMxlX5dft3DnIAKrXEoPEbvaQ6Cpua+gbtlKBc70UALuWYWiubpue mH4++3ktqEdWpCBUEk7wic+Mzo37+CNWMHRS4BEzpJn+ff+dK4Yc3XchUejZjmAUAc7a 7qfspVDDfqn+Ra31Z7Gt7odbWbozR5qNEuXRyDGHGbjtVgklL/DM+dlIElDgyKXfAfQ3 dMaA== 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=biyyDYCCRFNPfOlj02aoCHy3Pgq7W62SAjpx8Rfu8u0=; b=GfE8sMbDkt6POqA5zQjzwJizM1S6h2eO0ZmNZERVLZyCHiYW3eSzFoZdLpEQtNV5g0 k5xQtO0YPJXzxLrCDr99PVAXVNES5aDOBNlsoRKRy7hHwGw7sz4tkqAvndUvoL9VQK/3 EP9Ro8m7pVa/RBcIB85iQGJwT19IXi77YdIGWr6Vb26E3m2pUjGKZI9Pao/HGCmkMotH duvNwXFupnZVwlpfYX/rziv9YTfjd5xRqjVM6hVkIkvNe0CcOe1IIEHdR6TYf099Khii Tfosho84quvIWzDD+H/ESJN9WUTCdoXTYPzQ09UJQmy5zTf4YS0MSHsOt7TXIXBUKFjO eQ7A== X-Gm-Message-State: APjAAAWSrIn2ea41WOyYvgNlrENIoRYkvfHx/312/Cje1WZX8cNxZMcf PZah4GZbO/bpjuNDt98DfJGkaB/7Dy/bkD+Plh0= X-Google-Smtp-Source: APXvYqyiFtZujGXwSKSuJDLwPlRTmHkjbE8MiH3d4fEAW5lU4XgL80wd/LAAymXYwp4JXMo2lycXkQrjWH/qNwYhSWg= X-Received: by 2002:ac2:5c05:: with SMTP id r5mr13824045lfp.72.1572835825280; Sun, 03 Nov 2019 18:50:25 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Greg Mirsky Date: Sun, 3 Nov 2019 18:50:13 -0800 Message-ID: Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Anoop Ghanwani Cc: rtg-bfd WG , NVO3 , Dinesh Dutt , Joel Halpern Content-Type: multipart/alternative; boundary="000000000000a7ea8905967c6054" Archived-At: 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: Mon, 04 Nov 2019 02:50:39 -0000 --000000000000a7ea8905967c6054 Content-Type: text/plain; charset="UTF-8" Hi Anoop, thank you for your comments and questions. Please find my notes in-line tagged GIM>>. Regards, Greg On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani wrote: > Hi Greg, > > A few comments. > > The draft has nits, specifically around the way the IPv6 address is > written. > > In section 4: > > BFD packet MUST be encapsulated -> > > BFD packets MUST be encapsulated > > GIM>> Thanks, will do. > > >>> > > Destination MAC: This MUST NOT be of one of tenant's MAC > addresses. The destination MAC address MAY be the address > associated with the destination VTEP. The MAC address MAY be > configured, or it MAY be learned via a control plane protocol. > The details of how the MAC address is obtained are outside the > scope of this document. > > >>> > It looks like we have removed the option of using a well-known IANA > assigned MAC. If so, why is the above a MAY and not a MUST? What else can > it be? One interpretation is that it can be anything unicast, or > multicast, as long as it's not a tenant MAC. Is that the intent? If so, > it would be better to state it that way. Also (and this is purely > editorial), I think it would be better if the first sentence above were > moved to the end of the paragraph. > GIM>> Yes, you're right, we've removed that option and have removed the request to IANA. I also agree that " MAY be the address associated with the destination VTEP" is not the right choice of normative language. On the other hand, MUST might be too restrictive if BFD session is using the Management VNI. Would the following update address your concern: OLD TEXT: Destination MAC: This MUST NOT be of one of tenant's MAC addresses. The destination MAC address MAY be the address associated with the destination VTEP. The MAC address MAY be configured, or it MAY be learned via a control plane protocol. The details of how the MAC address is obtained are outside the scope of this document. NEW TEXT: Destination MAC: If the BFD session is not using the Management VNI, the destination MAC address MUST be the address associated with the destination VTEP. The Destination MAC MUST NOT be one of the tenant's MAC addresses. The MAC address MAY be configured, or it MAY be learned via a control plane protocol. The details of how the MAC address is obtained are outside the scope of this document. > > "The inner Ethernet frame carrying the BFD > Control packet- has the following format:" > > Extraneous '-' after packet. > GIM>> Thanks, will do that too. > > Thanks, > Anoop > > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky wrote: > >> Dear All, >> the new version includes updates resulting from the discussions of Joel's >> comments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, >> and Dinesh. On behalf of editors, thank you for your constructive comments >> and for sharing your expertise, all much appreciated. >> I hope we've addressed all your comments, and the draft can proceed >> further. >> >> Regards, >> Greg >> >> ---------- Forwarded message --------- >> From: >> Date: Fri, Nov 1, 2019 at 10:45 AM >> Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt >> To: Gregory Mirsky , Mallik Mudigonda < >> mmudigon@cisco.com>, Sudarsan Paragiri , Vengada >> Prasad Govindan , Santosh Pallagatti < >> santosh.pallagatti@gmail.com> >> >> >> >> A new version of I-D, draft-ietf-bfd-vxlan-08.txt >> has been successfully submitted by Greg Mirsky and posted to the >> IETF repository. >> >> Name: draft-ietf-bfd-vxlan >> Revision: 08 >> Title: BFD for VXLAN >> Document date: 2019-11-01 >> Group: bfd >> Pages: 11 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >> >> Abstract: >> This document describes the use of the Bidirectional Forwarding >> Detection (BFD) protocol in point-to-point Virtual eXtensible Local >> Area Network (VXLAN) tunnels forming up an overlay network. >> >> >> >> >> 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 >> >> --000000000000a7ea8905967c6054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anoop,
thank you for your comments= and questions. Please find my notes in-line tagged GIM>>.
=
Regards,
Greg

On Fri, Nov 1, 2019 at 4:24 PM = Anoop Ghanwani <anoop@alumni.du= ke.edu> wrote:
Hi Greg,

A few comments.

The draft has nits, specifically around the way the IPv6 a= ddress is written.

In section 4:
BFD packet MUST be encapsulated -&g=
t;
BFD packets MUST be encapsul=
ated
GIM>> Thanks, will do.= =C2=A0

= >>>
Destination MAC: This MU=
ST NOT be of one of tenant's MAC
         addresses.  The destination MAC address MAY be the address
         associated with the destination VTEP.  The MAC address MAY be
         configured, or it MAY be learned via a control plane protocol.
         The details of how the MAC address is obtained are outside the
         scope of this document.
>>>
It = looks like we have removed the option of using a well-known IANA assigned M= AC.=C2=A0 If so, why is the above a MAY and not a MUST?=C2=A0 What else can= it be?=C2=A0 One interpretation is that it can be anything unicast, or mul= ticast, as long as it's not a tenant MAC.=C2=A0 Is that the intent?=C2= =A0 If so, it would be better to state it that way.=C2=A0 Also (and this is= purely editorial), I think it would be better if the first sentence above = were moved to the end of the paragraph.
GIM>= ;> Yes, you're right, we've removed that option and have removed= the request to IANA. I also agree that " MAY be the address associate= d with the destination VTEP" is not the right choice of normative lang= uage. On the other hand, MUST might be too restrictive if BFD session is us= ing the Management VNI. Would the following update address your concern:
OLD TEXT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination M= AC: This MUST NOT be of one of tenant's MAC
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0addresses.=C2=A0 The destination MAC address MAY be the address=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the destination VTEP.= =C2=A0 The MAC address MAY be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ed, or it MAY be learned via a control plane protocol.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0The details of how the MAC address is obtained are outside= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this document.
=
NEW TEXT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the Management VNI,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the destination MAC address MUST be the address
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the destination VTEP.=C2= =A0 The Destination MAC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NO= T be one of the tenant's MAC addresses.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 The MAC address MAY be configured, or it MAY be learned via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protocol. The details of how = the MAC address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsi= de the scope of this document.

"The inner Ethernet frame carrying the BFD
   Control packet- has the following format:"
Extraneous '-&#= 39; after packet.
GIM>> Thanks, will do = that too.=C2=A0

Thanks,
Anoop

On Fri, Nov 1= , 2019 at 10:53 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
the = new version includes updates resulting from the discussions of Joel's c= omments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, = and Dinesh. On behalf of editors, thank you for your constructive comments = and for sharing your expertise, all much appreciated.
I hope we&#= 39;ve addressed all your comments, and the draft can proceed further.
=

Regards,
Greg

---------- Forwarded message -----= ----
From: <internet-drafts@ietf.org>
Date: Fr= i, Nov 1, 2019 at 10:45 AM
Subject: New Version Notification for draft-i= etf-bfd-vxlan-08.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigo= nda <mmudigon@ci= sco.com>, Sudarsan Paragiri <sudarsan.225@gmail.com>, Vengada Prasad Govi= ndan <venggovi@c= isco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>



A new version of I-D, draft-ietf-bfd-vxlan-08.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2019-11-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-bfd-vxlan-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-08

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in point-to-point Virtual eXtensible = Local
=C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000a7ea8905967c6054-- From nobody Sun Nov 3 19:33:00 2019 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 001BE120871; Sun, 3 Nov 2019 19:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 UodKhLqdn0nz; Sun, 3 Nov 2019 19:32:57 -0800 (PST) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) (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 D33B112008D; Sun, 3 Nov 2019 19:32:56 -0800 (PST) Received: by mail-ua1-f46.google.com with SMTP id n41so4524028uae.2; Sun, 03 Nov 2019 19:32:56 -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=BrJE4MAMptUQj1dWhesyTY/fYfPlc5hN4rjwUqRHVSU=; b=sCFG3jezYqzRsO4/CuaQ8LFdhcXr66YDx4MSXIMUffjG/I21f342nViE3hW7CDOCI0 2bcmRsxfUjUU0VO4Ghu5aZ5+MH9zbQBfSJyg4RaqeGSVN+JaY3JS0Ar3s1aLo5kDgZjC ZRb6YUf4hDPKEF+7O2vG2X/RoyJDj+bpkcGdV5lTIgeSaH4igLAgQOm+EbT85cCj6/zY J6b3x+9tTobFCNFlyAgubAJ0mxHAxobA8kB7SYZVyljCUnq2IPVEORmyCQSo4SkPQNIc kakHIhn1dW/lqVvLIuUWqFLaW+SFv5nJWRufsMrrOImubTtPkm6oytXD4vSRUhM8Hhqu 0oTg== X-Gm-Message-State: APjAAAXmHG/jTwXWfz9HbszsM2w0ph7D7t8NusD5G1UiPttFnABBQaYR BDEA0j7taf6V7VZ5JqJf9QHcm1xEp/9+6T2ICuw= X-Google-Smtp-Source: APXvYqxHZxncQKr/WKHy0NoRbe5gxHMTGLEHcAoV9Odpw+lfwci/rCg1W2hqv6wm6TmBZT1J3/j7Gx77HsYjWaPY9xs= X-Received: by 2002:ab0:4e2d:: with SMTP id g45mr8096415uah.29.1572838375671; Sun, 03 Nov 2019 19:32:55 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Anoop Ghanwani Date: Sun, 3 Nov 2019 19:32:44 -0800 Message-ID: Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Greg Mirsky Cc: rtg-bfd WG , NVO3 , Dinesh Dutt , Joel Halpern Content-Type: multipart/alternative; boundary="000000000000abcd9f05967cf840" Archived-At: 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: Mon, 04 Nov 2019 03:32:59 -0000 --000000000000abcd9f05967cf840 Content-Type: text/plain; charset="UTF-8" Hi Greg, In the case of the management VNI, are we trying to say that we would allow any MAC address other than a tenant MAC address? I would suggest some more text be added to clarify what is permitted on the management VLAN. Assuming that we want to allow any MAC other than a tenant MAC, how does this get enforced? In other words, what can be done for the network to protect itself if a sender violates this? One possible answer is to restrict the MAC address that may be used to one that is owned by the VTEP or a "agreed on" multicast MAC address. That means the receiver only needs to validate for those, and just treats everything else as data. Also, for interoperability purposes, it would be best to specify that a receiver MUST be able to handle any valid MAC address for the BFD session, while a sender MAY pick any of them. Thanks, Anoop On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky wrote: > Hi Anoop, > thank you for your comments and questions. Please find my notes in-line > tagged GIM>>. > > Regards, > Greg > > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani > wrote: > >> Hi Greg, >> >> A few comments. >> >> The draft has nits, specifically around the way the IPv6 address is >> written. >> >> In section 4: >> >> BFD packet MUST be encapsulated -> >> >> BFD packets MUST be encapsulated >> >> GIM>> Thanks, will do. > >> >> >>> >> >> Destination MAC: This MUST NOT be of one of tenant's MAC >> addresses. The destination MAC address MAY be the address >> associated with the destination VTEP. The MAC address MAY be >> configured, or it MAY be learned via a control plane protocol. >> The details of how the MAC address is obtained are outside the >> scope of this document. >> >> >>> >> It looks like we have removed the option of using a well-known IANA >> assigned MAC. If so, why is the above a MAY and not a MUST? What else can >> it be? One interpretation is that it can be anything unicast, or >> multicast, as long as it's not a tenant MAC. Is that the intent? If so, >> it would be better to state it that way. Also (and this is purely >> editorial), I think it would be better if the first sentence above were >> moved to the end of the paragraph. >> > GIM>> Yes, you're right, we've removed that option and have removed the > request to IANA. I also agree that " MAY be the address associated with the > destination VTEP" is not the right choice of normative language. On the > other hand, MUST might be too restrictive if BFD session is using the > Management VNI. Would the following update address your concern: > OLD TEXT: > Destination MAC: This MUST NOT be of one of tenant's MAC > addresses. The destination MAC address MAY be the address > associated with the destination VTEP. The MAC address MAY be > configured, or it MAY be learned via a control plane protocol. > The details of how the MAC address is obtained are outside the > scope of this document. > NEW TEXT: > Destination MAC: If the BFD session is not using the Management > VNI, > the destination MAC address MUST be the address > associated with the destination VTEP. The Destination MAC > MUST NOT be one of the tenant's MAC addresses. > The MAC address MAY be configured, or it MAY be learned via > a control plane protocol. The details of how the MAC address > is obtained are outside the scope of this document. > >> >> "The inner Ethernet frame carrying the BFD >> Control packet- has the following format:" >> >> Extraneous '-' after packet. >> > GIM>> Thanks, will do that too. > >> >> Thanks, >> Anoop >> >> On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >> wrote: >> >>> Dear All, >>> the new version includes updates resulting from the discussions of >>> Joel's comments in the RtrDir review of BFD over VXLAN draft, comments from >>> Anoop, and Dinesh. On behalf of editors, thank you for your constructive >>> comments and for sharing your expertise, all much appreciated. >>> I hope we've addressed all your comments, and the draft can proceed >>> further. >>> >>> Regards, >>> Greg >>> >>> ---------- Forwarded message --------- >>> From: >>> Date: Fri, Nov 1, 2019 at 10:45 AM >>> Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt >>> To: Gregory Mirsky , Mallik Mudigonda < >>> mmudigon@cisco.com>, Sudarsan Paragiri , >>> Vengada Prasad Govindan , Santosh Pallagatti < >>> santosh.pallagatti@gmail.com> >>> >>> >>> >>> A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>> has been successfully submitted by Greg Mirsky and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-bfd-vxlan >>> Revision: 08 >>> Title: BFD for VXLAN >>> Document date: 2019-11-01 >>> Group: bfd >>> Pages: 11 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>> Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>> >>> Abstract: >>> This document describes the use of the Bidirectional Forwarding >>> Detection (BFD) protocol in point-to-point Virtual eXtensible Local >>> Area Network (VXLAN) tunnels forming up an overlay network. >>> >>> >>> >>> >>> 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 >>> >>> --000000000000abcd9f05967cf840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

=
In the case of the management VNI, are we trying to say that we would = allow any MAC address other than a tenant MAC address?=C2=A0 I would sugges= t some more text be added to clarify what is permitted on the management VL= AN.=C2=A0 Assuming that we want to allow any MAC other than a tenant MAC, h= ow does this get enforced?=C2=A0 In other words, what can be done for the n= etwork to protect itself if a sender violates this?

One possible answer is to restrict the MAC address that may be used to on= e that is owned by the VTEP or a "agreed on" multicast MAC addres= s.=C2=A0 That means the receiver only needs to validate for those, and just= treats everything else as data.

Also, for interop= erability purposes, it would be best to specify that a receiver MUST be abl= e to handle any valid MAC address for the BFD session, while a sender MAY p= ick any of them.

Thanks,
Anoop

=
On Sun, No= v 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Anoop,
tha= nk you for your comments and questions. Please find my notes in-line tagged= GIM>>.

Regards,
Greg
<= br>
On Fri,= Nov 1, 2019 at 4:24 PM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Greg,
A few comments.

The draft has ni= ts, specifically around the way the IPv6 address is written.
=
In section 4:

BFD packet MUST be encapsulated ->
BFD packets MUST be encapsulated
GIM>> Thanks, will do.=C2=A0

>>>
Destination MAC: This MUST NOT be of one of tenant's =
MAC
         addresses.  The destination MAC address MAY be the address
         associated with the destination VTEP.  The MAC address MAY be
         configured, or it MAY be learned via a control plane protocol.
         The details of how the MAC address is obtained are outside the
         scope of this document.
>>>
It = looks like we have removed the option of using a well-known IANA assigned M= AC.=C2=A0 If so, why is the above a MAY and not a MUST?=C2=A0 What else can= it be?=C2=A0 One interpretation is that it can be anything unicast, or mul= ticast, as long as it's not a tenant MAC.=C2=A0 Is that the intent?=C2= =A0 If so, it would be better to state it that way.=C2=A0 Also (and this is= purely editorial), I think it would be better if the first sentence above = were moved to the end of the paragraph.
GIM>= ;> Yes, you're right, we've removed that option and have removed= the request to IANA. I also agree that " MAY be the address associate= d with the destination VTEP" is not the right choice of normative lang= uage. On the other hand, MUST might be too restrictive if BFD session is us= ing the Management VNI. Would the following update address your concern:
OLD TEXT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination M= AC: This MUST NOT be of one of tenant's MAC
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0addresses.=C2=A0 The destination MAC address MAY be the address=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the destination VTEP.= =C2=A0 The MAC address MAY be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configur= ed, or it MAY be learned via a control plane protocol.
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0The details of how the MAC address is obtained are outside= the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this document.
=
NEW TEXT:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the Management VNI,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the destination MAC address MUST be the address
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the destination VTEP.=C2= =A0 The Destination MAC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NO= T be one of the tenant's MAC addresses.
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 The MAC address MAY be configured, or it MAY be learned via
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protocol. The details of how = the MAC address
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsi= de the scope of this document.

"The inner Ethernet frame carrying the BFD
   Control packet- has the following format:"
Extraneous '-&#= 39; after packet.
GIM>> Thanks, will do = that too.=C2=A0

Thanks,
Anoop

On Fri, Nov 1= , 2019 at 10:53 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear All,
the = new version includes updates resulting from the discussions of Joel's c= omments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, = and Dinesh. On behalf of editors, thank you for your constructive comments = and for sharing your expertise, all much appreciated.
I hope we&#= 39;ve addressed all your comments, and the draft can proceed further.
=

Regards,
Greg

---------- Forwarded message -----= ----
From: <internet-drafts@ietf.org>
Date: Fr= i, Nov 1, 2019 at 10:45 AM
Subject: New Version Notification for draft-i= etf-bfd-vxlan-08.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigo= nda <mmudigon@ci= sco.com>, Sudarsan Paragiri <sudarsan.225@gmail.com>, Vengada Prasad Govi= ndan <venggovi@c= isco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>



A new version of I-D, draft-ietf-bfd-vxlan-08.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2019-11-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-bfd-vxlan-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-08

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in point-to-point Virtual eXtensible = Local
=C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000abcd9f05967cf840-- From nobody Sun Nov 3 19:52:13 2019 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 4367D120877; Sun, 3 Nov 2019 19:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 VOPFTZAvIyLB; Sun, 3 Nov 2019 19:52:08 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0765120848; Sun, 3 Nov 2019 19:52:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 475zQ04XmpzwPJ3; Sun, 3 Nov 2019 19:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572839528; bh=m2x+XoViTI4XZDyPArM8otLC6/a51MZ4CZKBAKa31EA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=oTRutfWEfqhfQ76QyPhr6rB/ClRJJ0ab65iNS+X6L4515OOkmR7oJqIbHg/sQibX0 A6GOUP21oW5maxq7FEudlX6jokaHvxtvddSMcW3e+1TKWr3IwapGkGmJgB0rEIfGmu /pk5t8TVgginUUfy5vIRujextpFUIDtSjaZQKXvc= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 475zPz3vBKzFpVD; Sun, 3 Nov 2019 19:52:07 -0800 (PST) Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Anoop Ghanwani , Greg Mirsky Cc: rtg-bfd WG , NVO3 , Dinesh Dutt References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 3 Nov 2019 22:52:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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: Mon, 04 Nov 2019 03:52:11 -0000 Anoop, I think I at least am misunderstanding you. If one is using the management VNI, as I understand it there is no tenant. So there are no tenant MAC addresses. (This is one of the reasons I like using the management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: > Hi Greg, > > In the case of the management VNI, are we trying to say that we would > allow any MAC address other than a tenant MAC address?  I would suggest > some more text be added to clarify what is permitted on the management > VLAN.  Assuming that we want to allow any MAC other than a tenant MAC, > how does this get enforced?  In other words, what can be done for the > network to protect itself if a sender violates this? > > One possible answer is to restrict the MAC address that may be used to > one that is owned by the VTEP or a "agreed on" multicast MAC address. > That means the receiver only needs to validate for those, and just > treats everything else as data. > > Also, for interoperability purposes, it would be best to specify that a > receiver MUST be able to handle any valid MAC address for the BFD > session, while a sender MAY pick any of them. > > Thanks, > Anoop > > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky > wrote: > > Hi Anoop, > thank you for your comments and questions. Please find my notes > in-line tagged GIM>>. > > Regards, > Greg > > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani > wrote: > > Hi Greg, > > A few comments. > > The draft has nits, specifically around the way the IPv6 address > is written. > > In section 4: > > BFD packet MUST be encapsulated -> > > BFD packets MUST be encapsulated > > GIM>> Thanks, will do. > > > >>> > > Destination MAC: This MUST NOT be of one of tenant's MAC > addresses. The destination MAC address MAY be the address > associated with the destination VTEP. The MAC address MAY be > configured, or it MAY be learned via a control plane protocol. > The details of how the MAC address is obtained are outside the > scope of this document. > > >>> > It looks like we have removed the option of using a well-known > IANA assigned MAC.  If so, why is the above a MAY and not a > MUST?  What else can it be?  One interpretation is that it can > be anything unicast, or multicast, as long as it's not a tenant > MAC.  Is that the intent?  If so, it would be better to state it > that way.  Also (and this is purely editorial), I think it would > be better if the first sentence above were moved to the end of > the paragraph. > > GIM>> Yes, you're right, we've removed that option and have removed > the request to IANA. I also agree that " MAY be the address > associated with the destination VTEP" is not the right choice of > normative language. On the other hand, MUST might be too restrictive > if BFD session is using the Management VNI. Would the following > update address your concern: > OLD TEXT: >          Destination MAC: This MUST NOT be of one of tenant's MAC >          addresses.  The destination MAC address MAY be the address >          associated with the destination VTEP.  The MAC address MAY be >          configured, or it MAY be learned via a control plane protocol. >          The details of how the MAC address is obtained are outside the >          scope of this document. > NEW TEXT: >          Destination MAC: If the BFD session is not using the > Management VNI, >          the destination MAC address MUST be the address >          associated with the destination VTEP.  The Destination MAC >          MUST NOT be one of the tenant's MAC addresses. >         The MAC address MAY be configured, or it MAY be learned via >         a control plane protocol. The details of how the MAC address >         is obtained are outside the scope of this document. > > > "The inner Ethernet frame carrying the BFD > Control packet- has the following format:" > > Extraneous '-' after packet. > > GIM>> Thanks, will do that too. > > > Thanks, > Anoop > > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky > > wrote: > > Dear All, > the new version includes updates resulting from the > discussions of Joel's comments in the RtrDir review of BFD > over VXLAN draft, comments from Anoop, and Dinesh. On behalf > of editors, thank you for your constructive comments and for > sharing your expertise, all much appreciated. > I hope we've addressed all your comments, and the draft can > proceed further. > > Regards, > Greg > > ---------- Forwarded message --------- > From: > > Date: Fri, Nov 1, 2019 at 10:45 AM > Subject: New Version Notification for > draft-ietf-bfd-vxlan-08.txt > To: Gregory Mirsky >, Mallik Mudigonda > >, Sudarsan > Paragiri >, Vengada Prasad Govindan > >, Santosh > Pallagatti > > > > > A new version of I-D, draft-ietf-bfd-vxlan-08.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name:           draft-ietf-bfd-vxlan > Revision:       08 > Title:          BFD for VXLAN > Document date:  2019-11-01 > Group:          bfd > Pages:          11 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 > > Abstract: >    This document describes the use of the Bidirectional > Forwarding >    Detection (BFD) protocol in point-to-point Virtual > eXtensible Local >    Area Network (VXLAN) tunnels forming up an overlay network. > > > > > 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 > From nobody Sun Nov 3 20:07:55 2019 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 4B4451208DE; Sun, 3 Nov 2019 20:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8hrTViSlkleK; Sun, 3 Nov 2019 20:07:51 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 B31B2120122; Sun, 3 Nov 2019 20:07:51 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id c184so11280937pfb.0; Sun, 03 Nov 2019 20:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=KknlE3iPQ+kpOaoGckMCIOJa12P4AlEm/m2TPwkJXaw=; b=cE3mg9OmEBPuJaWoBIoqCx+UBrd8UJQtuh01poQGG6UgUq377/6FM7o7CMo6+1A9yY ihTMblbWG877zfjihlcSgd4ItQH2S1i8vqiYwN+eC6db0BpaNmBMptqquQNOWoYjixIJ Owl9NwioZCBHwXwzYnHScWRpbO6FbhFAy+JUocLlz61NSng1epZdNdh6PK27vFL0fIg/ nXqbC540YOw1bFRYdalTkbkVmzjPDNTSfIVgI35Egay8mCNkKlfwf0BnLuJeDJWD85rB O5uOevvCu6LqIvY/gY0hCc1uAan7ufrbNztKTGdidtVx2NutQR8uKCR/s/8OmKLVf5zk H6gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=KknlE3iPQ+kpOaoGckMCIOJa12P4AlEm/m2TPwkJXaw=; b=RE7DifW+RmxyrstBW2oAGAxqFDj+F27dP50ushwWfiG5fgeZl+paOLi8zShswcxRqp MFESn9VLuSuboYGwV5iTaWuwW+iOJL/pMJN4lOJH1mx8I0AKVrIYRaegw00Eq5IkJO9P 5Tyt6XioMcGJ6wPjR46WRP3YYGl1L9kAa7JHP4pnkZQC6j4Y2p1AoVoGPIDVTO+fTHOD 8IvIabYLzB8ja08JuauGZHKyFNqJL4v+16PWRggwIuU7Kf1xwNZcf41mYgxsGB/CzDvv RggTqtbn+Kcbi+WbY1we5xHGjiq+QGeRmpx9fwE91jJNYJDPgXRU1V93pkJkKHRRvnUJ 26Ug== X-Gm-Message-State: APjAAAVOb7AzWlEFO3QbSuSzz/KSi3F6Dyg1LCNYKUogrKNFonZLSxR3 RgUT9tFBylCkji+97VI9Ykk= X-Google-Smtp-Source: APXvYqyY4owCa2RFxeifjPofXyGERMa9j46MdzdVvTUP1WKj///+maGYyjH6nFTtYHPek+H/1VBKyw== X-Received: by 2002:a63:fe06:: with SMTP id p6mr27020749pgh.245.1572840470953; Sun, 03 Nov 2019 20:07:50 -0800 (PST) Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id o7sm21366532pjo.7.2019.11.03.20.07.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Nov 2019 20:07:49 -0800 (PST) Date: Mon, 04 Nov 2019 09:07:45 +0500 From: Dinesh Dutt Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: "Joel M. Halpern" Cc: Anoop Ghanwani , Greg Mirsky , rtg-bfd WG , NVO3 Message-Id: <1572840465.25948.2@smtp.gmail.com> In-Reply-To: References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-qVqwxBFkaVO+qtFLQG+7" Archived-At: 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: Mon, 04 Nov 2019 04:07:54 -0000 --=-qVqwxBFkaVO+qtFLQG+7 Content-Type: text/plain; charset=us-ascii; format=flowed While I agree that there are no tenant MACs on a management VNI, I'm loathe to introduce another forwarding behavior, one that's VNI-specific. MUST use a MAC thats owned by the VTEP is all that's required. All VTEPs, existing and past work with this, because that's the VTEP decapsulate and forward behavior. Dinesh On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern wrote: > Anoop, I think I at least am misunderstanding you. > If one is using the management VNI, as I understand it there is no > tenant. So there are no tenant MAC addresses. (This is one of the > reasons I like using the management VNI.) > > > Yours, > Joel > > On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >> Hi Greg, >> >> In the case of the management VNI, are we trying to say that we >> would allow any MAC address other than a tenant MAC address? I >> would suggest some more text be added to clarify what is permitted >> on the management VLAN. Assuming that we want to allow any MAC >> other than a tenant MAC, how does this get enforced? In other >> words, what can be done for the network to protect itself if a >> sender violates this? >> >> One possible answer is to restrict the MAC address that may be used >> to one that is owned by the VTEP or a "agreed on" multicast MAC >> address. That means the receiver only needs to validate for those, >> and just treats everything else as data. >> >> Also, for interoperability purposes, it would be best to specify >> that a receiver MUST be able to handle any valid MAC address for >> the BFD session, while a sender MAY pick any of them. >> >> Thanks, >> Anoop >> >> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky > > wrote: >> >> Hi Anoop, >> thank you for your comments and questions. Please find my notes >> in-line tagged GIM>>. >> >> Regards, >> Greg >> >> On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani >> > > wrote: >> >> Hi Greg, >> >> A few comments. >> >> The draft has nits, specifically around the way the IPv6 >> address >> is written. >> >> In section 4: >> >> BFD packet MUST be encapsulated -> >> >> BFD packets MUST be encapsulated >> >> GIM>> Thanks, will do. >> >> >> >>> >> >> Destination MAC: This MUST NOT be of one of tenant's MAC >> addresses. The destination MAC address MAY be the >> address >> associated with the destination VTEP. The MAC >> address MAY be >> configured, or it MAY be learned via a control >> plane protocol. >> The details of how the MAC address is obtained are >> outside the >> scope of this document. >> >> >>> >> It looks like we have removed the option of using a >> well-known >> IANA assigned MAC. If so, why is the above a MAY and not a >> MUST? What else can it be? One interpretation is that it >> can >> be anything unicast, or multicast, as long as it's not a >> tenant >> MAC. Is that the intent? If so, it would be better to >> state it >> that way. Also (and this is purely editorial), I think it >> would >> be better if the first sentence above were moved to the end >> of >> the paragraph. >> >> GIM>> Yes, you're right, we've removed that option and have >> removed >> the request to IANA. I also agree that " MAY be the address >> associated with the destination VTEP" is not the right choice of >> normative language. On the other hand, MUST might be too >> restrictive >> if BFD session is using the Management VNI. Would the following >> update address your concern: >> OLD TEXT: >> Destination MAC: This MUST NOT be of one of tenant's >> MAC >> addresses. The destination MAC address MAY be the >> address >> associated with the destination VTEP. The MAC address >> MAY be >> configured, or it MAY be learned via a control plane >> protocol. >> The details of how the MAC address is obtained are >> outside the >> scope of this document. >> NEW TEXT: >> Destination MAC: If the BFD session is not using the >> Management VNI, >> the destination MAC address MUST be the address >> associated with the destination VTEP. The Destination >> MAC >> MUST NOT be one of the tenant's MAC addresses. >> The MAC address MAY be configured, or it MAY be learned >> via >> a control plane protocol. The details of how the MAC >> address >> is obtained are outside the scope of this document. >> >> >> "The inner Ethernet frame carrying the BFD >> Control packet- has the following format:" >> >> Extraneous '-' after packet. >> >> GIM>> Thanks, will do that too. >> >> >> Thanks, >> Anoop >> >> On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >> > wrote: >> >> Dear All, >> the new version includes updates resulting from the >> discussions of Joel's comments in the RtrDir review of >> BFD >> over VXLAN draft, comments from Anoop, and Dinesh. On >> behalf >> of editors, thank you for your constructive comments and >> for >> sharing your expertise, all much appreciated. >> I hope we've addressed all your comments, and the draft >> can >> proceed further. >> >> Regards, >> Greg >> >> ---------- Forwarded message --------- >> From: > > >> Date: Fri, Nov 1, 2019 at 10:45 AM >> Subject: New Version Notification for >> draft-ietf-bfd-vxlan-08.txt >> To: Gregory Mirsky > >, Mallik Mudigonda >> >, >> Sudarsan >> Paragiri > >, Vengada Prasad Govindan >> >, Santosh >> Pallagatti > > >> >> >> >> A new version of I-D, draft-ietf-bfd-vxlan-08.txt >> has been successfully submitted by Greg Mirsky and >> posted to the >> IETF repository. >> >> Name: draft-ietf-bfd-vxlan >> Revision: 08 >> Title: BFD for VXLAN >> Document date: 2019-11-01 >> Group: bfd >> Pages: 11 >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >> Htmlized: >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >> >> Abstract: >> This document describes the use of the Bidirectional >> Forwarding >> Detection (BFD) protocol in point-to-point Virtual >> eXtensible Local >> Area Network (VXLAN) tunnels forming up an overlay >> network. >> >> >> >> >> 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 >> --=-qVqwxBFkaVO+qtFLQG+7 Content-Type: text/html; charset=us-ascii
While I agree that there are no tenant MACs on a management VNI, I'm loathe to introduce another forwarding behavior, one that's VNI-specific. MUST use a MAC thats owned by the VTEP is all that's required. All VTEPs, existing and past work with this, because that's the VTEP decapsulate and forward behavior. 

Dinesh

On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you. If one is using the management VNI, as I understand it there is no tenant. So there are no tenant MAC addresses. (This is one of the reasons I like using the management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
Hi Greg, In the case of the management VNI, are we trying to say that we would allow any MAC address other than a tenant MAC address?  I would suggest some more text be added to clarify what is permitted on the management VLAN.  Assuming that we want to allow any MAC other than a tenant MAC, how does this get enforced?  In other words, what can be done for the network to protect itself if a sender violates this? One possible answer is to restrict the MAC address that may be used to one that is owned by the VTEP or a "agreed on" multicast MAC address. That means the receiver only needs to validate for those, and just treats everything else as data. Also, for interoperability purposes, it would be best to specify that a receiver MUST be able to handle any valid MAC address for the BFD session, while a sender MAY pick any of them. Thanks, Anoop On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote: Hi Anoop, thank you for your comments and questions. Please find my notes in-line tagged GIM>>. Regards, Greg On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <anoop@alumni.duke.edu <mailto:anoop@alumni.duke.edu>> wrote: Hi Greg, A few comments. The draft has nits, specifically around the way the IPv6 address is written. In section 4: BFD packet MUST be encapsulated -> BFD packets MUST be encapsulated GIM>> Thanks, will do. >>> Destination MAC: This MUST NOT be of one of tenant's MAC addresses. The destination MAC address MAY be the address associated with the destination VTEP. The MAC address MAY be configured, or it MAY be learned via a control plane protocol. The details of how the MAC address is obtained are outside the scope of this document. >>> It looks like we have removed the option of using a well-known IANA assigned MAC.  If so, why is the above a MAY and not a MUST?  What else can it be?  One interpretation is that it can be anything unicast, or multicast, as long as it's not a tenant MAC.  Is that the intent?  If so, it would be better to state it that way.  Also (and this is purely editorial), I think it would be better if the first sentence above were moved to the end of the paragraph. GIM>> Yes, you're right, we've removed that option and have removed the request to IANA. I also agree that " MAY be the address associated with the destination VTEP" is not the right choice of normative language. On the other hand, MUST might be too restrictive if BFD session is using the Management VNI. Would the following update address your concern: OLD TEXT:          Destination MAC: This MUST NOT be of one of tenant's MAC          addresses.  The destination MAC address MAY be the address          associated with the destination VTEP.  The MAC address MAY be          configured, or it MAY be learned via a control plane protocol.          The details of how the MAC address is obtained are outside the          scope of this document. NEW TEXT:          Destination MAC: If the BFD session is not using the Management VNI,          the destination MAC address MUST be the address          associated with the destination VTEP.  The Destination MAC          MUST NOT be one of the tenant's MAC addresses.         The MAC address MAY be configured, or it MAY be learned via         a control plane protocol. The details of how the MAC address         is obtained are outside the scope of this document. "The inner Ethernet frame carrying the BFD Control packet- has the following format:" Extraneous '-' after packet. GIM>> Thanks, will do that too. Thanks, Anoop On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote: Dear All, the new version includes updates resulting from the discussions of Joel's comments in the RtrDir review of BFD over VXLAN draft, comments from Anoop, and Dinesh. On behalf of editors, thank you for your constructive comments and for sharing your expertise, all much appreciated. I hope we've addressed all your comments, and the draft can proceed further. Regards, Greg ---------- Forwarded message --------- From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>> Date: Fri, Nov 1, 2019 at 10:45 AM Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Gregory Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>>, Mallik Mudigonda <mmudigon@cisco.com <mailto:mmudigon@cisco.com>>, Sudarsan Paragiri <sudarsan.225@gmail.com <mailto:sudarsan.225@gmail.com>>, Vengada Prasad Govindan <venggovi@cisco.com <mailto:venggovi@cisco.com>>, Santosh Pallagatti <santosh.pallagatti@gmail.com <mailto:santosh.pallagatti@gmail.com>> A new version of I-D, draft-ietf-bfd-vxlan-08.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name:           draft-ietf-bfd-vxlan Revision:       08 Title:          BFD for VXLAN Document date:  2019-11-01 Group:          bfd Pages:          11 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 Abstract:    This document describes the use of the Bidirectional Forwarding    Detection (BFD) protocol in point-to-point Virtual eXtensible Local    Area Network (VXLAN) tunnels forming up an overlay network. 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 <http://tools.ietf.org>. The IETF Secretariat
--=-qVqwxBFkaVO+qtFLQG+7-- From nobody Sun Nov 3 20:15:52 2019 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 22A82120888; Sun, 3 Nov 2019 20:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 FG4OTueA4wbk; Sun, 3 Nov 2019 20:15:40 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B04A7120251; Sun, 3 Nov 2019 20:15:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 475zx84XRHzwPfy; Sun, 3 Nov 2019 20:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1572840940; bh=KCFY8gDhutxmXEBfV3KADvIJo+BW6Ku9VzovXA/LXzQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JS1V1U+pokKDfEyUYmRGTQIjWLlTqzEQ06py1T1RWHZ+4iXmlxHbR5F6qqqmsrXOA dgsmYVbCPuiuLNsI3sujvUPy6ICW7LkdE8jxXarP+fQsmd23jp1B6bdsHjaaBiZZtq FURFj/3CaiAfdFFqEU5D2j9DyCy/pHy6dw+g97n4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 475zx800wQzFpVD; Sun, 3 Nov 2019 20:15:39 -0800 (PST) Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: rtg-bfd WG , NVO3 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572840465.25948.2@smtp.gmail.com> From: "Joel M. Halpern" Message-ID: <13b756b6-4a3f-e128-aeef-214e48727c6c@joelhalpern.com> Date: Sun, 3 Nov 2019 23:15:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1572840465.25948.2@smtp.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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: Mon, 04 Nov 2019 04:15:43 -0000 Are you referring to the Ethernet MAC addresses that the VTEP probably has on its underlay physical network? I can see why those would be good candidates to use on the management VNI. What I do not see is why we want to require it? Using those would seem to complicate configuring BFD, since as far as I know those addresses are not known to remote VTEPs. Yours, Joel On 11/3/2019 11:07 PM, Dinesh Dutt wrote: > While I agree that there are no tenant MACs on a management VNI, I'm > loathe to introduce another forwarding behavior, one that's > VNI-specific. MUST use a MAC thats owned by the VTEP is all that's > required. All VTEPs, existing and past work with this, because that's > the VTEP decapsulate and forward behavior. > > Dinesh > > On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern wrote: >> Anoop, I think I at least am misunderstanding you. If one is using the >> management VNI, as I understand it there is no tenant. So there are no >> tenant MAC addresses. (This is one of the reasons I like using the >> management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: From nobody Sun Nov 3 21:11:03 2019 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 3051E1200CD; Sun, 3 Nov 2019 21:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 0meWfO7Un0YM; Sun, 3 Nov 2019 21:10:50 -0800 (PST) Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (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 43488120096; Sun, 3 Nov 2019 21:10:50 -0800 (PST) Received: by mail-ua1-f52.google.com with SMTP id k11so1905939ual.10; Sun, 03 Nov 2019 21:10:50 -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=S0XpCVYfJ1CmN6hu1JS4UUnpqvXVIy5BKD5G1T5q8kY=; b=K4YeoJBw3IRnWaz20iQpWoue2sFrbvQ5xEi82Kiax4bkkvC4gDNXksiJrPveMFR21/ SqCT2nf0iN2w+a60fnxiOTrUbVBvBBsdxJY4x0ZLf7iPE4KHEoBrJuyvs8VLbKUqz3F+ e0VUTb2wRsasQ7q5TkTEgkNiR4SzXiftBHqh34ofoYfFDSzJh9f+XsosTIN53pPRfgKA MTCNDzw1smYFRrlHrwFRs7YgeF0V39RptNfXOS6U03LOxlxXuJfp3erv68Bpe1ZcsHN8 f+k7Z2BtWVLY6SsSJ1MhDXNOVVZQwseP8WyR6nTnei8Rl27abWBcYW3pBxZ8QjO3AueZ R2zQ== X-Gm-Message-State: APjAAAXfhsclKPHAaVBhEvJpLvpPHYrKeze6HyBp1GJNUrzkOV2LH/+X DkNEiI6CqFzuYkuE3HFUvbzHEZu9nQjsImf55QU= X-Google-Smtp-Source: APXvYqy+3xgzcuZ7EZd2XvEIuIECjipE5FF5puI8psB+O/tgTBxcmn9qiB9TytZ80LC7JM6kIS2y7BlUgcinrgP1OHY= X-Received: by 2002:ab0:7118:: with SMTP id x24mr10470759uan.99.1572844248989; Sun, 03 Nov 2019 21:10:48 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Anoop Ghanwani Date: Sun, 3 Nov 2019 21:10:37 -0800 Message-ID: Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: "Joel M. Halpern" Cc: Greg Mirsky , rtg-bfd WG , NVO3 , Dinesh Dutt Content-Type: multipart/alternative; boundary="000000000000bf87ed05967e56d5" Archived-At: 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: Mon, 04 Nov 2019 05:10:53 -0000 --000000000000bf87ed05967e56d5 Content-Type: text/plain; charset="UTF-8" Hi Joel, In that case I would propose the following text: "Destination MAC: If the BFD session is not using the Management VNI, the destination MAC address MUST be the address associated with the destination VTEP. If the BFD session uses the Management VNI, it may use any MAC address, since use of the Management VNI ensures that these packets will never be forwarded to a VM. The MAC address may be configured, or it may be learned via a control plane protocol. The details of how the MAC address to be used is obtained are outside the scope of this document." That said, for non-Management VNI, do we want to allow for flexibility for an implementation to use a multicast MAC of their choosing? If so, we should probably add a sentence for that too. Thanks, Anoop On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern wrote: > Anoop, I think I at least am misunderstanding you. > If one is using the management VNI, as I understand it there is no > tenant. So there are no tenant MAC addresses. (This is one of the > reasons I like using the management VNI.) > > > Yours, > Joel > > On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: > > Hi Greg, > > > > In the case of the management VNI, are we trying to say that we would > > allow any MAC address other than a tenant MAC address? I would suggest > > some more text be added to clarify what is permitted on the management > > VLAN. Assuming that we want to allow any MAC other than a tenant MAC, > > how does this get enforced? In other words, what can be done for the > > network to protect itself if a sender violates this? > > > > One possible answer is to restrict the MAC address that may be used to > > one that is owned by the VTEP or a "agreed on" multicast MAC address. > > That means the receiver only needs to validate for those, and just > > treats everything else as data. > > > > Also, for interoperability purposes, it would be best to specify that a > > receiver MUST be able to handle any valid MAC address for the BFD > > session, while a sender MAY pick any of them. > > > > Thanks, > > Anoop > > > > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky > > wrote: > > > > Hi Anoop, > > thank you for your comments and questions. Please find my notes > > in-line tagged GIM>>. > > > > Regards, > > Greg > > > > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani > > wrote: > > > > Hi Greg, > > > > A few comments. > > > > The draft has nits, specifically around the way the IPv6 address > > is written. > > > > In section 4: > > > > BFD packet MUST be encapsulated -> > > > > BFD packets MUST be encapsulated > > > > GIM>> Thanks, will do. > > > > > > >>> > > > > Destination MAC: This MUST NOT be of one of tenant's MAC > > addresses. The destination MAC address MAY be the > address > > associated with the destination VTEP. The MAC address > MAY be > > configured, or it MAY be learned via a control plane > protocol. > > The details of how the MAC address is obtained are > outside the > > scope of this document. > > > > >>> > > It looks like we have removed the option of using a well-known > > IANA assigned MAC. If so, why is the above a MAY and not a > > MUST? What else can it be? One interpretation is that it can > > be anything unicast, or multicast, as long as it's not a tenant > > MAC. Is that the intent? If so, it would be better to state it > > that way. Also (and this is purely editorial), I think it would > > be better if the first sentence above were moved to the end of > > the paragraph. > > > > GIM>> Yes, you're right, we've removed that option and have removed > > the request to IANA. I also agree that " MAY be the address > > associated with the destination VTEP" is not the right choice of > > normative language. On the other hand, MUST might be too restrictive > > if BFD session is using the Management VNI. Would the following > > update address your concern: > > OLD TEXT: > > Destination MAC: This MUST NOT be of one of tenant's MAC > > addresses. The destination MAC address MAY be the address > > associated with the destination VTEP. The MAC address MAY > be > > configured, or it MAY be learned via a control plane > protocol. > > The details of how the MAC address is obtained are outside > the > > scope of this document. > > NEW TEXT: > > Destination MAC: If the BFD session is not using the > > Management VNI, > > the destination MAC address MUST be the address > > associated with the destination VTEP. The Destination MAC > > MUST NOT be one of the tenant's MAC addresses. > > The MAC address MAY be configured, or it MAY be learned via > > a control plane protocol. The details of how the MAC address > > is obtained are outside the scope of this document. > > > > > > "The inner Ethernet frame carrying the BFD > > Control packet- has the following format:" > > > > Extraneous '-' after packet. > > > > GIM>> Thanks, will do that too. > > > > > > Thanks, > > Anoop > > > > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky > > > wrote: > > > > Dear All, > > the new version includes updates resulting from the > > discussions of Joel's comments in the RtrDir review of BFD > > over VXLAN draft, comments from Anoop, and Dinesh. On behalf > > of editors, thank you for your constructive comments and for > > sharing your expertise, all much appreciated. > > I hope we've addressed all your comments, and the draft can > > proceed further. > > > > Regards, > > Greg > > > > ---------- Forwarded message --------- > > From: > > > > Date: Fri, Nov 1, 2019 at 10:45 AM > > Subject: New Version Notification for > > draft-ietf-bfd-vxlan-08.txt > > To: Gregory Mirsky > >, Mallik Mudigonda > > >, Sudarsan > > Paragiri > >, Vengada Prasad Govindan > > >, Santosh > > Pallagatti > > > > > > > > > > A new version of I-D, draft-ietf-bfd-vxlan-08.txt > > has been successfully submitted by Greg Mirsky and posted to > the > > IETF repository. > > > > Name: draft-ietf-bfd-vxlan > > Revision: 08 > > Title: BFD for VXLAN > > Document date: 2019-11-01 > > Group: bfd > > Pages: 11 > > URL: > > > https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt > > Status: > https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > > Htmlized: > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 > > > > Abstract: > > This document describes the use of the Bidirectional > > Forwarding > > Detection (BFD) protocol in point-to-point Virtual > > eXtensible Local > > Area Network (VXLAN) tunnels forming up an overlay > network. > > > > > > > > > > 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 > > > --000000000000bf87ed05967e56d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,

In that case I would propose t= he following text:

"Destination MAC: If the BFD session is not using the=C2=A0Management VNI,
the destination MAC address MUST = be the address
associated with the destination VTEP.=C2=A0 If the BFD session us= es
the Management VNI, it may use any MAC address, since u= se of the=C2=A0
Management VNI ensures that these packets will ne= ver be forwarded to a VM.
The MAC address may be configured, or it may be learned via
a cont= rol plane protocol. The details of how the MAC address
to be used is obtained ar= e outside the scope of this document."

That said, for non-Management VNI, do we want to allow for flexibility
for an implementation to u= se a multicast MAC of their choosing?=C2=A0 If so, we
should probably add a sentence for that too.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halper= n <jmh@joelhalpern.com> wr= ote:
Anoop, I th= ink I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= .edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= .txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://t= ools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
--000000000000bf87ed05967e56d5-- From nobody Sun Nov 3 22:05:31 2019 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 9B51D120096; Sun, 3 Nov 2019 22:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 k6pLUDL7tKzY; Sun, 3 Nov 2019 22:05:27 -0800 (PST) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 CDF8412000F; Sun, 3 Nov 2019 22:05:27 -0800 (PST) Received: by mail-pf1-x442.google.com with SMTP id 3so11421623pfb.10; Sun, 03 Nov 2019 22:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=FwTiUEOTfYOS9oTcZVqXagLKE7eCMUmCVASEood6YAM=; b=g3cJSUnrPGMpUY4wfZuJqCCPaWya5TltSazyGrqPxVzZdlooCf6qEV1QhaO2+n8Fu4 the/p76ZY6vIZtGWJElI1UfxeCUAT6Xo+BCUbifNobZ3IQl2nG3vPWkAoqlMYdiiw5dS k2zybWXGu/CfUf5KJAfjSeEst1P1lNYfYzuaGQoNGJA8U0jxoYhFYHw31VyZFW4F+jiI E/dJhjUtYj9gYQYju5d7auXxqPDSn4U9iIR0jV7rPzslmGMrLgDHn2Rtsd+XQKCAU31i YrGEawrSC0nKblSMok1ImWLZG9bkG5znb7QqaUj5oyZ6BG5YDex2FKLcYV78GzXHJ+LL oV/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=FwTiUEOTfYOS9oTcZVqXagLKE7eCMUmCVASEood6YAM=; b=gBIfeod61Sfm8vJh2yr6ERGcTPNgkB6/Uz4eL6WkqaHkWgZ3DWCD8bniTtwJeMCYAk P4v1ZE6S73HC0paLz0+RGC1IL+XdpSOcQFgMGfufwkKPCLvcnXaT8TglwtStfLmdK+sy wIY3+/zxsKbVATJywaMEAsuWScPsxuNQwKM8b46zfzW7m3nmR2Jl8fddFfdvRIJbQfGp 2O621fSvRMYllWEAeMdtSmFQjO24D7N/dBwjfsDlKOgFDLa8ZFg1TcbxVHJ8L0AuRmmD QNwrgDWY7p+XudOeKPAZMgk1Bmp1zTKJrOPNuGwyBNvRnLdjBqLUwMY1OxLdSk+fgR1y RnXg== X-Gm-Message-State: APjAAAWrBD0Uccs1zZ7apM0zQZt8o+8zzu6ci5sjpbavu/zx4gKavGeR q/FhTaboAd1Xanb2QUQfSiHiDu025MI= X-Google-Smtp-Source: APXvYqzhXCjKhT9DeuzQkxgCkeo1uU9LFXqvrrtWqvIzlzsG4inx/RXdZ0tZURPbwV0MtwsxXIRXbQ== X-Received: by 2002:a17:90a:eb04:: with SMTP id j4mr11883186pjz.80.1572847527234; Sun, 03 Nov 2019 22:05:27 -0800 (PST) Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id b26sm17412900pgs.93.2019.11.03.22.05.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Nov 2019 22:05:26 -0800 (PST) Date: Mon, 04 Nov 2019 11:05:22 +0500 From: Dinesh Dutt Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: "Joel M. Halpern" Cc: rtg-bfd WG , NVO3 Message-Id: <1572847522.25948.3@smtp.gmail.com> In-Reply-To: <13b756b6-4a3f-e128-aeef-214e48727c6c@joelhalpern.com> References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572840465.25948.2@smtp.gmail.com> <13b756b6-4a3f-e128-aeef-214e48727c6c@joelhalpern.com> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-nvjxewAyZSx5Hhl2eerE" Archived-At: 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: Mon, 04 Nov 2019 06:05:30 -0000 --=-nvjxewAyZSx5Hhl2eerE Content-Type: text/plain; charset=us-ascii; format=flowed Hi Joel, I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or whatever else) for the maagement VNI. That fixes the additional burden of configuring BFD for the management VNI. Requiring another forwarding behavior for a VNI is additional overhead and *may* not be supported by existing implementations. Dinesh On Mon, Nov 4, 2019 at 9:45 AM, Joel M. Halpern wrote: > Are you referring to the Ethernet MAC addresses that the VTEP > probably has on its underlay physical network? I can see why those > would be good candidates to use on the management VNI. What I do not > see is why we want to require it? Using those would seem to > complicate configuring BFD, since as far as I know those addresses > are not known to remote VTEPs. > > Yours, > Joel > > On 11/3/2019 11:07 PM, Dinesh Dutt wrote: >> While I agree that there are no tenant MACs on a management VNI, I'm >> loathe to introduce another forwarding behavior, one that's >> VNI-specific. MUST use a MAC thats owned by the VTEP is all that's >> required. All VTEPs, existing and past work with this, because >> that's the VTEP decapsulate and forward behavior. >> >> Dinesh >> >> On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern >> wrote: >>> Anoop, I think I at least am misunderstanding you. If one is using >>> the management VNI, as I understand it there is no tenant. So >>> there are no tenant MAC addresses. (This is one of the reasons I >>> like using the management VNI.) Yours, Joel On 11/3/2019 10:32 >>> PM, Anoop Ghanwani wrote: --=-nvjxewAyZSx5Hhl2eerE Content-Type: text/html; charset=us-ascii
Hi Joel,

I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or whatever else) for the maagement VNI. That fixes the additional burden of configuring BFD for the management VNI. Requiring another forwarding behavior for a VNI is additional overhead and *may* not be supported by existing implementations. 

Dinesh

On Mon, Nov 4, 2019 at 9:45 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Are you referring to the Ethernet MAC addresses that the VTEP probably has on its underlay physical network? I can see why those would be good candidates to use on the management VNI. What I do not see is why we want to require it? Using those would seem to complicate configuring BFD, since as far as I know those addresses are not known to remote VTEPs. Yours, Joel On 11/3/2019 11:07 PM, Dinesh Dutt wrote:
While I agree that there are no tenant MACs on a management VNI, I'm loathe to introduce another forwarding behavior, one that's VNI-specific. MUST use a MAC thats owned by the VTEP is all that's required. All VTEPs, existing and past work with this, because that's the VTEP decapsulate and forward behavior. Dinesh On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you. If one is using the management VNI, as I understand it there is no tenant. So there are no tenant MAC addresses. (This is one of the reasons I like using the management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
--=-nvjxewAyZSx5Hhl2eerE-- From nobody Mon Nov 4 05:12:08 2019 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 A77471201EA; Mon, 4 Nov 2019 05:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 I4OiuB7Lb5Y6; Mon, 4 Nov 2019 05:12:06 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 ABB0912081B; Mon, 4 Nov 2019 05:12:05 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id w18so17028793wrt.3; Mon, 04 Nov 2019 05:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6eDOeA2o5nZh+Z5V3ejB/rURnI9oM0BLbn4ANLuyBEc=; b=uhx4JeVmc0LZhOvewQK5+nhjHs6OvbIQm+gN98NBO6Wwbi2IBIvb5ACV7r6/1i1MPA vl39qzCoP1jptOnueg2uuEJNsMcngRkwqVgHPeELW+7MItNlcWPYDB3uIcWDW0e9aCPf 9b4cYYmOCyU5HVdoLJTv2CRVB7kb+sflINjFGFcN+1UNgKaDXSfR4vR6QXV0X/SleEP8 hvDe0FMwYZL5HOUwSfZnBbHw8g6je6Pl4/qsqLKQksTXbdjnsOX3X2V0hgyF7aEbslvY argi2kMIeUKIafZtZO7n5BjHyLmErlzfVUSJIzF97/hbXZfwikRZ2DpMo601EeXwIgvv ub9A== 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=6eDOeA2o5nZh+Z5V3ejB/rURnI9oM0BLbn4ANLuyBEc=; b=G1s6VtQkGKyZ686cODZY2qrUyngTPSRkwcbChFBE3Khe5M7STt9ieIM2hEkjygQZNY pzNDF70b1UYw9tsZN9ECuZeAa6XhfPNg+Bx95tpXaUE+BTGEISLdPszK7Dxmr7WzXwDs xjc6iUTQzxkEvVjcgrTrJBTA9xBTNPCb8i1MsWRxm8ZN0xTx58fRNP5wir3soe8+8peB YmPfUoBqF6Vqiv4tZE4vQa9c33YLuvOu3xz7MKoiW2GLHEVTxu6kpYNSoSzw7UuiD75T eB2yiBCB9m04h8OOTzTjyfCNCEQfnrnIj5Hgp2r0PRLOOitSEz1HOKxwFUic0LFPmA4B l8qQ== X-Gm-Message-State: APjAAAUpL7hw+K/wP6hZdyblOUn0pn6pYoCGrvj9RfEfygZ+hyOv6e0j lNLZtjZoOvKpIgPr3AhE3uuNhExIIIvLdTgTXL/IwdiCs4I= X-Google-Smtp-Source: APXvYqzHbKh556GRVdk/9At82HGS8lF0Nt252hLFPQ8GxRioi6+jmZ3x9N/gzdSG/1GmGAdphlAVkiOkWvKdmo7Z8Dg= X-Received: by 2002:adf:e9c7:: with SMTP id l7mr23486809wrn.57.1572873124203; Mon, 04 Nov 2019 05:12:04 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572840465.25948.2@smtp.gmail.com> <13b756b6-4a3f-e128-aeef-214e48727c6c@joelhalpern.com> <1572847522.25948.3@smtp.gmail.com> In-Reply-To: <1572847522.25948.3@smtp.gmail.com> From: Santosh P K Date: Mon, 4 Nov 2019 18:41:52 +0530 Message-ID: Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: "Joel M. Halpern" , rtg-bfd WG , NVO3 Content-Type: multipart/alternative; boundary="000000000000d8525d0596850ff8" Archived-At: 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: Mon, 04 Nov 2019 13:12:07 -0000 --000000000000d8525d0596850ff8 Content-Type: text/plain; charset="UTF-8" Dinesh, Thanks for your comments. Having fixed or multicast MAC addresses is something was considered earlier in the draft based on the comments we removed it in updated draft. If management VNI is used then MAC address should not matter at right? as the packet has to take the exception path and reach the CPU. Thanks Santosh P K On Mon, Nov 4, 2019 at 11:35 AM Dinesh Dutt wrote: > Hi Joel, > > I'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or > whatever else) for the maagement VNI. That fixes the additional burden of > configuring BFD for the management VNI. Requiring another forwarding > behavior for a VNI is additional overhead and *may* not be supported by > existing implementations. > > Dinesh > > On Mon, Nov 4, 2019 at 9:45 AM, Joel M. Halpern > wrote: > > Are you referring to the Ethernet MAC addresses that the VTEP probably has > on its underlay physical network? I can see why those would be good > candidates to use on the management VNI. What I do not see is why we want > to require it? Using those would seem to complicate configuring BFD, since > as far as I know those addresses are not known to remote VTEPs. Yours, Joel > On 11/3/2019 11:07 PM, Dinesh Dutt wrote: > > While I agree that there are no tenant MACs on a management VNI, I'm > loathe to introduce another forwarding behavior, one that's VNI-specific. > MUST use a MAC thats owned by the VTEP is all that's required. All VTEPs, > existing and past work with this, because that's the VTEP decapsulate and > forward behavior. Dinesh On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern < > jmh@joelhalpern.com> wrote: > > Anoop, I think I at least am misunderstanding you. If one is using the > management VNI, as I understand it there is no tenant. So there are no > tenant MAC addresses. (This is one of the reasons I like using the > management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: > > --000000000000d8525d0596850ff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dinesh,
=C2=A0 =C2=A0 =C2=A0Thanks fo= r your comments. Having fixed or multicast MAC addresses is something was c= onsidered earlier=C2=A0in the draft based on the comments we removed it in = updated draft. If management=C2=A0VNI is used then MAC address should not m= atter at right? as the packet has to take the exception path and reach the = CPU.=C2=A0


Thanks
S= antosh P K
=C2=A0
On Mon, Nov 4, 2019 at 11:35 AM Dinesh Dutt <didutt@gmail.com> wrote:
Hi Joel,

I= 'm comfortable if we fixed a MAC addresss such as 0a:0a:0a:0a:0a:0a (or= whatever else) for the maagement VNI. That fixes the additional burden of = configuring BFD for the management VNI. Requiring another forwarding behavi= or for a VNI is additional overhead and *may* not be supported by existing = implementations.=C2=A0

Dinesh

On Mon, Nov 4= , 2019 at 9:45 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Are you referring to the Ethe= rnet MAC addresses that the VTEP probably has on its underlay physical netw= ork? I can see why those would be good candidates to use on the management= VNI. What I do not see is why we want to require it? Using those would s= eem to complicate configuring BFD, since as far as I know those addresses a= re not known to remote VTEPs. Yours, Joel On 11/3/2019 11:07 PM, Dinesh Dutt wrote:
While I agree that there are no tenant MACs on a management VNI= , I'm loathe to introduce another forwarding behavior, one that's = VNI-specific. MUST use a MAC thats owned by the VTEP is all that's re= quired. All VTEPs, existing and past work with this, because that's th= e VTEP decapsulate and forward behavior. Dinesh On Mon, Nov 4, 2019 at 9:22 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you. If one is us= ing the management VNI, as I understand it there is no tenant. So there a= re no tenant MAC addresses. (This is one of the reasons I like using the = management VNI.) Yours, Joel On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
--000000000000d8525d0596850ff8-- From nobody Mon Nov 4 05:14:45 2019 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 6FC5D1201CE; Mon, 4 Nov 2019 05:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RjC6WQqx6Wc5; Mon, 4 Nov 2019 05:14:40 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 D7917120144; Mon, 4 Nov 2019 05:14:39 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id z26so3436188wmi.4; Mon, 04 Nov 2019 05:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Il13ExJqvcllIA4X/FyM2svbYrx6/H45njMW0d+n/UI=; b=SE3IZ1rOGz8SM/dvztmb6Psz2IJMscT5JswyxlKCuPz9VCib6ewh75iznKgPYFLbwv mGO8BM3wQcqVx0KMWkmzKW/Y8SVUZzDGr4wutYziBbOR3fwhqpM/Pqx5nVjqQeRS5foa i1rdDe4PFBn/UtA8rJPiauAQeJ0bGq54m57oYWoGauIPAxZW7j/4McOgH4yaj3zK9eyW KbI7OpNQfjt4rSDbZtBw2ajRBRKuZZrTVzNbO0kwqyaGZRGXWSau7Os8SPNFQKCjG6+6 V/1ZkXbkJn5NE3Bm22bBMXbD2N8Dj0Azd31fqfHrjlDUOcxQ01Vd/rejd0GCSXceZIxN 6B/w== 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=Il13ExJqvcllIA4X/FyM2svbYrx6/H45njMW0d+n/UI=; b=gcZMGH3MLZAFE24XjINf4hE+hWOX0qBbLYnPPAY/yi9+oeOLxkPEW8ClUXqb57CnTg N5ymDCr6QGjwGgrX4jwo9WIKPJS8XbUoQuB1RsOf01ETOgaFn4lor+BcUyt+bpJWx65z aCO20+F1Jc4gZEPiOWeuW9QbHLlzI3Ie1D6/u8EXee2PufTxix5+F+laKZY6Fn7Y7ARW o4ze6nnCS9bbYilMtKAWTLJ47McB+ZsbjURsm3YqbPfAPIU4g0kAYob6a5C4r7jYp07r /0xzC0NenIePbiXGzeO8lBQsVaQpOEAOFdFySLmLgyB/PPzTIEvOZIoS2CFHMyrViZB7 AIkw== X-Gm-Message-State: APjAAAUlddc1hRJeytZgR0ULVhLzsCa0hR9tY5CMe2ZROSe+RtcipyVF 3I/wHqujBLwHojeM3WfmlsBa6ZYpuJuOkrh7gOQ6OTwX2To= X-Google-Smtp-Source: APXvYqz8hrR3Y1HF0kUf8vvFmutOmfp6vo/CG0WHyr+GcehPuT21eeEk6xumbu6vYp3wEDZZ9RLVtxs4zHLuDwzWTPo= X-Received: by 2002:a1c:a9cb:: with SMTP id s194mr24270872wme.92.1572873278208; Mon, 04 Nov 2019 05:14:38 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Santosh P K Date: Mon, 4 Nov 2019 18:44:27 +0530 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Anoop Ghanwani Cc: "Joel M. Halpern" , Greg Mirsky , rtg-bfd WG , NVO3 , Dinesh Dutt Content-Type: multipart/alternative; boundary="00000000000006418c059685190d" Archived-At: 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: Mon, 04 Nov 2019 13:14:43 -0000 --00000000000006418c059685190d Content-Type: text/plain; charset="UTF-8" Anoop, Thanks for your comments. For non-managment VNI why do we need to have multicast MAC address for backward compatibility for existing implementation or there are any use cases such that we can avoid learning of remote end VTEP? Thanks Santosh P K On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani wrote: > Hi Joel, > > In that case I would propose the following text: > > "Destination MAC: If the BFD session is not using the Management VNI, > the destination MAC address MUST be the address > associated with the destination VTEP. If the BFD session uses > the Management VNI, it may use any MAC address, since use of the > Management VNI ensures that these packets will never be forwarded to a VM. > The MAC address may be configured, or it may be learned via > a control plane protocol. The details of how the MAC address > to be used is obtained are outside the scope of this document." > > That said, for non-Management VNI, do we want to allow for flexibility > for an implementation to use a multicast MAC of their choosing? If so, we > should probably add a sentence for that too. > > Thanks, > Anoop > > > On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern > wrote: > >> Anoop, I think I at least am misunderstanding you. >> If one is using the management VNI, as I understand it there is no >> tenant. So there are no tenant MAC addresses. (This is one of the >> reasons I like using the management VNI.) >> >> >> Yours, >> Joel >> >> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >> > Hi Greg, >> > >> > In the case of the management VNI, are we trying to say that we would >> > allow any MAC address other than a tenant MAC address? I would suggest >> > some more text be added to clarify what is permitted on the management >> > VLAN. Assuming that we want to allow any MAC other than a tenant MAC, >> > how does this get enforced? In other words, what can be done for the >> > network to protect itself if a sender violates this? >> > >> > One possible answer is to restrict the MAC address that may be used to >> > one that is owned by the VTEP or a "agreed on" multicast MAC address. >> > That means the receiver only needs to validate for those, and just >> > treats everything else as data. >> > >> > Also, for interoperability purposes, it would be best to specify that a >> > receiver MUST be able to handle any valid MAC address for the BFD >> > session, while a sender MAY pick any of them. >> > >> > Thanks, >> > Anoop >> > >> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky > > > wrote: >> > >> > Hi Anoop, >> > thank you for your comments and questions. Please find my notes >> > in-line tagged GIM>>. >> > >> > Regards, >> > Greg >> > >> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >> anoop@alumni.duke..edu >> > > wrote: >> > >> > Hi Greg, >> > >> > A few comments. >> > >> > The draft has nits, specifically around the way the IPv6 address >> > is written. >> > >> > In section 4: >> > >> > BFD packet MUST be encapsulated -> >> > >> > BFD packets MUST be encapsulated >> > >> > GIM>> Thanks, will do. >> > >> > >> > >>> >> > >> > Destination MAC: This MUST NOT be of one of tenant's MAC >> > addresses. The destination MAC address MAY be the >> address >> > associated with the destination VTEP. The MAC >> address MAY be >> > configured, or it MAY be learned via a control plane >> protocol. >> > The details of how the MAC address is obtained are >> outside the >> > scope of this document. >> > >> > >>> >> > It looks like we have removed the option of using a well-known >> > IANA assigned MAC. If so, why is the above a MAY and not a >> > MUST? What else can it be? One interpretation is that it can >> > be anything unicast, or multicast, as long as it's not a tenant >> > MAC. Is that the intent? If so, it would be better to state it >> > that way. Also (and this is purely editorial), I think it would >> > be better if the first sentence above were moved to the end of >> > the paragraph. >> > >> > GIM>> Yes, you're right, we've removed that option and have removed >> > the request to IANA. I also agree that " MAY be the address >> > associated with the destination VTEP" is not the right choice of >> > normative language. On the other hand, MUST might be too restrictive >> > if BFD session is using the Management VNI. Would the following >> > update address your concern: >> > OLD TEXT: >> > Destination MAC: This MUST NOT be of one of tenant's MAC >> > addresses. The destination MAC address MAY be the address >> > associated with the destination VTEP. The MAC address >> MAY be >> > configured, or it MAY be learned via a control plane >> protocol. >> > The details of how the MAC address is obtained are >> outside the >> > scope of this document. >> > NEW TEXT: >> > Destination MAC: If the BFD session is not using the >> > Management VNI, >> > the destination MAC address MUST be the address >> > associated with the destination VTEP. The Destination MAC >> > MUST NOT be one of the tenant's MAC addresses. >> > The MAC address MAY be configured, or it MAY be learned via >> > a control plane protocol. The details of how the MAC >> address >> > is obtained are outside the scope of this document. >> > >> > >> > "The inner Ethernet frame carrying the BFD >> > Control packet- has the following format:" >> > >> > Extraneous '-' after packet. >> > >> > GIM>> Thanks, will do that too. >> > >> > >> > Thanks, >> > Anoop >> > >> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >> > > wrote: >> > >> > Dear All, >> > the new version includes updates resulting from the >> > discussions of Joel's comments in the RtrDir review of BFD >> > over VXLAN draft, comments from Anoop, and Dinesh. On behalf >> > of editors, thank you for your constructive comments and for >> > sharing your expertise, all much appreciated. >> > I hope we've addressed all your comments, and the draft can >> > proceed further. >> > >> > Regards, >> > Greg >> > >> > ---------- Forwarded message --------- >> > From: > > > >> > Date: Fri, Nov 1, 2019 at 10:45 AM >> > Subject: New Version Notification for >> > draft-ietf-bfd-vxlan-08..txt >> > To: Gregory Mirsky > > >, Mallik Mudigonda >> > >, Sudarsan >> > Paragiri > > >, Vengada Prasad Govindan >> > >, Santosh >> > Pallagatti > > > >> > >> > >> > >> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >> > has been successfully submitted by Greg Mirsky and posted >> to the >> > IETF repository. >> > >> > Name: draft-ietf-bfd-vxlan >> > Revision: 08 >> > Title: BFD for VXLAN >> > Document date: 2019-11-01 >> > Group: bfd >> > Pages: 11 >> > URL: >> > >> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >> > Status: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >> > Htmlized: >> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >> > Htmlized: >> > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >> > Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >> > >> > Abstract: >> > This document describes the use of the Bidirectional >> > Forwarding >> > Detection (BFD) protocol in point-to-point Virtual >> > eXtensible Local >> > Area Network (VXLAN) tunnels forming up an overlay >> network. >> > >> > >> > >> > >> > 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 < >> http://tools.ietf.org>. >> > >> > The IETF Secretariat >> > >> > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > --00000000000006418c059685190d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non-= managment VNI why do we need to have multicast MAC address for backward=C2= =A0compatibility for existing implementation=C2=A0or there are any use case= s such that we can avoid learning of remote end VTEP?=C2=A0

<= /div>
Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop@al= umni.duke.edu> wrote:
Hi Joel,

In that case I wo= uld propose the following text:

"Destination MAC: If the BFD session is not using the=C2=A0Management VNI,
the destination MAC = address MUST be the address
associated with the destination VTEP.=C2=A0 If the B= FD session uses
the Management VNI, it may use any MAC add= ress, since use of the=C2=A0
Management VNI ensures that these pa= ckets will never be forwarded to a VM.
The MAC address may be configured, or it may be = learned via
a control plane protocol. The details of how the MAC address<= br style=3D"color:rgb(0,0,0)">to be used i= s obtained are outside the scope of this document."

That said, for non-Management VNI, do we want to allow for = flexibility
for an implem= entation to use a multicast MAC of their choosing?=C2=A0 If so, we
should probably add a sentence for that to= o.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Jo= el M. Halpern <= jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--00000000000006418c059685190d-- From nobody Mon Nov 4 07:00:54 2019 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 9F06C120A62; Mon, 4 Nov 2019 07:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 T3EUOhatCeIZ; Mon, 4 Nov 2019 07:00:43 -0800 (PST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 96371120986; Mon, 4 Nov 2019 07:00:42 -0800 (PST) Received: by mail-vs1-f47.google.com with SMTP id y129so11163753vsc.6; Mon, 04 Nov 2019 07:00:42 -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=+xHobcSm4cxGdT5LCPpFYwZ5ktAQJo6VFhFSHG74+Dk=; b=l9vXdIiWn1vQqcearJZURuI2/7ey/A9JWE+k+YT9e7nh6wqdBbkLfo1uUk9zeYpDmw cdie8sBJrFwspzIedKhVyR8Y12pokH5rfui+ewRHeCLq06EojP1O4QPDuN5+Zbk4nQDE 28cThty8xiG/twpd6k0UXBsVJG90F15oWXfHaoyHlrvUtT1rSRN3dAuJzYuvFQj4FSKZ SsT71RROQKRmHtd92x4crR/xb/CttMPbrQ+t0b0SEzk9MyIHdjtjPlf43RTYmT9bmXuP +7SP/gr9UsxBUWb2fOMrsQogP4Pvi219h6Ud6I7hOckcsHPzNsTYEpM8BfUHY/wQafF0 cODg== X-Gm-Message-State: APjAAAWCw7mvbGNhS0icqlPyDD9p0VXWXmzyBZBthBHp1wKq3AY+MOn6 nD62585WtG8NteRMI0Tn9Tg5LHnNzuhA1VAEj+RRgL6u X-Google-Smtp-Source: APXvYqwd8D/dWVfQwJgG4YwJhIeTRG37KuYreiBi4EUv4E2yJO04uXIRJvZOMS8cu7AJBQ6OxXc9moyUvc2It6ydqrw= X-Received: by 2002:a67:1a82:: with SMTP id a124mr12779625vsa.60.1572879641444; Mon, 04 Nov 2019 07:00:41 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Anoop Ghanwani Date: Mon, 4 Nov 2019 07:00:27 -0800 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Santosh P K Cc: "Joel M. Halpern" , Greg Mirsky , rtg-bfd WG , NVO3 , Dinesh Dutt Content-Type: multipart/alternative; boundary="0000000000004d87360596869410" Archived-At: 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: Mon, 04 Nov 2019 15:00:50 -0000 --0000000000004d87360596869410 Content-Type: text/plain; charset="UTF-8" Hi Santosh, I'm not aware of any implementation that uses a multicast MAC for this. The closest thing that I'm aware of that helps alleviate the need for knowing the MAC of the remote VTEP is what's done in open vswitch: http://www.openvswitch.org/support/dist-docs/vtep.5.html *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set the destination MAC to be used for transmitted BFD packets. The default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be the equivalent. Anoop On Mon, Nov 4, 2019 at 5:14 AM Santosh P K wrote: > Anoop, > Thanks for your comments. For non-managment VNI why do we need to have > multicast MAC address for backward compatibility for existing > implementation or there are any use cases such that we can avoid learning > of remote end VTEP? > > Thanks > Santosh P K > > On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani > wrote: > >> Hi Joel, >> >> In that case I would propose the following text: >> >> "Destination MAC: If the BFD session is not using the Management VNI, >> the destination MAC address MUST be the address >> associated with the destination VTEP. If the BFD session uses >> the Management VNI, it may use any MAC address, since use of the >> Management VNI ensures that these packets will never be forwarded to a VM. >> The MAC address may be configured, or it may be learned via >> a control plane protocol. The details of how the MAC address >> to be used is obtained are outside the scope of this document." >> >> That said, for non-Management VNI, do we want to allow for flexibility >> for an implementation to use a multicast MAC of their choosing? If so, we >> should probably add a sentence for that too. >> >> Thanks, >> Anoop >> >> >> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >> wrote: >> >>> Anoop, I think I at least am misunderstanding you. >>> If one is using the management VNI, as I understand it there is no >>> tenant. So there are no tenant MAC addresses. (This is one of the >>> reasons I like using the management VNI.) >>> >>> >>> Yours, >>> Joel >>> >>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>> > Hi Greg, >>> > >>> > In the case of the management VNI, are we trying to say that we would >>> > allow any MAC address other than a tenant MAC address? I would >>> suggest >>> > some more text be added to clarify what is permitted on the management >>> > VLAN. Assuming that we want to allow any MAC other than a tenant MAC, >>> > how does this get enforced? In other words, what can be done for the >>> > network to protect itself if a sender violates this? >>> > >>> > One possible answer is to restrict the MAC address that may be used to >>> > one that is owned by the VTEP or a "agreed on" multicast MAC address. >>> > That means the receiver only needs to validate for those, and just >>> > treats everything else as data. >>> > >>> > Also, for interoperability purposes, it would be best to specify that >>> a >>> > receiver MUST be able to handle any valid MAC address for the BFD >>> > session, while a sender MAY pick any of them. >>> > >>> > Thanks, >>> > Anoop >>> > >>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >> > > wrote: >>> > >>> > Hi Anoop, >>> > thank you for your comments and questions. Please find my notes >>> > in-line tagged GIM>>. >>> > >>> > Regards, >>> > Greg >>> > >>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>> anoop@alumni.duke..edu >>> > > wrote: >>> > >>> > Hi Greg, >>> > >>> > A few comments. >>> > >>> > The draft has nits, specifically around the way the IPv6 >>> address >>> > is written. >>> > >>> > In section 4: >>> > >>> > BFD packet MUST be encapsulated -> >>> > >>> > BFD packets MUST be encapsulated >>> > >>> > GIM>> Thanks, will do. >>> > >>> > >>> > >>> >>> > >>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>> > addresses. The destination MAC address MAY be the >>> address >>> > associated with the destination VTEP. The MAC >>> address MAY be >>> > configured, or it MAY be learned via a control plane >>> protocol. >>> > The details of how the MAC address is obtained are >>> outside the >>> > scope of this document. >>> > >>> > >>> >>> > It looks like we have removed the option of using a well-known >>> > IANA assigned MAC. If so, why is the above a MAY and not a >>> > MUST? What else can it be? One interpretation is that it can >>> > be anything unicast, or multicast, as long as it's not a tenant >>> > MAC. Is that the intent? If so, it would be better to state >>> it >>> > that way. Also (and this is purely editorial), I think it >>> would >>> > be better if the first sentence above were moved to the end of >>> > the paragraph. >>> > >>> > GIM>> Yes, you're right, we've removed that option and have removed >>> > the request to IANA. I also agree that " MAY be the address >>> > associated with the destination VTEP" is not the right choice of >>> > normative language. On the other hand, MUST might be too >>> restrictive >>> > if BFD session is using the Management VNI. Would the following >>> > update address your concern: >>> > OLD TEXT: >>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>> > addresses. The destination MAC address MAY be the >>> address >>> > associated with the destination VTEP. The MAC address >>> MAY be >>> > configured, or it MAY be learned via a control plane >>> protocol. >>> > The details of how the MAC address is obtained are >>> outside the >>> > scope of this document. >>> > NEW TEXT: >>> > Destination MAC: If the BFD session is not using the >>> > Management VNI, >>> > the destination MAC address MUST be the address >>> > associated with the destination VTEP. The Destination >>> MAC >>> > MUST NOT be one of the tenant's MAC addresses. >>> > The MAC address MAY be configured, or it MAY be learned >>> via >>> > a control plane protocol. The details of how the MAC >>> address >>> > is obtained are outside the scope of this document. >>> > >>> > >>> > "The inner Ethernet frame carrying the BFD >>> > Control packet- has the following format:" >>> > >>> > Extraneous '-' after packet. >>> > >>> > GIM>> Thanks, will do that too. >>> > >>> > >>> > Thanks, >>> > Anoop >>> > >>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>> > > wrote: >>> > >>> > Dear All, >>> > the new version includes updates resulting from the >>> > discussions of Joel's comments in the RtrDir review of BFD >>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>> behalf >>> > of editors, thank you for your constructive comments and >>> for >>> > sharing your expertise, all much appreciated. >>> > I hope we've addressed all your comments, and the draft can >>> > proceed further. >>> > >>> > Regards, >>> > Greg >>> > >>> > ---------- Forwarded message --------- >>> > From: >> > > >>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>> > Subject: New Version Notification for >>> > draft-ietf-bfd-vxlan-08..txt >>> > To: Gregory Mirsky >> > >, Mallik Mudigonda >>> > >, Sudarsan >>> > Paragiri >> > >, Vengada Prasad Govindan >>> > >, Santosh >>> > Pallagatti >> > > >>> > >>> > >>> > >>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>> > has been successfully submitted by Greg Mirsky and posted >>> to the >>> > IETF repository. >>> > >>> > Name: draft-ietf-bfd-vxlan >>> > Revision: 08 >>> > Title: BFD for VXLAN >>> > Document date: 2019-11-01 >>> > Group: bfd >>> > Pages: 11 >>> > URL: >>> > >>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>> > Status: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>> > Htmlized: >>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>> > Htmlized: >>> > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>> > Diff: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>> > >>> > Abstract: >>> > This document describes the use of the Bidirectional >>> > Forwarding >>> > Detection (BFD) protocol in point-to-point Virtual >>> > eXtensible Local >>> > Area Network (VXLAN) tunnels forming up an overlay >>> network. >>> > >>> > >>> > >>> > >>> > 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 < >>> http://tools.ietf.org>. >>> > >>> > The IETF Secretariat >>> > >>> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > --0000000000004d87360596869410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Santosh,

I'm not aware of any im= plementation that uses a multicast MAC for this.=C2=A0 The closest thing th= at I'm aware of that helps alleviate the need for knowing the MAC of th= e remote=C2=A0VTEP is what's done in open vswitch:
   bfd_conf=
ig_remote : bfd_dst_=
mac: optional string
              Set  to an Ethernet address in the form xx:x=
x:xx:xx:xx:x=
x to set
              the destination MAC to be used for transmitted BFD packets.  =
The
              default is 00:23:20:00:00:0<=
/b>1.
That OUI belongs to Nicira/VMware.=C2=A0 An IA= NA assigned unicast MAC would be the equivalent.

A= noop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.com> wrote:
= Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non-managment VNI why= do we need to have multicast MAC address for backward=C2=A0compatibility f= or existing implementation=C2=A0or there are any use cases such that we can= avoid learning of remote end VTEP?=C2=A0

Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanw= ani <anoop@al= umni.duke.edu> wrote:
Hi Joel,

In that case I wo= uld propose the following text:

"Destination MAC: If the BFD session is not using the=C2=A0Management VNI,
the destination MAC = address MUST be the address
associated with the destination VTEP.=C2=A0 If the B= FD session uses
the Management VNI, it may use any MAC add= ress, since use of the=C2=A0
Management VNI ensures that these pa= ckets will never be forwarded to a VM.
The MAC address may be configured, or it may be = learned via
a control plane protocol. The details of how the MAC address<= br style=3D"color:rgb(0,0,0)">to be used i= s obtained are outside the scope of this document."

That said, for non-Management VNI, do we want to allow for = flexibility
for an implem= entation to use a multicast MAC of their choosing?=C2=A0 If so, we
should probably add a sentence for that to= o.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Jo= el M. Halpern <= jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--0000000000004d87360596869410-- From nobody Mon Nov 4 08:00:06 2019 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 5941C120A48; Mon, 4 Nov 2019 07:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZMHKybTVSccF; Mon, 4 Nov 2019 07:59:51 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 34B4A120A47; Mon, 4 Nov 2019 07:59:51 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id f2so8795814wrs.11; Mon, 04 Nov 2019 07:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a6/3hm/GAvr5inC2rDw7mb2r3DFKgk0PT4WPlxm9+90=; b=phZVtDeuCyNzAUozu/jjLX1HNtwkZI47FjOtpZCt7WsqlxwK4zFXN9AsUHBZjuiqdU C/txQs2/ni1pcpcE7T/urC8xvJB5KIxr6ezMHjKEELboMczbQSXXNWu8MPasA44D7Esw vv8nCXH05tNdbvHhNoi56AzjRsC5cXoO1s2xPfD6c+N10/4VjeTSJFRBKaTMU2g87w9e H+OQXM0eGcnO4BvbLYWhQe4AIsO1/QDDYFSC47ya1G9ghR2CgFSCeolpQgDMRth0d6gV A+dF8ApvUIAl2mXyf1eaXM+lqZcQplvpSvRQwVp/9rDar/FvoEeCyGi78feWM0ygyhfp pnOA== 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=a6/3hm/GAvr5inC2rDw7mb2r3DFKgk0PT4WPlxm9+90=; b=LTsodrVyWOCpcnNwKOuajJocFDVsG0pG2VjbAer0vJ63Tzlo6T7tq9POU/T63xmKew rH+Vk5fe16esqdarP7nasqQstq+UMvc9BQh6WbNSDgLw3V2cFcQTDzPTg+KXk9ajnkT8 dfyv1hnUvSmc6IKxLOe9t3wTvE7pApkHHG+QjJzW5NHYHOrjn4xOy7pQCPaNPhwojxSN hK6xbgJ3oQNL4bnNGCiXImtyMTIofqNvKbuawxzVxmgHUWci72i5+eW+ux6XakYo4+3r rox/3yk4DLcHSNUlkI9m8Gklc7L1uCE+cl37oJ6DueTm2MtQ3T5Efjr7zXGOXZK54aiX s2yg== X-Gm-Message-State: APjAAAXeWPBgTWHK5XgnCF6/BXfje8UlZyEGrlV8KEImDBwJRhY3LmLT mRm78VQOxoXooULbcmZBS3Kj4srPIptS3kNaViM= X-Google-Smtp-Source: APXvYqxGZxRbAEgJO5zKS4PvZ/YyXXVFQU+66aRWjFb+JFwkBJvE2e8V8VYXx4Eh5RnkDjO3WvyKtdd9qE48gNPB5CQ= X-Received: by 2002:adf:dc8d:: with SMTP id r13mr16262418wrj.391.1572883189587; Mon, 04 Nov 2019 07:59:49 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> In-Reply-To: From: Santosh P K Date: Mon, 4 Nov 2019 21:29:38 +0530 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Anoop Ghanwani Cc: "Joel M. Halpern" , Greg Mirsky , rtg-bfd WG , NVO3 , Dinesh Dutt Content-Type: multipart/alternative; boundary="000000000000c9e29d0596876793" Archived-At: 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: Mon, 04 Nov 2019 15:59:55 -0000 --000000000000c9e29d0596876793 Content-Type: text/plain; charset="UTF-8" Thanks Anoop this helps. I guess in that case we may not restrict it to VTEP MAC only and leave it to implementation but we might need to add text for interop in cases if someone uses fixed mac like this for valid non-managment VNI then how it should be handled? We can wait for others also to comment on this before we can make these changes to draft. Thanks Santosh P K On Mon, Nov 4, 2019 at 8:30 PM Anoop Ghanwani wrote: > Hi Santosh, > > I'm not aware of any implementation that uses a multicast MAC for this. > The closest thing that I'm aware of that helps alleviate the need for > knowing the MAC of the remote VTEP is what's done in open vswitch: > http://www.openvswitch.org/support/dist-docs/vtep.5.html > > *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string > Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set > the destination MAC to be used for transmitted BFD packets. The > default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. > > That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be > the equivalent. > > Anoop > > On Mon, Nov 4, 2019 at 5:14 AM Santosh P K > wrote: > >> Anoop, >> Thanks for your comments. For non-managment VNI why do we need to have >> multicast MAC address for backward compatibility for existing >> implementation or there are any use cases such that we can avoid learning >> of remote end VTEP? >> >> Thanks >> Santosh P K >> >> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >> wrote: >> >>> Hi Joel, >>> >>> In that case I would propose the following text: >>> >>> "Destination MAC: If the BFD session is not using the Management VNI, >>> the destination MAC address MUST be the address >>> associated with the destination VTEP. If the BFD session uses >>> the Management VNI, it may use any MAC address, since use of the >>> Management VNI ensures that these packets will never be forwarded to a >>> VM. >>> The MAC address may be configured, or it may be learned via >>> a control plane protocol. The details of how the MAC address >>> to be used is obtained are outside the scope of this document." >>> >>> That said, for non-Management VNI, do we want to allow for flexibility >>> for an implementation to use a multicast MAC of their choosing? If so, >>> we >>> should probably add a sentence for that too. >>> >>> Thanks, >>> Anoop >>> >>> >>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>> wrote: >>> >>>> Anoop, I think I at least am misunderstanding you. >>>> If one is using the management VNI, as I understand it there is no >>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>> reasons I like using the management VNI.) >>>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>> > Hi Greg, >>>> > >>>> > In the case of the management VNI, are we trying to say that we would >>>> > allow any MAC address other than a tenant MAC address? I would >>>> suggest >>>> > some more text be added to clarify what is permitted on the >>>> management >>>> > VLAN. Assuming that we want to allow any MAC other than a tenant >>>> MAC, >>>> > how does this get enforced? In other words, what can be done for the >>>> > network to protect itself if a sender violates this? >>>> > >>>> > One possible answer is to restrict the MAC address that may be used >>>> to >>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>> address. >>>> > That means the receiver only needs to validate for those, and just >>>> > treats everything else as data. >>>> > >>>> > Also, for interoperability purposes, it would be best to specify that >>>> a >>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>> > session, while a sender MAY pick any of them. >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>> > > wrote: >>>> > >>>> > Hi Anoop, >>>> > thank you for your comments and questions. Please find my notes >>>> > in-line tagged GIM>>. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>>> anoop@alumni.duke..edu >>>> > > wrote: >>>> > >>>> > Hi Greg, >>>> > >>>> > A few comments. >>>> > >>>> > The draft has nits, specifically around the way the IPv6 >>>> address >>>> > is written. >>>> > >>>> > In section 4: >>>> > >>>> > BFD packet MUST be encapsulated -> >>>> > >>>> > BFD packets MUST be encapsulated >>>> > >>>> > GIM>> Thanks, will do. >>>> > >>>> > >>>> > >>> >>>> > >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC >>>> address MAY be >>>> > configured, or it MAY be learned via a control >>>> plane protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > >>>> > >>> >>>> > It looks like we have removed the option of using a well-known >>>> > IANA assigned MAC. If so, why is the above a MAY and not a >>>> > MUST? What else can it be? One interpretation is that it can >>>> > be anything unicast, or multicast, as long as it's not a >>>> tenant >>>> > MAC. Is that the intent? If so, it would be better to state >>>> it >>>> > that way. Also (and this is purely editorial), I think it >>>> would >>>> > be better if the first sentence above were moved to the end of >>>> > the paragraph. >>>> > >>>> > GIM>> Yes, you're right, we've removed that option and have >>>> removed >>>> > the request to IANA. I also agree that " MAY be the address >>>> > associated with the destination VTEP" is not the right choice of >>>> > normative language. On the other hand, MUST might be too >>>> restrictive >>>> > if BFD session is using the Management VNI. Would the following >>>> > update address your concern: >>>> > OLD TEXT: >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC address >>>> MAY be >>>> > configured, or it MAY be learned via a control plane >>>> protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > NEW TEXT: >>>> > Destination MAC: If the BFD session is not using the >>>> > Management VNI, >>>> > the destination MAC address MUST be the address >>>> > associated with the destination VTEP. The Destination >>>> MAC >>>> > MUST NOT be one of the tenant's MAC addresses. >>>> > The MAC address MAY be configured, or it MAY be learned >>>> via >>>> > a control plane protocol. The details of how the MAC >>>> address >>>> > is obtained are outside the scope of this document. >>>> > >>>> > >>>> > "The inner Ethernet frame carrying the BFD >>>> > Control packet- has the following format:" >>>> > >>>> > Extraneous '-' after packet. >>>> > >>>> > GIM>> Thanks, will do that too. >>>> > >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>> > > wrote: >>>> > >>>> > Dear All, >>>> > the new version includes updates resulting from the >>>> > discussions of Joel's comments in the RtrDir review of BFD >>>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>>> behalf >>>> > of editors, thank you for your constructive comments and >>>> for >>>> > sharing your expertise, all much appreciated. >>>> > I hope we've addressed all your comments, and the draft >>>> can >>>> > proceed further. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > ---------- Forwarded message --------- >>>> > From: >>> > > >>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>> > Subject: New Version Notification for >>>> > draft-ietf-bfd-vxlan-08..txt >>>> > To: Gregory Mirsky >>> > >, Mallik Mudigonda >>>> > >, >>>> Sudarsan >>>> > Paragiri >>> > >, Vengada Prasad Govindan >>>> > >, Santosh >>>> > Pallagatti >>> > > >>>> > >>>> > >>>> > >>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>> > has been successfully submitted by Greg Mirsky and posted >>>> to the >>>> > IETF repository. >>>> > >>>> > Name: draft-ietf-bfd-vxlan >>>> > Revision: 08 >>>> > Title: BFD for VXLAN >>>> > Document date: 2019-11-01 >>>> > Group: bfd >>>> > Pages: 11 >>>> > URL: >>>> > >>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>> > Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>> > Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>> > Htmlized: >>>> > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>> > Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>> > >>>> > Abstract: >>>> > This document describes the use of the Bidirectional >>>> > Forwarding >>>> > Detection (BFD) protocol in point-to-point Virtual >>>> > eXtensible Local >>>> > Area Network (VXLAN) tunnels forming up an overlay >>>> network. >>>> > >>>> > >>>> > >>>> > >>>> > 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 < >>>> http://tools.ietf.org>. >>>> > >>>> > The IETF Secretariat >>>> > >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> --000000000000c9e29d0596876793 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Anoop this helps. I guess in that case we may not r= estrict it to VTEP MAC only and leave it to implementation=C2=A0but we migh= t need to add text for interop in cases if someone uses fixed mac like this= for valid non-managment VNI then how it should be handled?=C2=A0

<= /div>
We can wait for others also to comment on this before we can make= these changes to draft.=C2=A0


Than= ks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 8:30 PM Anoop Gh= anwani <anoop@alumni.duke.edu> wrote:
Hi Santosh,

I'm not aware of any impl= ementation that uses a multicast MAC for this.=C2=A0 The closest thing that= I'm aware of that helps alleviate the need for knowing the MAC of the = remote=C2=A0VTEP is what's done in open vswitch:
bfd_co= nfig_remote : bfd_ds= t_mac: optional string Set to an Ethernet address in the form xx:x= x:xx:xx:xx:x= x to set the destination MAC to be used for transmitted BFD packets. = The default is 00:23:20:00:00:0<= /b>1.
That OUI belongs to Nicira/VMware.=C2=A0 An IA= NA assigned unicast MAC would be the equivalent.

A= noop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.co= m> wrote:
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non= -managment VNI why do we need to have multicast MAC address for backward=C2= =A0compatibility for existing implementation=C2=A0or there are any use case= s such that we can avoid learning of remote end VTEP?=C2=A0

<= /div>
Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD sessio= n is not using the=C2=A0Management = VNI,
= the destination MAC address MUST be the address
associated with the destination = VTEP.=C2=A0 If the BFD session uses
the Management VNI, it= may use any MAC address, since use of the=C2=A0
Management VNI e= nsures that these packets will never be forwarded to a VM.
The MAC address may be confi= gured, or it may be learned via
a control plane protocol. The details of how the= MAC address
to be used is obtained are outside the scope of this document."= ;

That said, for non-Management VNI, do w= e want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?=C2= =A0 If so, we
should probably add = a sentence for that too.

Thanks,
Anoop<= /div>

On Sun, N= ov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am mis= understanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--000000000000c9e29d0596876793-- From nobody Mon Nov 4 09:36:42 2019 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 2834C120BBA; Mon, 4 Nov 2019 09:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com 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 9Z8OkQo0UQfE; Mon, 4 Nov 2019 09:36:24 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 9BD77120BAD; Mon, 4 Nov 2019 09:36:24 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id 29so454915pgm.6; Mon, 04 Nov 2019 09:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=1Glmi7fk9WAipwghDMWJDXH2fl/cVkYgnq1+gUAhhVM=; b=c5DKFNKA6w5YtuR5aS88aXkEZhd8Gbmme/OYY0SwMxS2FwcbS1I+joCyOzYzzJubT6 vjGu+uHvA6kO7+ehClZwr3UpNwHizBziB2KJa4TaeQxpqRhpRhj3YaixDTZ2Cl6hdsAJ coVOUqieITM6sXoz/34qpP1z0lJa28V7y0OGuAMCB/VPbHUqupCfZVCOuyLJsEIq9M7t r8XGsu0wclSQrUMXtJBL2n8ZPv8H1I1p4v4myEzgpOrvqjQGj0JpvVI+tgjvk984lOJm azuhRQRTz0BhTpZ5IpQmvd+UUEtXbP9BrcK5pe0KdLyrqsLKnnfzhOZNMpShcfj7HCJf y80A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=1Glmi7fk9WAipwghDMWJDXH2fl/cVkYgnq1+gUAhhVM=; b=rgu04X8yUwRwioX7CqujWQzI2qxMTgRy/NoJQQxBR7kxC/prL2q1DxANW9XYJvgDW4 eMIxppy4sCVPx7i6SdrCBHkT3YasBLR/XFndE2vnZh6GaLVkOWit5VYeYuhph2/mDEEp RXkUPzMyW7+Ug37SRmF0Shsx99TR3i7oY8EFNZTmoSXESOruKeWmkrzAbGXHV69wUf6H 27p/DVggzHhW5woiaPlIFJoaueGXM+rCsz7g3UwpXKrY8Syo/yoLRlF5p/Jy+N86KpUP ruZllsuKOTi/5GBiWJyu6lhg/36oCZBxEMS/l8EEPGE7NKu6/tM8YhfV/Ozk5c/fhAPZ mcqw== X-Gm-Message-State: APjAAAUFM1ZnCiXxpi7oCX1q7D20j/O4HQi7sIX+9qP+1m/McnjJc4nN r5tp0OMbb3YxYOU7SseATRk= X-Google-Smtp-Source: APXvYqyChcbFrRmK0Ei0LF9W15jDnmtB+O0S73N3xwGUgTlvEzLQo7+ClTIY03oOJxpaykxuO9ZBCA== X-Received: by 2002:aa7:8b4d:: with SMTP id i13mr33110836pfd.226.1572888983982; Mon, 04 Nov 2019 09:36:23 -0800 (PST) Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id g19sm8855718pfi.65.2019.11.04.09.36.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Nov 2019 09:36:22 -0800 (PST) Date: Mon, 04 Nov 2019 22:36:17 +0500 From: Dinesh Dutt Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Anoop Ghanwani Cc: Santosh P K , "Joel M. Halpern" , Greg Mirsky , rtg-bfd WG , NVO3 Message-Id: <1572888977.25948.5@smtp.gmail.com> In-Reply-To: References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-w8Y5Woiq3+aBHyCgs3YL" Archived-At: 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: Mon, 04 Nov 2019 17:36:32 -0000 --=-w8Y5Woiq3+aBHyCgs3YL Content-Type: text/plain; charset=us-ascii; format=flowed I didn't suggest the use of a multicast MAC, any MAC would be fine in the management VNI since there can be no tenant VMs on a management VNI. I was recommending specifying a unicast MAC. Santosh, as I mentioned to Joel, I don't want to add additional forwarding requirements--such as VNI-specific behavior--in VXLAN. The existing mechanism is sufficient for the case we're discussing here. Just pick a MAC in management VNI for the sake of configuration simplicity. Dinesh On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani wrote: > Hi Santosh, > > I'm not aware of any implementation that uses a multicast MAC for > this. The closest thing that I'm aware of that helps alleviate the > need for knowing the MAC of the remote VTEP is what's done in open > vswitch: > http://www.openvswitch.org/support/dist-docs/vtep.5.html > bfd_config_remote : bfd_dst_mac: optional string > Set to an Ethernet address in the form > xx:xx:xx:xx:xx:xx to set > the destination MAC to be used for transmitted BFD > packets. The > default is 00:23:20:00:00:01. > That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC > would be the equivalent. > > Anoop > > On Mon, Nov 4, 2019 at 5:14 AM Santosh P K > wrote: >> Anoop, >> Thanks for your comments. For non-managment VNI why do we need to >> have multicast MAC address for backward compatibility for existing >> implementation or there are any use cases such that we can avoid >> learning of remote end VTEP? >> >> Thanks >> Santosh P K >> >> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >> wrote: >>> Hi Joel, >>> >>> In that case I would propose the following text: >>> >>> "Destination MAC: If the BFD session is not using the Management >>> VNI, >>> the destination MAC address MUST be the address >>> associated with the destination VTEP. If the BFD session uses >>> the Management VNI, it may use any MAC address, since use of the >>> Management VNI ensures that these packets will never be forwarded >>> to a VM. >>> The MAC address may be configured, or it may be learned via >>> a control plane protocol. The details of how the MAC address >>> to be used is obtained are outside the scope of this document." >>> >>> That said, for non-Management VNI, do we want to allow for >>> flexibility >>> for an implementation to use a multicast MAC of their choosing? If >>> so, we >>> should probably add a sentence for that too. >>> >>> Thanks, >>> Anoop >>> >>> >>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>> wrote: >>>> Anoop, I think I at least am misunderstanding you. >>>> If one is using the management VNI, as I understand it there is no >>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>> reasons I like using the management VNI.) >>>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>> > Hi Greg, >>>> > >>>> > In the case of the management VNI, are we trying to say that we >>>> would >>>> > allow any MAC address other than a tenant MAC address? I would >>>> suggest >>>> > some more text be added to clarify what is permitted on the >>>> management >>>> > VLAN. Assuming that we want to allow any MAC other than a >>>> tenant MAC, >>>> > how does this get enforced? In other words, what can be done >>>> for the >>>> > network to protect itself if a sender violates this? >>>> > >>>> > One possible answer is to restrict the MAC address that may be >>>> used to >>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>> address. >>>> > That means the receiver only needs to validate for those, and >>>> just >>>> > treats everything else as data. >>>> > >>>> > Also, for interoperability purposes, it would be best to specify >>>> that a >>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>> > session, while a sender MAY pick any of them. >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>> > > wrote: >>>> > >>>> > Hi Anoop, >>>> > thank you for your comments and questions. Please find my >>>> notes >>>> > in-line tagged GIM>>. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani >>>> >>> > > wrote: >>>> > >>>> > Hi Greg, >>>> > >>>> > A few comments. >>>> > >>>> > The draft has nits, specifically around the way the IPv6 >>>> address >>>> > is written. >>>> > >>>> > In section 4: >>>> > >>>> > BFD packet MUST be encapsulated -> >>>> > >>>> > BFD packets MUST be encapsulated >>>> > >>>> > GIM>> Thanks, will do. >>>> > >>>> > >>>> > >>> >>>> > >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be >>>> the address >>>> > associated with the destination VTEP. The MAC >>>> address MAY be >>>> > configured, or it MAY be learned via a control >>>> plane protocol. >>>> > The details of how the MAC address is obtained >>>> are outside the >>>> > scope of this document. >>>> > >>>> > >>> >>>> > It looks like we have removed the option of using a >>>> well-known >>>> > IANA assigned MAC. If so, why is the above a MAY and >>>> not a >>>> > MUST? What else can it be? One interpretation is that >>>> it can >>>> > be anything unicast, or multicast, as long as it's not a >>>> tenant >>>> > MAC. Is that the intent? If so, it would be better to >>>> state it >>>> > that way. Also (and this is purely editorial), I think >>>> it would >>>> > be better if the first sentence above were moved to the >>>> end of >>>> > the paragraph. >>>> > >>>> > GIM>> Yes, you're right, we've removed that option and have >>>> removed >>>> > the request to IANA. I also agree that " MAY be the address >>>> > associated with the destination VTEP" is not the right >>>> choice of >>>> > normative language. On the other hand, MUST might be too >>>> restrictive >>>> > if BFD session is using the Management VNI. Would the >>>> following >>>> > update address your concern: >>>> > OLD TEXT: >>>> > Destination MAC: This MUST NOT be of one of >>>> tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC >>>> address MAY be >>>> > configured, or it MAY be learned via a control >>>> plane protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > NEW TEXT: >>>> > Destination MAC: If the BFD session is not using >>>> the >>>> > Management VNI, >>>> > the destination MAC address MUST be the address >>>> > associated with the destination VTEP. The >>>> Destination MAC >>>> > MUST NOT be one of the tenant's MAC addresses. >>>> > The MAC address MAY be configured, or it MAY be >>>> learned via >>>> > a control plane protocol. The details of how the >>>> MAC address >>>> > is obtained are outside the scope of this document. >>>> > >>>> > >>>> > "The inner Ethernet frame carrying the BFD >>>> > Control packet- has the following format:" >>>> > >>>> > Extraneous '-' after packet. >>>> > >>>> > GIM>> Thanks, will do that too. >>>> > >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>> > > >>>> wrote: >>>> > >>>> > Dear All, >>>> > the new version includes updates resulting from the >>>> > discussions of Joel's comments in the RtrDir review >>>> of BFD >>>> > over VXLAN draft, comments from Anoop, and Dinesh. >>>> On behalf >>>> > of editors, thank you for your constructive comments >>>> and for >>>> > sharing your expertise, all much appreciated. >>>> > I hope we've addressed all your comments, and the >>>> draft can >>>> > proceed further. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > ---------- Forwarded message --------- >>>> > From: >>> > > >>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>> > Subject: New Version Notification for >>>> > draft-ietf-bfd-vxlan-08..txt >>>> > To: Gregory Mirsky >>> > >, Mallik Mudigonda >>>> > >, >>>> Sudarsan >>>> > Paragiri >>> > >, Vengada Prasad >>>> Govindan >>>> > >, >>>> Santosh >>>> > Pallagatti >>> > > >>>> > >>>> > >>>> > >>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>> > has been successfully submitted by Greg Mirsky and >>>> posted to the >>>> > IETF repository. >>>> > >>>> > Name: draft-ietf-bfd-vxlan >>>> > Revision: 08 >>>> > Title: BFD for VXLAN >>>> > Document date: 2019-11-01 >>>> > Group: bfd >>>> > Pages: 11 >>>> > URL: >>>> > >>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>> > Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>> > Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>> > Htmlized: >>>> > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>> > Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>> > >>>> > Abstract: >>>> > This document describes the use of the >>>> Bidirectional >>>> > Forwarding >>>> > Detection (BFD) protocol in point-to-point >>>> Virtual >>>> > eXtensible Local >>>> > Area Network (VXLAN) tunnels forming up an >>>> overlay network. >>>> > >>>> > >>>> > >>>> > >>>> > 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 >>>> > >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 --=-w8Y5Woiq3+aBHyCgs3YL Content-Type: text/html; charset=us-ascii
I didn't suggest the use of a multicast MAC, any MAC would be fine in the management VNI since there can be no tenant VMs on a management VNI. I was recommending specifying a unicast MAC.

Santosh, as I mentioned to Joel, I don't want to add additional forwarding requirements--such as VNI-specific behavior--in VXLAN. The existing mechanism is sufficient for the case we're discussing here. Just pick a MAC in management VNI for the sake of configuration simplicity.

Dinesh

On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Santosh,

I'm not aware of any implementation that uses a multicast MAC for this.  The closest thing that I'm aware of that helps alleviate the need for knowing the MAC of the remote VTEP is what's done in open vswitch:
   bfd_config_remote : bfd_dst_mac: optional string
              Set  to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set
              the destination MAC to be used for transmitted BFD packets.  The
              default is 00:23:20:00:00:01.
That OUI belongs to Nicira/VMware.  An IANA assigned unicast MAC would be the equivalent.

Anoop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.com> wrote:
Anoop,
   Thanks for your comments. For non-managment VNI why do we need to have multicast MAC address for backward compatibility for existing implementation or there are any use cases such that we can avoid learning of remote end VTEP? 

Thanks
Santosh P K 

On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD session is not using the Management VNI,
the destination MAC address MUST be the address
associated with the destination VTEP.  If the BFD session uses
the Management VNI, it may use any MAC address, since use of the 
Management VNI ensures that these packets will never be forwarded to a VM.
The MAC address may be configured, or it may be learned via
a control plane protocol. The details of how the MAC address
to be used is obtained are outside the scope of this document."

That said, for non-Management VNI, do we want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?  If so, we
should probably add a sentence for that too.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.  So there are no tenant MAC addresses.  (This is one of the
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would
> allow any MAC address other than a tenant MAC address?  I would suggest
> some more text be added to clarify what is permitted on the management
> VLAN.  Assuming that we want to allow any MAC other than a tenant MAC,
> how does this get enforced?  In other words, what can be done for the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to
> one that is owned by the VTEP or a "agreed on" multicast MAC address. 
> That means the receiver only needs to validate for those, and just
> treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:gregimirsky@gmail.com>> wrote:
>
>     Hi Anoop,
>     thank you for your comments and questions. Please find my notes
>     in-line tagged GIM>>.
>
>     Regards,
>     Greg
>
>     On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <anoop@alumni.duke..edu
>     <mailto:anoop@alumni.duke.edu>> wrote:
>
>         Hi Greg,
>
>         A few comments.
>
>         The draft has nits, specifically around the way the IPv6 address
>         is written.
>
>         In section 4:
>
>         BFD packet MUST be encapsulated ->
>
>         BFD packets MUST be encapsulated
>
>     GIM>> Thanks, will do.
>
>
>          >>>
>
>         Destination MAC: This MUST NOT be of one of tenant's MAC
>                   addresses.  The destination MAC address MAY be the address
>                   associated with the destination VTEP.  The MAC address MAY be
>                   configured, or it MAY be learned via a control plane protocol.
>                   The details of how the MAC address is obtained are outside the
>                   scope of this document.
>
>          >>>
>         It looks like we have removed the option of using a well-known
>         IANA assigned MAC.  If so, why is the above a MAY and not a
>         MUST?  What else can it be?  One interpretation is that it can
>         be anything unicast, or multicast, as long as it's not a tenant
>         MAC.  Is that the intent?  If so, it would be better to state it
>         that way.  Also (and this is purely editorial), I think it would
>         be better if the first sentence above were moved to the end of
>         the paragraph.
>
>     GIM>> Yes, you're right, we've removed that option and have removed
>     the request to IANA. I also agree that " MAY be the address
>     associated with the destination VTEP" is not the right choice of
>     normative language. On the other hand, MUST might be too restrictive
>     if BFD session is using the Management VNI. Would the following
>     update address your concern:
>     OLD TEXT:
>               Destination MAC: This MUST NOT be of one of tenant's MAC
>               addresses.  The destination MAC address MAY be the address
>               associated with the destination VTEP.  The MAC address MAY be
>               configured, or it MAY be learned via a control plane protocol.
>               The details of how the MAC address is obtained are outside the
>               scope of this document.
>     NEW TEXT:
>               Destination MAC: If the BFD session is not using the
>     Management VNI,
>               the destination MAC address MUST be the address
>               associated with the destination VTEP.  The Destination MAC
>               MUST NOT be one of the tenant's MAC addresses.
>              The MAC address MAY be configured, or it MAY be learned via
>              a control plane protocol. The details of how the MAC address
>              is obtained are outside the scope of this document.
>
>
>         "The inner Ethernet frame carrying the BFD
>             Control packet- has the following format:"
>
>         Extraneous '-' after packet.
>
>     GIM>> Thanks, will do that too.
>
>
>         Thanks,
>         Anoop
>
>         On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky
>         <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
>
>             Dear All,
>             the new version includes updates resulting from the
>             discussions of Joel's comments in the RtrDir review of BFD
>             over VXLAN draft, comments from Anoop, and Dinesh. On behalf
>             of editors, thank you for your constructive comments and for
>             sharing your expertise, all much appreciated.
>             I hope we've addressed all your comments, and the draft can
>             proceed further.
>
>             Regards,
>             Greg
>
>             ---------- Forwarded message ---------
>             From: <internet-drafts@ietf.org
>             <mailto:internet-drafts@ietf.org>>
>             Date: Fri, Nov 1, 2019 at 10:45 AM
>             Subject: New Version Notification for
>             draft-ietf-bfd-vxlan-08..txt
>             To: Gregory Mirsky <gregimirsky@gmail.com
>             <mailto:gregimirsky@gmail.com>>, Mallik Mudigonda
>             <mmudigon@cisco.com <mailto:mmudigon@cisco.com>>, Sudarsan
>             Paragiri <sudarsan.225@gmail.com
>             <mailto:sudarsan.225@gmail.com>>, Vengada Prasad Govindan
>             <venggovi@cisco.com <mailto:venggovi@cisco.com>>, Santosh
>             Pallagatti <santosh.pallagatti@gmail.com
>             <mailto:santosh.pallagatti@gmail.com>>
>
>
>
>             A new version of I-D, draft-ietf-bfd-vxlan-08.txt
>             has been successfully submitted by Greg Mirsky and posted to the
>             IETF repository.
>
>             Name:           draft-ietf-bfd-vxlan
>             Revision:       08
>             Title:          BFD for VXLAN
>             Document date:  2019-11-01
>             Group:          bfd
>             Pages:          11
>             URL:
>             https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt
>             Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>             Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>             Htmlized:
>             https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
>             Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08
>
>             Abstract:
>                 This document describes the use of the Bidirectional
>             Forwarding
>                 Detection (BFD) protocol in point-to-point Virtual
>             eXtensible Local
>                 Area Network (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>             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 <http://tools.ietf.org>.
>
>             The IETF Secretariat
>
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--=-w8Y5Woiq3+aBHyCgs3YL-- From nobody Mon Nov 4 10:32:48 2019 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 82DCD120C38; Mon, 4 Nov 2019 01:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oRmoLh8_0OsY; Mon, 4 Nov 2019 01:43:26 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 ABDFF120B6A; Mon, 4 Nov 2019 01:43:25 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id c17so8469833wmk.2; Mon, 04 Nov 2019 01:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ck+Apk7TlT5/zFdBn8K5b7GDWg+Avb1L32L/fBn0IB0=; b=pXX4/Gbd2bTMMucnX8kmbXtF/0ZoEPUNAepUPPIDPomXuGLiKI9LvfTQyZ8oWVWOyf ulgRnoT6miC5bkU8HPtResN9n4E6gHS3Saq5zzbW2j3RqwuCmcHE7yT+gb7A+9HH5Xas SkJDyjh31p6UV3ulV/5Ilg/MEErntKpAm6HvgtBJmzwEooR869d/9WVXc9FI9ai2dnpe OKoFz902FVWaaa5AywyR/Y2VKn1I/BdqROYXRR7wlxeEF+a2tCe6WlaKMz4249K2RWqy uzs35MpS2WFo0X1CLJHaVqbJ+jV2e/4WULdDZ1JuLFrmUD5KxWkk8geOMW0sdhdpArcK rqSQ== 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=ck+Apk7TlT5/zFdBn8K5b7GDWg+Avb1L32L/fBn0IB0=; b=kQFLnRyUteCI+2KP2C9nSr3H1wUaOl9KSLrYRWSF52rRbFNDNmHBa8RB30q1MEUErr 6AYRVL2kB+OeT7+cpXwVa5Ge6YJ8eFSsox3GgT8zZkHSRQGd1EteUNXl9p76JuRbckqU SDpGjorVCzwAvZJBNyOuRFU9dZ9AudP3Oa+LQ2IxTJyrU7oMMHHf3O7S17vxYURShPQ1 0J62OyEhLR9Qh8gPvA+MBGGmn70Jhx+ibK2A2Q4x2V86PlYCCa4ptlX4FE75D2fRQunk 6m2zeh9QYOU4RO3577COlrZLFiELux7s2kXhDAJV/3q0IqF0il6lAKu0QhBiOxLMrvbH WDRg== X-Gm-Message-State: APjAAAV0bYz7XBKE3MvtF8gJk4zwVOsyekL9CC+UP3GKGACE3gjH03JG tYj5Pj9t8YgUva+MIZtN5P7r9sYEd66IQmfk1lY= X-Google-Smtp-Source: APXvYqxFW08Vk4b1h+HDOcuZHol0ODDGcoGQwPlb2G5ymVhoFNdNj5lCyJ9xIYPn/zfDeMP2hhadgtorPnYUXVb+ePU= X-Received: by 2002:a1c:a9cb:: with SMTP id s194mr23368497wme.92.1572860604030; Mon, 04 Nov 2019 01:43:24 -0800 (PST) MIME-Version: 1.0 References: <1571795542.10436.5@smtp.gmail.com> <1571798869.2855.1@smtp.gmail.com> <1571860470.2855.11@smtp.gmail.com> <20191029205651.GA10145@pfrc.org> In-Reply-To: <20191029205651.GA10145@pfrc.org> From: Santosh P K Date: Mon, 4 Nov 2019 15:13:12 +0530 Message-ID: Subject: Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP To: Jeffrey Haas Cc: Anoop Ghanwani , Dinesh Dutt , Greg Mirsky , "Joel M. Halpern" , NVO3 , draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG , "T. Sridhar" , xiao.min2@zte.com.cn Content-Type: multipart/alternative; boundary="00000000000095a395059682255f" Archived-At: X-Mailman-Approved-At: Mon, 04 Nov 2019 10:32:48 -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: Mon, 04 Nov 2019 09:43:31 -0000 --00000000000095a395059682255f Content-Type: text/plain; charset="UTF-8" Jeff, Sorry for delayed response. I was on vacation and returned today and trying to catch up with discussion here. Please see my inline response [SPK]. On Wed, Oct 30, 2019 at 2:23 AM Jeffrey Haas wrote: > Santosh, > > On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote: > > "As per section 4 inner destination IP address MAY be set to 127/8 > address. > > There could be firewall configured on VTEP to block 127/8 address range > if > > set as destination IP in inner IP header. It is recommended to allow > 127/8 > > range address through firewall only if inner IP header's destination IP > is > > set to 127/8 IP address." > > Would it be reasonable to suggest "SHOULD be set"? > Our motivation in this section is to offer what is likely to be a > reasonable > default, without providing restriction from something more amenable to some > provider's requirement. > [SPK] Agreed. I will take a look at updated version and we can change these wordings. > > Similarly, based on this text, we'll get asked about "recommended" vs. > "RECOMMENDED". What level of strength do you think we should have here? > [SPK] Agreed. Will change it. > > > -- Jeff > --00000000000095a395059682255f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff,
=C2=A0 =C2=A0Sorry for delayed = response. I was on vacation and returned today and trying to catch up with = discussion here. Please see my inline response [SPK].

<= /div>
O= n Wed, Oct 30, 2019 at 2:23 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
Santosh,

On Mon, Oct 28, 2019 at 10:24:06PM +0530, Santosh P K wrote:
> "As per section 4 inner destination IP address MAY be set to 127/= 8 address.
> There could be firewall configured on VTEP to block 127/8 address rang= e if
> set as destination IP in inner IP header. It is recommended to allow 1= 27/8
> range address through firewall only if inner IP header's destinati= on IP is
> set to 127/8 IP address."

Would it be reasonable to suggest "SHOULD be set"?=C2=A0

Our motivation in this section is to offer what is likely to be a reasonabl= e
default, without providing restriction from something more amenable to some=
provider's requirement.
=C2=A0
[SPK] Agr= eed. I will take a look at updated version and we can change these wordings= .=C2=A0

Similarly, based on this text, we'll get asked about "recommended&= quot; vs.
"RECOMMENDED".=C2=A0 What level of strength do you think we shoul= d have here?
[SPK] Agreed. Will change it.=C2=A0=C2=A0=


-- Jeff
--00000000000095a395059682255f-- From nobody Mon Nov 4 11:43:24 2019 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 8AEAA120047; Mon, 4 Nov 2019 11:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 ohrXih8vMnCp; Mon, 4 Nov 2019 11:43:20 -0800 (PST) Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) (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 C1308120025; Mon, 4 Nov 2019 11:43:19 -0800 (PST) Received: by mail-ua1-f52.google.com with SMTP id k11so2695298ual.10; Mon, 04 Nov 2019 11:43:19 -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=SJsho/7i/OkNWjsGpolpWsIgJ7EJI14ZRavszSWDmsg=; b=a/rXzp6PLjzo1iyxaSjJTteX/Er10Gzfl8XV4jE7+4k7IC08OCouWt8U8fglaubBfM 2OpOW0UqlPcbQXYLnR4UKnBV4co58YqGyajAxKy5efbcMAtZiy+xnPPAo/dSfjG6UkWm UVdJuJbf6XZ049w+raTgNx1mIBGIonhsS+7HfEXGb/aLB6+TUNnwVu80TmKmrBrdYM1g 91P77XhwDyMg9D3ajYi/yDhTfaJENXxvHQGWxhA30UnTCSh3ZNA6WGpqZUa7S/6ZF+C/ aQHf4d6/zNl8bDnc8SM1v+XToT/mp4UUBx5/nilW/8ntIPVIZ3VWQBvQH7xOAmWXbwnY o2NQ== X-Gm-Message-State: APjAAAUJF64R8bneOfgbDE63qCxVFJ5dBU8WrOf8doqKHOKceM11SUoj JDamji0W+y558KAaPY47v1VM2Mlj3zlEopzNvM0= X-Google-Smtp-Source: APXvYqx9QOXMViH67wRDOFwiCbWCa7uC1vy3QFBC7ovFNzpgHYo5y6zzsBWpBXaXgJ1HS4jj0UVj2qjgZeM7Bfw4jbc= X-Received: by 2002:ab0:4ea9:: with SMTP id l41mr12662184uah.76.1572896598573; Mon, 04 Nov 2019 11:43:18 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> In-Reply-To: <1572888977.25948.5@smtp.gmail.com> From: Anoop Ghanwani Date: Mon, 4 Nov 2019 11:43:06 -0800 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: Santosh P K , "Joel M. Halpern" , Greg Mirsky , rtg-bfd WG , NVO3 Content-Type: multipart/alternative; boundary="00000000000006ca7805968a87fd" Archived-At: 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: Mon, 04 Nov 2019 19:43:22 -0000 --00000000000006ca7805968a87fd Content-Type: text/plain; charset="UTF-8" Dinesh, The multicast MAC was mentioned by me (because I incorrectly assumed that is what the original proposal was), hence Santosh's question. Sorry for the confusion. Anoop On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote: > I didn't suggest the use of a multicast MAC, any MAC would be fine in the > management VNI since there can be no tenant VMs on a management VNI. I was > recommending specifying a unicast MAC. > > Santosh, as I mentioned to Joel, I don't want to add additional forwarding > requirements--such as VNI-specific behavior--in VXLAN. The existing > mechanism is sufficient for the case we're discussing here. Just pick a MAC > in management VNI for the sake of configuration simplicity. > > Dinesh > > On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani > wrote: > > Hi Santosh, > > I'm not aware of any implementation that uses a multicast MAC for this. > The closest thing that I'm aware of that helps alleviate the need for > knowing the MAC of the remote VTEP is what's done in open vswitch: > http://www.openvswitch.org/support/dist-docs/vtep.5.html > > *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string > Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set > the destination MAC to be used for transmitted BFD packets. The > default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. > > That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be > the equivalent. > > Anoop > > On Mon, Nov 4, 2019 at 5:14 AM Santosh P K > wrote: > >> Anoop, >> Thanks for your comments. For non-managment VNI why do we need to have >> multicast MAC address for backward compatibility for existing >> implementation or there are any use cases such that we can avoid learning >> of remote end VTEP? >> >> Thanks >> Santosh P K >> >> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >> wrote: >> >>> Hi Joel, >>> >>> In that case I would propose the following text: >>> >>> "Destination MAC: If the BFD session is not using the Management VNI, >>> the destination MAC address MUST be the address >>> associated with the destination VTEP. If the BFD session uses >>> the Management VNI, it may use any MAC address, since use of the >>> Management VNI ensures that these packets will never be forwarded to a >>> VM. >>> The MAC address may be configured, or it may be learned via >>> a control plane protocol. The details of how the MAC address >>> to be used is obtained are outside the scope of this document." >>> >>> That said, for non-Management VNI, do we want to allow for flexibility >>> for an implementation to use a multicast MAC of their choosing? If so, >>> we >>> should probably add a sentence for that too. >>> >>> Thanks, >>> Anoop >>> >>> >>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>> wrote: >>> >>>> Anoop, I think I at least am misunderstanding you. >>>> If one is using the management VNI, as I understand it there is no >>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>> reasons I like using the management VNI.) >>>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>> > Hi Greg, >>>> > >>>> > In the case of the management VNI, are we trying to say that we would >>>> > allow any MAC address other than a tenant MAC address? I would >>>> suggest >>>> > some more text be added to clarify what is permitted on the >>>> management >>>> > VLAN. Assuming that we want to allow any MAC other than a tenant >>>> MAC, >>>> > how does this get enforced? In other words, what can be done for the >>>> > network to protect itself if a sender violates this? >>>> > >>>> > One possible answer is to restrict the MAC address that may be used >>>> to >>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>> address. >>>> > That means the receiver only needs to validate for those, and just >>>> > treats everything else as data. >>>> > >>>> > Also, for interoperability purposes, it would be best to specify that >>>> a >>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>> > session, while a sender MAY pick any of them. >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>> > > wrote: >>>> > >>>> > Hi Anoop, >>>> > thank you for your comments and questions. Please find my notes >>>> > in-line tagged GIM>>. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>>> anoop@alumni.duke..edu >>>> > > wrote: >>>> > >>>> > Hi Greg, >>>> > >>>> > A few comments. >>>> > >>>> > The draft has nits, specifically around the way the IPv6 >>>> address >>>> > is written. >>>> > >>>> > In section 4: >>>> > >>>> > BFD packet MUST be encapsulated -> >>>> > >>>> > BFD packets MUST be encapsulated >>>> > >>>> > GIM>> Thanks, will do. >>>> > >>>> > >>>> > >>> >>>> > >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC >>>> address MAY be >>>> > configured, or it MAY be learned via a control >>>> plane protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > >>>> > >>> >>>> > It looks like we have removed the option of using a well-known >>>> > IANA assigned MAC. If so, why is the above a MAY and not a >>>> > MUST? What else can it be? One interpretation is that it can >>>> > be anything unicast, or multicast, as long as it's not a >>>> tenant >>>> > MAC. Is that the intent? If so, it would be better to state >>>> it >>>> > that way. Also (and this is purely editorial), I think it >>>> would >>>> > be better if the first sentence above were moved to the end of >>>> > the paragraph. >>>> > >>>> > GIM>> Yes, you're right, we've removed that option and have >>>> removed >>>> > the request to IANA. I also agree that " MAY be the address >>>> > associated with the destination VTEP" is not the right choice of >>>> > normative language. On the other hand, MUST might be too >>>> restrictive >>>> > if BFD session is using the Management VNI. Would the following >>>> > update address your concern: >>>> > OLD TEXT: >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC address >>>> MAY be >>>> > configured, or it MAY be learned via a control plane >>>> protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > NEW TEXT: >>>> > Destination MAC: If the BFD session is not using the >>>> > Management VNI, >>>> > the destination MAC address MUST be the address >>>> > associated with the destination VTEP. The Destination >>>> MAC >>>> > MUST NOT be one of the tenant's MAC addresses. >>>> > The MAC address MAY be configured, or it MAY be learned >>>> via >>>> > a control plane protocol. The details of how the MAC >>>> address >>>> > is obtained are outside the scope of this document. >>>> > >>>> > >>>> > "The inner Ethernet frame carrying the BFD >>>> > Control packet- has the following format:" >>>> > >>>> > Extraneous '-' after packet. >>>> > >>>> > GIM>> Thanks, will do that too. >>>> > >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>> > > wrote: >>>> > >>>> > Dear All, >>>> > the new version includes updates resulting from the >>>> > discussions of Joel's comments in the RtrDir review of BFD >>>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>>> behalf >>>> > of editors, thank you for your constructive comments and >>>> for >>>> > sharing your expertise, all much appreciated. >>>> > I hope we've addressed all your comments, and the draft >>>> can >>>> > proceed further. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > ---------- Forwarded message --------- >>>> > From: >>> > > >>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>> > Subject: New Version Notification for >>>> > draft-ietf-bfd-vxlan-08..txt >>>> > To: Gregory Mirsky >>> > >, Mallik Mudigonda >>>> > >, >>>> Sudarsan >>>> > Paragiri >>> > >, Vengada Prasad Govindan >>>> > >, Santosh >>>> > Pallagatti >>> > > >>>> > >>>> > >>>> > >>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>> > has been successfully submitted by Greg Mirsky and posted >>>> to the >>>> > IETF repository. >>>> > >>>> > Name: draft-ietf-bfd-vxlan >>>> > Revision: 08 >>>> > Title: BFD for VXLAN >>>> > Document date: 2019-11-01 >>>> > Group: bfd >>>> > Pages: 11 >>>> > URL: >>>> > >>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>> > Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>> > Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>> > Htmlized: >>>> > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>> > Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>> > >>>> > Abstract: >>>> > This document describes the use of the Bidirectional >>>> > Forwarding >>>> > Detection (BFD) protocol in point-to-point Virtual >>>> > eXtensible Local >>>> > Area Network (VXLAN) tunnels forming up an overlay >>>> network. >>>> > >>>> > >>>> > >>>> > >>>> > 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 < >>>> http://tools.ietf.org>. >>>> > >>>> > The IETF Secretariat >>>> > >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> --00000000000006ca7805968a87fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dinesh,

The multicast = MAC was mentioned by me (because I incorrectly assumed that is what the ori= ginal proposal was), hence Santosh's question.=C2=A0 Sorry for the conf= usion.

Anoop

On Mon, Nov 4, 2019 at 9:36 AM D= inesh Dutt <didutt@gmail.com>= wrote:
I didn't su= ggest the use of a multicast MAC, any MAC would be fine in the management V= NI since there can be no tenant VMs on a management VNI. I was recommending= specifying a unicast MAC.

Santosh, as I mentioned= to Joel, I don't want to add additional forwarding requirements--such = as VNI-specific behavior--in VXLAN. The existing mechanism is sufficient fo= r the case we're discussing here. Just pick a MAC in management VNI for= the sake of configuration simplicity.

Dinesh

O= n Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
<= blockquote type=3D"cite">
Hi Santosh,

I&= #39;m not aware of any implementation that uses a multicast MAC for this.= =C2=A0 The closest thing that I'm aware of that helps alleviate the nee= d for knowing the MAC of the remote=C2=A0VTEP is what's done in open vs= witch:
   bfd_config_remote : bf=
d_dst_mac: opti=
onal string
              Set  to an Ethernet address in the form xx:x=
x:xx:xx:xx:x=
x to set
              the destination MAC to be used for transmitted BFD packets.  =
The
              default is 00:23:20:00:00:0<=
/b>1.
That OUI belongs to Nicira/VMware.=C2=A0 An IA= NA assigned unicast MAC would be the equivalent.

A= noop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.co= m> wrote:
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non= -managment VNI why do we need to have multicast MAC address for backward=C2= =A0compatibility for existing implementation=C2=A0or there are any use case= s such that we can avoid learning of remote end VTEP?=C2=A0

<= /div>
Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD sessio= n is not using the=C2=A0Management = VNI,
= the destination MAC address MUST be the address
associated with the destination = VTEP.=C2=A0 If the BFD session uses
the Management VNI, it= may use any MAC address, since use of the=C2=A0
Management VNI e= nsures that these packets will never be forwarded to a VM.
The MAC address may be confi= gured, or it may be learned via
a control plane protocol. The details of how the= MAC address
to be used is obtained are outside the scope of this document."= ;

That said, for non-Management VNI, do w= e want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?=C2= =A0 If so, we
should probably add = a sentence for that too.

Thanks,
Anoop<= /div>

On Sun, N= ov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am mis= understanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--00000000000006ca7805968a87fd-- From nobody Mon Nov 4 18:30:35 2019 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 16ADE120143; Mon, 4 Nov 2019 18:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 95vlVC21CWnu; Mon, 4 Nov 2019 18:30:22 -0800 (PST) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 123AB120033; Mon, 4 Nov 2019 18:30:21 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65dc0de97509-31934; Tue, 05 Nov 2019 10:29:43 +0800 (CST) X-RM-TRANSID: 2ee65dc0de97509-31934 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.55]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75dc0de96e2a-26c7d; Tue, 05 Nov 2019 10:29:43 +0800 (CST) X-RM-TRANSID: 2ee75dc0de96e2a-26c7d From: "Weiqiang Cheng" To: Cc: , , =?gb2312?B?J831yPDRqSc=?= , Subject: The usecase of the BFD application Date: Tue, 5 Nov 2019 10:29:43 +0800 Message-ID: <028a01d59380$e2350480$a69f0d80$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_028B_01D593C3.F0584480" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdWTgOGzmazQhOf+TgG5QDz0B7yZyw== Content-Language: zh-cn Archived-At: 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: Tue, 05 Nov 2019 02:30:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_028B_01D593C3.F0584480 Content-Type: multipart/alternative; boundary="----=_NextPart_001_028C_01D593C3.F0584480" ------=_NextPart_001_028C_01D593C3.F0584480 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi Chairs, We prepared a draft to use BFD in datacenter application scenario. Because the time zone difference, we missed the submission deadline and we will upload it on Nov. 16. If possible, we still hope to apply a slot to present it. Could you see if it is Ok for the group? B.R. Weiqiang Cheng ------=_NextPart_001_028C_01D593C3.F0584480 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = Chairs,

We = prepared a draft to use BFD in datacenter application = scenario.

Because the time zone difference, we missed the submission = deadline and we will upload it on Nov. 16.

If possible, we still hope to apply = a slot to present it. Could you see if it is Ok for the = group?

 

B.R.

Weiqiang Cheng

------=_NextPart_001_028C_01D593C3.F0584480-- ------=_NextPart_000_028B_01D593C3.F0584480 Content-Type: text/plain; name="draft-wang-bfd-one-arm-use-case-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-wang-bfd-one-arm-use-case-00.txt" =0A= =0A= =0A= BFD Working Group R. Wang=0A= Internet-Draft W. Cheng=0A= Intended status: Informational China Mobile=0A= Expires: May 7, 2020 Y. Zhao=0A= A. Liu=0A= ZTE=0A= November 4, 2019=0A= =0A= =0A= Using One-Arm BFD in Cloud Network=0A= draft-wang-bfd-one-arm-use-case-00=0A= =0A= Abstract=0A= =0A= Bidirectional Forwarding Detection (BFD) is a fault detection=0A= protocol that can quickly determine a communication failure between=0A= devices and notify upper-layer applications [RFC5880]. BFD has=0A= asynchronous detecting mode and demand detection mode to satisfy=0A= different scenarios, also supports echo function to reduce the device=0A= requirement for BFD. One-Arm BFD this draft descripted supports=0A= another BFD detecting function rather than the echo as described in=0A= [RFC5880] [RFC5881], it needs nothing BFD capability to one of the=0A= devices deployed BFD detecting. Using One-Arm BFD function, the one=0A= device works on BFD detecting normally and the other device just=0A= loopback the BFD packets like echo function. One-Arm BFD is suitable=0A= for the cloud virtualization network, the One-Arm BFD is deploy on=0A= NFV gateways, and NFV virtual machine vNICs just enable the echo/=0A= loopback process.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at https://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on May 7, 2020.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires May 7, 2020 [Page 1]=0A= =0C=0A= Internet-Draft Using One-Arm BFD in Cloud Network November 2019=0A= =0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2019 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (https://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2=0A= 1.1. Conventions Used in This Document . . . . . . . . . . . . 3=0A= 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3=0A= 2. One-Arm BFD Use Case . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4=0A= 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4=0A= 7. Normative References . . . . . . . . . . . . . . . . . . . . 4=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5=0A= =0A= 1. Introduction=0A= =0A= To minimize the impact of device faults on services and improve=0A= network availability, a network device must be able to quickly detect=0A= faults in communication with adjacent devices. Measures can then be=0A= taken to promptly rectify the faults to ensure service continuity.=0A= =0A= BFD is a low-overhead, short-duration method to detect faults on the=0A= path between adjacent forwarding engines. The faults can be=0A= interface, data link, and even forwarding engine faults. It is a=0A= single, unified mechanism to monitor any media and protocol layers in=0A= real time.=0A= =0A= BFD has asynchronous detecting mode and demand detection mode to=0A= satisfy different scenarios, also supports echo function to reduce=0A= the device requirement for BFD. BFD echo function is used when two=0A= devices are connected but only one of them supports full BFD=0A= capability. When the echo function is activated, the local system=0A= sends a BFD control packet and the remote system loops back the=0A= =0A= =0A= =0A= Wang, et al. Expires May 7, 2020 [Page 2]=0A= =0C=0A= Internet-Draft Using One-Arm BFD in Cloud Network November 2019=0A= =0A= =0A= packet through the forwarding channel. If several consecutive echo=0A= packets are not received, the session is declared to be Down. BFD=0A= echo function reduces one of the two devices requirement for BFD.=0A= =0A= With the development of network cloud and NFV virtualization, there=0A= are many connections between gateway devices and the virtual machine=0A= devices. The virtual machine devices don't support BFD capacity at=0A= all. There is difficult to deploy BFD between the gateway devices=0A= and the virtual machine vNICs. One-Arm BFD supports this scenario,=0A= it supports gateway enable full BFD capability and virtual machine=0A= don't support BFD at all, just simply loopback BFD packets on vNICs.=0A= =0A= 1.1. Conventions Used in This Document=0A= =0A= 1.1.1. Terminology=0A= =0A= BFD: Bidirectional Forwarding Detection=0A= =0A= NFV: Network Function Virtualization=0A= =0A= 1.1.2. Requirements Language=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and=0A= "OPTIONAL" in this document are to be interpreted as described in BCP=0A= 14 [RFC2119] [RFC8174] when, and only when, they appear in all=0A= capitals, as shown here.=0A= =0A= 2. One-Arm BFD Use Case=0A= =0A= With the development of network cloud and NFV virtualization, there=0A= are many connections between gateway devices and the virtual machine=0A= devices. The virtual machine(VM) devices don't support BFD capacity=0A= at all. If the gateway devices are deployed BFD protocol, there are=0A= some problems including scalability, detecting period and so on. And=0A= the VM can't support BFD protocol currently. One-Arm echo BFD can=0A= resolve these problems. One-arm echo BFD is used when two devices=0A= are connected and only one of them supports BFD. A one-arm BFD echo=0A= session can be established on the device that supports BFD, the other=0A= device just loopback BFD packets.=0A= =0A= After receiving a one-arm BFD echo session packet, the device that=0A= does not support BFD immediately loops back the packet, implementing=0A= quick link failure detection. As shown in Figure 1, Device A such as=0A= a NFV gateway supports BFD, whereas Device B such as a virtual=0A= machine does not. To rapidly detect faults in the link between=0A= Device A and Device B, configure a one-arm BFD echo session on Device=0A= A. After receiving a one-arm BFD echo session packet from Device A,=0A= =0A= =0A= =0A= Wang, et al. Expires May 7, 2020 [Page 3]=0A= =0C=0A= Internet-Draft Using One-Arm BFD in Cloud Network November 2019=0A= =0A= =0A= Device B immediately loops back the packet, implementing rapid link=0A= fault detection.=0A= =0A= =0A= Device A One-Arm Echo Device B=0A= +--------+ BFD session +---------+=0A= | A |---------------------------------| B |=0A= | |Inf 1 Inf 1| |=0A= +--------+10.1.1.1/24 10.1.1.2/24+---------+=0A= BFD is supported. BFD is not supported.=0A= =0A= =0A= Figure 1: One-Arm BFD deploying scenario=0A= =0A= 3. Discussion=0A= =0A= One-Arm BFD detecting function is better than BFD echo function mode.=0A= First One-Arm BFD can use full BFD capacity in the BFD-supported=0A= device. So One-Arm BFD can also support fast detecting and manage=0A= BFD sessions effectively. Second it is scalable using one-arm BFD=0A= detecting to adapt the NFV virtualization. Finally, it is the same=0A= process in the non-BFD-supported devices with echo function. So one-=0A= arm BFD can be deployed to the cloud network, and the VMs don't=0A= require to support BFD capacity.=0A= =0A= 4. Security Considerations=0A= =0A= TBD.=0A= =0A= 5. IANA Considerations=0A= =0A= This document has no IANA action requested.=0A= =0A= 6. Acknowledgements=0A= =0A= TBD.=0A= =0A= 7. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119,=0A= DOI 10.17487/RFC2119, March 1997,=0A= .=0A= =0A= [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection=0A= (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,=0A= .=0A= =0A= =0A= =0A= =0A= Wang, et al. Expires May 7, 2020 [Page 4]=0A= =0C=0A= Internet-Draft Using One-Arm BFD in Cloud Network November 2019=0A= =0A= =0A= [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection=0A= (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,=0A= DOI 10.17487/RFC5881, June 2010,=0A= .=0A= =0A= [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC=0A= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,=0A= May 2017, .=0A= =0A= Authors' Addresses=0A= =0A= Ruixue Wang=0A= China Mobile=0A= Beijing=0A= CN=0A= =0A= Email: wangruixue@chinamobile.com=0A= =0A= =0A= Weiqiang Cheng=0A= China Mobile=0A= Beijing=0A= CN=0A= =0A= Email: chengweiqiang@chinamobile.com=0A= =0A= =0A= Yanhua Zhao=0A= ZTE=0A= Nanjing=0A= CN=0A= =0A= Email: zhao.yanhua3@zte.com.cn=0A= =0A= =0A= Aihua Liu=0A= ZTE=0A= Shenzhen=0A= CN=0A= =0A= Email: liu.aihua@zte.com.cn=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Wang, et al. Expires May 7, 2020 [Page 5]=0A= =0A= ------=_NextPart_000_028B_01D593C3.F0584480-- From nobody Mon Nov 4 21:55:21 2019 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 AC924120048 for ; Mon, 4 Nov 2019 21:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NM/NrX3R; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sdn+ugYG 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 smBrGepSxjCE for ; Mon, 4 Nov 2019 21:55:17 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27BA120020 for ; Mon, 4 Nov 2019 21:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3106; q=dns/txt; s=iport; t=1572933317; x=1574142917; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=W2S00Ou0Bvc6vqAmIjdQgGVcRSbZgtdlEifEBjAUT7Q=; b=NM/NrX3R57TNO8cjjWg+9LBsGanWzNGjQm4bwjcXLtSd05T4VZCNR/ub 1qWsb1qXyrBmAs+uIxkFTD2jussS93PLz2bnL4rYEXZuWy4z90B+xVPc8 BN/8mFHxj2xKBIB85ST6lLRl7PHSDyxLExrxkJbYCu77beXougm+QHO2o E=; IronPort-PHdr: =?us-ascii?q?9a23=3AehY9nRX9/TeGKkhvp55fuct66MXV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank1HcJZXlJ/8FmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACRDsFd/5tdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBawQBAQELAYFKUAVsWCAECyqHbwOKe06CEJd+gS6BJAN?= =?us-ascii?q?UCQEBAQwBASMKAgEBhEAChA4kNgcOAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQE?= =?us-ascii?q?DEigGAQE4CwQCAQgOAwMBAQEfEDIdCAIEARIIGoMBgkYDLgEOpBcCgTiIYII?= =?us-ascii?q?ngn4BAQWBOAIOQYMLGIIXCYE2AYwSGIFAP4EQR4JMPoJiAQECAQEWgUkkgxy?= =?us-ascii?q?CLJ50jwQKgiSHEo5BgjxyhmiPUY5DiC6RKgIEAgQFAg4BAQWBWQUtgVhwFRq?= =?us-ascii?q?DDQlHERSDBgwXg1CFFIU+AXSBKI1FAQE?= X-IronPort-AV: E=Sophos;i="5.68,270,1569283200"; d="scan'208";a="662340711" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2019 05:55:13 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xA55tDnx021278 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2019 05:55:13 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 23:55:06 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Nov 2019 23:55:05 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 4 Nov 2019 23:55:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ToPF8NrGC57zUIxBoK9oZTezI4pKVaGou+XedKC9dyaBWceQ2Ik936aLspNjnJlBl5W3oclm43twJp6bvPonesekJjZDvWXElTprHuFhAnydbScvyjS/X52tx2MjGJN/iN/fF5+uEM8/N8DgriZ/iSGdWgXlNC962A7nuguetofqGuTG8wgBaZi3rJs71rg/n1Dv2gW7h9zUWj/PplY1m1wWN9Nu+KcI/1z3z6cq393hgxuxnFIhYcqv/D9iiYYxbzPtAgsR34nYNs+nke8dNq5qzv9fiIyWtQnh+aNgZY7p0sXhUIKkjKTd0X+juqK7xLOxVP+tu6yD8S/bYG6n4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BwpNyutlKioQlaq+UUIpSb3NYKFafgREPzIw+FbH414=; b=CcMWMv+zdGSPd8kB/mWGQ8zJNbZVllkx/bwIpPTZyDuhthSxsLwa/TdbDiGQJWaL4Uv+TNfDxbwVjvyhmY8+GvaODyvsQ7ELCnwEDlMDjDlcmu2yML2fup7GH5EzyUnOOjgBra1y/n51fR8CAD7wTii+/bSstGeJhbMRzW/px0GcEAXQznN7gshxj5OcW7AOEf11XEHMVcg2HzLRnTkUdX+DSz9b7pLYlOk3xYZ6k0snQHuZu2x+rjWt2ACjfPd/+CsAs3m7aiGQwACaEFjUYyzaafEv2VcNiNUJQddSGrzKZRfse/Hlwf5Ta6zZG1ZE6nzxG5n4d3Do+O/a7/N8sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BwpNyutlKioQlaq+UUIpSb3NYKFafgREPzIw+FbH414=; b=sdn+ugYGV9TqhI5FVmNKp8korYG/DNyKb7WeNYXkbbiSfd1P7MhqDXCVyCSPYLEurUtp+wth2zE8qv//gqjKDKyBFv2jpjn1aSYIspAuiBY65hcZPW30ohZHVuq9pwrDpUiI50scoa3xtWA0KpraA5UA9B4NWIJYqyQi9YwvLyg= Received: from MWHPR11MB1341.namprd11.prod.outlook.com (10.169.237.144) by MWHPR11MB1422.namprd11.prod.outlook.com (10.169.234.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.24; Tue, 5 Nov 2019 05:55:05 +0000 Received: from MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::5556:6e44:dbd2:a55f]) by MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::5556:6e44:dbd2:a55f%11]) with mapi id 15.20.2408.024; Tue, 5 Nov 2019 05:55:05 +0000 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: draft-ietf-bfd-large-packets-02 Thread-Topic: draft-ietf-bfd-large-packets-02 Thread-Index: AQHVkMv1cle+Xn0mwk2I6saLmxQhfqd8F41g Date: Tue, 5 Nov 2019 05:55:04 +0000 Message-ID: References: <20191101155244.GA30539@pfrc.org> In-Reply-To: <20191101155244.GA30539@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1006::d7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d53c2240-0070-40e7-5fef-08d761b4b4bd x-ms-traffictypediagnostic: MWHPR11MB1422: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(39860400002)(366004)(189003)(199004)(13464003)(7736002)(99286004)(102836004)(66574012)(186003)(71200400001)(14444005)(256004)(81166006)(8676002)(81156014)(52536014)(25786009)(64756008)(66446008)(66476007)(66556008)(5660300002)(76116006)(66946007)(14454004)(478600001)(86362001)(76176011)(305945005)(229853002)(11346002)(6506007)(46003)(8936002)(71190400001)(446003)(2906002)(966005)(486006)(476003)(9686003)(2501003)(6306002)(6246003)(55016002)(7696005)(6436002)(33656002)(74316002)(6116002)(110136005)(316002)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1422; H:MWHPR11MB1341.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: alKc11+Xzw0xLurLNQFRqO0f4fRzKGXkHLEqzlTSGk4SfcNR5y3srgwbPJn+jzfyWW39Y9lPqumKsgt0Pmp0NlVvDPe69CnfiogYnGcaAuFZiQ/4IAgGT26i1vrayI4DoJedGCWXptQM3xwQ56Q9WeqejYgWb2pF2rKTGEbiiLi557wIxcnpIRjfUGxp6PJo5WLBiM1URiX18MXwTqsNBvDLXYDZGVUgOo8JwP/THFC+vjYYsBccAUr5X6pfJ3NRW93dhI7Se3Jce75yyRpaQZuAGX0X/AjH6yWMq0ayBpQmajZbwWf9mVeLEPsu+eBuYGS2BCrl1R11j1B7hZixO7msnD4OltPSHdo/RXH2mVqhQlqSmFo0zdUtX5LkMD2Z6CAibw5lz/hmSpa6rI8KznY6jnuQ2q2qwDQx6Utdcxbv9vOR7IeYA5XOIAdZMCeuC1dAkuyeu7tjxvyQ9EkSjdWB6GTibof7sFZCSOXQOVc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d53c2240-0070-40e7-5fef-08d761b4b4bd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 05:55:04.9622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JpJ/DbcYQ80stPOOlhVtLuwCy2jWrKqf588YfOJDCnG1mtyeyBjb0h+a9AU6Fv5WCJj0+0LFOQfzxh+wjI13VA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1422 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: 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: Tue, 05 Nov 2019 05:55:20 -0000 Jeff/Albert - Thanx for the updated version. This addresses my concerns. A couple of modest comments. 1)Section 3.4 s/that balacing/that balancing 2)Regarding S-BFD (Section 3.5) It would seem difficult to support (for a given discriminator) some session= s using large packets and some not. I can think of a few options: a)Passive end uses large packets only if the Active end does. This assumes = MTU is the same in both directions. b)A separate discriminator is used for large packet sessions c)Use of large packets is always on (or always off) on the passive side Probably there are other choices. What did you have in mind? I think adding some guidance in that regard migh= t be useful. Les > -----Original Message----- > From: Rtg-bfd On Behalf Of Jeffrey Haas > Sent: Friday, November 01, 2019 8:53 AM > To: rtg-bfd@ietf.org > Subject: draft-ietf-bfd-large-packets-02 >=20 > Working Group, >=20 > This version attempts to roll up all discussion points to date. Your > further review is appreciated. >=20 > -- Jeff and Albert >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 01 Nov 2019 08:46:00 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: rtg-bfd@ietf.org > Subject: I-D Action: draft-ietf-bfd-large-packets-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection WG of= the > IETF. >=20 > Title : BFD Encapsulated in Large Packets > Authors : Jeffrey Haas > Albert Fu > Filename : draft-ietf-bfd-large-packets-02.txt > Pages : 7 > Date : 2019-11-01 >=20 > Abstract: > The Bidirectional Forwarding Detection (BFD) protocol is commonly > used to verify connectivity between two systems. BFD packets are > typically very small. It is desirable in some circumstances to know > that not only is the path between two systems reachable, but also > that it is capable of carrying a payload of a particular size. This > document discusses thoughts on how to implement such a mechanism > using BFD in Asynchronous mode. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-bfd-large-packets-02 > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-large-packets-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > ----- End forwarded message ----- From nobody Tue Nov 5 09:54:25 2019 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 37B43120112; Tue, 5 Nov 2019 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3VV0DLiM6BCl; Tue, 5 Nov 2019 09:54:19 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 8814E12001A; Tue, 5 Nov 2019 09:54:18 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id e9so9594871ljp.13; Tue, 05 Nov 2019 09:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ZJ42urL6S5MBCJsdKHVsuKoer8Hw6TJFxq4loRXvdI=; b=O5+5lv+t9LYRvwwQhnGKfApqkWKr+/ZsN2tFmonDg/LAS4SPRD2m529E0nVmteIlE9 InjJcTPy5xTJ5gQQKOryKIio2mQ4nNfzzxa9gjst8oDeDs3H0FYGUHW8H1nJrCsAjv+F 1QFEbdykVbNxJwmgpF3TJNK8om/H8lZk4O63PfcUElXFzug698ZPwJvdxnLIKMZXy9J5 Vku7G+jxtngskoW/7nKAaoiTD3QOILIi7yj5NetfLNJlYeMFc7uK7Vm/Py/g1WBQPmO8 CWUzTdlHfDBVE2XeB8V/l5hK4/rzXXIVtUGAhpxGOZDPG6IovI/d/fuj109KQlY0Oeye HOrw== 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=2ZJ42urL6S5MBCJsdKHVsuKoer8Hw6TJFxq4loRXvdI=; b=rYD1pMWcB36noRm/ImlFPcmfbG7IFQn80fmGnxFUC3CkFWHrxj1apeCJiZ2dBBEqm/ V2mVgP/zEtd4DO+6OEZg2oCuiAcOP7kbf7o/+hLZm7NWv80uvF+0T0LGMo1FWhDHEgc7 QLZ9A5ePku8boiyHIgeGJHXE9D8xrrpfQGg2Le3Dp4EFLNxxdmvpfejOU75g2rjhVZGw VTPsN5alLdwUYSvdXiAyDmtDrXWlArUnxBmOxEd2ceLaXu0rkytNcKcRK3T/Ll3/TBUl jCbcgj6DpR3d9ovGyMqpl0e4oEmicgp37XdnDjDZKjLVGs12+KXJx4PZZds7BEE55vAm 5s3Q== X-Gm-Message-State: APjAAAWWm/qKQdJy7pUxSQ6Ejz6Z1yVsqpdtAA/F1xQmFO8tl+9dO2j4 2CILIehll0dcNkwd9WRRlA7Jl917srwYmWwhEAaANA== X-Google-Smtp-Source: APXvYqxkPW+W4YbFD7RRum6BIuJ03m3dpou5COD1Oso+WZmQTIjBMFApjZdc9mwKOdJELTco+ZvUowNcqvkGIuHu4hI= X-Received: by 2002:a2e:3612:: with SMTP id d18mr24522144lja.222.1572976456529; Tue, 05 Nov 2019 09:54:16 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> In-Reply-To: <1572888977.25948.5@smtp.gmail.com> From: Greg Mirsky Date: Tue, 5 Nov 2019 09:54:03 -0800 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: Anoop Ghanwani , Santosh P K , "Joel M. Halpern" , rtg-bfd WG , NVO3 Content-Type: multipart/alternative; boundary="000000000000ee7cdd05969d1e95" Archived-At: 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: Tue, 05 Nov 2019 17:54:23 -0000 --000000000000ee7cdd05969d1e95 Content-Type: text/plain; charset="UTF-8" Hi Dinesh, I agree that using a particular MAC over the Management VNI will minimize configuration and thus reduce the operator's headache. I'm concerned that adding RECOMMENDATION to use the specific MAC address over the Management VNI comes very close to requesting the assignment of the MAC for the Management VNI. Regards, Greg On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote: > I didn't suggest the use of a multicast MAC, any MAC would be fine in the > management VNI since there can be no tenant VMs on a management VNI. I was > recommending specifying a unicast MAC. > > Santosh, as I mentioned to Joel, I don't want to add additional forwarding > requirements--such as VNI-specific behavior--in VXLAN. The existing > mechanism is sufficient for the case we're discussing here. Just pick a MAC > in management VNI for the sake of configuration simplicity. > > Dinesh > > On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani > wrote: > > Hi Santosh, > > I'm not aware of any implementation that uses a multicast MAC for this. > The closest thing that I'm aware of that helps alleviate the need for > knowing the MAC of the remote VTEP is what's done in open vswitch: > http://www.openvswitch.org/support/dist-docs/vtep.5.html > > *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string > Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set > the destination MAC to be used for transmitted BFD packets. The > default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. > > That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be > the equivalent. > > Anoop > > On Mon, Nov 4, 2019 at 5:14 AM Santosh P K > wrote: > >> Anoop, >> Thanks for your comments. For non-managment VNI why do we need to have >> multicast MAC address for backward compatibility for existing >> implementation or there are any use cases such that we can avoid learning >> of remote end VTEP? >> >> Thanks >> Santosh P K >> >> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >> wrote: >> >>> Hi Joel, >>> >>> In that case I would propose the following text: >>> >>> "Destination MAC: If the BFD session is not using the Management VNI, >>> the destination MAC address MUST be the address >>> associated with the destination VTEP. If the BFD session uses >>> the Management VNI, it may use any MAC address, since use of the >>> Management VNI ensures that these packets will never be forwarded to a >>> VM. >>> The MAC address may be configured, or it may be learned via >>> a control plane protocol. The details of how the MAC address >>> to be used is obtained are outside the scope of this document." >>> >>> That said, for non-Management VNI, do we want to allow for flexibility >>> for an implementation to use a multicast MAC of their choosing? If so, >>> we >>> should probably add a sentence for that too. >>> >>> Thanks, >>> Anoop >>> >>> >>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>> wrote: >>> >>>> Anoop, I think I at least am misunderstanding you. >>>> If one is using the management VNI, as I understand it there is no >>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>> reasons I like using the management VNI.) >>>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>> > Hi Greg, >>>> > >>>> > In the case of the management VNI, are we trying to say that we would >>>> > allow any MAC address other than a tenant MAC address? I would >>>> suggest >>>> > some more text be added to clarify what is permitted on the >>>> management >>>> > VLAN. Assuming that we want to allow any MAC other than a tenant >>>> MAC, >>>> > how does this get enforced? In other words, what can be done for the >>>> > network to protect itself if a sender violates this? >>>> > >>>> > One possible answer is to restrict the MAC address that may be used >>>> to >>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>> address. >>>> > That means the receiver only needs to validate for those, and just >>>> > treats everything else as data. >>>> > >>>> > Also, for interoperability purposes, it would be best to specify that >>>> a >>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>> > session, while a sender MAY pick any of them. >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>> > > wrote: >>>> > >>>> > Hi Anoop, >>>> > thank you for your comments and questions. Please find my notes >>>> > in-line tagged GIM>>. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>>> anoop@alumni.duke..edu >>>> > > wrote: >>>> > >>>> > Hi Greg, >>>> > >>>> > A few comments. >>>> > >>>> > The draft has nits, specifically around the way the IPv6 >>>> address >>>> > is written. >>>> > >>>> > In section 4: >>>> > >>>> > BFD packet MUST be encapsulated -> >>>> > >>>> > BFD packets MUST be encapsulated >>>> > >>>> > GIM>> Thanks, will do. >>>> > >>>> > >>>> > >>> >>>> > >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC >>>> address MAY be >>>> > configured, or it MAY be learned via a control >>>> plane protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > >>>> > >>> >>>> > It looks like we have removed the option of using a well-known >>>> > IANA assigned MAC. If so, why is the above a MAY and not a >>>> > MUST? What else can it be? One interpretation is that it can >>>> > be anything unicast, or multicast, as long as it's not a >>>> tenant >>>> > MAC. Is that the intent? If so, it would be better to state >>>> it >>>> > that way. Also (and this is purely editorial), I think it >>>> would >>>> > be better if the first sentence above were moved to the end of >>>> > the paragraph. >>>> > >>>> > GIM>> Yes, you're right, we've removed that option and have >>>> removed >>>> > the request to IANA. I also agree that " MAY be the address >>>> > associated with the destination VTEP" is not the right choice of >>>> > normative language. On the other hand, MUST might be too >>>> restrictive >>>> > if BFD session is using the Management VNI. Would the following >>>> > update address your concern: >>>> > OLD TEXT: >>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>> > addresses. The destination MAC address MAY be the >>>> address >>>> > associated with the destination VTEP. The MAC address >>>> MAY be >>>> > configured, or it MAY be learned via a control plane >>>> protocol. >>>> > The details of how the MAC address is obtained are >>>> outside the >>>> > scope of this document. >>>> > NEW TEXT: >>>> > Destination MAC: If the BFD session is not using the >>>> > Management VNI, >>>> > the destination MAC address MUST be the address >>>> > associated with the destination VTEP. The Destination >>>> MAC >>>> > MUST NOT be one of the tenant's MAC addresses. >>>> > The MAC address MAY be configured, or it MAY be learned >>>> via >>>> > a control plane protocol. The details of how the MAC >>>> address >>>> > is obtained are outside the scope of this document. >>>> > >>>> > >>>> > "The inner Ethernet frame carrying the BFD >>>> > Control packet- has the following format:" >>>> > >>>> > Extraneous '-' after packet. >>>> > >>>> > GIM>> Thanks, will do that too. >>>> > >>>> > >>>> > Thanks, >>>> > Anoop >>>> > >>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>> > > wrote: >>>> > >>>> > Dear All, >>>> > the new version includes updates resulting from the >>>> > discussions of Joel's comments in the RtrDir review of BFD >>>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>>> behalf >>>> > of editors, thank you for your constructive comments and >>>> for >>>> > sharing your expertise, all much appreciated. >>>> > I hope we've addressed all your comments, and the draft >>>> can >>>> > proceed further. >>>> > >>>> > Regards, >>>> > Greg >>>> > >>>> > ---------- Forwarded message --------- >>>> > From: >>> > > >>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>> > Subject: New Version Notification for >>>> > draft-ietf-bfd-vxlan-08..txt >>>> > To: Gregory Mirsky >>> > >, Mallik Mudigonda >>>> > >, >>>> Sudarsan >>>> > Paragiri >>> > >, Vengada Prasad Govindan >>>> > >, Santosh >>>> > Pallagatti >>> > > >>>> > >>>> > >>>> > >>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>> > has been successfully submitted by Greg Mirsky and posted >>>> to the >>>> > IETF repository. >>>> > >>>> > Name: draft-ietf-bfd-vxlan >>>> > Revision: 08 >>>> > Title: BFD for VXLAN >>>> > Document date: 2019-11-01 >>>> > Group: bfd >>>> > Pages: 11 >>>> > URL: >>>> > >>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>> > Status: >>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>> > Htmlized: >>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>> > Htmlized: >>>> > >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>> > Diff: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>> > >>>> > Abstract: >>>> > This document describes the use of the Bidirectional >>>> > Forwarding >>>> > Detection (BFD) protocol in point-to-point Virtual >>>> > eXtensible Local >>>> > Area Network (VXLAN) tunnels forming up an overlay >>>> network. >>>> > >>>> > >>>> > >>>> > >>>> > 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 < >>>> http://tools.ietf.org>. >>>> > >>>> > The IETF Secretariat >>>> > >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> --000000000000ee7cdd05969d1e95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dinesh,
I agree that using a particular MAC over th= e Management VNI will minimize configuration and thus reduce the operator&#= 39;s headache. I'm concerned that adding RECOMMENDATION to use the spec= ific MAC address over the Management VNI comes very close to requesting the= assignment of the MAC for the Management VNI.

Reg= ards,
Greg

On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt <didutt@gmail.com> wrote:
=
I didn't suggest the use of= a multicast MAC, any MAC would be fine in the management VNI since there c= an be no tenant VMs on a management VNI. I was recommending specifying a un= icast MAC.

Santosh, as I mentioned to Joel, I don&= #39;t want to add additional forwarding requirements--such as VNI-specific = behavior--in VXLAN. The existing mechanism is sufficient for the case we= 9;re discussing here. Just pick a MAC in management VNI for the sake of con= figuration simplicity.

Dinesh

On Mon, Nov 4= , 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Santosh,

I'm not aw= are of any implementation that uses a multicast MAC for this.=C2=A0 The clo= sest thing that I'm aware of that helps alleviate the need for knowing = the MAC of the remote=C2=A0VTEP is what's done in open vswitch:
http://www.openvswitch.org/support/dist-docs/vtep.5.html= 
   bfd_<=
/b>config_re=
mote : bfd_<=
b>dst_mac: optional string
              Set  to an Ethernet address in the form xx:x=
x:xx:xx:xx:x=
x to set
              the destination MAC to be used for transmitted BFD packets.  =
The
              default is 00:23:20:00:00:0<=
/b>1.
That OUI belongs to Nicira/VMware.=C2=A0 An IA= NA assigned unicast MAC would be the equivalent.

A= noop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.co= m> wrote:
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non= -managment VNI why do we need to have multicast MAC address for backward=C2= =A0compatibility for existing implementation=C2=A0or there are any use case= s such that we can avoid learning of remote end VTEP?=C2=A0

<= /div>
Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD sessio= n is not using the=C2=A0Management = VNI,
= the destination MAC address MUST be the address
associated with the destination = VTEP.=C2=A0 If the BFD session uses
the Management VNI, it= may use any MAC address, since use of the=C2=A0
Management VNI e= nsures that these packets will never be forwarded to a VM.
The MAC address may be confi= gured, or it may be learned via
a control plane protocol. The details of how the= MAC address
to be used is obtained are outside the scope of this document."= ;

That said, for non-Management VNI, do w= e want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?=C2= =A0 If so, we
should probably add = a sentence for that too.

Thanks,
Anoop<= /div>

On Sun, N= ov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am mis= understanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--000000000000ee7cdd05969d1e95-- From nobody Tue Nov 5 16:29:37 2019 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 EA8FD1200C3; Tue, 5 Nov 2019 16:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=gmail.com 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 597sGkcQ95Uj; Tue, 5 Nov 2019 16:29:28 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 2E0DC12011B; Tue, 5 Nov 2019 16:29:13 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id a18so9407100plm.10; Tue, 05 Nov 2019 16:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=ois6+6H6iJvXE3l8hcUiW2YOXoJPFuR1lijEP3W4lKs=; b=aTMxJoKPQxjhcUao8vvb+73AMUwwWdwIQ/PRONn73puUmPLqK1QVQy7XBBfNPWJfwj uWlhg39e3B2+VEJWUYzqJE+urwPKC8Cx4EsonF8JZmOxXKxeDh9F8yjH1CfIOh1PyVci rDkYXzXcJv9tZQIB65kb6IOPbdIx5vKkYuYODL2BHVMOBUkc/89F0ei/VRCPvf6qH5LK lO1ORA97ttRKEKDy69iVYTZ5+grPKWoPNnCnLsptCX3I4hdU+7dA7x+GeCL+1hWrmnnb V9DsJ2feF3Rkqcelk0+VhfqV+Sfe2AEsrmUkAxtkIkTV7iHw/oFlu/GXJoq/5xIAZMpN 2NHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=ois6+6H6iJvXE3l8hcUiW2YOXoJPFuR1lijEP3W4lKs=; b=DRSzOEdkyFZpLI4Y1I0RUwnoqdv5IyZuNmFBT/7sYphu1dr/IWSDTrdVTv9F56B+DX DPJjir3G7Poi1r9UyJeCSUSdXsfAOj+nUql3zHi2mzgDTzKn7DDahSqatWVVy2MYGbwp 1Qng3gQ9BxpDqqbUI4C4SNDUo7bR/xtIKUcVciU/YgEvCJ6xF5IEC13gY9U5vI8BUzNC wK0MDbG0XGOoptwf/GviqMLrC7FA0gv41Z2HbhGYwYQ6mee2DapcHY0PTuLvvIVHQirM Z18q+i8CrQyCTBEF5lAEyO6V4EceKLlJ0GX2Ybr14d94hwMfSUt14JT14KDgdUs6mEyM 3AvQ== X-Gm-Message-State: APjAAAXoURsa57PAJsFCacRFewSCMPymZYh51LMX5d9LAgbRH+R2mqIa EjQY0SldGS+A21V8cJYmdKk= X-Google-Smtp-Source: APXvYqzfwFfQ1RLNVJJOUl2ojByibp7f2Ee7cNzEo3Y+JDnj4N6XLPThPETAMNCjJCyIFy3z1RzwFA== X-Received: by 2002:a17:902:758a:: with SMTP id j10mr9338087pll.29.1573000152374; Tue, 05 Nov 2019 16:29:12 -0800 (PST) Received: from [192.168.0.105] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id h8sm1204296pjp.1.2019.11.05.16.29.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 16:29:11 -0800 (PST) Date: Wed, 06 Nov 2019 05:29:05 +0500 From: Dinesh Dutt Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Greg Mirsky Cc: Anoop Ghanwani , Santosh P K , "Joel M. Halpern" , rtg-bfd WG , NVO3 Message-Id: <1573000145.25948.19@smtp.gmail.com> In-Reply-To: References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-7Br5iMthCyzCS1LOjYfE" Archived-At: 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: Wed, 06 Nov 2019 00:29:31 -0000 --=-7Br5iMthCyzCS1LOjYfE Content-Type: text/plain; charset=us-ascii; format=flowed I understand Greg. Maybe suggest a value, rather than recommend it? Its just to reduce configuration. The key parts are to not change the existing VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't leak to tenants (which typically don't exist in case of a management VNI). Dinesh On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky wrote: > Hi Dinesh, > I agree that using a particular MAC over the Management VNI will > minimize configuration and thus reduce the operator's headache. I'm > concerned that adding RECOMMENDATION to use the specific MAC address > over the Management VNI comes very close to requesting the assignment > of the MAC for the Management VNI. > > Regards, > Greg > > On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote: >> I didn't suggest the use of a multicast MAC, any MAC would be fine >> in the management VNI since there can be no tenant VMs on a >> management VNI. I was recommending specifying a unicast MAC. >> >> Santosh, as I mentioned to Joel, I don't want to add additional >> forwarding requirements--such as VNI-specific behavior--in VXLAN. >> The existing mechanism is sufficient for the case we're discussing >> here. Just pick a MAC in management VNI for the sake of >> configuration simplicity. >> >> Dinesh >> >> On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani >> wrote: >>> Hi Santosh, >>> >>> I'm not aware of any implementation that uses a multicast MAC for >>> this. The closest thing that I'm aware of that helps alleviate the >>> need for knowing the MAC of the remote VTEP is what's done in open >>> vswitch: >>> http://www.openvswitch.org/support/dist-docs/vtep.5.html >>> bfd_config_remote : bfd_dst_mac: optional string >>> Set to an Ethernet address in the form >>> xx:xx:xx:xx:xx:xx to set >>> the destination MAC to be used for transmitted BFD >>> packets. The >>> default is 00:23:20:00:00:01. >>> That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC >>> would be the equivalent. >>> >>> Anoop >>> >>> On Mon, Nov 4, 2019 at 5:14 AM Santosh P K >>> wrote: >>>> Anoop, >>>> Thanks for your comments. For non-managment VNI why do we need >>>> to have multicast MAC address for backward compatibility for >>>> existing implementation or there are any use cases such that we >>>> can avoid learning of remote end VTEP? >>>> >>>> Thanks >>>> Santosh P K >>>> >>>> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >>>> wrote: >>>>> Hi Joel, >>>>> >>>>> In that case I would propose the following text: >>>>> >>>>> "Destination MAC: If the BFD session is not using the Management >>>>> VNI, >>>>> the destination MAC address MUST be the address >>>>> associated with the destination VTEP. If the BFD session uses >>>>> the Management VNI, it may use any MAC address, since use of the >>>>> Management VNI ensures that these packets will never be forwarded >>>>> to a VM. >>>>> The MAC address may be configured, or it may be learned via >>>>> a control plane protocol. The details of how the MAC address >>>>> to be used is obtained are outside the scope of this document." >>>>> >>>>> That said, for non-Management VNI, do we want to allow for >>>>> flexibility >>>>> for an implementation to use a multicast MAC of their choosing? >>>>> If so, we >>>>> should probably add a sentence for that too. >>>>> >>>>> Thanks, >>>>> Anoop >>>>> >>>>> >>>>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>>>> wrote: >>>>>> Anoop, I think I at least am misunderstanding you. >>>>>> If one is using the management VNI, as I understand it there is >>>>>> no >>>>>> tenant. So there are no tenant MAC addresses. (This is one of >>>>>> the >>>>>> reasons I like using the management VNI.) >>>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>>>> > Hi Greg, >>>>>> > >>>>>> > In the case of the management VNI, are we trying to say that >>>>>> we would >>>>>> > allow any MAC address other than a tenant MAC address? I >>>>>> would suggest >>>>>> > some more text be added to clarify what is permitted on the >>>>>> management >>>>>> > VLAN. Assuming that we want to allow any MAC other than a >>>>>> tenant MAC, >>>>>> > how does this get enforced? In other words, what can be done >>>>>> for the >>>>>> > network to protect itself if a sender violates this? >>>>>> > >>>>>> > One possible answer is to restrict the MAC address that may be >>>>>> used to >>>>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>>>> address. >>>>>> > That means the receiver only needs to validate for those, and >>>>>> just >>>>>> > treats everything else as data. >>>>>> > >>>>>> > Also, for interoperability purposes, it would be best to >>>>>> specify that a >>>>>> > receiver MUST be able to handle any valid MAC address for the >>>>>> BFD >>>>>> > session, while a sender MAY pick any of them. >>>>>> > >>>>>> > Thanks, >>>>>> > Anoop >>>>>> > >>>>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>>>>> >>>>> > > wrote: >>>>>> > >>>>>> > Hi Anoop, >>>>>> > thank you for your comments and questions. Please find my >>>>>> notes >>>>>> > in-line tagged GIM>>. >>>>>> > >>>>>> > Regards, >>>>>> > Greg >>>>>> > >>>>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani >>>>>> >>>>> > > wrote: >>>>>> > >>>>>> > Hi Greg, >>>>>> > >>>>>> > A few comments. >>>>>> > >>>>>> > The draft has nits, specifically around the way the >>>>>> IPv6 address >>>>>> > is written. >>>>>> > >>>>>> > In section 4: >>>>>> > >>>>>> > BFD packet MUST be encapsulated -> >>>>>> > >>>>>> > BFD packets MUST be encapsulated >>>>>> > >>>>>> > GIM>> Thanks, will do. >>>>>> > >>>>>> > >>>>>> > >>> >>>>>> > >>>>>> > Destination MAC: This MUST NOT be of one of tenant's >>>>>> MAC >>>>>> > addresses. The destination MAC address MAY >>>>>> be the address >>>>>> > associated with the destination VTEP. The >>>>>> MAC address MAY be >>>>>> > configured, or it MAY be learned via a >>>>>> control plane protocol. >>>>>> > The details of how the MAC address is >>>>>> obtained are outside the >>>>>> > scope of this document. >>>>>> > >>>>>> > >>> >>>>>> > It looks like we have removed the option of using a >>>>>> well-known >>>>>> > IANA assigned MAC. If so, why is the above a MAY and >>>>>> not a >>>>>> > MUST? What else can it be? One interpretation is >>>>>> that it can >>>>>> > be anything unicast, or multicast, as long as it's not >>>>>> a tenant >>>>>> > MAC. Is that the intent? If so, it would be better >>>>>> to state it >>>>>> > that way. Also (and this is purely editorial), I >>>>>> think it would >>>>>> > be better if the first sentence above were moved to >>>>>> the end of >>>>>> > the paragraph. >>>>>> > >>>>>> > GIM>> Yes, you're right, we've removed that option and >>>>>> have removed >>>>>> > the request to IANA. I also agree that " MAY be the address >>>>>> > associated with the destination VTEP" is not the right >>>>>> choice of >>>>>> > normative language. On the other hand, MUST might be too >>>>>> restrictive >>>>>> > if BFD session is using the Management VNI. Would the >>>>>> following >>>>>> > update address your concern: >>>>>> > OLD TEXT: >>>>>> > Destination MAC: This MUST NOT be of one of >>>>>> tenant's MAC >>>>>> > addresses. The destination MAC address MAY be >>>>>> the address >>>>>> > associated with the destination VTEP. The MAC >>>>>> address MAY be >>>>>> > configured, or it MAY be learned via a control >>>>>> plane protocol. >>>>>> > The details of how the MAC address is obtained >>>>>> are outside the >>>>>> > scope of this document. >>>>>> > NEW TEXT: >>>>>> > Destination MAC: If the BFD session is not using >>>>>> the >>>>>> > Management VNI, >>>>>> > the destination MAC address MUST be the address >>>>>> > associated with the destination VTEP. The >>>>>> Destination MAC >>>>>> > MUST NOT be one of the tenant's MAC addresses. >>>>>> > The MAC address MAY be configured, or it MAY be >>>>>> learned via >>>>>> > a control plane protocol. The details of how the >>>>>> MAC address >>>>>> > is obtained are outside the scope of this >>>>>> document. >>>>>> > >>>>>> > >>>>>> > "The inner Ethernet frame carrying the BFD >>>>>> > Control packet- has the following format:" >>>>>> > >>>>>> > Extraneous '-' after packet. >>>>>> > >>>>>> > GIM>> Thanks, will do that too. >>>>>> > >>>>>> > >>>>>> > Thanks, >>>>>> > Anoop >>>>>> > >>>>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>>>> > > >>>>>> wrote: >>>>>> > >>>>>> > Dear All, >>>>>> > the new version includes updates resulting from the >>>>>> > discussions of Joel's comments in the RtrDir >>>>>> review of BFD >>>>>> > over VXLAN draft, comments from Anoop, and Dinesh. >>>>>> On behalf >>>>>> > of editors, thank you for your constructive >>>>>> comments and for >>>>>> > sharing your expertise, all much appreciated. >>>>>> > I hope we've addressed all your comments, and the >>>>>> draft can >>>>>> > proceed further. >>>>>> > >>>>>> > Regards, >>>>>> > Greg >>>>>> > >>>>>> > ---------- Forwarded message --------- >>>>>> > From: >>>>> > > >>>>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>>>> > Subject: New Version Notification for >>>>>> > draft-ietf-bfd-vxlan-08..txt >>>>>> > To: Gregory Mirsky >>>>> > >, Mallik Mudigonda >>>>>> > >, >>>>>> Sudarsan >>>>>> > Paragiri >>>>> > >, Vengada Prasad >>>>>> Govindan >>>>>> > >, >>>>>> Santosh >>>>>> > Pallagatti >>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>>>> > has been successfully submitted by Greg Mirsky and >>>>>> posted to the >>>>>> > IETF repository. >>>>>> > >>>>>> > Name: draft-ietf-bfd-vxlan >>>>>> > Revision: 08 >>>>>> > Title: BFD for VXLAN >>>>>> > Document date: 2019-11-01 >>>>>> > Group: bfd >>>>>> > Pages: 11 >>>>>> > URL: >>>>>> > >>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>>>> > Status: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>>>> > Htmlized: >>>>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>>>> > Htmlized: >>>>>> > >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>>>> > Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>>>> > >>>>>> > Abstract: >>>>>> > This document describes the use of the >>>>>> Bidirectional >>>>>> > Forwarding >>>>>> > Detection (BFD) protocol in point-to-point >>>>>> Virtual >>>>>> > eXtensible Local >>>>>> > Area Network (VXLAN) tunnels forming up an >>>>>> overlay network. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > 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 >>>>>> > >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 --=-7Br5iMthCyzCS1LOjYfE Content-Type: text/html; charset=us-ascii
I understand Greg. Maybe suggest a value, rather than recommend it? Its just to reduce configuration. The key parts are to not change the existing VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't leak to tenants (which typically don't exist in case of a management VNI). 

Dinesh

On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Dinesh,
I agree that using a particular MAC over the Management VNI will minimize configuration and thus reduce the operator's headache. I'm concerned that adding RECOMMENDATION to use the specific MAC address over the Management VNI comes very close to requesting the assignment of the MAC for the Management VNI.

Regards,
Greg

On Mon, Nov 4, 2 019 at 9:36 AM Dinesh Dutt <didutt@gmail.com> wrote:
I didn't suggest the use of a multicast MAC, any MAC would be fine in the management VNI since there can be no tenant VMs on a management VNI. I was recommending specifying a unicast MAC.

Santosh, as I mentioned to Joel, I don't want to add additional forwarding requirements--such as VNI-specific behavior--in VXLAN. The existing mechanism is sufficient for the case we're discussing here. Just pick a MAC in management VNI for the sake of configuration simplicity.

Dinesh

On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Santosh,

I'm not aware of any implementation that uses a multicast MAC for this.  The closest thing that I'm aware of that helps alleviate the need for knowing the MAC of the remote VTEP is what's done in open vswitch:
   bfd_config_remote : bfd_dst_mac: optional string
              Set  to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set
              the destination MAC to be used for transmitted BFD packets.  The
              default is 00:23:20:00:00:01.
That OUI belongs to Nicira/VMware.  An IANA assigned unicast MAC would be the equivalent.

Anoop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.com> wrote:
Anoop,
   Thanks for your comments. For non-managment VNI why do we need to have multicast MAC address for backward compatibility for existing implementation or there are any use cases such that we can avoid learning of remote end VTEP? 

Thanks
Santosh P K& nbsp;

On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD session is not using the Management VNI,
the destination MAC address MUST be the address
associated with the destination VTEP.  If the BFD session uses
the Management VNI, it may use any MAC address, since use of the 
Management VNI ensures that these pac kets will never be forwarded to a VM.
The MAC address may be configured, or it may be learned via
a control plane protocol. The details of how the MAC address
to be used is obtained are outside the scope of this document."

That said, for non-Management VNI, do we want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?  If so, we
should probably add a sentence for that too.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.  So there are no tenant MAC addresses.  (This is one of the
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would
> allow any MAC address other than a tenant MAC address?  I would suggest
> some more text be added to clarify what is permitted on the management
> VLAN.  Assuming that we want to allow any MAC other than a tenant MAC,
> how does this get enforced?  In other words, what can be done for the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to
> one that is owned by the VTEP or a "agreed on" multicast MAC address. 
> That means the receiver only needs to validate for those, and just
> treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:gregimirsky@gmail.com>> wrote:
>
>     Hi Anoop,
>     thank you for your comments and questions. Please find my notes
>     in-line tagged GIM>>.
>
>     Regards,
>     Greg
>
>     On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <anoop@alumni.duke..edu
>     <mailto:anoop@alumni.duke.edu>> wrote:
>
>         Hi Greg,
>
>         A few comments.
>
>         The draft has nits, specifically around the way the IPv6 address
>         is written.
>
>         In section 4:
>
>         BFD packet MUST be encapsulated ->
>
>         BFD packets MUST be encapsulated
>
>     GIM>> Thanks, will do.
>
>
>          >>>
>
>         Destination MAC: This MUST NOT be of one of tenant's MAC
>                   addresses.  The destination MAC address MAY be the address
>                   associated with the destination VTEP.  The MAC address MAY be
>                   configured, or it MAY be learned via a control plane protocol.
>                   The details of how the MAC address is obtained are outside the
>                   scope of this document.
>
>          >>>
>         It looks like we have removed the option of using a well-known
>         IANA assigned MAC.  If so, why is the above a MAY and not a
>         MUST?  What else can it be?  One interpretation is that it can
>         be anything unicast, or multicast, as long as it's not a tenant
>         MAC.  Is that the intent?  If so, it would be better to state it
>         that way.  Also (and this is purely editorial), I think it would
>         be better if the first sentence above were moved to the end of
>         the paragraph.
>
>     GIM>> Yes, you're right, we've removed that option and have removed
>     the request to IANA. I also agree that " MAY be the address
>     associated with the destination VTEP" is not the right choice of
>     normative language. On the other hand, MUST might be too restrictive
>     if BFD session is using the Management VNI. Would the following
>     update address your concern:
>     OLD TEXT:
>               Destination MAC: This MUST NOT be of one of tenant's MAC
>               addresses.  The destination MAC address MAY be the address
>               associated with the destination VTEP.  The MAC address MAY be
>               configured, or it MAY be learned via a control plane protocol.
>               The details of how the MAC address is obtained are outside the
>               scope of this document.
>     NEW TEXT:
>               Destination MAC: If the BFD session is not using the
>     Management VNI,
>               the destination MAC address MUST be the address
>               associated with the destination VTEP.  The Destination MAC
>               MUST NOT be one of the tenant's MAC addresses.
>              The MAC address MAY be configured, or it MAY be learned via
>              a control plane protocol. The details of how the MAC address
>              is obtained are outside the scope of this document.
>
>
>         "The inner Ethernet frame carrying the BFD
>             Control packet- has the following format:"
>
>         Extraneous '-' after packet.
>
>     GIM>> Thanks, will do that too.
>
>
>         Thanks,
>         Anoop
>
>         On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky
>         <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
>
>             Dear All,
>             the new version includes updates resulting from the
>             discussions of Joel's comments in the RtrDir review of BFD
>             over VXLAN draft, comments from Anoop, and Dinesh. On behalf
>             of editors, thank you for your constructive comments and for
>             sharing your expertise, all much appreciated.
>             I hope we've addressed all your comments, and the draft can
>             proceed further.
>
>             Regards,
>             Greg
>
>             ---------- Forwarded message ---------
>             From: <internet-drafts@ietf.org
>             <mailto:internet-drafts@ietf.org>>
>             Date: Fri, Nov 1, 2019 at 10:45 AM
>             Subject: New Version Notification for
>             draft-ietf-bfd-vxlan-08..txt
>             To: Gregory Mirsky <gregimirsky@gmail.com
>             <mailto:gregimirsky@gmail.com>>, Mallik Mudigonda
>             <mmudigon@cisco.com <mailto:mmudigon@cisco.com>>, Sudarsan
>             Paragiri <sudarsan.225@gmail.com
>             <mailto:sudarsan.225@gmail.com>>, Vengada Prasad Govindan
>             <venggovi@cisco.com <mailto:venggovi@cisco.com>>, Santosh
>             Pallagatti <santosh.pallagatti@gmail.com
>             <mailto:santosh.pallagatti@gmail.com>>
>
>
>
>             A new version of I-D, draft-ietf-bfd-vxlan-08.txt
>             has been successfully submitted by Greg Mirsky and posted to the
>             IETF repository.
>
>             Name:           draft-ietf-bfd-vxlan
>             Revision:       08
>             Title:          BFD for VXLAN
>             Document date:  2019-11-01
>             Group:          bfd
>             Pages:          11
>             URL:
>             https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt
>             Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>             Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>             Htmlized:
>             https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
>             Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08
>
>             Abstract:
>                 This document describes the use of the Bidirectional
>             Forwarding
>                 Detection (BFD) protocol in point-to-point Virtual
>             eXtensible Local
>                 Area Network (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>             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 <http://tools.ietf.org>.
>
>             The IETF Secretariat
>
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--=-7Br5iMthCyzCS1LOjYfE-- From nobody Tue Nov 5 17:39:05 2019 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 ED42D120041; Tue, 5 Nov 2019 17:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 HfOu4R1Gl7Jz; Tue, 5 Nov 2019 17:38:54 -0800 (PST) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (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 80206120274; Tue, 5 Nov 2019 17:38:27 -0800 (PST) Received: by mail-vk1-f179.google.com with SMTP id k24so2308498vko.7; Tue, 05 Nov 2019 17:38:27 -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=kJA6xGiqK6zh9TCMEe9fTJ0HMtODq3AOQtFSXo8Um28=; b=o+25wtN4SGUtOKcw1gLrt7yw0w7Fi99jeHa2mXeBVF2Uuw/cPU16z9f7P5tgARBcmJ cf5OWMG77VuzeFzYmq+luY7JuMbJFJN8Z5HaR3XfckwtPFBmL7Tew1MACwTHaLYjLjOu IQiqwDuUlu+yz0vbrx7KDqiClify0hAHWjIGHGD0klNDzOa0fBmsFFRZc309cZuYDrAE kNhat9CPZP5OIYD/sPQ2LwBZDd7GQvf8fYIR4DC5aS9yPsQTfKPAvSDROiptKuKD7JXg MzfTxWoLTh7YiAdJRQawiNRrAm5OguTPXOoucx4J6RxcQBpDBXdpPlu5GyAiFDvNHert 2L3w== X-Gm-Message-State: APjAAAVsPqpIH4/rdgslZQTxpBQLrSOBYhdPPKwijZmdyI/OQYBcETOx wyZu+df4+MUXEPWkgR318D6rBwmJyidMCzSxZIo= X-Google-Smtp-Source: APXvYqxOaVOXij7ikxPjTiMnB8sG9t8YQ+jYu/GCKlIAh28+C4Kpb2lqaNejv4g/yJVZ2vrpZeGDIKFr/W4wMRiB3Is= X-Received: by 2002:a1f:8dc5:: with SMTP id p188mr135858vkd.13.1573004306455; Tue, 05 Nov 2019 17:38:26 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> <1573000145.25948.19@smtp.gmail.com> In-Reply-To: <1573000145.25948.19@smtp.gmail.com> From: Anoop Ghanwani Date: Tue, 5 Nov 2019 17:38:14 -0800 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: Greg Mirsky , Santosh P K , "Joel M. Halpern" , rtg-bfd WG , NVO3 Content-Type: multipart/alternative; boundary="000000000000eaa2d80596a39ab0" Archived-At: 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: Wed, 06 Nov 2019 01:38:58 -0000 --000000000000eaa2d80596a39ab0 Content-Type: text/plain; charset="UTF-8" Greg, What is the resistance to getting an address assigned by IANA? (Apologies if I missed the discussion.) Also not sure about the value of the statement >> An implementation MAY use VNI number 1 as the default value for the Management VNI. >> What prompted this, and if we need to recommend a value, why not 0? Thanks, Anoop On Tue, Nov 5, 2019 at 4:29 PM Dinesh Dutt wrote: > I understand Greg. Maybe suggest a value, rather than recommend it? Its > just to reduce configuration. The key parts are to not change the existing > VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't leak to > tenants (which typically don't exist in case of a management VNI). > > Dinesh > > On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky > wrote: > > Hi Dinesh, > I agree that using a particular MAC over the Management VNI will minimize > configuration and thus reduce the operator's headache. I'm concerned that > adding RECOMMENDATION to use the specific MAC address over the Management > VNI comes very close to requesting the assignment of the MAC for the > Management VNI. > > Regards, > Greg > > On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote: > >> I didn't suggest the use of a multicast MAC, any MAC would be fine in the >> management VNI since there can be no tenant VMs on a management VNI. I was >> recommending specifying a unicast MAC. >> >> Santosh, as I mentioned to Joel, I don't want to add additional >> forwarding requirements--such as VNI-specific behavior--in VXLAN. The >> existing mechanism is sufficient for the case we're discussing here. Just >> pick a MAC in management VNI for the sake of configuration simplicity. >> >> Dinesh >> >> On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani >> wrote: >> >> Hi Santosh, >> >> I'm not aware of any implementation that uses a multicast MAC for this. >> The closest thing that I'm aware of that helps alleviate the need for >> knowing the MAC of the remote VTEP is what's done in open vswitch: >> http://www.openvswitch.org/support/dist-docs/vtep.5.html >> >> *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string >> Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set >> the destination MAC to be used for transmitted BFD packets. The >> default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. >> >> That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would be >> the equivalent. >> >> Anoop >> >> On Mon, Nov 4, 2019 at 5:14 AM Santosh P K >> wrote: >> >>> Anoop, >>> Thanks for your comments. For non-managment VNI why do we need to >>> have multicast MAC address for backward compatibility for existing >>> implementation or there are any use cases such that we can avoid learning >>> of remote end VTEP? >>> >>> Thanks >>> Santosh P K >>> >>> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >>> wrote: >>> >>>> Hi Joel, >>>> >>>> In that case I would propose the following text: >>>> >>>> "Destination MAC: If the BFD session is not using the Management VNI, >>>> the destination MAC address MUST be the address >>>> associated with the destination VTEP. If the BFD session uses >>>> the Management VNI, it may use any MAC address, since use of the >>>> Management VNI ensures that these packets will never be forwarded to a >>>> VM. >>>> The MAC address may be configured, or it may be learned via >>>> a control plane protocol. The details of how the MAC address >>>> to be used is obtained are outside the scope of this document." >>>> >>>> That said, for non-Management VNI, do we want to allow for flexibility >>>> for an implementation to use a multicast MAC of their choosing? If so, >>>> we >>>> should probably add a sentence for that too. >>>> >>>> Thanks, >>>> Anoop >>>> >>>> >>>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>>> wrote: >>>> >>>>> Anoop, I think I at least am misunderstanding you. >>>>> If one is using the management VNI, as I understand it there is no >>>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>>> reasons I like using the management VNI.) >>>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>>> > Hi Greg, >>>>> > >>>>> > In the case of the management VNI, are we trying to say that we >>>>> would >>>>> > allow any MAC address other than a tenant MAC address? I would >>>>> suggest >>>>> > some more text be added to clarify what is permitted on the >>>>> management >>>>> > VLAN. Assuming that we want to allow any MAC other than a tenant >>>>> MAC, >>>>> > how does this get enforced? In other words, what can be done for >>>>> the >>>>> > network to protect itself if a sender violates this? >>>>> > >>>>> > One possible answer is to restrict the MAC address that may be used >>>>> to >>>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>>> address. >>>>> > That means the receiver only needs to validate for those, and just >>>>> > treats everything else as data. >>>>> > >>>>> > Also, for interoperability purposes, it would be best to specify >>>>> that a >>>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>>> > session, while a sender MAY pick any of them. >>>>> > >>>>> > Thanks, >>>>> > Anoop >>>>> > >>>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>>> > > wrote: >>>>> > >>>>> > Hi Anoop, >>>>> > thank you for your comments and questions. Please find my notes >>>>> > in-line tagged GIM>>. >>>>> > >>>>> > Regards, >>>>> > Greg >>>>> > >>>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>>>> anoop@alumni.duke..edu >>>>> > > wrote: >>>>> > >>>>> > Hi Greg, >>>>> > >>>>> > A few comments. >>>>> > >>>>> > The draft has nits, specifically around the way the IPv6 >>>>> address >>>>> > is written. >>>>> > >>>>> > In section 4: >>>>> > >>>>> > BFD packet MUST be encapsulated -> >>>>> > >>>>> > BFD packets MUST be encapsulated >>>>> > >>>>> > GIM>> Thanks, will do. >>>>> > >>>>> > >>>>> > >>> >>>>> > >>>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>>> > addresses. The destination MAC address MAY be the >>>>> address >>>>> > associated with the destination VTEP. The MAC >>>>> address MAY be >>>>> > configured, or it MAY be learned via a control >>>>> plane protocol. >>>>> > The details of how the MAC address is obtained are >>>>> outside the >>>>> > scope of this document. >>>>> > >>>>> > >>> >>>>> > It looks like we have removed the option of using a >>>>> well-known >>>>> > IANA assigned MAC. If so, why is the above a MAY and not a >>>>> > MUST? What else can it be? One interpretation is that it >>>>> can >>>>> > be anything unicast, or multicast, as long as it's not a >>>>> tenant >>>>> > MAC. Is that the intent? If so, it would be better to >>>>> state it >>>>> > that way. Also (and this is purely editorial), I think it >>>>> would >>>>> > be better if the first sentence above were moved to the end >>>>> of >>>>> > the paragraph. >>>>> > >>>>> > GIM>> Yes, you're right, we've removed that option and have >>>>> removed >>>>> > the request to IANA. I also agree that " MAY be the address >>>>> > associated with the destination VTEP" is not the right choice of >>>>> > normative language. On the other hand, MUST might be too >>>>> restrictive >>>>> > if BFD session is using the Management VNI. Would the following >>>>> > update address your concern: >>>>> > OLD TEXT: >>>>> > Destination MAC: This MUST NOT be of one of tenant's >>>>> MAC >>>>> > addresses. The destination MAC address MAY be the >>>>> address >>>>> > associated with the destination VTEP. The MAC address >>>>> MAY be >>>>> > configured, or it MAY be learned via a control plane >>>>> protocol. >>>>> > The details of how the MAC address is obtained are >>>>> outside the >>>>> > scope of this document. >>>>> > NEW TEXT: >>>>> > Destination MAC: If the BFD session is not using the >>>>> > Management VNI, >>>>> > the destination MAC address MUST be the address >>>>> > associated with the destination VTEP. The Destination >>>>> MAC >>>>> > MUST NOT be one of the tenant's MAC addresses. >>>>> > The MAC address MAY be configured, or it MAY be learned >>>>> via >>>>> > a control plane protocol. The details of how the MAC >>>>> address >>>>> > is obtained are outside the scope of this document. >>>>> > >>>>> > >>>>> > "The inner Ethernet frame carrying the BFD >>>>> > Control packet- has the following format:" >>>>> > >>>>> > Extraneous '-' after packet. >>>>> > >>>>> > GIM>> Thanks, will do that too. >>>>> > >>>>> > >>>>> > Thanks, >>>>> > Anoop >>>>> > >>>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>>> > > >>>>> wrote: >>>>> > >>>>> > Dear All, >>>>> > the new version includes updates resulting from the >>>>> > discussions of Joel's comments in the RtrDir review of >>>>> BFD >>>>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>>>> behalf >>>>> > of editors, thank you for your constructive comments and >>>>> for >>>>> > sharing your expertise, all much appreciated. >>>>> > I hope we've addressed all your comments, and the draft >>>>> can >>>>> > proceed further. >>>>> > >>>>> > Regards, >>>>> > Greg >>>>> > >>>>> > ---------- Forwarded message --------- >>>>> > From: >>>> > > >>>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>>> > Subject: New Version Notification for >>>>> > draft-ietf-bfd-vxlan-08..txt >>>>> > To: Gregory Mirsky >>>> > >, Mallik Mudigonda >>>>> > >, >>>>> Sudarsan >>>>> > Paragiri >>>> > >, Vengada Prasad >>>>> Govindan >>>>> > >, >>>>> Santosh >>>>> > Pallagatti >>>> > > >>>>> > >>>>> > >>>>> > >>>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>>> > has been successfully submitted by Greg Mirsky and >>>>> posted to the >>>>> > IETF repository. >>>>> > >>>>> > Name: draft-ietf-bfd-vxlan >>>>> > Revision: 08 >>>>> > Title: BFD for VXLAN >>>>> > Document date: 2019-11-01 >>>>> > Group: bfd >>>>> > Pages: 11 >>>>> > URL: >>>>> > >>>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>>> > Status: >>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>>> > Htmlized: >>>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>>> > Htmlized: >>>>> > >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>>> > Diff: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>>> > >>>>> > Abstract: >>>>> > This document describes the use of the Bidirectional >>>>> > Forwarding >>>>> > Detection (BFD) protocol in point-to-point Virtual >>>>> > eXtensible Local >>>>> > Area Network (VXLAN) tunnels forming up an overlay >>>>> network. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > 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 < >>>>> http://tools.ietf.org>. >>>>> > >>>>> > The IETF Secretariat >>>>> > >>>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>> --000000000000eaa2d80596a39ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,

What is the resistance to getting= an address assigned by IANA?

(Apologies if I miss= ed the discussion.)

Also not sure about the value = of the statement=C2=A0
>>
An implementation MAY use VNI number 1 as the
   default value for the Management VNI.
>>
What prompted this, and if we need to recommend a value, why not 0?
<= div>
Thanks,
Anoop

On Tue, Nov 5, 2019 at 4:29= PM Dinesh Dutt <didutt@gmail.com> wrote:
I underst= and Greg. Maybe suggest a value, rather than recommend it? Its just to redu= ce configuration. The key parts are to not change the existing VXLAN forwar= ding behavior and ensure that BFD between VTEPs doesn't leak to tenants= (which typically don't exist in case of a management VNI).=C2=A0
=

Dinesh

On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsk= y <gregimirsk= y@gmail.com> wrote:
Hi= Dinesh,
I agree that using a particular MAC over the Management VNI wi= ll minimize configuration and thus reduce the operator's headache. I= 9;m concerned that adding RECOMMENDATION to use the specific MAC address ov= er the Management VNI comes very close to requesting the assignment of the = MAC for the Management VNI.

Regards,
Gre= g

On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt <didutt@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I di= dn't suggest the use of a multicast MAC, any MAC would be fine in the m= anagement VNI since there can be no tenant VMs on a management VNI. I was r= ecommending specifying a unicast MAC.

Santosh, as = I mentioned to Joel, I don't want to add additional forwarding requirem= ents--such as VNI-specific behavior--in VXLAN. The existing mechanism is su= fficient for the case we're discussing here. Just pick a MAC in managem= ent VNI for the sake of configuration simplicity.

= Dinesh

On Mon, Nov 4, 2019 at 8:30 PM, Ano= op Ghanwani <= anoop@alumni.duke.edu> wrote:
Hi Santosh,

I'm not aware of any implementa= tion that uses a multicast MAC for this.=C2=A0 The closest thing that I'= ;m aware of that helps alleviate the need for knowing the MAC of the remote= =C2=A0VTEP is what's done in open vswitch:
   bfd_config_remot<=
/b>e : bfd_dst_mac: optional string
              Set  to an Ethernet address in the form xx:x=
x:xx:xx:xx:x=
x to set
              the destination MAC to be used for transmitted BFD packets.  =
The
              default is 00:23:20:00:00:0<=
/b>1.
That OUI belongs to Nicira/VMware.=C2=A0 An IA= NA assigned unicast MAC would be the equivalent.

A= noop

On Mon, Nov 4, 2019 at 5:14 AM Santosh P K <santosh.pallagatti@gmail.co= m> wrote:
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non= -managment VNI why do we need to have multicast MAC address for backward=C2= =A0compatibility for existing implementation=C2=A0or there are any use case= s such that we can avoid learning of remote end VTEP?=C2=A0

<= /div>
Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD sessio= n is not using the=C2=A0Management = VNI,
= the destination MAC address MUST be the address
associated with the destination = VTEP.=C2=A0 If the BFD session uses
the Management VNI, it= may use any MAC address, since use of the=C2=A0
Management VNI e= nsures that these packets will never be forwarded to a VM.
The MAC address may be confi= gured, or it may be learned via
a control plane protocol. The details of how the= MAC address
to be used is obtained are outside the scope of this document."= ;

That said, for non-Management VNI, do w= e want to allow for flexibility
for an implementation to use a multicast MAC of their choosing?=C2= =A0 If so, we
should probably add = a sentence for that too.

Thanks,
Anoop<= /div>

On Sun, N= ov 3, 2019 at 7:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
Anoop, I think I at least am mis= understanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would =
> allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
--000000000000eaa2d80596a39ab0-- From nobody Tue Nov 5 18:42:44 2019 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 A68CC120274; Tue, 5 Nov 2019 17:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GYr35f_ydiqB; Tue, 5 Nov 2019 17:59:45 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 DA529120236; Tue, 5 Nov 2019 17:59:30 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id r18so288764pgu.13; Tue, 05 Nov 2019 17:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=NnxM5GeWiC6+3Z90Ooy4THesBSVzZ04q5FE1HvLrgMg=; b=lFAOr+Tr4RYnz8UfM+sR911EUBxiqoDJKhB+AQ8i3D10zFRgluKxkxr7p2eeZ5p/xr 90YNytS7NwpAQB1jgkh3RRQT68stQARpWvBc0sCjMmzpTL3AN/eXZbll0zl7lTozloY7 Ejct4DTQmnivmwf3OSbqAji5nuUF/GAveiR6pJfGPEOb+qwCstehXmcjLJsBSnIeGfmh geCBiEIucUdh+cr1Kfy6HvUSiXH70+Afs8WjWkk2rVXf437MSQDo0AnsHh+qhK/QkdOU JTFRE9k98sY9FG9Ai7kObXUo6dIubp1SbjyDKCZmFIHpVHiea46mITstkHG/4Y+m+eZh U6/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=NnxM5GeWiC6+3Z90Ooy4THesBSVzZ04q5FE1HvLrgMg=; b=U1B09phEmozkuJJwTYhPs78hHcve/SxLG1xDnXe0NVhzHHD1HK1ppzfAh62CZsok95 Ewc/LBoxEsdFOakmTv4nDN81PNUfBjuSYmcFFiL/OVaYN1sVaqdYduy3nVdYOmlR1Rfz bibQTJwTl2he7q+qDNthMlf8zNt4BNDbVPJJrrefqPCRTUfT8YYd0R9N4lNY+sbfM5gC pSUfgUWd8+2NxAL9Pb42fjg6oo+6F3pH3ZCv4AmGX+8PZhl+1q75LBu308D3M9JbVGvT OK2zZRCgr+940B98Um0EYVJXC5AJqyBsy0iSH98/Jr0RTqYzx5kh25vcX7p+ziBRSPlb /pdg== X-Gm-Message-State: APjAAAVNM9+GBJlo2WseHmTStZ0Q2wqA10ilKHtBolAOKLX6Y/WEabeN RSN+es+qCyLjQ9qlbdb3Fo0= X-Google-Smtp-Source: APXvYqy7m3yS83HovtSEQSrQdln/e/n0jrCCl285aaR4V2qk4pzhtZ7oXzUEqlFul6YbHC/j6qJvKA== X-Received: by 2002:a63:d308:: with SMTP id b8mr40123949pgg.246.1573005570146; Tue, 05 Nov 2019 17:59:30 -0800 (PST) Received: from [192.168.0.104] ([61.2.196.166]) by smtp.gmail.com with ESMTPSA id w27sm20326925pgc.20.2019.11.05.17.59.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 17:59:29 -0800 (PST) Date: Wed, 6 Nov 2019 07:29:18 +0530 From: Dinesh Dutt To: Anoop Ghanwani Cc: Greg Mirsky , Santosh P K , "Joel M. Halpern" , rtg-bfd WG , NVO3 Message-ID: <7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark> In-Reply-To: References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> <1573000145.25948.19@smtp.gmail.com> Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt X-Readdle-Message-ID: 7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5dc228fb_47432df2_7cc3" Archived-At: X-Mailman-Approved-At: Tue, 05 Nov 2019 18:42:42 -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: Wed, 06 Nov 2019 01:59:49 -0000 --5dc228fb_47432df2_7cc3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Anoop , I fear 0 may not be supported by a bunch of existing switching silicon. Dinesh On Nov 6, 2019, 7:08 AM +0530, Anoop Ghanwani , = wrote: > Greg, > > What is the resistance to getting an address assigned by IANA=3F > > (Apologies if I missed the discussion.) > > Also not sure about the value of the statement > >> > An implementation MAY use VNI number 1 as the > default value for the Management VNI. > >> > What prompted this, and if we need to recommend a value, why not 0=3F > > Thanks, > Anoop > > > On Tue, Nov 5, 2019 at 4:29 PM Dinesh Dutt wrote= : > > > I understand Greg. Maybe suggest a value, rather than recommend it=3F= Its just to reduce configuration. The key parts are to not change the ex= isting VXLAN forwarding behavior and ensure that B=46D between VTEPs does= n't leak to tenants (which typically don't exist in case of a management = VNI). > > > > > > Dinesh > > > > > > On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky wrote: > > > > Hi Dinesh, > > > > I agree that using a particular MAC over the Management VNI will = minimize configuration and thus reduce the operator's headache. I'm conce= rned that adding RECOMMENDATION to use the specific MAC address over the = Management VNI comes very close to requesting the assignment of the MAC f= or the Management VNI. > > > > > > > > Regards, > > > > Greg > > > > > > > > > On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt = wrote: > > > > > > I didn't suggest the use of a multicast MAC, any MAC would be= fine in the management VNI since there can be no tenant VMs on a managem= ent VNI. I was recommending specifying a unicast MAC. > > > > > > > > > > > > Santosh, as I mentioned to Joel, I don't want to add addition= al forwarding requirements--such as VNI-specific behavior--in VXLAN. The = existing mechanism is sufficient for the case we're discussing here. Just= pick a MAC in management VNI for the sake of configuration simplicity. > > > > > > > > > > > > Dinesh > > > > > > > > > > > > On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani wrote: > > > > > > > Hi Santosh, > > > > > > > > > > > > > > I'm not aware of any implementation that uses a multicast M= AC for this.=C2=A0 The closest thing that I'm aware of that helps allevia= te the need for knowing the MAC of the remote=C2=A0VTEP is what's done in= open vswitch: > > > > > > > http://www.openvswitch.org/support/dist-docs/vtep.5.html > > > > > > > bfd=5Fconfig=5Fremote : bfd=5Fdst=5Fmac: optional string > > > > > > > Set to an Ethernet address in the form xx:xx:= xx:xx:xx:xx to set > > > > > > > the destination MAC to be used for transmitted= B=46D packets. The > > > > > > > default is 00:23:20:00:00:01. > > > > > > > That OUI belongs to Nicira/VMware.=C2=A0 An IANA assigned u= nicast MAC would be the equivalent. > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > On Mon, Nov 4, 2019 at 5:14 AM Santosh P K wrote: > > > > > > > > > Anoop, > > > > > > > > > =C2=A0 =C2=A0Thanks for your comments. =46or non-managm= ent VNI why do we need to have multicast MAC address for backward=C2=A0co= mpatibility for existing implementation=C2=A0or there are any use cases s= uch that we can avoid learning of remote end VTEP=3F > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > Santosh P K > > > > > > > > > > > > > > > > > > > On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani wrote: > > > > > > > > > > > Hi Joel, > > > > > > > > > > > > > > > > > > > > > > In that case I would propose the following text: > > > > > > > > > > > > > > > > > > > > > > =22Destination MAC: If the B=46D session is not usi= ng the=C2=A0Management VNI, > > > > > > > > > > > the destination MAC address MUST be the address > > > > > > > > > > > associated with the destination VTEP.=C2=A0 If the = B=46D session uses > > > > > > > > > > > the Management VNI, it may use any MAC address, sin= ce use of the > > > > > > > > > > > Management VNI ensures that these packets will neve= r be forwarded to a VM. > > > > > > > > > > > The MAC address may be configured, or it may be lea= rned via > > > > > > > > > > > a control plane protocol. The details of how the MA= C address > > > > > > > > > > > to be used is obtained are outside the scope of thi= s document.=22 > > > > > > > > > > > > > > > > > > > > > > That said, for non-Management VNI, do we want to al= low for flexibility > > > > > > > > > > > for an implementation to use a multicast MAC of the= ir choosing=3F=C2=A0 If so, we > > > > > > > > > > > should probably add a sentence for that too. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern wrote: > > > > > > > > > > > > > Anoop, I think I at least am misunderstanding y= ou. > > > > > > > > > > > > > If one is using the management VNI, as I unders= tand it there is no > > > > > > > > > > > > > tenant.=C2=A0 So there are no tenant MAC addres= ses.=C2=A0 (This is one of the > > > > > > > > > > > > > reasons I like using the management VNI.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yours, > > > > > > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: > > > > > > > > > > > > > > Hi Greg, > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the case of the management VNI, are we try= ing to say that we would > > > > > > > > > > > > > > allow any MAC address other than a tenant MAC= address=3F=C2=A0 I would suggest > > > > > > > > > > > > > > some more text be added to clarify what is pe= rmitted on the management > > > > > > > > > > > > > > VLAN.=C2=A0 Assuming that we want to allow an= y MAC other than a tenant MAC, > > > > > > > > > > > > > > how does this get enforced=3F=C2=A0 In other = words, what can be done for the > > > > > > > > > > > > > > network to protect itself if a sender violate= s this=3F > > > > > > > > > > > > > > > > > > > > > > > > > > > > One possible answer is to restrict the MAC ad= dress that may be used to > > > > > > > > > > > > > > one that is owned by the VTEP or a =22agreed = on=22 multicast MAC address. > > > > > > > > > > > > > > That means the receiver only needs to validat= e for those, and just > > > > > > > > > > > > > > treats everything else as data. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, for interoperability purposes, it would= be best to specify that a > > > > > > > > > > > > > > receiver MUST be able to handle any valid MAC= address for the B=46D > > > > > > > > > > > > > > session, while a sender MAY pick any of them.= > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Hi Anoop, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0thank you for your comment= s and questions. Please find my notes > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Regards, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Greg > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0On =46ri, Nov 1, 2019 at 4= :24 PM Anoop Ghanwani > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg, > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few commen= ts. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft ha= s nits, specifically around the way the IPv6 address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4= : > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=46D packet= MUST be encapsulated -> > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B=46D packet= s MUST be encapsulated > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination = MAC: This MUST NOT be of one of tenant's MAC > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0 The destination MAC address MAY be = the address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0associated with the destination VTEP.=C2=A0 The MAC = address MAY be > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0configured, or it MAY be learned via a control plane= protocol. > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0The details of how the MAC address is obtained are o= utside the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0scope of this document. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks lik= e we have removed the option of using a well-known > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigne= d MAC.=C2=A0 If so, why is the above a MAY and not a > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST=3F=C2=A0= What else can it be=3F=C2=A0 One interpretation is that it can > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything = unicast, or multicast, as long as it's not a tenant > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 I= s that the intent=3F=C2=A0 If so, it would be better to state it > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2= =A0 Also (and this is purely editorial), I think it would > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if= the first sentence above were moved to the end of > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragrap= h. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, w= e've removed that option and have removed > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0the request to IANA. I als= o agree that =22 MAY be the address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0associated with the destin= ation VTEP=22 is not the right choice of > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0normative language. On the= other hand, MUST might be too restrictive > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0if B=46D session is using = the Management VNI. Would the following > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0update address your concer= n: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0OLD TEXT: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Destination MAC: This MUST NOT be of one of tenant's MAC > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0addresses.=C2=A0 The destination MAC address MAY be the address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0associated with the destination VTEP.=C2=A0 The MAC address MAY be= > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0configured, or it MAY be learned via a control plane protocol. > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0The details of how the MAC address is obtained are outside the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0scope of this document. > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0NEW TEXT: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Destination MAC: If the B=46D session is not using the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0Management VNI, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0the destination MAC address MUST be the address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0associated with the destination VTEP.=C2=A0 The Destination MAC > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0MUST NOT be one of the tenant's MAC addresses. > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= The MAC address MAY be configured, or it MAY be learned via > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= a control plane protocol. The details of how the MAC address > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= is obtained are outside the scope of this document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=22The inner= Ethernet frame carrying the B=46D > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Control packet- has the following format:=22 > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '= -' after packet. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that= too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On =46ri, No= v 1, 2019 at 10:53 AM Greg Mirsky > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Dear All, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= the new version includes updates resulting from the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= discussions of Joel's comments in the RtrDir review of B=46D > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= over VXLAN draft, comments from Anoop, and Dinesh. On behalf > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= of editors, thank you for your constructive comments and for > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= sharing your expertise, all much appreciated. > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= I hope we've addressed all your comments, and the draft can > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= proceed further. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Regards, > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Greg > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ---------- =46orwarded message --------- > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =46rom: > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Date: =46ri, Nov 1, 2019 at 10:45 AM > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Subject: New Version Notification for > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= draft-ietf-bfd-vxlan-08..txt > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= To: Gregory Mirsky > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= >, Mallik Mudigonda > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= >, Sudarsan > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Paragiri > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= >, Vengada Prasad Govindan > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= >, Santosh > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Pallagatti > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= A new version of I-D, draft-ietf-bfd-vxlan-08.txt > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= has been successfully submitted by Greg Mirsky and posted to the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= IET=46 repository. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008 > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B=46D for VXLAN > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Document date:=C2=A0 2019-11-01 > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11 > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= URL: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Htmlized: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Diff: https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-bfd-vxlan-08 > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Abstract: > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0This document describes the use of the Bidirectional > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =46orwarding > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Detection (B=46D) protocol in point-to-point Virtual > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= eXtensible Local > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Please note that it may take a couple of minutes from the > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= time of submission > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= until the htmlized version and diff are available at > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= tools.ietf.org . > > > > > > > > > > > > > > > > > > > > > > > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= The IET=46 Secretariat > > > > > > > > > > > > > > > > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F > > > > > > > > > > > nvo3 mailing list > > > > > > > > > > > nvo3=40ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/nvo3 --5dc228fb_47432df2_7cc3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Anoop
,

I fear 0 may not be supported by a bunch of existing switching silicon.
Dinesh
On Nov 6, 2019, 7:08 AM +0530, Anoo= p Ghanwani <anoop=40alumni.duke.edu>, wrote:
Greg,

What is the resistance to getting an address assigned by IANA=3F

(Apologies if I missed the discussion.)

Also not sure about the value of the statement&=23160;
>>
An implemen=
tation MAY use VNI number 1 as the
   default value for the Management VNI.
>>
What prompted this, and if we need to recommend a value, why not 0=3F=

Thanks,
Anoop

On Tue, Nov 5, 2019 at 4:= 29 PM Dinesh Dutt <didutt=40= gmail.com> wrote:
I understand Greg. Maybe suggest a value, rather than recommend it=3F= Its just to reduce configuration. The key parts are to not change the ex= isting VXLAN forwarding behavior and ensure that B=46D between VTEPs does= n't leak to tenants (which typically don't exist in case of a management = VNI).&=23160;

Dinesh

On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky <gregimirsky=40gmail.com> wrote:
Hi Dinesh,
I agree that using a particular MAC over the Management VNI will min= imize configuration and thus reduce the operator's headache. I'm concerne= d that adding RECOMMENDATION to use the specific MAC address over the Man= agement VNI comes very close to requesting the assignment of the MAC for = the Management VNI.

Regards,
Greg

On Mon, Nov 4, 2019 at 9:= 36 AM Dinesh Dutt <didutt=40gmail.com> wrote:
I didn't suggest the use of a multicast MAC, any MAC would be fine i= n the management VNI since there can be no tenant VMs on a management VNI= . I was recommending specifying a unicast MAC.

Santosh, as I mentioned to Joel, I don't want to add additional forw= arding requirements--such as VNI-specific behavior--in VXLAN. The existin= g mechanism is sufficient for the case we're discussing here. Just pick a= MAC in management VNI for the sake of configuration simplicity.

Dinesh

On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop=40alumni.duke.edu<= /a>> wrote:
Hi Santosh,

I'm not aware of any implementation that uses a multicast MAC for th= is.&=23160; The closest thing that I'm aware of that helps alleviate the = need for knowing the MAC of the remote&=23160;VTEP is what's done in open= vswitch:
 
   bfd=5F=
config=5Fremote : bfd=5F=
dst=5Fmac: optional =
string
              Set  to an Ethernet address in the form xx:xx:xx:xx:xx:xx to set
              the destination MAC to be used for transmitted B=46D packet=
s.  The
              default is 00:23:=
20:00:00:<=
b>01.
That OUI belongs to Nicira/VMware.&=23160; An IANA assigned unicast = MAC would be the equivalent.

Anoop

On Mon, Nov 4, 2019 at 5:= 14 AM Santosh P K <santosh.pallagatti=40gmail.com> wrote:
Anoop,
&=23160; &=23160;Thanks for your comments. =46or non-managment VNI w= hy do we need to have multicast MAC address for backward&=23160;compatibi= lity for existing implementation&=23160;or there are any use cases such t= hat we can avoid learning of remote end VTEP=3F&=23160;

Thanks
Santosh P K&=23160;

On Mon, Nov 4, 2019 at 10= :41 AM Anoop Ghanwani <anoop=40alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

=22Destination MAC: If the B=46= D session is not using the&=23= 160;Management VNI,
the destination MAC address MUST be = the address
associated with the destination VTEP= .&=23160; If the B=46D session uses
the Management VNI, it may use any MAC address, since use of the&=23= 160;
Management VNI ensures that these packets will never be forwarded to= a VM.
The MAC address may be configured, o= r it may be learned via
a control plane protocol. The detail= s of how the MAC address
to be used is obtained are outside t= he scope of this document.=22

That said, for non-Management V= NI, do we want to allow for flexibility
for an implementation to use a = multicast MAC of their choosing=3F&=23160; If so, we
should probably add a sentence for tha= t too.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:= 52 PM Joel M. Halpern <jmh=40joelhalpern.com> wrote:
Anoop, I th= ink I at least am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.&=23160; So there are no tenant MAC addresses.&=23160; (This is on= e of the
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we woul= d
> allow any MAC address other than a tenant MAC address=3F&=23160; I w= ould suggest
> some more text be added to clarify what is permitted on the manageme= nt
> VLAN.&=23160; Assuming that we want to allow any MAC other than a te= nant MAC,
> how does this get enforced=3F&=23160; In other words, what can be do= ne for the
> network to protect itself if a sender violates this=3F
>
> One possible answer is to restrict the MAC address that may be used = to
> one that is owned by the VTEP or a =22agreed on=22 multicast MAC add= ress.&=23160;
> That means the receiver only needs to validate for those, and just > treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify tha= t a
> receiver MUST be able to handle any valid MAC address for the B=46D<= br /> > session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky=40gmail.com=
> <mailto:gregimirsky=40gmail.com>> wrote:
>
>&=23160; &=23160; &=23160;Hi Anoop,
>&=23160; &=23160; &=23160;thank you for your comments and questions. = Please find my notes
>&=23160; &=23160; &=23160;in-line tagged GIM>>.
>
>&=23160; &=23160; &=23160;Regards,
>&=23160; &=23160; &=23160;Greg
>
>&=23160; &=23160; &=23160;On =46ri, Nov 1, 2019 at 4:24 PM Anoop Ghan= wani <anoop=40alumni.duke..edu
>&=23160; &=23160; &=23160;<mailto:anoop=40alumni.duke.edu>>= ; wrote:
>
>&=23160; &=23160; &=23160; &=23160; &=23160;Hi Greg,
>
>&=23160; &=23160; &=23160; &=23160; &=23160;A few comments.
>
>&=23160; &=23160; &=23160; &=23160; &=23160;The draft has nits, speci= fically around the way the IPv6 address
>&=23160; &=23160; &=23160; &=23160; &=23160;is written.
>
>&=23160; &=23160; &=23160; &=23160; &=23160;In section 4:
>
>&=23160; &=23160; &=23160; &=23160; &=23160;B=46D packet MUST be enca= psulated ->
>
>&=23160; &=23160; &=23160; &=23160; &=23160;B=46D packets MUST be enc= apsulated
>
>&=23160; &=23160; &=23160;GIM>> Thanks, will do.
>
>
>&=23160; &=23160; &=23160; &=23160; &=23160; >>>
>
>&=23160; &=23160; &=23160; &=23160; &=23160;Destination MAC: This MUS= T NOT be of one of tenant's MAC
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160;addresses.&=23160; The destination MAC address MAY be= the address
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160;associated with the destination VTEP.&=23160; The MAC= address MAY be
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160;configured, or it MAY be learned via a control plane = protocol.
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160;The details of how the MAC address is obtained are ou= tside the
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160; &=23160;scope of this document.
>
>&=23160; &=23160; &=23160; &=23160; &=23160; >>>
>&=23160; &=23160; &=23160; &=23160; &=23160;It looks like we have rem= oved the option of using a well-known
>&=23160; &=23160; &=23160; &=23160; &=23160;IANA assigned MAC.&=23160= ; If so, why is the above a MAY and not a
>&=23160; &=23160; &=23160; &=23160; &=23160;MUST=3F&=23160; What else= can it be=3F&=23160; One interpretation is that it can
>&=23160; &=23160; &=23160; &=23160; &=23160;be anything unicast, or m= ulticast, as long as it's not a tenant
>&=23160; &=23160; &=23160; &=23160; &=23160;MAC.&=23160; Is that the = intent=3F&=23160; If so, it would be better to state it
>&=23160; &=23160; &=23160; &=23160; &=23160;that way.&=23160; Also (a= nd this is purely editorial), I think it would
>&=23160; &=23160; &=23160; &=23160; &=23160;be better if the first se= ntence above were moved to the end of
>&=23160; &=23160; &=23160; &=23160; &=23160;the paragraph.
>
>&=23160; &=23160; &=23160;GIM>> Yes, you're right, we've remove= d that option and have removed
>&=23160; &=23160; &=23160;the request to IANA. I also agree that =22 = MAY be the address
>&=23160; &=23160; &=23160;associated with the destination VTEP=22 is = not the right choice of
>&=23160; &=23160; &=23160;normative language. On the other hand, MUST= might be too restrictive
>&=23160; &=23160; &=23160;if B=46D session is using the Management VN= I. Would the following
>&=23160; &=23160; &=23160;update address your concern:
>&=23160; &=23160; &=23160;OLD TEXT:
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;Destination MAC: This MUST NOT be of one of tenant's MAC
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;addresses.&=23160; The destination MAC address MAY be the address
= >&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;associated with the destination VTEP.&=23160; The MAC address MAY be >&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;configured, or it MAY be learned via a control plane protocol.
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;The details of how the MAC address is obtained are outside the
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;scope of this document.
>&=23160; &=23160; &=23160;NEW TEXT:
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;Destination MAC: If the B=46D session is not using the
>&=23160; &=23160; &=23160;Management VNI,
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;the destination MAC address MUST be the address
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;associated with the destination VTEP.&=23160; The Destination MAC
= >&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0;MUST NOT be one of the tenant's MAC addresses.
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; The MA= C address MAY be configured, or it MAY be learned via
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; a cont= rol plane protocol. The details of how the MAC address
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; is obt= ained are outside the scope of this document.
>
>
>&=23160; &=23160; &=23160; &=23160; &=23160;=22The inner Ethernet fra= me carrying the B=46D
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Control= packet- has the following format:=22
>
>&=23160; &=23160; &=23160; &=23160; &=23160;Extraneous '-' after pack= et.
>
>&=23160; &=23160; &=23160;GIM>> Thanks, will do that too.
= >
>
>&=23160; &=23160; &=23160; &=23160; &=23160;Thanks,
>&=23160; &=23160; &=23160; &=23160; &=23160;Anoop
>
>&=23160; &=23160; &=23160; &=23160; &=23160;On =46ri, Nov 1, 2019 at = 10:53 AM Greg Mirsky
>&=23160; &=23160; &=23160; &=23160; &=23160;<gregimirsky=40gmail.com= <mailto:gregimirsky=40gmail.com>> wrote:
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Dear Al= l,
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;the new= version includes updates resulting from the
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;discuss= ions of Joel's comments in the RtrDir review of B=46D
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;over VX= LAN draft, comments from Anoop, and Dinesh. On behalf
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;of edit= ors, thank you for your constructive comments and for
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;sharing= your expertise, all much appreciated.
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;I hope = we've addressed all your comments, and the draft can
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;proceed= further.
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Regards= ,
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Greg >
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;-------= --- =46orwarded message ---------
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;=46rom:= <internet-drafts=40ietf.org
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<mai= lto:internet-drafts=40ietf.org>>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Date: =46= ri, Nov 1, 2019 at 10:45 AM
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Subject= : New Version Notification for
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;draft-i= etf-bfd-vxlan-08..txt
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;To: Gre= gory Mirsky <gregimirsky=40gmail.com
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<mai= lto:gregimirsky=40gmail.com>>, Mallik Mudigonda
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<mmudigon= =40cisco.com <mailto:mmudigon=40cisco.com>>, Sudarsan
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Paragir= i <sudarsan.225=40gmail.com
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<mai= lto:sudarsan.225=40gmail.com>>, Vengada Prasad Govindan
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<venggovi= =40cisco.com <mailto:venggovi=40cisco.com>>, Santosh
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Pallaga= tti <santosh.pallagatti=40gmail.com
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;<mai= lto:santosh.pallagatti=40gmail.com>>
>
>
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;A new v= ersion of I-D, draft-ietf-bfd-vxlan-08.txt
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;has bee= n successfully submitted by Greg Mirsky and posted to the
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;IET=46 = repository.
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Name:&=23= 160; &=23160; &=23160; &=23160; &=23160; &=23160;draft-ietf-bfd-vxlan
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Revisio= n:&=23160; &=23160; &=23160; &=23160;08
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Title:&= =23160; &=23160; &=23160; &=23160; &=23160; B=46D for VXLAN
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Documen= t date:&=23160; 2019-11-01
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Group:&= =23160; &=23160; &=23160; &=23160; &=23160; bfd
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Pages:&= =23160; &=23160; &=23160; &=23160; &=23160; 11
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;URL: >&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;https://www.ietf.org/inte= rnet-drafts/draft-ietf-bfd-vxlan-08.txt
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Status:= https://datatracker.ietf.or= g/doc/draft-ietf-bfd-vxlan/
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Htmlize= d: https://tools.ietf.org/html/= draft-ietf-bfd-vxlan-08
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Htmlize= d:
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;https://datatracker.ietf.org/doc= /html/draft-ietf-bfd-vxlan
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Diff: <= a href=3D=22https://www.ietf.org/rfcdiff=3Furl2=3Ddraft-ietf-bfd-vxlan-08= =22 rel=3D=22noreferrer=22 target=3D=22=5Fblank=22>https://www.ietf.org/r= fcdiff=3Furl2=3Ddraft-ietf-bfd-vxlan-08
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Abstrac= t:
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160;This document describes the use of the Bidirectional
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;=46orwa= rding
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160;Detection (B=46D) protocol in point-to-point Virtual
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;eXtensi= ble Local
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=2316= 0; &=23160;Area Network (VXLAN) tunnels forming up an overlay network. >
>
>
>
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;Please = note that it may take a couple of minutes from the
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;time of= submission
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;until t= he htmlized version and diff are available at
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;tools.ietf.org <http://tools.ietf.org>. >
>&=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;The IET= =46 Secretariat
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
nvo3 mailing list
nvo3=40iet= f.org
https://www.ietf.org/mailman/listinfo/nv= o3
--5dc228fb_47432df2_7cc3-- From nobody Tue Nov 5 21:52:17 2019 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 42A161201EA; Tue, 5 Nov 2019 21:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 bcN3_73jzn_z; Tue, 5 Nov 2019 21:52:11 -0800 (PST) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 EBDC512002E; Tue, 5 Nov 2019 21:52:10 -0800 (PST) Received: by mail-ua1-f53.google.com with SMTP id l38so6953198uad.4; Tue, 05 Nov 2019 21:52:10 -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=1Bp0EyY68XjnnWxFTrmeDtBXhViD+UnB6VjAXnNFPyg=; b=F0Rhf6MuzdRhHoOWc+5xV4T7MlnGT6d2NXQrWyJwMdjRJP7hhfYUVcQXPMbIhXrbOL YW2ZnGWuF900tyqVlOZtEXLeBiAeeWXNWu/UHs+S9jvIw4hf1mEyBcINnsyShmijyrdH hp8QvXlSHmVJsaT8k1twUtukfcoFkkpgpPzEuM2hRzXlj93M3OQOyVkdsmzuRY+cxDnm nJxi6lEmEkZQmxSDKZ4t1G3Nr/h5Ltv8+EppSYZPFTvVtgmgSMFxI6aae/aZSHHPB32N Iz09cj1Z2J37HlLhC9JhBdwaO34jZKd8Rp2wooLbpdsEoZfi5YqQVjf0vVcB2GFcZIcs 6+Pw== X-Gm-Message-State: APjAAAXnROLcq1Ycp9z6T0WUkcRYcmdzR06OxamTftPh/4q8ccHihKSZ WSl6fryEpCkCl6Kpq6E4hbNk1OC9Z+vQjlv0lKE= X-Google-Smtp-Source: APXvYqwSnbPPv3VzfpEJZ7TqHCRJyhi4wE9TMQqQ43gOgiPtNDrEhjHkH3nASnMnabZrxmYVHPEDVC9PKdGrx0mc0i4= X-Received: by 2002:ab0:4e2d:: with SMTP id g45mr449278uah.29.1573019529816; Tue, 05 Nov 2019 21:52:09 -0800 (PST) MIME-Version: 1.0 References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <1572888977.25948.5@smtp.gmail.com> <1573000145.25948.19@smtp.gmail.com> <7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark> In-Reply-To: <7e9b8c35-bf9b-4de7-ae30-a2c74b7fb834@Spark> From: Anoop Ghanwani Date: Tue, 5 Nov 2019 21:51:58 -0800 Message-ID: Subject: Re: [nvo3] New Version Notification for draft-ietf-bfd-vxlan-08.txt To: Dinesh Dutt Cc: Greg Mirsky , Santosh P K , "Joel M. Halpern" , rtg-bfd WG , NVO3 Content-Type: multipart/alternative; boundary="0000000000004cae210596a7261a" Archived-At: 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: Wed, 06 Nov 2019 05:52:14 -0000 --0000000000004cae210596a7261a Content-Type: text/plain; charset="UTF-8" Hi Dinesh, OK, assuming you are aware of some such silicon. I know that all the implementations I have dealt with support VNI 0 for BFD. But my concern is with how the statement is worded. As written, it basically conveys nothing because while it MAY be 1, it MAY be any other number too. I suspect what we want to say is that "any VNI that is not provisioned for tenant systems may be used for the management VNI and a default value of 1 is RECOMMENDED." Anoop On Tue, Nov 5, 2019 at 5:59 PM Dinesh Dutt wrote: > Anoop > , > > I fear 0 may not be supported by a bunch of existing switching silicon. > > Dinesh > On Nov 6, 2019, 7:08 AM +0530, Anoop Ghanwani , > wrote: > > Greg, > > What is the resistance to getting an address assigned by IANA? > > (Apologies if I missed the discussion.) > > Also not sure about the value of the statement > >> > > An implementation MAY use VNI number 1 as the > default value for the Management VNI. > > >> > What prompted this, and if we need to recommend a value, why not 0? > > Thanks, > Anoop > > On Tue, Nov 5, 2019 at 4:29 PM Dinesh Dutt wrote: > >> I understand Greg. Maybe suggest a value, rather than recommend it? Its >> just to reduce configuration. The key parts are to not change the existing >> VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't leak to >> tenants (which typically don't exist in case of a management VNI). >> >> Dinesh >> >> On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky >> wrote: >> >> Hi Dinesh, >> I agree that using a particular MAC over the Management VNI will minimize >> configuration and thus reduce the operator's headache. I'm concerned that >> adding RECOMMENDATION to use the specific MAC address over the Management >> VNI comes very close to requesting the assignment of the MAC for the >> Management VNI. >> >> Regards, >> Greg >> >> On Mon, Nov 4, 2019 at 9:36 AM Dinesh Dutt wrote: >> >>> I didn't suggest the use of a multicast MAC, any MAC would be fine in >>> the management VNI since there can be no tenant VMs on a management VNI. I >>> was recommending specifying a unicast MAC. >>> >>> Santosh, as I mentioned to Joel, I don't want to add additional >>> forwarding requirements--such as VNI-specific behavior--in VXLAN. The >>> existing mechanism is sufficient for the case we're discussing here. Just >>> pick a MAC in management VNI for the sake of configuration simplicity. >>> >>> Dinesh >>> >>> On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani >>> wrote: >>> >>> Hi Santosh, >>> >>> I'm not aware of any implementation that uses a multicast MAC for this. >>> The closest thing that I'm aware of that helps alleviate the need for >>> knowing the MAC of the remote VTEP is what's done in open vswitch: >>> http://www.openvswitch.org/support/dist-docs/vtep.5.html >>> >>> *b**f**d**_**c**o**n**f**i**g**_**r**e**m**o**t**e* *:* *b**f**d**_**d**s**t**_**m**a**c*: optional string >>> Set to an Ethernet address in the form *x**x*:*x**x*:*x**x*:*x**x*:*x**x*:*x**x* to set >>> the destination MAC to be used for transmitted BFD packets. The >>> default is *0**0**:**2**3**:**2**0**:**0**0**:**0**0**:**0**1*. >>> >>> That OUI belongs to Nicira/VMware. An IANA assigned unicast MAC would >>> be the equivalent. >>> >>> Anoop >>> >>> On Mon, Nov 4, 2019 at 5:14 AM Santosh P K >>> wrote: >>> >>>> Anoop, >>>> Thanks for your comments. For non-managment VNI why do we need to >>>> have multicast MAC address for backward compatibility for existing >>>> implementation or there are any use cases such that we can avoid learning >>>> of remote end VTEP? >>>> >>>> Thanks >>>> Santosh P K >>>> >>>> On Mon, Nov 4, 2019 at 10:41 AM Anoop Ghanwani >>>> wrote: >>>> >>>>> Hi Joel, >>>>> >>>>> In that case I would propose the following text: >>>>> >>>>> "Destination MAC: If the BFD session is not using the Management VNI, >>>>> the destination MAC address MUST be the address >>>>> associated with the destination VTEP. If the BFD session uses >>>>> the Management VNI, it may use any MAC address, since use of the >>>>> Management VNI ensures that these packets will never be forwarded to a >>>>> VM. >>>>> The MAC address may be configured, or it may be learned via >>>>> a control plane protocol. The details of how the MAC address >>>>> to be used is obtained are outside the scope of this document." >>>>> >>>>> That said, for non-Management VNI, do we want to allow for flexibility >>>>> for an implementation to use a multicast MAC of their choosing? If >>>>> so, we >>>>> should probably add a sentence for that too. >>>>> >>>>> Thanks, >>>>> Anoop >>>>> >>>>> >>>>> On Sun, Nov 3, 2019 at 7:52 PM Joel M. Halpern >>>>> wrote: >>>>> >>>>>> Anoop, I think I at least am misunderstanding you. >>>>>> If one is using the management VNI, as I understand it there is no >>>>>> tenant. So there are no tenant MAC addresses. (This is one of the >>>>>> reasons I like using the management VNI.) >>>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 11/3/2019 10:32 PM, Anoop Ghanwani wrote: >>>>>> > Hi Greg, >>>>>> > >>>>>> > In the case of the management VNI, are we trying to say that we >>>>>> would >>>>>> > allow any MAC address other than a tenant MAC address? I would >>>>>> suggest >>>>>> > some more text be added to clarify what is permitted on the >>>>>> management >>>>>> > VLAN. Assuming that we want to allow any MAC other than a tenant >>>>>> MAC, >>>>>> > how does this get enforced? In other words, what can be done for >>>>>> the >>>>>> > network to protect itself if a sender violates this? >>>>>> > >>>>>> > One possible answer is to restrict the MAC address that may be used >>>>>> to >>>>>> > one that is owned by the VTEP or a "agreed on" multicast MAC >>>>>> address. >>>>>> > That means the receiver only needs to validate for those, and just >>>>>> > treats everything else as data. >>>>>> > >>>>>> > Also, for interoperability purposes, it would be best to specify >>>>>> that a >>>>>> > receiver MUST be able to handle any valid MAC address for the BFD >>>>>> > session, while a sender MAY pick any of them. >>>>>> > >>>>>> > Thanks, >>>>>> > Anoop >>>>>> > >>>>>> > On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky >>>>> > > wrote: >>>>>> > >>>>>> > Hi Anoop, >>>>>> > thank you for your comments and questions. Please find my notes >>>>>> > in-line tagged GIM>>. >>>>>> > >>>>>> > Regards, >>>>>> > Greg >>>>>> > >>>>>> > On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani < >>>>>> anoop@alumni.duke..edu >>>>>> > > wrote: >>>>>> > >>>>>> > Hi Greg, >>>>>> > >>>>>> > A few comments. >>>>>> > >>>>>> > The draft has nits, specifically around the way the IPv6 >>>>>> address >>>>>> > is written. >>>>>> > >>>>>> > In section 4: >>>>>> > >>>>>> > BFD packet MUST be encapsulated -> >>>>>> > >>>>>> > BFD packets MUST be encapsulated >>>>>> > >>>>>> > GIM>> Thanks, will do. >>>>>> > >>>>>> > >>>>>> > >>> >>>>>> > >>>>>> > Destination MAC: This MUST NOT be of one of tenant's MAC >>>>>> > addresses. The destination MAC address MAY be >>>>>> the address >>>>>> > associated with the destination VTEP. The MAC >>>>>> address MAY be >>>>>> > configured, or it MAY be learned via a control >>>>>> plane protocol. >>>>>> > The details of how the MAC address is obtained >>>>>> are outside the >>>>>> > scope of this document. >>>>>> > >>>>>> > >>> >>>>>> > It looks like we have removed the option of using a >>>>>> well-known >>>>>> > IANA assigned MAC. If so, why is the above a MAY and not a >>>>>> > MUST? What else can it be? One interpretation is that it >>>>>> can >>>>>> > be anything unicast, or multicast, as long as it's not a >>>>>> tenant >>>>>> > MAC. Is that the intent? If so, it would be better to >>>>>> state it >>>>>> > that way. Also (and this is purely editorial), I think it >>>>>> would >>>>>> > be better if the first sentence above were moved to the end >>>>>> of >>>>>> > the paragraph. >>>>>> > >>>>>> > GIM>> Yes, you're right, we've removed that option and have >>>>>> removed >>>>>> > the request to IANA. I also agree that " MAY be the address >>>>>> > associated with the destination VTEP" is not the right choice of >>>>>> > normative language. On the other hand, MUST might be too >>>>>> restrictive >>>>>> > if BFD session is using the Management VNI. Would the following >>>>>> > update address your concern: >>>>>> > OLD TEXT: >>>>>> > Destination MAC: This MUST NOT be of one of tenant's >>>>>> MAC >>>>>> > addresses. The destination MAC address MAY be the >>>>>> address >>>>>> > associated with the destination VTEP. The MAC >>>>>> address MAY be >>>>>> > configured, or it MAY be learned via a control plane >>>>>> protocol. >>>>>> > The details of how the MAC address is obtained are >>>>>> outside the >>>>>> > scope of this document. >>>>>> > NEW TEXT: >>>>>> > Destination MAC: If the BFD session is not using the >>>>>> > Management VNI, >>>>>> > the destination MAC address MUST be the address >>>>>> > associated with the destination VTEP. The >>>>>> Destination MAC >>>>>> > MUST NOT be one of the tenant's MAC addresses. >>>>>> > The MAC address MAY be configured, or it MAY be >>>>>> learned via >>>>>> > a control plane protocol. The details of how the MAC >>>>>> address >>>>>> > is obtained are outside the scope of this document. >>>>>> > >>>>>> > >>>>>> > "The inner Ethernet frame carrying the BFD >>>>>> > Control packet- has the following format:" >>>>>> > >>>>>> > Extraneous '-' after packet. >>>>>> > >>>>>> > GIM>> Thanks, will do that too. >>>>>> > >>>>>> > >>>>>> > Thanks, >>>>>> > Anoop >>>>>> > >>>>>> > On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky >>>>>> > > >>>>>> wrote: >>>>>> > >>>>>> > Dear All, >>>>>> > the new version includes updates resulting from the >>>>>> > discussions of Joel's comments in the RtrDir review of >>>>>> BFD >>>>>> > over VXLAN draft, comments from Anoop, and Dinesh. On >>>>>> behalf >>>>>> > of editors, thank you for your constructive comments >>>>>> and for >>>>>> > sharing your expertise, all much appreciated. >>>>>> > I hope we've addressed all your comments, and the draft >>>>>> can >>>>>> > proceed further. >>>>>> > >>>>>> > Regards, >>>>>> > Greg >>>>>> > >>>>>> > ---------- Forwarded message --------- >>>>>> > From: >>>>> > > >>>>>> > Date: Fri, Nov 1, 2019 at 10:45 AM >>>>>> > Subject: New Version Notification for >>>>>> > draft-ietf-bfd-vxlan-08..txt >>>>>> > To: Gregory Mirsky >>>>> > >, Mallik Mudigonda >>>>>> > >, >>>>>> Sudarsan >>>>>> > Paragiri >>>>> > >, Vengada Prasad >>>>>> Govindan >>>>>> > >, >>>>>> Santosh >>>>>> > Pallagatti >>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>>> > A new version of I-D, draft-ietf-bfd-vxlan-08.txt >>>>>> > has been successfully submitted by Greg Mirsky and >>>>>> posted to the >>>>>> > IETF repository. >>>>>> > >>>>>> > Name: draft-ietf-bfd-vxlan >>>>>> > Revision: 08 >>>>>> > Title: BFD for VXLAN >>>>>> > Document date: 2019-11-01 >>>>>> > Group: bfd >>>>>> > Pages: 11 >>>>>> > URL: >>>>>> > >>>>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt >>>>>> > Status: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >>>>>> > Htmlized: >>>>>> https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08 >>>>>> > Htmlized: >>>>>> > >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan >>>>>> > Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08 >>>>>> > >>>>>> > Abstract: >>>>>> > This document describes the use of the Bidirectional >>>>>> > Forwarding >>>>>> > Detection (BFD) protocol in point-to-point Virtual >>>>>> > eXtensible Local >>>>>> > Area Network (VXLAN) tunnels forming up an overlay >>>>>> network. >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > 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 < >>>>>> http://tools.ietf.org>. >>>>>> > >>>>>> > The IETF Secretariat >>>>>> > >>>>>> >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>> >>>> --0000000000004cae210596a7261a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dinesh,

OK, assuming you are aware o= f some such silicon.=C2=A0 I know that all the implementations I have dealt= with support VNI 0 for BFD.

But my concern is wit= h how the statement is worded.=C2=A0 As written, it basically conveys nothi= ng because while it MAY be 1, it MAY be any other number too.=C2=A0 I suspe= ct what we want to say is that "any VNI that is not provisioned for te= nant systems may be used for the management VNI and a default value of 1 is= RECOMMENDED."

Anoop

 --0000000000004cae210596a7261a-- From nobody Wed Nov 6 08:46:45 2019 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 0EF531200B9 for ; Wed, 6 Nov 2019 08:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 ji6y7-N2vo50 for ; Wed, 6 Nov 2019 08:46:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAD120089 for ; Wed, 6 Nov 2019 08:46:42 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 8C4241E2F2; Wed, 6 Nov 2019 11:50:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: draft-ietf-bfd-large-packets-02 From: Jeffrey Haas In-Reply-To: Date: Wed, 6 Nov 2019 11:46:41 -0500 Cc: "rtg-bfd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191101155244.GA30539@pfrc.org> To: "Les Ginsberg (ginsberg)" X-Mailer: Apple Mail (2.3601.0.10) Archived-At: 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: Wed, 06 Nov 2019 16:46:44 -0000 Les, > On Nov 5, 2019, at 12:55 AM, Les Ginsberg (ginsberg) = wrote: >=20 > Jeff/Albert - >=20 > Thanx for the updated version. This addresses my concerns. >=20 > A couple of modest comments. >=20 > 1)Section 3.4 >=20 > s/that balacing/that balancing Queued for next rev. > 2)Regarding S-BFD (Section 3.5) >=20 > It would seem difficult to support (for a given discriminator) some = sessions using large packets and some not. I can think of a few = options: >=20 > a)Passive end uses large packets only if the Active end does. This = assumes MTU is the same in both directions. Asymmetric MTUs are not only possible, but likely in S-BFD scenarios. = But it's a valid point. > b)A separate discriminator is used for large packet sessions > c)Use of large packets is always on (or always off) on the passive = side >=20 > Probably there are other choices. >=20 > What did you have in mind? I think adding some guidance in that regard = might be useful. My personal thought on the matter had been roughly: - By default, respond with the same size IP encapsulation as you = receive. - While S-BFD permits largely non-configured responses to Initiators, = there's likely to be SOME configuration present. If necessary, specific = configuration can be given to cover size of packets to respond to. = (Roughly aligning with the ACLs used to manage whom can initiate S-BFD = in the first place.) One way to interpret your questions is that there should be some implied = configuration for BFD for Large Packets, not only on the sending side, = but on the receiver. For the receiver, something roughly like "bfd.PaddedPduReceiveMaxSize" = as a parameter. Possibly acting also as a way to enable the feature or = not. For an S-BFD reflector, perhaps parameters to control beyond the receive = max size whether it responds with the same size as the iP encapsulation, = and whether there's a cap for such a response. Does the above address your concerns? -- Jeff From nobody Sat Nov 9 08:30:29 2019 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 9933E12008C for ; Sat, 9 Nov 2019 08:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cf7iIMCF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BXIANSxK 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 2ES_wMsLS5Gd for ; Sat, 9 Nov 2019 08:30:25 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877BD120073 for ; Sat, 9 Nov 2019 08:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4360; q=dns/txt; s=iport; t=1573317025; x=1574526625; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=cf7iIMCFX+TQrjbcZiYszshO6xXLS/0/rI0VO2JF6HvQokUxLxKH23Ej zlvNfkqCtkTnZbyqry8JefDfxSoybpU4RmlpSrmVcw/lRkxrd5kUpHGf5 rPRMZD9vOM5jxCiGUyFSu3HEyHhpRLJzBnkkXDOMGVI4NVsUhiNuRcFHz s=; IronPort-PHdr: =?us-ascii?q?9a23=3As2NSjhD7zWF8XOmrzrAcUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABn6cZd/4wNJK1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYFKUAWBRCAECyqEKYNGA4prgl6?= =?us-ascii?q?YAIJSA1QJAQEBDAEBLQIBAYRAAheDeSQ3Bg4CAwEDAgMCAQEEAQEBAgEFBG2?= =?us-ascii?q?FNwyFUQEBAQQSEREMAQE3AQsEAgEGAg4DBAEBAQICJgICAjAVCAgCBA4FCBq?= =?us-ascii?q?FRwMuAY9lkGMCgTiIYHWBMoJ+AQEFhQ4YghcJgQ4oAYwTGIFAP4EQR4JMPoR?= =?us-ascii?q?HJIJqMoIskAyeCAqCJZVfmXmoPQIEAgQFAg4BAQWBaCOBWHAVgydQERSQNgw?= =?us-ascii?q?Xg1CKUgF0gSiQPgEB?= X-IronPort-AV: E=Sophos;i="5.68,286,1569283200"; d="scan'208";a="376314208" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2019 16:30:13 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA9GUDwH009643 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Nov 2019 16:30:13 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 10:30:12 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 11:30:11 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 9 Nov 2019 10:30:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QdNtbcOtmtLHnRgnYoik5mBcReQGuGFplbJAAPx3TuHffwgkzjN8hH6jeVaoG8fpxgcOTmbrK7+rL0zmI0Bs8JSq1dhxZW30BNourd5qcsdymhhzM84DA7Gpzc1LMVej/BPDGNSHLqCF1y6rvDhRbffOMKTJdTTtcpalwkkRT541SzxTTFR8Xui53cgohBuW9DaTe0ZthZVkt7UZExl/O6EiJGCQP4U7IcM1RS2q0dJnOSLdeKCUIOU0MjY2F5yYnyUnkxPfOIRLGc0ya6L1k203b+CVPpyjRcZrU4z9a8o98xA4bkL/0LFw09uWS1s6XuSNDDo5t91Bd/pRlNip/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=ClzLRF05H+026wothvCdDWyzUYdNC1R/UtVy64tNUPkXmbWZnqgqGav6AVjQmPnaeu0H8AJebKyRYvxWc9RRR+gxm5ibgKYrDLsOoA4AOjUk2JdYzzH46H2fEI2y1KeYX1/Tc9rmG0RmJazc2KjWDzwQSRaA3IqorjXXBvN3CmkfV7gRNz1m9FjweC6iz7PuMJghR4lT4pOjmqNuMeh+jkrMh1qsPTX3bR2rULdcQ07AMn/mmCwJX84JuSH8CdL3O8tOsGTWS119fkjfvvP4xycH8EvwKQeltYpoNih/XU2fyT4jZeqK8+A2BzIO+tKWAd97n9vq7UiX2ba5KxvDMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=50SKv7vBi6H+BYUiJC1/QkDKPi6R03BliqAsAMVjsSI=; b=BXIANSxK5YTWoEr6kBpkGUYiI3YbRFaoVx5WeZUHmd2MCMg7eDour0WAHrahdeoTOcR60xl5nROsU0aCOfC15LmCDGtMr1a/1MdyCI+GmRDliRHrSsbQHoqNGXM5udr5yFS5KFlCbO2d9kcVhYmRgF6SiysC37jLCkE+G+HlJVQ= Received: from MWHPR11MB1341.namprd11.prod.outlook.com (10.169.237.144) by MWHPR11MB1951.namprd11.prod.outlook.com (10.175.52.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Sat, 9 Nov 2019 16:30:09 +0000 Received: from MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::1c7d:aa6e:14ad:11ce]) by MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::1c7d:aa6e:14ad:11ce%8]) with mapi id 15.20.2430.023; Sat, 9 Nov 2019 16:30:09 +0000 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas CC: "rtg-bfd@ietf.org" Subject: RE: draft-ietf-bfd-large-packets-02 Thread-Topic: draft-ietf-bfd-large-packets-02 Thread-Index: AQHVkMv1cle+Xn0mwk2I6saLmxQhfqd8F41ggAJKYoCABLB30A== Date: Sat, 9 Nov 2019 16:30:09 +0000 Message-ID: References: <20191101155244.GA30539@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1003::3e3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93ee61f5-2954-484c-4781-08d76532167d x-ms-traffictypediagnostic: MWHPR11MB1951: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(39860400002)(346002)(136003)(13464003)(31014005)(189003)(199004)(8936002)(8676002)(7736002)(6436002)(316002)(229853002)(305945005)(6916009)(81166006)(256004)(66446008)(81156014)(25786009)(5660300002)(66556008)(64756008)(71200400001)(71190400001)(52536014)(74316002)(102836004)(76176011)(7696005)(53546011)(6506007)(486006)(66476007)(476003)(11346002)(446003)(46003)(186003)(9686003)(2906002)(6116002)(14454004)(478600001)(66946007)(76116006)(86362001)(33656002)(55016002)(99286004)(4326008)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1951; H:MWHPR11MB1341.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wW1Bo/RM/wXLkZgUQGE6zWZ20Df//u5FDB4YAi9n01Rvt1IvGY1Ki5KdpE4MayCdXgx5UuFJcrDK+JT+V/JXnV7Oui1xRvb+X65YKBdEmwodBBdq7MZ7nQ/1n/Avj23Kf+KS8pVLL8umfCg1HeSQ3cYG5hiXSlbPRpuL9Ulv4y5Bpw0u6eai986Gu//DrPMzrESQ7q35M8Fq+sWv2ADLDMKjMF0XHAeb2o9gv//ovGyTE5YXCHn2CW6wraqeTwdwA5L/V4I7QPlzy68v6vLgUc0NK64FpsiLtaiVgWvaQUgtLSY/xB4jeJ1ugPJGQ0hgTTOH/n2O/NHB7scXlk4/5EXey23Z26yKd3e0J4tN5Ha9Lv1ygmT+C1tuIPn+GujFSULqeLsRolX8kAcMKW+3zCE/Jtl0P1hOYh/h09MTl1PaWmg/pKiHgKCYxB7gyj+8 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 93ee61f5-2954-484c-4781-08d76532167d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 16:30:09.5254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3ugoIVrfVh9xrZ86/l5Q53uUZm/kqSZgrDwM1qNHml1tcXKWkjhdGgZJac0LVbJplkXdAEOD+UhhL64CNhRzfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1951 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: 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: Sat, 09 Nov 2019 16:30:27 -0000 SmVmZiAtDQoNCkkgZG8gbm90IGhhdmUgYSBzcGVjaWZpYyBtb2RlbCBpbiBtaW5kIGZvciBTLUJG RCBhbmQgbGFyZ2UgcGFja2V0cyAtIGltcGxlbWVudGF0aW9ucyBzaG91bGQgYmUgZnJlZSB0byBj aG9vc2UuIEkgdGhpbmsgeW91IGhhdmUgY292ZXJlZCB0aGUgb3B0aW9ucyB3ZWxsIGluIHlvdXIg Y29tbWVudHMgYmVsb3cuIE1haW5seSBJIHdhbnRlZCB0aGlzIGRpc2N1c3NlZCBpbiB0aGUgZHJh ZnQuDQoNClRoZSBvbmx5IHRoaW5nIHRoYXQgbWlnaHQgYmUgdHJvdWJsZXNvbWUgaXMgdGhlIG5v dGlvbiBvZiB1c2luZyBhIHNlcGFyYXRlIGRpc2NyaW1pbmF0b3IgZm9yIGxhcmdlIHBhY2tldCBT LUJGRCAoeWVzIC0gSSBzdWdnZXN0ZWQgdGhpcyAtIG5vdCB5b3Ug8J+YiikuIFRoaXMgcmFpc2Vz IHRoZSB1bnNvbHZlZCBwcm9ibGVtIG9mIGhvdyBkb2VzIG9uZSBpbmRpY2F0ZSB3aGljaCBkaXNj cmltaW5hdG9yIGlzIGZvciB3aGljaCB1c2UgY2FzZS4gQWx0aG91Z2ggdGhlIElHUCBleHRlbnNp b25zIHN1cHBvcnQgYWR2ZXJ0aXNpbmcgbXVsdGlwbGUgUy1CRkQgZGlzY3JpbWluYXRvcnMgd2Ug bmV2ZXIgZmlndXJlZCBvdXQgaG93IHRvIGluZGljYXRlIGhvdyBhIGdpdmVuIGRpc2NyaW1pbmF0 b3Igc2hvdWxkIGJlIHVzZWQuIEkgb25seSBtZW50aW9uIGl0IHNpbmNlIHRoaXMgZHJhZnQgaW50 cm9kdWNlcyBhIHBvc3NpYmxlIHVzZSBjYXNlIGZvciBtdWx0aXBsZSBTLUJGRCBkaXNjcmltaW5h dG9ycyAtIGJ1dCB0aGlzIGlzbuKAmXQgYSBuZXcgaXNzdWUgYW5kIGRvZXNu4oCZdCBoYXZlIHRv IGJlIHNvbHZlZCBieSB0aGlzIGRyYWZ0Lg0KDQogICBMZXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+DQo+IFNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTkgODo0NyBBTQ0KPiBUbzogTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT4NCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtYmZkLWxhcmdlLXBhY2tldHMtMDINCj4gDQo+ IExlcywNCj4gDQo+IA0KPiA+IE9uIE5vdiA1LCAyMDE5LCBhdCAxMjo1NSBBTSwgTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykNCj4gPGdpbnNiZXJnQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBK ZWZmL0FsYmVydCAtDQo+ID4NCj4gPiBUaGFueCBmb3IgdGhlIHVwZGF0ZWQgdmVyc2lvbi4gVGhp cyBhZGRyZXNzZXMgbXkgY29uY2VybnMuDQo+ID4NCj4gPiBBIGNvdXBsZSBvZiBtb2Rlc3QgY29t bWVudHMuDQo+ID4NCj4gPiAxKVNlY3Rpb24gMy40DQo+ID4NCj4gPiBzL3RoYXQgYmFsYWNpbmcv dGhhdCBiYWxhbmNpbmcNCj4gDQo+IFF1ZXVlZCBmb3IgbmV4dCByZXYuDQo+IA0KPiA+IDIpUmVn YXJkaW5nIFMtQkZEIChTZWN0aW9uIDMuNSkNCj4gPg0KPiA+IEl0IHdvdWxkIHNlZW0gZGlmZmlj dWx0IHRvIHN1cHBvcnQgKGZvciBhIGdpdmVuIGRpc2NyaW1pbmF0b3IpIHNvbWUgc2Vzc2lvbnMN Cj4gdXNpbmcgbGFyZ2UgcGFja2V0cyBhbmQgc29tZSBub3QuIEkgIGNhbiB0aGluayBvZiBhIGZl dyBvcHRpb25zOg0KPiA+DQo+ID4gYSlQYXNzaXZlIGVuZCB1c2VzIGxhcmdlIHBhY2tldHMgb25s eSBpZiB0aGUgQWN0aXZlIGVuZCBkb2VzLiBUaGlzIGFzc3VtZXMNCj4gTVRVIGlzIHRoZSBzYW1l IGluIGJvdGggZGlyZWN0aW9ucy4NCj4gDQo+IEFzeW1tZXRyaWMgTVRVcyBhcmUgbm90IG9ubHkg cG9zc2libGUsIGJ1dCBsaWtlbHkgaW4gUy1CRkQgc2NlbmFyaW9zLiAgQnV0IGl0J3MNCj4gYSB2 YWxpZCBwb2ludC4NCj4gDQo+ID4gYilBIHNlcGFyYXRlIGRpc2NyaW1pbmF0b3IgaXMgdXNlZCBm b3IgbGFyZ2UgcGFja2V0IHNlc3Npb25zDQo+ID4gYylVc2Ugb2YgbGFyZ2UgcGFja2V0cyBpcyBh bHdheXMgb24gKG9yIGFsd2F5cyBvZmYpIG9uIHRoZSBwYXNzaXZlIHNpZGUNCj4gPg0KPiA+IFBy b2JhYmx5IHRoZXJlIGFyZSBvdGhlciBjaG9pY2VzLg0KPiA+DQo+ID4gV2hhdCBkaWQgeW91IGhh dmUgaW4gbWluZD8gSSB0aGluayBhZGRpbmcgc29tZSBndWlkYW5jZSBpbiB0aGF0IHJlZ2FyZA0K PiBtaWdodCBiZSB1c2VmdWwuDQo+IA0KPiBNeSBwZXJzb25hbCB0aG91Z2h0IG9uIHRoZSBtYXR0 ZXIgaGFkIGJlZW4gcm91Z2hseToNCj4gLSBCeSBkZWZhdWx0LCByZXNwb25kIHdpdGggdGhlIHNh bWUgc2l6ZSBJUCBlbmNhcHN1bGF0aW9uIGFzIHlvdSByZWNlaXZlLg0KPiAtIFdoaWxlIFMtQkZE IHBlcm1pdHMgbGFyZ2VseSBub24tY29uZmlndXJlZCByZXNwb25zZXMgdG8gSW5pdGlhdG9ycywg dGhlcmUncw0KPiBsaWtlbHkgdG8gYmUgU09NRSBjb25maWd1cmF0aW9uIHByZXNlbnQuICBJZiBu ZWNlc3NhcnksIHNwZWNpZmljIGNvbmZpZ3VyYXRpb24NCj4gY2FuIGJlIGdpdmVuIHRvIGNvdmVy IHNpemUgb2YgcGFja2V0cyB0byByZXNwb25kIHRvLiAgKFJvdWdobHkgYWxpZ25pbmcgd2l0aA0K PiB0aGUgQUNMcyB1c2VkIHRvIG1hbmFnZSB3aG9tIGNhbiBpbml0aWF0ZSBTLUJGRCBpbiB0aGUg Zmlyc3QgcGxhY2UuKQ0KPiANCj4gT25lIHdheSB0byBpbnRlcnByZXQgeW91ciBxdWVzdGlvbnMg aXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgc29tZSBpbXBsaWVkDQo+IGNvbmZpZ3VyYXRpb24gZm9y IEJGRCBmb3IgTGFyZ2UgUGFja2V0cywgbm90IG9ubHkgb24gdGhlIHNlbmRpbmcgc2lkZSwgYnV0 IG9uDQo+IHRoZSByZWNlaXZlci4NCj4gDQo+IEZvciB0aGUgcmVjZWl2ZXIsIHNvbWV0aGluZyBy b3VnaGx5IGxpa2UgImJmZC5QYWRkZWRQZHVSZWNlaXZlTWF4U2l6ZSIgYXMNCj4gYSBwYXJhbWV0 ZXIuICBQb3NzaWJseSBhY3RpbmcgYWxzbyBhcyBhIHdheSB0byBlbmFibGUgdGhlIGZlYXR1cmUg b3Igbm90Lg0KPiANCj4gRm9yIGFuIFMtQkZEIHJlZmxlY3RvciwgcGVyaGFwcyBwYXJhbWV0ZXJz IHRvIGNvbnRyb2wgYmV5b25kIHRoZSByZWNlaXZlDQo+IG1heCBzaXplIHdoZXRoZXIgaXQgcmVz cG9uZHMgd2l0aCB0aGUgc2FtZSBzaXplIGFzIHRoZSBpUCBlbmNhcHN1bGF0aW9uLCBhbmQNCj4g d2hldGhlciB0aGVyZSdzIGEgY2FwIGZvciBzdWNoIGEgcmVzcG9uc2UuDQo+IA0KPiBEb2VzIHRo ZSBhYm92ZSBhZGRyZXNzIHlvdXIgY29uY2VybnM/DQo+IA0KPiAtLSBKZWZmDQoNCg== From nobody Sat Nov 9 11:08:24 2019 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 D68A7120046; Sat, 9 Nov 2019 11:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 A-KMVsC2uCpB; Sat, 9 Nov 2019 11:08:19 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CF83D12001A; Sat, 9 Nov 2019 11:08:18 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id DE2D11E2F5; Sat, 9 Nov 2019 14:12:04 -0500 (EST) Date: Sat, 9 Nov 2019 14:12:04 -0500 From: Jeffrey Haas To: Weiqiang Cheng Cc: bfd-chairs@ietf.org, rtg-bfd@ietf.org, =?utf-8?B?J+eOi+eRnumbqic=?= , liu.aihua@zte.com.cn Subject: Re: The usecase of the BFD application Message-ID: <20191109191204.GC19227@pfrc.org> References: <028a01d59380$e2350480$a69f0d80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <028a01d59380$e2350480$a69f0d80$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Sat, 09 Nov 2019 19:08:22 -0000 Weiqiang Cheng, BFD appears to be likely to have a small amount of business at the upcoming IETF-106. The working grooup needs to find a secretary to commit to minutes for us to meet. If we do meet, you may have 10 minutes to discuss this. I will ask you to include the following information in your presentation: - How does this proposal differ from BBF TR-146? (https://www.broadband-forum.org/download/TR-146.pdf) - What are the implications for BFD clients? This would include BFD yang models. -- Jeff On Tue, Nov 05, 2019 at 10:29:43AM +0800, Weiqiang Cheng wrote: > Hi Chairs, > > We prepared a draft to use BFD in datacenter application scenario. > > Because the time zone difference, we missed the submission deadline and we > will upload it on Nov. 16. > > If possible, we still hope to apply a slot to present it. Could you see if > it is Ok for the group? > > > > B.R. > > Weiqiang Cheng > > > > > BFD Working Group R. Wang > Internet-Draft W. Cheng > Intended status: Informational China Mobile > Expires: May 7, 2020 Y. Zhao > A. Liu > ZTE > November 4, 2019 > > > Using One-Arm BFD in Cloud Network > draft-wang-bfd-one-arm-use-case-00 > > Abstract > > Bidirectional Forwarding Detection (BFD) is a fault detection > protocol that can quickly determine a communication failure between > devices and notify upper-layer applications [RFC5880]. BFD has > asynchronous detecting mode and demand detection mode to satisfy > different scenarios, also supports echo function to reduce the device > requirement for BFD. One-Arm BFD this draft descripted supports > another BFD detecting function rather than the echo as described in > [RFC5880] [RFC5881], it needs nothing BFD capability to one of the > devices deployed BFD detecting. Using One-Arm BFD function, the one > device works on BFD detecting normally and the other device just > loopback the BFD packets like echo function. One-Arm BFD is suitable > for the cloud virtualization network, the One-Arm BFD is deploy on > NFV gateways, and NFV virtual machine vNICs just enable the echo/ > loopback process. > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at https://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on May 7, 2020. > > > > > > > Wang, et al. Expires May 7, 2020 [Page 1] > > Internet-Draft Using One-Arm BFD in Cloud Network November 2019 > > > Copyright Notice > > Copyright (c) 2019 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (https://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 > 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 > 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 > 2. One-Arm BFD Use Case . . . . . . . . . . . . . . . . . . . . 3 > 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 > 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 > 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 > > 1. Introduction > > To minimize the impact of device faults on services and improve > network availability, a network device must be able to quickly detect > faults in communication with adjacent devices. Measures can then be > taken to promptly rectify the faults to ensure service continuity. > > BFD is a low-overhead, short-duration method to detect faults on the > path between adjacent forwarding engines. The faults can be > interface, data link, and even forwarding engine faults. It is a > single, unified mechanism to monitor any media and protocol layers in > real time. > > BFD has asynchronous detecting mode and demand detection mode to > satisfy different scenarios, also supports echo function to reduce > the device requirement for BFD. BFD echo function is used when two > devices are connected but only one of them supports full BFD > capability. When the echo function is activated, the local system > sends a BFD control packet and the remote system loops back the > > > > Wang, et al. Expires May 7, 2020 [Page 2] > > Internet-Draft Using One-Arm BFD in Cloud Network November 2019 > > > packet through the forwarding channel. If several consecutive echo > packets are not received, the session is declared to be Down. BFD > echo function reduces one of the two devices requirement for BFD. > > With the development of network cloud and NFV virtualization, there > are many connections between gateway devices and the virtual machine > devices. The virtual machine devices don't support BFD capacity at > all. There is difficult to deploy BFD between the gateway devices > and the virtual machine vNICs. One-Arm BFD supports this scenario, > it supports gateway enable full BFD capability and virtual machine > don't support BFD at all, just simply loopback BFD packets on vNICs. > > 1.1. Conventions Used in This Document > > 1.1.1. Terminology > > BFD: Bidirectional Forwarding Detection > > NFV: Network Function Virtualization > > 1.1.2. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > 2. One-Arm BFD Use Case > > With the development of network cloud and NFV virtualization, there > are many connections between gateway devices and the virtual machine > devices. The virtual machine(VM) devices don't support BFD capacity > at all. If the gateway devices are deployed BFD protocol, there are > some problems including scalability, detecting period and so on. And > the VM can't support BFD protocol currently. One-Arm echo BFD can > resolve these problems. One-arm echo BFD is used when two devices > are connected and only one of them supports BFD. A one-arm BFD echo > session can be established on the device that supports BFD, the other > device just loopback BFD packets. > > After receiving a one-arm BFD echo session packet, the device that > does not support BFD immediately loops back the packet, implementing > quick link failure detection. As shown in Figure 1, Device A such as > a NFV gateway supports BFD, whereas Device B such as a virtual > machine does not. To rapidly detect faults in the link between > Device A and Device B, configure a one-arm BFD echo session on Device > A. After receiving a one-arm BFD echo session packet from Device A, > > > > Wang, et al. Expires May 7, 2020 [Page 3] > > Internet-Draft Using One-Arm BFD in Cloud Network November 2019 > > > Device B immediately loops back the packet, implementing rapid link > fault detection. > > > Device A One-Arm Echo Device B > +--------+ BFD session +---------+ > | A |---------------------------------| B | > | |Inf 1 Inf 1| | > +--------+10.1.1.1/24 10.1.1.2/24+---------+ > BFD is supported. BFD is not supported. > > > Figure 1: One-Arm BFD deploying scenario > > 3. Discussion > > One-Arm BFD detecting function is better than BFD echo function mode. > First One-Arm BFD can use full BFD capacity in the BFD-supported > device. So One-Arm BFD can also support fast detecting and manage > BFD sessions effectively. Second it is scalable using one-arm BFD > detecting to adapt the NFV virtualization. Finally, it is the same > process in the non-BFD-supported devices with echo function. So one- > arm BFD can be deployed to the cloud network, and the VMs don't > require to support BFD capacity. > > 4. Security Considerations > > TBD. > > 5. IANA Considerations > > This document has no IANA action requested. > > 6. Acknowledgements > > TBD. > > 7. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, > . > > > > > Wang, et al. Expires May 7, 2020 [Page 4] > > Internet-Draft Using One-Arm BFD in Cloud Network November 2019 > > > [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > DOI 10.17487/RFC5881, June 2010, > . > > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, . > > Authors' Addresses > > Ruixue Wang > China Mobile > Beijing > CN > > Email: wangruixue@chinamobile.com > > > Weiqiang Cheng > China Mobile > Beijing > CN > > Email: chengweiqiang@chinamobile.com > > > Yanhua Zhao > ZTE > Nanjing > CN > > Email: zhao.yanhua3@zte.com.cn > > > Aihua Liu > ZTE > Shenzhen > CN > > Email: liu.aihua@zte.com.cn > > > > > > > > > > > Wang, et al. Expires May 7, 2020 [Page 5] > From nobody Sat Nov 9 11:20:00 2019 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 DD24212001A for ; Sat, 9 Nov 2019 11:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 XluVadU2n2_S for ; Sat, 9 Nov 2019 11:19:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EE5D212008D for ; Sat, 9 Nov 2019 11:19:56 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 580781E2F2; Sat, 9 Nov 2019 14:23:43 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B4DB9E-ADDF-4E09-9759-7649AD550980" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: IETF-106 agenda? From: Jeffrey Haas In-Reply-To: Date: Sat, 9 Nov 2019 14:19:55 -0500 Cc: rtg-bfd WG , Reshad Rahman Message-Id: References: <20191101181535.GA10713@pfrc.org> To: Greg Mirsky X-Mailer: Apple Mail (2.3601.0.10) Archived-At: 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: Sat, 09 Nov 2019 19:19:59 -0000 --Apple-Mail=_E6B4DB9E-ADDF-4E09-9759-7649AD550980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greg. > On Nov 1, 2019, at 4:27 PM, Greg Mirsky wrote: >=20 > I think that it will be of interest to the group to get an update on = the draft-mirmin-bfd-extended. We've added details on the use of the = Padding TLV. As noted previously, we will be deferring this work for next IETF. > Also, would appreciate the opportunity to discuss the status of = draft-mirsky-bfd-mpls-demand at the meeting. Our agenda is likely to be light, and a small amount of time can be = reserved - say 10 minutes. However, there are strict requirements on = the slides since we'd previously discussed this at IETF-105 and on-list: Your slides need to clearly demonstrate what you think is missing from = RFC 5880 procedures. In particular, from our prior discussions: - 5880 describes entering and leaving demand mode. - Previous discussion clarified that a change of the status field is a = reason to do a poll sequence to notify the remote end of the new status. = (See text from concatenated paths mode 6.8.17 describing one such = scenario.) We agreed that an errata could potentially be filed to = clarify this document wide. So, we will need what exact protocol normative behavior is missing. -- Jeff= --Apple-Mail=_E6B4DB9E-ADDF-4E09-9759-7649AD550980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Greg.


On Nov = 1, 2019, at 4:27 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

I = think that it will be of interest to the group to get an update on the = draft-mirmin-bfd-extended. We've added details on the use of the Padding = TLV.

As noted = previously, we will be deferring this work for next IETF.

Also, would appreciate the opportunity to discuss the = status of draft-mirsky-bfd-mpls-demand at the = meeting.

Our agenda is likely to be light, and a small amount of time = can be reserved - say 10 minutes.  However, there are strict = requirements on the slides since we'd previously discussed this at = IETF-105 and on-list:

Your slides need to clearly demonstrate what you think is = missing from RFC 5880 procedures.

In particular, from our prior = discussions:
- 5880 describes entering and leaving = demand mode.
- Previous discussion clarified that a = change of the status field is a reason to do a poll sequence to notify = the remote end of the new status.  (See text from concatenated = paths mode 6.8.17 describing one such scenario.)  We agreed that an = errata could potentially be filed to clarify this document = wide.

So, we = will need what exact protocol normative behavior is missing.

-- = Jeff
= --Apple-Mail=_E6B4DB9E-ADDF-4E09-9759-7649AD550980-- From nobody Sat Nov 9 11:28:17 2019 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 3C6D912008D for ; Sat, 9 Nov 2019 11:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 AAlk1ZmQ8IkX for ; Sat, 9 Nov 2019 11:28:13 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AA08712001A for ; Sat, 9 Nov 2019 11:28:13 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7E9A91E2F5; Sat, 9 Nov 2019 14:32:00 -0500 (EST) Date: Sat, 9 Nov 2019 14:32:00 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Cc: "Reshad Rahman (rrahman)" Subject: Re: IETF-106 agenda? Message-ID: <20191109193200.GD19227@pfrc.org> References: <20191101181535.GA10713@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191101181535.GA10713@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Sat, 09 Nov 2019 19:28:15 -0000 Working Group, We will be attempting to meet at IETF-106. There's just enough business to discuss to warrant using our time slot. Note as below: We do not currently have a minutes taker. If we do not have one (ideally volunteering ahead of time) by meeting start time, we will suspend without a meeting. The authors of BFD for vxlan are requested to prepare slides covering changes since the last IETF and a summary of the rather energetic discussion we've had since that meeting. Additionally, please summarize the open issues since we have a few still being discussed on the list. Please recall that BFD is meeting on Tuesday. Please send me your slides by Sunday. ----- Current targeted agenda: Chairs update: 5 mins - Jeff Haas BFD for vxlan: 15 minutes - TBD BFD for Large Packets: 5 minutes - Jeff BFD Demand Mode: 10 minutes - Greg Using One-Arm BFD in Cloud Network: 10 minutes -- Jeff On Fri, Nov 01, 2019 at 02:15:35PM -0400, Jeffrey Haas wrote: > Working Group, > > A session request had gone in for IETF 106 to accommodate the need for a > possible session. The agenda, to this point, had been left as an open > question primarily to accommodate need to close on lingering questions in > active work. In particular, this was for two items: > > - BFD for vxlan > - BFD for Large Packets > > (For transparency, I am an author on BFD for large packets) > > As of this afternoon, we seem to have drafts submitted that cover the known > open issues on both of these drafts. In particular, the work to get us to > the latest draft for the vxlan document took over 150 messages. > > If BFD meets, agenda time was primarily reserved to reconcile open issues on > these documents. > > Discussion on BFDv2 is currently deferred for next IETF to focus the Working > Group's limited attention on closing open work. > > That said, if we have other topics to consider, please submit them for > consideration. If we have no such topics, and the discussion on the above > two drafts seems likely to conclude well over e-mail, we may consider > canceling the session. > > As a final note, since Reshad is unable to make it to IETF-106, if we do > decide to continue with our meeting, we will require the commitment for a > minutes taker. Reshad and I often will cover that for each other over the > course of a session, but I won't be able to sustain that on my own. > > -- Jeff, for the chairs. From nobody Sat Nov 9 11:49:52 2019 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 1355F12008D for ; Sat, 9 Nov 2019 11:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IPJv3r4I; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=d07TshEX 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 2VH7-FxfRMZa for ; Sat, 9 Nov 2019 11:49:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9998512001A for ; Sat, 9 Nov 2019 11:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7995; q=dns/txt; s=iport; t=1573328987; x=1574538587; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mOLRauFlkcV0c8vypJC//Jfk5dw2UVZc0FA/RGDE04A=; b=IPJv3r4I2Em+NH1BboOdqeKeOT01tyHWNPtBYsjI1h3iATas4W7M25tx fX8WQNrLxM0VC2l7tA8Ii0a6NREbZNJNps4bFiiyAIaepwCp96TJv/p1y sWvXZhRcJgVWWuR9I3YQy5HSCnLzJ4K8zhxavWl1mMa1ov/FgoVJ2EVMO s=; IronPort-PHdr: =?us-ascii?q?9a23=3A/T4U6h8X++0Kbv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcWdCEL9JeLjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAACNF8dd/4cNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWwFAQELAYFKUAWBRCAECyoKhB+DRgOKbII5iX2JRoRigS6BJAN?= =?us-ascii?q?UCQEBAQwBAS0CAQGEQAIXg3kkNgcOAgMLAQEEAQEBAgEFBG2FNwyFUgIEDAY?= =?us-ascii?q?RHQEBNwEPAgEGAj8DAgICHxEUEQIEDgUigwCBek0DLgGQA5BjAoE4iGB1gTK?= =?us-ascii?q?CfgEBBYUKDQuCFwmBNgGMExiBQD+BOAwTghc1PoEEgReCAyaDETKCLIlWgz2?= =?us-ascii?q?CeYVDiT2OR0EKgiWQXFaEEhuCPYdhj1uQCIkHjBSDGgIEAgQFAg4BAQWBWQg?= =?us-ascii?q?qgVhwFWUBgkE+EhEUkDYMDAuDUIpTdIEojX4EgS0BLwFeAQE?= X-IronPort-AV: E=Sophos;i="5.68,286,1569283200"; d="scan'208,217";a="662867161" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2019 19:49:46 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xA9Jnk1m016480 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Nov 2019 19:49:46 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 13:49:45 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Nov 2019 13:49:45 -0600 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 9 Nov 2019 13:49:45 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UtsbGJHYtH468+kLqaMOiM3CyoFD5qZC5+/W7m4dWYuF4w8OAF/48D5caNh+UonXGtlhSrhMLAp5iqXKgMpfsKhYSwRX3utbkN8j+RlflO+JexLr1s/WPS6qdkIj1yN31JcQ3F9PPoy/7XNXoBKiptfNlmtg932JRLoL7h21ldy42D7bnKmajBG84LnC2zioyAy8RdVxIDgak47lFBEDyL+n7v2uVxJZDiUbwePNEA8wg4B0A0wVX9y5ktrj8Nrg3lKFncOASGNJaubIPMbPGcJxHG6oxEA9/iQQ7Nt1NNK/bEXH7V7tN4RlZIae8K64F/CADQo/UMkkqCda2OEfmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mOLRauFlkcV0c8vypJC//Jfk5dw2UVZc0FA/RGDE04A=; b=NIHoWbnsLnkr0KS4KhBRBjYvg4zokRCaMGk84lGMQ/1zrsSttIPUbEsPD5Tl7S8CDRoWFLd2tPu6cDqfzvB6Jlig91mBpPoF63g1Xt6aYzXakZ7V3gs251yxPVu8Fn3vVizDpjrR25AJRgy1Fw4BIAnOPR7nYOd4OnwtVn+/Dhg5OYEFgr/uM7kwboMZ/LyNXTBmV5LvT3RHBedaam/rewTqcSmQSAlpSJE4l+uQAuudRGThN85Q9qnJU4qqw6R3UGVqlP/ifz9EOEh5HnITPwReNt9oefS2RgeOY8hm3fQ3k9L99G448ab6Or3neqQP7H+o/6SzYf9nVVf3Q5J6Mg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mOLRauFlkcV0c8vypJC//Jfk5dw2UVZc0FA/RGDE04A=; b=d07TshEXbedQgIOW4Zqb9Q2/t+ci0U3ZcTjFCsOtljCpuWEJnfMVSetMhVbonCc4cNQC8kAuz7Edr/9osqWw8qhQNc5dT4yBgMFPBQHCpFLlQKC7bvkD+ZmvhxiZQ9ayrzeh+Xadp9/IPABVU78ZcbDv3N7tGE6SfLZDRYsrXcY= Received: from BN6PR11MB0034.namprd11.prod.outlook.com (10.161.156.160) by BN6PR11MB4178.namprd11.prod.outlook.com (10.255.132.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.23; Sat, 9 Nov 2019 19:49:44 +0000 Received: from BN6PR11MB0034.namprd11.prod.outlook.com ([fe80::502b:7ec7:4cb0:3781]) by BN6PR11MB0034.namprd11.prod.outlook.com ([fe80::502b:7ec7:4cb0:3781%3]) with mapi id 15.20.2430.020; Sat, 9 Nov 2019 19:49:44 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Jeff Haas , "Reshad Rahman (rrahman)" , rtg-bfd WG Subject: Re: IETF-106 agenda? Thread-Topic: IETF-106 agenda? Thread-Index: AQHVkN/nkntDtAi4SUOyFKFIRIyq6qd2w7cAgAyIMoA= Date: Sat, 9 Nov 2019 19:49:44 +0000 Message-ID: <37C3B4B1-21F2-4368-914C-844959D01AAD@cisco.com> References: <20191101181535.GA10713@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3601.0.10) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ae522e76-29dc-4c49-a29e-08d7654df7ef x-ms-traffictypediagnostic: BN6PR11MB4178: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 021670B4D2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(346002)(136003)(376002)(199004)(189003)(51444003)(256004)(71190400001)(14444005)(5660300002)(71200400001)(6246003)(478600001)(486006)(446003)(76176011)(91956017)(54896002)(6512007)(11346002)(2616005)(476003)(81156014)(81166006)(4326008)(8936002)(7736002)(229853002)(236005)(14454004)(6486002)(8676002)(6916009)(6436002)(316002)(66556008)(6116002)(66446008)(3846002)(66476007)(64756008)(50226002)(36756003)(33656002)(1411001)(66574012)(76116006)(2906002)(86362001)(54906003)(66946007)(99286004)(66066001)(6506007)(53546011)(26005)(186003)(102836004)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB4178; H:BN6PR11MB0034.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JYXSYnqi/nabb878XAbK3Mkw+WJB7tLKUjFI/WSrM6Xmn5A2nbSej8+zdqz1kmMNmMKq5LhvrjtNQtYIqMLk/PYGjCkENRE7Uuw684c7/NYo10CYojRJkSVDr9gBGyPtEX3uZc6aeUcjphKeSyooGXxo0qFK9RntS0518zJg6riTIr12safYiIp2kLI1zZWWbjt5cw8eMvXqWwbDghCaQvWIPLWQY/+9e/eUWnMcYSSusRWi0yYA/L43SR9EvXPtNyZf8WGA0UnZY4RUa6cL9iJ76gp0xPj2vpuY4nXYkF6JcWp5BrQbRRvCrjJgNwA6w9ol4pp81jKlm9JkhQgUxWAJ5+bzHrDu8z9u5Vwo/ZReOIHCvPUuBsAcEx+kcb9qcZPuMruScwBxSX4bTTUkf9SegpUc8NEXw0dD7dDlRUYe0mICtjFxEnLBYspgm7pM Content-Type: multipart/alternative; boundary="_000_37C3B4B121F24368914C844959D01AADciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ae522e76-29dc-4c49-a29e-08d7654df7ef X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2019 19:49:44.1489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8JihRhin+YWGULANtI9EAx46DYXx5iu8mV3omZQ/I/R0djWr5wA6KCBADQ87WPpmrDLImBOfxLVRNtfPecqIHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4178 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: 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: Sat, 09 Nov 2019 19:49:50 -0000 --_000_37C3B4B121F24368914C844959D01AADciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCjIwMTkvMTEvMDEg5Y2I5b6MNDoyN+OAgUdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFp bC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+44Gu44Oh44O844OrOg0KDQpIaSBK ZWZmLCBldCBhbC4sDQpJIHRoaW5rIHRoYXQgaXQgd2lsbCBiZSBvZiBpbnRlcmVzdCB0byB0aGUg Z3JvdXAgdG8gZ2V0IGFuIHVwZGF0ZSBvbiB0aGUgZHJhZnQtbWlybWluLWJmZC1leHRlbmRlZC4g V2UndmUgYWRkZWQgZGV0YWlscyBvbiB0aGUgdXNlIG9mIHRoZSBQYWRkaW5nIFRMVi4NCkFsc28s IHdvdWxkIGFwcHJlY2lhdGUgdGhlIG9wcG9ydHVuaXR5IHRvIGRpc2N1c3MgdGhlIHN0YXR1cyBv ZiBkcmFmdC1taXJza3ktYmZkLW1wbHMtZGVtYW5kIGF0IHRoZSBtZWV0aW5nLg0KDQoNCklzIHRo ZXJlIGEgd29yZCBmb3IgYSByZWN1cnNpdmUgcmVjdXJyZW50IGTDqWrDoCB2dT8NCg0KS2luZGx5 LA0KDQpDYXJsb3MuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIEZyaSwgTm92IDEsIDIwMTkgYXQg MTE6MTIgQU0gSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5v cmc+PiB3cm90ZToNCldvcmtpbmcgR3JvdXAsDQoNCkEgc2Vzc2lvbiByZXF1ZXN0IGhhZCBnb25l IGluIGZvciBJRVRGIDEwNiB0byBhY2NvbW1vZGF0ZSB0aGUgbmVlZCBmb3IgYQ0KcG9zc2libGUg c2Vzc2lvbi4gIFRoZSBhZ2VuZGEsIHRvIHRoaXMgcG9pbnQsIGhhZCBiZWVuIGxlZnQgYXMgYW4g b3Blbg0KcXVlc3Rpb24gcHJpbWFyaWx5IHRvIGFjY29tbW9kYXRlIG5lZWQgdG8gY2xvc2Ugb24g bGluZ2VyaW5nIHF1ZXN0aW9ucyBpbg0KYWN0aXZlIHdvcmsuICBJbiBwYXJ0aWN1bGFyLCB0aGlz IHdhcyBmb3IgdHdvIGl0ZW1zOg0KDQotIEJGRCBmb3IgdnhsYW4NCi0gQkZEIGZvciBMYXJnZSBQ YWNrZXRzDQoNCihGb3IgdHJhbnNwYXJlbmN5LCBJIGFtIGFuIGF1dGhvciBvbiBCRkQgZm9yIGxh cmdlIHBhY2tldHMpDQoNCkFzIG9mIHRoaXMgYWZ0ZXJub29uLCB3ZSBzZWVtIHRvIGhhdmUgZHJh ZnRzIHN1Ym1pdHRlZCB0aGF0IGNvdmVyIHRoZSBrbm93bg0Kb3BlbiBpc3N1ZXMgb24gYm90aCBv ZiB0aGVzZSBkcmFmdHMuICBJbiBwYXJ0aWN1bGFyLCB0aGUgd29yayB0byBnZXQgdXMgdG8NCnRo ZSBsYXRlc3QgZHJhZnQgZm9yIHRoZSB2eGxhbiBkb2N1bWVudCB0b29rIG92ZXIgMTUwIG1lc3Nh Z2VzLg0KDQpJZiBCRkQgbWVldHMsIGFnZW5kYSB0aW1lIHdhcyBwcmltYXJpbHkgcmVzZXJ2ZWQg dG8gcmVjb25jaWxlIG9wZW4gaXNzdWVzIG9uDQp0aGVzZSBkb2N1bWVudHMuDQoNCkRpc2N1c3Np b24gb24gQkZEdjIgaXMgY3VycmVudGx5IGRlZmVycmVkIGZvciBuZXh0IElFVEYgdG8gZm9jdXMg dGhlIFdvcmtpbmcNCkdyb3VwJ3MgbGltaXRlZCBhdHRlbnRpb24gb24gY2xvc2luZyBvcGVuIHdv cmsuDQoNClRoYXQgc2FpZCwgaWYgd2UgaGF2ZSBvdGhlciB0b3BpY3MgdG8gY29uc2lkZXIsIHBs ZWFzZSBzdWJtaXQgdGhlbSBmb3INCmNvbnNpZGVyYXRpb24uICBJZiB3ZSBoYXZlIG5vIHN1Y2gg dG9waWNzLCBhbmQgdGhlIGRpc2N1c3Npb24gb24gdGhlIGFib3ZlDQp0d28gZHJhZnRzIHNlZW1z IGxpa2VseSB0byBjb25jbHVkZSB3ZWxsIG92ZXIgZS1tYWlsLCB3ZSBtYXkgY29uc2lkZXINCmNh bmNlbGluZyB0aGUgc2Vzc2lvbi4NCg0KQXMgYSBmaW5hbCBub3RlLCBzaW5jZSBSZXNoYWQgaXMg dW5hYmxlIHRvIG1ha2UgaXQgdG8gSUVURi0xMDYsIGlmIHdlIGRvDQpkZWNpZGUgdG8gY29udGlu dWUgd2l0aCBvdXIgbWVldGluZywgd2Ugd2lsbCByZXF1aXJlIHRoZSBjb21taXRtZW50IGZvciBh DQptaW51dGVzIHRha2VyLiAgUmVzaGFkIGFuZCBJIG9mdGVuIHdpbGwgY292ZXIgdGhhdCBmb3Ig ZWFjaCBvdGhlciBvdmVyIHRoZQ0KY291cnNlIG9mIGEgc2Vzc2lvbiwgYnV0IEkgd29uJ3QgYmUg YWJsZSB0byBzdXN0YWluIHRoYXQgb24gbXkgb3duLg0KDQotLSBKZWZmLCBmb3IgdGhlIGNoYWly cy4NCg0KDQo= --_000_37C3B4B121F24368914C844959D01AADciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4125F6209C68624E8357100B8FA13DF5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjIw MTkvMTEvMDEg5Y2I5b6MNDoyN+OAgUdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3Jl Z2ltaXJza3lAZ21haWwuY29tIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0 O+OBruODoeODvOODqzo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgSmVmZiwgZXQg YWwuLA0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHRoYXQgaXQgd2lsbCBiZSBvZiBpbnRlcmVzdCB0 byB0aGUgZ3JvdXAgdG8gZ2V0IGFuIHVwZGF0ZSBvbiB0aGUgZHJhZnQtbWlybWluLWJmZC1leHRl bmRlZC4gV2UndmUgYWRkZWQgZGV0YWlscyBvbiB0aGUgdXNlIG9mIHRoZSBQYWRkaW5nIFRMVi48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWxzbywgd291bGQgYXBwcmVjaWF0ZSB0aGUgb3Bwb3J0dW5p dHkgdG8gZGlzY3VzcyB0aGUgc3RhdHVzIG9mJm5ic3A7ZHJhZnQtbWlyc2t5LWJmZC1tcGxzLWRl bWFuZCBhdCB0aGUgbWVldGluZy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXY+SXMgdGhlcmUgYSB3b3JkIGZvciBhIHJlY3Vyc2l2ZSByZWN1cnJlbnQg ZMOpasOgIHZ1PzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+S2luZGx5 LDwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Q2FybG9zLjwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMs PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0 dHIiPk9uIEZyaSwgTm92IDEsIDIwMTkgYXQgMTE6MTIgQU0gSmVmZnJleSBIYWFzICZsdDs8YSBo cmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIGNsYXNzPSIiPmpoYWFzQHBmcmMub3JnPC9hPiZn dDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNv bGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpXb3JraW5nIEdyb3VwLDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkEgc2Vzc2lvbiByZXF1ZXN0IGhhZCBnb25lIGlu IGZvciBJRVRGIDEwNiB0byBhY2NvbW1vZGF0ZSB0aGUgbmVlZCBmb3IgYTxiciBjbGFzcz0iIj4N CnBvc3NpYmxlIHNlc3Npb24uJm5ic3A7IFRoZSBhZ2VuZGEsIHRvIHRoaXMgcG9pbnQsIGhhZCBi ZWVuIGxlZnQgYXMgYW4gb3BlbjxiciBjbGFzcz0iIj4NCnF1ZXN0aW9uIHByaW1hcmlseSB0byBh Y2NvbW1vZGF0ZSBuZWVkIHRvIGNsb3NlIG9uIGxpbmdlcmluZyBxdWVzdGlvbnMgaW48YnIgY2xh c3M9IiI+DQphY3RpdmUgd29yay4mbmJzcDsgSW4gcGFydGljdWxhciwgdGhpcyB3YXMgZm9yIHR3 byBpdGVtczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotIEJGRCBmb3IgdnhsYW48YnIg Y2xhc3M9IiI+DQotIEJGRCBmb3IgTGFyZ2UgUGFja2V0czxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCihGb3IgdHJhbnNwYXJlbmN5LCBJIGFtIGFuIGF1dGhvciBvbiBCRkQgZm9yIGxhcmdl IHBhY2tldHMpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgb2YgdGhpcyBhZnRlcm5v b24sIHdlIHNlZW0gdG8gaGF2ZSBkcmFmdHMgc3VibWl0dGVkIHRoYXQgY292ZXIgdGhlIGtub3du PGJyIGNsYXNzPSIiPg0Kb3BlbiBpc3N1ZXMgb24gYm90aCBvZiB0aGVzZSBkcmFmdHMuJm5ic3A7 IEluIHBhcnRpY3VsYXIsIHRoZSB3b3JrIHRvIGdldCB1cyB0bzxiciBjbGFzcz0iIj4NCnRoZSBs YXRlc3QgZHJhZnQgZm9yIHRoZSB2eGxhbiBkb2N1bWVudCB0b29rIG92ZXIgMTUwIG1lc3NhZ2Vz LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIEJGRCBtZWV0cywgYWdlbmRhIHRpbWUg d2FzIHByaW1hcmlseSByZXNlcnZlZCB0byByZWNvbmNpbGUgb3BlbiBpc3N1ZXMgb248YnIgY2xh c3M9IiI+DQp0aGVzZSBkb2N1bWVudHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRGlz Y3Vzc2lvbiBvbiBCRkR2MiBpcyBjdXJyZW50bHkgZGVmZXJyZWQgZm9yIG5leHQgSUVURiB0byBm b2N1cyB0aGUgV29ya2luZzxiciBjbGFzcz0iIj4NCkdyb3VwJ3MgbGltaXRlZCBhdHRlbnRpb24g b24gY2xvc2luZyBvcGVuIHdvcmsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhdCBz YWlkLCBpZiB3ZSBoYXZlIG90aGVyIHRvcGljcyB0byBjb25zaWRlciwgcGxlYXNlIHN1Ym1pdCB0 aGVtIGZvcjxiciBjbGFzcz0iIj4NCmNvbnNpZGVyYXRpb24uJm5ic3A7IElmIHdlIGhhdmUgbm8g c3VjaCB0b3BpY3MsIGFuZCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgYWJvdmU8YnIgY2xhc3M9IiI+ DQp0d28gZHJhZnRzIHNlZW1zIGxpa2VseSB0byBjb25jbHVkZSB3ZWxsIG92ZXIgZS1tYWlsLCB3 ZSBtYXkgY29uc2lkZXI8YnIgY2xhc3M9IiI+DQpjYW5jZWxpbmcgdGhlIHNlc3Npb24uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgYSBmaW5hbCBub3RlLCBzaW5jZSBSZXNoYWQgaXMg dW5hYmxlIHRvIG1ha2UgaXQgdG8gSUVURi0xMDYsIGlmIHdlIGRvPGJyIGNsYXNzPSIiPg0KZGVj aWRlIHRvIGNvbnRpbnVlIHdpdGggb3VyIG1lZXRpbmcsIHdlIHdpbGwgcmVxdWlyZSB0aGUgY29t bWl0bWVudCBmb3IgYTxiciBjbGFzcz0iIj4NCm1pbnV0ZXMgdGFrZXIuJm5ic3A7IFJlc2hhZCBh bmQgSSBvZnRlbiB3aWxsIGNvdmVyIHRoYXQgZm9yIGVhY2ggb3RoZXIgb3ZlciB0aGU8YnIgY2xh c3M9IiI+DQpjb3Vyc2Ugb2YgYSBzZXNzaW9uLCBidXQgSSB3b24ndCBiZSBhYmxlIHRvIHN1c3Rh aW4gdGhhdCBvbiBteSBvd24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gSmVmZiwg Zm9yIHRoZSBjaGFpcnMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_37C3B4B121F24368914C844959D01AADciscocom_-- From nobody Sun Nov 10 22:50:42 2019 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 7A9EA12020A for ; Sun, 10 Nov 2019 22:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 W_48uZySwxcr for ; Sun, 10 Nov 2019 22:50:39 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C637312013D for ; Sun, 10 Nov 2019 22:50:37 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 14DFECDDFB98988407EC for ; Mon, 11 Nov 2019 14:50:35 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 026B31F74AF5228C83B2; Mon, 11 Nov 2019 14:50:35 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id xAB6mlUe003806; Mon, 11 Nov 2019 14:48:47 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn) Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Mon, 11 Nov 2019 14:48:47 +0800 (CST) Date: Mon, 11 Nov 2019 14:48:47 +0800 (CST) X-Zmail-TransId: 2afa5dc9044f59d9d221 X-Mailer: Zmail v1.0 Message-ID: <201911111448470627265@zte.com.cn> In-Reply-To: <20191109193200.GD19227@pfrc.org> References: 20191101181535.GA10713@pfrc.org,20191109193200.GD19227@pfrc.org Mime-Version: 1.0 From: To: Cc: , Subject: =?UTF-8?B?UmU6SUVURi0xMDYgYWdlbmRhPw==?= Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn xAB6mlUe003806 Archived-At: 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: Mon, 11 Nov 2019 06:50:41 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgSmVmZiwNCg0KDQoNCg0KDQoNCkkgY291bGQgYmUgb25lIG1pbnV0ZXMgdGFrZXIgaWYgbm8g b3RoZXJzIGV4cGVyaWVuY2VkIHZvbHVudGVlcmVkLg0KDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2Fy ZHMsDQoNCg0KWGlhbyBNaW4NCg0KDQoNCg0KDQoNCg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K 5Y+R5Lu25Lq677yaSmVmZnJleUhhYXMgPGpoYWFzQHBmcmMub3JnPg0K5pS25Lu25Lq677yacnRn LWJmZEBpZXRmLm9yZyA8cnRnLWJmZEBpZXRmLm9yZz47DQrmioTpgIHkurrvvJpSZXNoYWQgUmFo bWFuIChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb20+Ow0K5pelIOacnyDvvJoyMDE55bm0MTHm nIgxMOaXpSAwMzoyOA0K5Li7IOmimCDvvJpSZTogSUVURi0xMDYgYWdlbmRhPw0KDQoNCg0KDQpX b3JraW5nIEdyb3VwLA0KDQpXZSB3aWxsIGJlIGF0dGVtcHRpbmcgdG8gbWVldCBhdCBJRVRGLTEw Ni4gIFRoZXJlJ3MganVzdCBlbm91Z2ggYnVzaW5lc3MgdG8NCmRpc2N1c3MgdG8gd2FycmFudCB1 c2luZyBvdXIgdGltZSBzbG90Lg0KDQpOb3RlIGFzIGJlbG93OiBXZSBkbyBub3QgY3VycmVudGx5 IGhhdmUgYSBtaW51dGVzIHRha2VyLiAgSWYgd2UgZG8gbm90IGhhdmUNCm9uZSAoaWRlYWxseSB2 b2x1bnRlZXJpbmcgYWhlYWQgb2YgdGltZSkgYnkgbWVldGluZyBzdGFydCB0aW1lLCB3ZSB3aWxs DQpzdXNwZW5kIHdpdGhvdXQgYSBtZWV0aW5nLg0KDQpUaGUgYXV0aG9ycyBvZiBCRkQgZm9yIHZ4 bGFuIGFyZSByZXF1ZXN0ZWQgdG8gcHJlcGFyZSBzbGlkZXMgY292ZXJpbmcNCmNoYW5nZXMgc2lu Y2UgdGhlIGxhc3QgSUVURiBhbmQgYSBzdW1tYXJ5IG9mIHRoZSByYXRoZXIgZW5lcmdldGljIGRp c2N1c3Npb24NCndlJ3ZlIGhhZCBzaW5jZSB0aGF0IG1lZXRpbmcuICBBZGRpdGlvbmFsbHksIHBs ZWFzZSBzdW1tYXJpemUgdGhlIG9wZW4NCmlzc3VlcyBzaW5jZSB3ZSBoYXZlIGEgZmV3IHN0aWxs IGJlaW5nIGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4NCg0KUGxlYXNlIHJlY2FsbCB0aGF0IEJGRCBp cyBtZWV0aW5nIG9uIFR1ZXNkYXkuICBQbGVhc2Ugc2VuZCBtZSB5b3VyIHNsaWRlcyBieQ0KU3Vu ZGF5Lg0KDQotLS0tLQ0KDQpDdXJyZW50IHRhcmdldGVkIGFnZW5kYToNCg0KQ2hhaXJzIHVwZGF0 ZToNCiAgNSBtaW5zIC0gSmVmZiBIYWFzDQoNCkJGRCBmb3IgdnhsYW46IA0KICAxNSBtaW51dGVz IC0gVEJEDQoNCkJGRCBmb3IgTGFyZ2UgUGFja2V0czoNCiAgNSBtaW51dGVzIC0gSmVmZg0KDQpC RkQgRGVtYW5kIE1vZGU6DQogIDEwIG1pbnV0ZXMgLSBHcmVnDQoNClVzaW5nIE9uZS1Bcm0gQkZE IGluIENsb3VkIE5ldHdvcms6DQogIDEwIG1pbnV0ZXMNCg0KDQotLSBKZWZmDQoNCg0KT24gRnJp LCBOb3YgMDEsIDIwMTkgYXQgMDI6MTU6MzVQTSAtMDQwMCwgSmVmZnJleSBIYWFzIHdyb3RlOg0K PiBXb3JraW5nIEdyb3VwLA0KPiANCj4gQSBzZXNzaW9uIHJlcXVlc3QgaGFkIGdvbmUgaW4gZm9y IElFVEYgMTA2IHRvIGFjY29tbW9kYXRlIHRoZSBuZWVkIGZvciBhDQo+IHBvc3NpYmxlIHNlc3Np b24uICBUaGUgYWdlbmRhLCB0byB0aGlzIHBvaW50LCBoYWQgYmVlbiBsZWZ0IGFzIGFuIG9wZW4N Cj4gcXVlc3Rpb24gcHJpbWFyaWx5IHRvIGFjY29tbW9kYXRlIG5lZWQgdG8gY2xvc2Ugb24gbGlu Z2VyaW5nIHF1ZXN0aW9ucyBpbg0KPiBhY3RpdmUgd29yay4gIEluIHBhcnRpY3VsYXIsIHRoaXMg d2FzIGZvciB0d28gaXRlbXM6DQo+IA0KPiAtIEJGRCBmb3IgdnhsYW4NCj4gLSBCRkQgZm9yIExh cmdlIFBhY2tldHMNCj4gDQo+IChGb3IgdHJhbnNwYXJlbmN5LCBJIGFtIGFuIGF1dGhvciBvbiBC RkQgZm9yIGxhcmdlIHBhY2tldHMpDQo+IA0KPiBBcyBvZiB0aGlzIGFmdGVybm9vbiwgd2Ugc2Vl bSB0byBoYXZlIGRyYWZ0cyBzdWJtaXR0ZWQgdGhhdCBjb3ZlciB0aGUga25vd24NCj4gb3BlbiBp c3N1ZXMgb24gYm90aCBvZiB0aGVzZSBkcmFmdHMuICBJbiBwYXJ0aWN1bGFyLCB0aGUgd29yayB0 byBnZXQgdXMgdG8NCj4gdGhlIGxhdGVzdCBkcmFmdCBmb3IgdGhlIHZ4bGFuIGRvY3VtZW50IHRv b2sgb3ZlciAxNTAgbWVzc2FnZXMuDQo+IA0KPiBJZiBCRkQgbWVldHMsIGFnZW5kYSB0aW1lIHdh cyBwcmltYXJpbHkgcmVzZXJ2ZWQgdG8gcmVjb25jaWxlIG9wZW4gaXNzdWVzIG9uDQo+IHRoZXNl IGRvY3VtZW50cy4NCj4gDQo+IERpc2N1c3Npb24gb24gQkZEdjIgaXMgY3VycmVudGx5IGRlZmVy cmVkIGZvciBuZXh0IElFVEYgdG8gZm9jdXMgdGhlIFdvcmtpbmcNCj4gR3JvdXAncyBsaW1pdGVk IGF0dGVudGlvbiBvbiBjbG9zaW5nIG9wZW4gd29yay4NCj4gDQo+IFRoYXQgc2FpZCwgaWYgd2Ug aGF2ZSBvdGhlciB0b3BpY3MgdG8gY29uc2lkZXIsIHBsZWFzZSBzdWJtaXQgdGhlbSBmb3INCj4g Y29uc2lkZXJhdGlvbi4gIElmIHdlIGhhdmUgbm8gc3VjaCB0b3BpY3MsIGFuZCB0aGUgZGlzY3Vz c2lvbiBvbiB0aGUgYWJvdmUNCj4gdHdvIGRyYWZ0cyBzZWVtcyBsaWtlbHkgdG8gY29uY2x1ZGUg d2VsbCBvdmVyIGUtbWFpbCwgd2UgbWF5IGNvbnNpZGVyDQo+IGNhbmNlbGluZyB0aGUgc2Vzc2lv bi4NCj4gDQo+IEFzIGEgZmluYWwgbm90ZSwgc2luY2UgUmVzaGFkIGlzIHVuYWJsZSB0byBtYWtl IGl0IHRvIElFVEYtMTA2LCBpZiB3ZSBkbw0KPiBkZWNpZGUgdG8gY29udGludWUgd2l0aCBvdXIg bWVldGluZywgd2Ugd2lsbCByZXF1aXJlIHRoZSBjb21taXRtZW50IGZvciBhDQo+IG1pbnV0ZXMg dGFrZXIuICBSZXNoYWQgYW5kIEkgb2Z0ZW4gd2lsbCBjb3ZlciB0aGF0IGZvciBlYWNoIG90aGVy IG92ZXIgdGhlDQo+IGNvdXJzZSBvZiBhIHNlc3Npb24sIGJ1dCBJIHdvbid0IGJlIGFibGUgdG8g c3VzdGFpbiB0aGF0IG9uIG15IG93bi4NCj4gDQo+IC0tIEplZmYsIGZvciB0aGUgY2hhaXJzLg== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhpIEplZmYsPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+SSBjb3VsZCBiZSBvbmUgbWludXRlcyB0YWtlciBpZiBubyBvdGhlcnMgZXhwZXJp ZW5jZWQgdm9sdW50ZWVyZWQuPGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWls eTphcmlhbDsiPkJlc3QgUmVnYXJkcyw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQt ZmFtaWx5OmFyaWFsOyI+WGlhbyBNaW48L3A+PGRpdiBjbGFzcz0iek1haWxTaWduIiB1bm9uYW1l Y2g9IuiCluaVjzEwMDkzNTcwIiB1bm9uYW1lZW49InhpYW9taW4xMDA5MzU3MCI+PGRpdiBjbGFz cz0iek1haWxTaWduQ29udGVudCI+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iek1haWxGcm9tIj48 L2Rpdj48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHlsZT0iZGlzcGxheTpibG9jayI+ PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDogMTAwJTsgaGVpZ2h0OiAyOHB4 OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjogI0UwRTVFOTsgY29sb3I6ICMx Mzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlPcmdUeHQi PuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPjxkaXYg Y2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlI ZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48 ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R5Lu25Lq677ya PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPkplZmZyZXlIYWFzICZsdDtqaGFh c0BwZnJjLm9yZyZndDs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhp c3RvcnlUT1R4dCI+5pS25Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5h bWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5ydGctYmZkQGlldGYub3JnICZsdDtydGctYmZk QGlldGYub3JnJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhp c3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5h bWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5SZXNoYWQgUmFobWFuIChycmFobWFuKSAmbHQ7 cnJhaG1hbkBjaXNjby5jb20mZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2Ut ZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+ MjAxOeW5tDEx5pyIMTDml6UgMDM6Mjg8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdl LWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNz PSJ6cmVhZFRpdGxlIj48c3Ryb25nPlJlOiBJRVRGLTEwNiBhZ2VuZGE/PC9zdHJvbmc+PC9zcGFu PjwvZGl2PjwvZGl2PjxkaXYgem1haWxidXNpbmVzcz0iYnVzaW5lc3NFeHRlcm5hbCI+PC9kaXY+ PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2PldvcmtpbmcmbmJzcDtHcm91cCw8YnI+ PGJyPldlJm5ic3A7d2lsbCZuYnNwO2JlJm5ic3A7YXR0ZW1wdGluZyZuYnNwO3RvJm5ic3A7bWVl dCZuYnNwO2F0Jm5ic3A7SUVURi0xMDYuJm5ic3A7Jm5ic3A7VGhlcmUncyZuYnNwO2p1c3QmbmJz cDtlbm91Z2gmbmJzcDtidXNpbmVzcyZuYnNwO3RvPGJyPmRpc2N1c3MmbmJzcDt0byZuYnNwO3dh cnJhbnQmbmJzcDt1c2luZyZuYnNwO291ciZuYnNwO3RpbWUmbmJzcDtzbG90Ljxicj48YnI+Tm90 ZSZuYnNwO2FzJm5ic3A7YmVsb3c6Jm5ic3A7V2UmbmJzcDtkbyZuYnNwO25vdCZuYnNwO2N1cnJl bnRseSZuYnNwO2hhdmUmbmJzcDthJm5ic3A7bWludXRlcyZuYnNwO3Rha2VyLiZuYnNwOyZuYnNw O0lmJm5ic3A7d2UmbmJzcDtkbyZuYnNwO25vdCZuYnNwO2hhdmU8YnI+b25lJm5ic3A7KGlkZWFs bHkmbmJzcDt2b2x1bnRlZXJpbmcmbmJzcDthaGVhZCZuYnNwO29mJm5ic3A7dGltZSkmbmJzcDti eSZuYnNwO21lZXRpbmcmbmJzcDtzdGFydCZuYnNwO3RpbWUsJm5ic3A7d2UmbmJzcDt3aWxsPGJy PnN1c3BlbmQmbmJzcDt3aXRob3V0Jm5ic3A7YSZuYnNwO21lZXRpbmcuPGJyPjxicj5UaGUmbmJz cDthdXRob3JzJm5ic3A7b2YmbmJzcDtCRkQmbmJzcDtmb3ImbmJzcDt2eGxhbiZuYnNwO2FyZSZu YnNwO3JlcXVlc3RlZCZuYnNwO3RvJm5ic3A7cHJlcGFyZSZuYnNwO3NsaWRlcyZuYnNwO2NvdmVy aW5nPGJyPmNoYW5nZXMmbmJzcDtzaW5jZSZuYnNwO3RoZSZuYnNwO2xhc3QmbmJzcDtJRVRGJm5i c3A7YW5kJm5ic3A7YSZuYnNwO3N1bW1hcnkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3JhdGhlciZu YnNwO2VuZXJnZXRpYyZuYnNwO2Rpc2N1c3Npb248YnI+d2UndmUmbmJzcDtoYWQmbmJzcDtzaW5j ZSZuYnNwO3RoYXQmbmJzcDttZWV0aW5nLiZuYnNwOyZuYnNwO0FkZGl0aW9uYWxseSwmbmJzcDtw bGVhc2UmbmJzcDtzdW1tYXJpemUmbmJzcDt0aGUmbmJzcDtvcGVuPGJyPmlzc3VlcyZuYnNwO3Np bmNlJm5ic3A7d2UmbmJzcDtoYXZlJm5ic3A7YSZuYnNwO2ZldyZuYnNwO3N0aWxsJm5ic3A7YmVp bmcmbmJzcDtkaXNjdXNzZWQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2xpc3QuPGJyPjxicj5QbGVh c2UmbmJzcDtyZWNhbGwmbmJzcDt0aGF0Jm5ic3A7QkZEJm5ic3A7aXMmbmJzcDttZWV0aW5nJm5i c3A7b24mbmJzcDtUdWVzZGF5LiZuYnNwOyZuYnNwO1BsZWFzZSZuYnNwO3NlbmQmbmJzcDttZSZu YnNwO3lvdXImbmJzcDtzbGlkZXMmbmJzcDtieTxicj5TdW5kYXkuPGJyPjxicj4tLS0tLTxicj48 YnI+Q3VycmVudCZuYnNwO3RhcmdldGVkJm5ic3A7YWdlbmRhOjxicj48YnI+Q2hhaXJzJm5ic3A7 dXBkYXRlOjxicj4mbmJzcDsmbmJzcDs1Jm5ic3A7bWlucyZuYnNwOy0mbmJzcDtKZWZmJm5ic3A7 SGFhczxicj48YnI+QkZEJm5ic3A7Zm9yJm5ic3A7dnhsYW46Jm5ic3A7PGJyPiZuYnNwOyZuYnNw OzE1Jm5ic3A7bWludXRlcyZuYnNwOy0mbmJzcDtUQkQ8YnI+PGJyPkJGRCZuYnNwO2ZvciZuYnNw O0xhcmdlJm5ic3A7UGFja2V0czo8YnI+Jm5ic3A7Jm5ic3A7NSZuYnNwO21pbnV0ZXMmbmJzcDst Jm5ic3A7SmVmZjxicj48YnI+QkZEJm5ic3A7RGVtYW5kJm5ic3A7TW9kZTo8YnI+Jm5ic3A7Jm5i c3A7MTAmbmJzcDttaW51dGVzJm5ic3A7LSZuYnNwO0dyZWc8YnI+PGJyPlVzaW5nJm5ic3A7T25l LUFybSZuYnNwO0JGRCZuYnNwO2luJm5ic3A7Q2xvdWQmbmJzcDtOZXR3b3JrOjxicj4mbmJzcDsm bmJzcDsxMCZuYnNwO21pbnV0ZXM8YnI+PGJyPjxicj4tLSZuYnNwO0plZmY8YnI+PGJyPjxicj5P biZuYnNwO0ZyaSwmbmJzcDtOb3YmbmJzcDswMSwmbmJzcDsyMDE5Jm5ic3A7YXQmbmJzcDswMjox NTozNVBNJm5ic3A7LTA0MDAsJm5ic3A7SmVmZnJleSZuYnNwO0hhYXMmbmJzcDt3cm90ZTo8YnI+ Jmd0OyZuYnNwO1dvcmtpbmcmbmJzcDtHcm91cCw8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7 QSZuYnNwO3Nlc3Npb24mbmJzcDtyZXF1ZXN0Jm5ic3A7aGFkJm5ic3A7Z29uZSZuYnNwO2luJm5i c3A7Zm9yJm5ic3A7SUVURiZuYnNwOzEwNiZuYnNwO3RvJm5ic3A7YWNjb21tb2RhdGUmbmJzcDt0 aGUmbmJzcDtuZWVkJm5ic3A7Zm9yJm5ic3A7YTxicj4mZ3Q7Jm5ic3A7cG9zc2libGUmbmJzcDtz ZXNzaW9uLiZuYnNwOyZuYnNwO1RoZSZuYnNwO2FnZW5kYSwmbmJzcDt0byZuYnNwO3RoaXMmbmJz cDtwb2ludCwmbmJzcDtoYWQmbmJzcDtiZWVuJm5ic3A7bGVmdCZuYnNwO2FzJm5ic3A7YW4mbmJz cDtvcGVuPGJyPiZndDsmbmJzcDtxdWVzdGlvbiZuYnNwO3ByaW1hcmlseSZuYnNwO3RvJm5ic3A7 YWNjb21tb2RhdGUmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtjbG9zZSZuYnNwO29uJm5ic3A7bGlu Z2VyaW5nJm5ic3A7cXVlc3Rpb25zJm5ic3A7aW48YnI+Jmd0OyZuYnNwO2FjdGl2ZSZuYnNwO3dv cmsuJm5ic3A7Jm5ic3A7SW4mbmJzcDtwYXJ0aWN1bGFyLCZuYnNwO3RoaXMmbmJzcDt3YXMmbmJz cDtmb3ImbmJzcDt0d28mbmJzcDtpdGVtczo8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7LSZu YnNwO0JGRCZuYnNwO2ZvciZuYnNwO3Z4bGFuPGJyPiZndDsmbmJzcDstJm5ic3A7QkZEJm5ic3A7 Zm9yJm5ic3A7TGFyZ2UmbmJzcDtQYWNrZXRzPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyhG b3ImbmJzcDt0cmFuc3BhcmVuY3ksJm5ic3A7SSZuYnNwO2FtJm5ic3A7YW4mbmJzcDthdXRob3Im bmJzcDtvbiZuYnNwO0JGRCZuYnNwO2ZvciZuYnNwO2xhcmdlJm5ic3A7cGFja2V0cyk8YnI+Jmd0 OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7QXMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDthZnRlcm5vb24s Jm5ic3A7d2UmbmJzcDtzZWVtJm5ic3A7dG8mbmJzcDtoYXZlJm5ic3A7ZHJhZnRzJm5ic3A7c3Vi bWl0dGVkJm5ic3A7dGhhdCZuYnNwO2NvdmVyJm5ic3A7dGhlJm5ic3A7a25vd248YnI+Jmd0OyZu YnNwO29wZW4mbmJzcDtpc3N1ZXMmbmJzcDtvbiZuYnNwO2JvdGgmbmJzcDtvZiZuYnNwO3RoZXNl Jm5ic3A7ZHJhZnRzLiZuYnNwOyZuYnNwO0luJm5ic3A7cGFydGljdWxhciwmbmJzcDt0aGUmbmJz cDt3b3JrJm5ic3A7dG8mbmJzcDtnZXQmbmJzcDt1cyZuYnNwO3RvPGJyPiZndDsmbmJzcDt0aGUm bmJzcDtsYXRlc3QmbmJzcDtkcmFmdCZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Z4bGFuJm5ic3A7 ZG9jdW1lbnQmbmJzcDt0b29rJm5ic3A7b3ZlciZuYnNwOzE1MCZuYnNwO21lc3NhZ2VzLjxicj4m Z3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDtJZiZuYnNwO0JGRCZuYnNwO21lZXRzLCZuYnNwO2FnZW5k YSZuYnNwO3RpbWUmbmJzcDt3YXMmbmJzcDtwcmltYXJpbHkmbmJzcDtyZXNlcnZlZCZuYnNwO3Rv Jm5ic3A7cmVjb25jaWxlJm5ic3A7b3BlbiZuYnNwO2lzc3VlcyZuYnNwO29uPGJyPiZndDsmbmJz cDt0aGVzZSZuYnNwO2RvY3VtZW50cy48YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7RGlzY3Vz c2lvbiZuYnNwO29uJm5ic3A7QkZEdjImbmJzcDtpcyZuYnNwO2N1cnJlbnRseSZuYnNwO2RlZmVy cmVkJm5ic3A7Zm9yJm5ic3A7bmV4dCZuYnNwO0lFVEYmbmJzcDt0byZuYnNwO2ZvY3VzJm5ic3A7 dGhlJm5ic3A7V29ya2luZzxicj4mZ3Q7Jm5ic3A7R3JvdXAncyZuYnNwO2xpbWl0ZWQmbmJzcDth dHRlbnRpb24mbmJzcDtvbiZuYnNwO2Nsb3NpbmcmbmJzcDtvcGVuJm5ic3A7d29yay48YnI+Jmd0 OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7VGhhdCZuYnNwO3NhaWQsJm5ic3A7aWYmbmJzcDt3ZSZuYnNw O2hhdmUmbmJzcDtvdGhlciZuYnNwO3RvcGljcyZuYnNwO3RvJm5ic3A7Y29uc2lkZXIsJm5ic3A7 cGxlYXNlJm5ic3A7c3VibWl0Jm5ic3A7dGhlbSZuYnNwO2Zvcjxicj4mZ3Q7Jm5ic3A7Y29uc2lk ZXJhdGlvbi4mbmJzcDsmbmJzcDtJZiZuYnNwO3dlJm5ic3A7aGF2ZSZuYnNwO25vJm5ic3A7c3Vj aCZuYnNwO3RvcGljcywmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtkaXNjdXNzaW9uJm5ic3A7b24m bmJzcDt0aGUmbmJzcDthYm92ZTxicj4mZ3Q7Jm5ic3A7dHdvJm5ic3A7ZHJhZnRzJm5ic3A7c2Vl bXMmbmJzcDtsaWtlbHkmbmJzcDt0byZuYnNwO2NvbmNsdWRlJm5ic3A7d2VsbCZuYnNwO292ZXIm bmJzcDtlLW1haWwsJm5ic3A7d2UmbmJzcDttYXkmbmJzcDtjb25zaWRlcjxicj4mZ3Q7Jm5ic3A7 Y2FuY2VsaW5nJm5ic3A7dGhlJm5ic3A7c2Vzc2lvbi48YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5i c3A7QXMmbmJzcDthJm5ic3A7ZmluYWwmbmJzcDtub3RlLCZuYnNwO3NpbmNlJm5ic3A7UmVzaGFk Jm5ic3A7aXMmbmJzcDt1bmFibGUmbmJzcDt0byZuYnNwO21ha2UmbmJzcDtpdCZuYnNwO3RvJm5i c3A7SUVURi0xMDYsJm5ic3A7aWYmbmJzcDt3ZSZuYnNwO2RvPGJyPiZndDsmbmJzcDtkZWNpZGUm bmJzcDt0byZuYnNwO2NvbnRpbnVlJm5ic3A7d2l0aCZuYnNwO291ciZuYnNwO21lZXRpbmcsJm5i c3A7d2UmbmJzcDt3aWxsJm5ic3A7cmVxdWlyZSZuYnNwO3RoZSZuYnNwO2NvbW1pdG1lbnQmbmJz cDtmb3ImbmJzcDthPGJyPiZndDsmbmJzcDttaW51dGVzJm5ic3A7dGFrZXIuJm5ic3A7Jm5ic3A7 UmVzaGFkJm5ic3A7YW5kJm5ic3A7SSZuYnNwO29mdGVuJm5ic3A7d2lsbCZuYnNwO2NvdmVyJm5i c3A7dGhhdCZuYnNwO2ZvciZuYnNwO2VhY2gmbmJzcDtvdGhlciZuYnNwO292ZXImbmJzcDt0aGU8 YnI+Jmd0OyZuYnNwO2NvdXJzZSZuYnNwO29mJm5ic3A7YSZuYnNwO3Nlc3Npb24sJm5ic3A7YnV0 Jm5ic3A7SSZuYnNwO3dvbid0Jm5ic3A7YmUmbmJzcDthYmxlJm5ic3A7dG8mbmJzcDtzdXN0YWlu Jm5ic3A7dGhhdCZuYnNwO29uJm5ic3A7bXkmbmJzcDtvd24uPGJyPiZndDsmbmJzcDs8YnI+Jmd0 OyZuYnNwOy0tJm5ic3A7SmVmZiwmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtjaGFpcnMuPGJyPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Nov 11 00:11:25 2019 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 842C7120857 for ; Mon, 11 Nov 2019 00:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 iW7e7g6yn_Z5 for ; Mon, 11 Nov 2019 00:11:21 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C986E120850 for ; Mon, 11 Nov 2019 00:11:21 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3068A1E2F5; Mon, 11 Nov 2019 03:15:10 -0500 (EST) Date: Mon, 11 Nov 2019 03:15:10 -0500 From: Jeffrey Haas To: xiao.min2@zte.com.cn Cc: rtg-bfd@ietf.org, rrahman@cisco.com Subject: Re: IETF-106 agenda? Message-ID: <20191111081509.GA32420@pfrc.org> References: <20191109193200.GD19227@pfrc.org> <201911111448470627265@zte.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201911111448470627265@zte.com.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Mon, 11 Nov 2019 08:11:23 -0000 Xiao Min, On Mon, Nov 11, 2019 at 02:48:47PM +0800, xiao.min2@zte.com.cn wrote: > Hi Jeff, > > I could be one minutes taker if no others experienced volunteered. Thank you. That's all we need. And with etherpad others may help too. -- Jeff From nobody Mon Nov 11 23:57:21 2019 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 408241200A1; Mon, 11 Nov 2019 23:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 kyCB3ewEgWQQ; Mon, 11 Nov 2019 23:57:13 -0800 (PST) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 238A91201E3; Mon, 11 Nov 2019 23:57:10 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5dca65b08b9-cae16; Tue, 12 Nov 2019 15:56:32 +0800 (CST) X-RM-TRANSID: 2eea5dca65b08b9-cae16 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.2.51.55]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75dca65a5de0-08d87; Tue, 12 Nov 2019 15:56:32 +0800 (CST) X-RM-TRANSID: 2ee75dca65a5de0-08d87 From: "Weiqiang Cheng" To: "'Jeffrey Haas'" Cc: , , =?gb2312?B?J831yPDRqSc=?= , References: <028a01d59380$e2350480$a69f0d80$@com> <20191109191204.GC19227@pfrc.org> In-Reply-To: <20191109191204.GC19227@pfrc.org> Subject: Re: The usecase of the BFD application Date: Tue, 12 Nov 2019 15:56:23 +0800 Message-ID: <001b01d5992e$adf704d0$09e50e70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdWXMjfxz+DIgR8dQ9G8QVxBdyIqswB+WqSg Content-Language: zh-cn Archived-At: 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: Tue, 12 Nov 2019 07:57:18 -0000 Hi Jeffrey, Thanks for your comments.=20 We will cover those points in the presentation. =20 We just have a quick review on TR-146, where it says that Echo function = is=20 used and the destination IP is set to an IP address of the sender (the=20 latter is similar to the One-arm idea) for unidirectional failure = detection. =20 But based on our understanding, BFD Echo requires that the receiver must = be=20 able to recognize and process BFD control packet. One-arm idea assumes = that=20 the receiving end is completely unaware of BFD, it just forwards the = packet=20 based on routing. This is very useful in the scenario (e.g., Data Center = or=20 4G/5G Telecom Cloud) where large number of BFD sessions may be needed, = and=20 the receiver cannot handle too much BFD sessions with limited resource. = The idea is straight forward, we will include more details (e.g., = session=20 establishment, state machine, YANG etc.) in the next version. That is nice to have a slot to discuss the topic. =20 B.R. Weiqiang Cheng -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA11=D4=C210=C8=D5 03:12 =CA=D5=BC=FE=C8=CB: Weiqiang Cheng =B3=AD=CB=CD: bfd-chairs@ietf.org; rtg-bfd@ietf.org; = '=CD=F5=C8=F0=D1=A9'; liu.aihua@zte.com.cn =D6=F7=CC=E2: Re: The usecase of the BFD application Weiqiang Cheng, BFD appears to be likely to have a small amount of business at the = upcoming IETF-106. The working grooup needs to find a secretary to commit to = minutes for us to meet. If we do meet, you may have 10 minutes to discuss this. I will ask you to include the following information in your = presentation: - How does this proposal differ from BBF TR-146? (https://www.broadband-forum.org/download/TR-146.pdf) - What are the implications for BFD clients? This would include BFD = yang models. -- Jeff On Tue, Nov 05, 2019 at 10:29:43AM +0800, Weiqiang Cheng wrote: > Hi Chairs, >=20 > We prepared a draft to use BFD in datacenter application scenario. >=20 > Because the time zone difference, we missed the submission deadline = and we > will upload it on Nov. 16. >=20 > If possible, we still hope to apply a slot to present it. Could you = see if > it is Ok for the group? >=20 > =20 >=20 > B.R. >=20 > Weiqiang Cheng >=20 >=20 >=20 >=20 > BFD Working Group R. = Wang > Internet-Draft W. = Cheng > Intended status: Informational China = Mobile > Expires: May 7, 2020 Y. = Zhao > A. = Liu > = ZTE > November 4, = 2019 >=20 >=20 > Using One-Arm BFD in Cloud Network > draft-wang-bfd-one-arm-use-case-00 >=20 > Abstract >=20 > Bidirectional Forwarding Detection (BFD) is a fault detection > protocol that can quickly determine a communication failure between > devices and notify upper-layer applications [RFC5880]. BFD has > asynchronous detecting mode and demand detection mode to satisfy > different scenarios, also supports echo function to reduce the = device > requirement for BFD. One-Arm BFD this draft descripted supports > another BFD detecting function rather than the echo as described in > [RFC5880] [RFC5881], it needs nothing BFD capability to one of the > devices deployed BFD detecting. Using One-Arm BFD function, the = one > device works on BFD detecting normally and the other device just > loopback the BFD packets like echo function. One-Arm BFD is = suitable > for the cloud virtualization network, the One-Arm BFD is deploy on > NFV gateways, and NFV virtual machine vNICs just enable the echo/ > loopback process. >=20 > Status of This Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current = Internet- > Drafts is at https://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at = any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on May 7, 2020. >=20 >=20 >=20 >=20 >=20 >=20 > Wang, et al. Expires May 7, 2020 [Page = 1] >=20 > Internet-Draft Using One-Arm BFD in Cloud Network November = 2019 >=20 >=20 > Copyright Notice >=20 > Copyright (c) 2019 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (https://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document = must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 2 > 1.1. Conventions Used in This Document . . . . . . . . . . . . = 3 > 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . = 3 > 1.1.2. Requirements Language . . . . . . . . . . . . . . . . = 3 > 2. One-Arm BFD Use Case . . . . . . . . . . . . . . . . . . . . = 3 > 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . = 4 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . = 4 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 4 > 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 4 > 7. Normative References . . . . . . . . . . . . . . . . . . . . = 4 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 5 >=20 > 1. Introduction >=20 > To minimize the impact of device faults on services and improve > network availability, a network device must be able to quickly = detect > faults in communication with adjacent devices. Measures can then = be > taken to promptly rectify the faults to ensure service continuity. >=20 > BFD is a low-overhead, short-duration method to detect faults on = the > path between adjacent forwarding engines. The faults can be > interface, data link, and even forwarding engine faults. It is a > single, unified mechanism to monitor any media and protocol layers = in > real time. >=20 > BFD has asynchronous detecting mode and demand detection mode to > satisfy different scenarios, also supports echo function to reduce > the device requirement for BFD. BFD echo function is used when two > devices are connected but only one of them supports full BFD > capability. When the echo function is activated, the local system > sends a BFD control packet and the remote system loops back the >=20 >=20 >=20 > Wang, et al. Expires May 7, 2020 [Page = 2] >=20 > Internet-Draft Using One-Arm BFD in Cloud Network November = 2019 >=20 >=20 > packet through the forwarding channel. If several consecutive echo > packets are not received, the session is declared to be Down. BFD > echo function reduces one of the two devices requirement for BFD. >=20 > With the development of network cloud and NFV virtualization, there > are many connections between gateway devices and the virtual = machine > devices. The virtual machine devices don't support BFD capacity at > all. There is difficult to deploy BFD between the gateway devices > and the virtual machine vNICs. One-Arm BFD supports this scenario, > it supports gateway enable full BFD capability and virtual machine > don't support BFD at all, just simply loopback BFD packets on = vNICs. >=20 > 1.1. Conventions Used in This Document >=20 > 1.1.1. Terminology >=20 > BFD: Bidirectional Forwarding Detection >=20 > NFV: Network Function Virtualization >=20 > 1.1.2. Requirements Language >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", = and > "OPTIONAL" in this document are to be interpreted as described in = BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. >=20 > 2. One-Arm BFD Use Case >=20 > With the development of network cloud and NFV virtualization, there > are many connections between gateway devices and the virtual = machine > devices. The virtual machine(VM) devices don't support BFD = capacity > at all. If the gateway devices are deployed BFD protocol, there = are > some problems including scalability, detecting period and so on. = And > the VM can't support BFD protocol currently. One-Arm echo BFD can > resolve these problems. One-arm echo BFD is used when two devices > are connected and only one of them supports BFD. A one-arm BFD = echo > session can be established on the device that supports BFD, the = other > device just loopback BFD packets. >=20 > After receiving a one-arm BFD echo session packet, the device that > does not support BFD immediately loops back the packet, = implementing > quick link failure detection. As shown in Figure 1, Device A such = as > a NFV gateway supports BFD, whereas Device B such as a virtual > machine does not. To rapidly detect faults in the link between > Device A and Device B, configure a one-arm BFD echo session on = Device > A. After receiving a one-arm BFD echo session packet from Device = A, >=20 >=20 >=20 > Wang, et al. Expires May 7, 2020 [Page = 3] >=20 > Internet-Draft Using One-Arm BFD in Cloud Network November = 2019 >=20 >=20 > Device B immediately loops back the packet, implementing rapid link > fault detection. >=20 >=20 > Device A One-Arm Echo Device B > +--------+ BFD session +---------+ > | A |---------------------------------| B | > | |Inf 1 Inf 1| | > +--------+10.1.1.1/24 10.1.1.2/24+---------+ > BFD is supported. BFD is not supported. >=20 >=20 > Figure 1: One-Arm BFD deploying scenario >=20 > 3. Discussion >=20 > One-Arm BFD detecting function is better than BFD echo function = mode. > First One-Arm BFD can use full BFD capacity in the BFD-supported > device. So One-Arm BFD can also support fast detecting and manage > BFD sessions effectively. Second it is scalable using one-arm BFD > detecting to adapt the NFV virtualization. Finally, it is the same > process in the non-BFD-supported devices with echo function. So = one- > arm BFD can be deployed to the cloud network, and the VMs don't > require to support BFD capacity. >=20 > 4. Security Considerations >=20 > TBD. >=20 > 5. IANA Considerations >=20 > This document has no IANA action requested. >=20 > 6. Acknowledgements >=20 > TBD. >=20 > 7. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . >=20 > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding = Detection > (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, > . >=20 >=20 >=20 >=20 > Wang, et al. Expires May 7, 2020 [Page = 4] >=20 > Internet-Draft Using One-Arm BFD in Cloud Network November = 2019 >=20 >=20 > [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding = Detection > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, > DOI 10.17487/RFC5881, June 2010, > . >=20 > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, . >=20 > Authors' Addresses >=20 > Ruixue Wang > China Mobile > Beijing > CN >=20 > Email: wangruixue@chinamobile.com >=20 >=20 > Weiqiang Cheng > China Mobile > Beijing > CN >=20 > Email: chengweiqiang@chinamobile.com >=20 >=20 > Yanhua Zhao > ZTE > Nanjing > CN >=20 > Email: zhao.yanhua3@zte.com.cn >=20 >=20 > Aihua Liu > ZTE > Shenzhen > CN >=20 > Email: liu.aihua@zte.com.cn >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Wang, et al. Expires May 7, 2020 [Page = 5] >=20 From nobody Tue Nov 12 00:13:39 2019 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 5E2E312012C; Tue, 12 Nov 2019 00:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 mGIEksypDUWy; Tue, 12 Nov 2019 00:13:35 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 902B4120046; Tue, 12 Nov 2019 00:13:35 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AD05C1E2F5; Tue, 12 Nov 2019 03:17:24 -0500 (EST) Date: Tue, 12 Nov 2019 03:17:24 -0500 From: Jeffrey Haas To: Weiqiang Cheng Cc: bfd-chairs@ietf.org, rtg-bfd@ietf.org, =?utf-8?B?J+eOi+eRnumbqic=?= , liu.aihua@zte.com.cn Subject: Re: The usecase of the BFD application Message-ID: <20191112081724.GC32420@pfrc.org> References: <028a01d59380$e2350480$a69f0d80$@com> <20191109191204.GC19227@pfrc.org> <001b01d5992e$adf704d0$09e50e70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001b01d5992e$adf704d0$09e50e70$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Tue, 12 Nov 2019 08:13:37 -0000 Weiqiang Cheng, On Tue, Nov 12, 2019 at 03:56:23PM +0800, Weiqiang Cheng wrote: > We will cover those points in the presentation. Thank you. > We just have a quick review on TR-146, where it says that Echo function is > used and the destination IP is set to an IP address of the sender (the > latter is similar to the One-arm idea) for unidirectional failure detection. > > But based on our understanding, BFD Echo requires that the receiver must be > able to recognize and process BFD control packet. One-arm idea assumes that > the receiving end is completely unaware of BFD, it just forwards the packet > based on routing. This is very useful in the scenario (e.g., Data Center or > 4G/5G Telecom Cloud) where large number of BFD sessions may be needed, and > the receiver cannot handle too much BFD sessions with limited resource. TR-146 similarly does not use any BFD signaling, so it is very similar (identical?) to your Internet-Draft. > The idea is straight forward, we will include more details (e.g., session > establishment, state machine, YANG etc.) in the next version. Thank you. -- Jeff From nobody Tue Nov 19 19:21:41 2019 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 6EC771201EF; Tue, 19 Nov 2019 18:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vxesKSMYFy_U; Tue, 19 Nov 2019 18:42:00 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D8F831201E0; Tue, 19 Nov 2019 18:41:59 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id d6so18853575lfc.0; Tue, 19 Nov 2019 18:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6tSMg4LZCvRFYPqpSou/YN1Xv82VXsjxLPlcrjVa1gw=; b=dZBuYMCoB/rGcMPWiMKGH4Ib9jJ8FIBU0SuDovfbthRBgHMt4d3kIDHXLvjqLaN0bJ I1HRbHyG75132OicNaPEpN921gtLhoACa2Gy0ov6JfzoNZ29ntc6ju5cegdqWEdWqJsK F2C1ePKFhYt7cWoWOxxGMgYP1TYlkW+W4YD5QwGkiZ7+ed8tJLO7pQ5Y0ITYsPF5kfYe gaj678SZFxp0ajcxAkAiIzyfuKOvD7G2vYzOBo0RXe/n0kXchDOKN2VONX5PQjQ3D6Gu nt6gI0pwwULwZH9vZP74gKuAoAzijPE06SDIGGNT4wpc8Xt3ChaxFG5Su/vvVG70nUiK AXnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6tSMg4LZCvRFYPqpSou/YN1Xv82VXsjxLPlcrjVa1gw=; b=dxr/e1/D+TEYNeVGpakMUwVQo/kLuzzAHpDGQhF/9vtcqIsRkrMfQ6t3pkyP+ltXuj 5Ao2PGcvpcakGJJDIZ8Jxqqlg0M1IYS1Y3keElsGCY7y2dNSah7sX0gWtMfRgiSEIJWn hTgkMg78mL7R8x0FBIpgCoHvcsU6htBvJD5WeGgHrgrT2v/wrCpxTjB2Lo46wnDh7/0g K+56bUCaXCbtEK4FwsXCudncu6V95uEH4pzydU6UmHxOmSjbBFPdRh+VHp3SmTW+BbzB gZY+FStdY2cJS3t7STpERT+WfPmRTuQhXaI1nvzNIDyvGJxQCvTHg3DAodABGuR8TaH7 FAOA== X-Gm-Message-State: APjAAAXgb0eIYc9hwbBYMyjvqqoit/dWRTTZ8rBoXKczXELQrbEUA8K+ CbqEime7g0xx/iRivDf96xQzPQzif38HrAemN6NHRLZJDKI= X-Google-Smtp-Source: APXvYqyORqz9e1GO6nCawXrJb8pu8lfoJ47h/SjiJsFC0dsMBSX/SYTJKQokzEPTp8wCSsOPbFbS4xke6mQSvvCD5sY= X-Received: by 2002:a05:6512:486:: with SMTP id v6mr536138lfq.72.1574217717651; Tue, 19 Nov 2019 18:41:57 -0800 (PST) MIME-Version: 1.0 From: Greg Mirsky Date: Wed, 20 Nov 2019 10:41:46 +0800 Message-ID: Subject: Update to BFD over VXLAN To: rtg-bfd WG , bfd-chairs@ietf.org, Martin Vigoureux Content-Type: multipart/mixed; boundary="000000000000dc44870597be1fa2" Archived-At: X-Mailman-Approved-At: Tue, 19 Nov 2019 19:21:36 -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: Wed, 20 Nov 2019 02:42:03 -0000 --000000000000dc44870597be1fa2 Content-Type: multipart/alternative; boundary="000000000000dc44850597be1fa0" --000000000000dc44850597be1fa0 Content-Type: text/plain; charset="UTF-8" Dear All, as was decided at the meeting, an explanation of using an address from the Internal host loopback interface address range has been added into the Security Consideration section: NEW TEXT: This document recommends using an address from the Internal host loopback addresses range as the destination IP address in the inner IP header. Using such address prevents the forwarding of the encapsulated BFD control message by a transient node in case the VXLAN tunnel is broken as according to [RFC1812]: A router SHOULD NOT forward, except over a loopback interface, any packet that has a destination address on network 127. A router MAY have a switch that allows the network manager to disable these checks. If such a switch is provided, it MUST default to performing the checks. Welcome your comments and suggestions. If the update is acceptable, will upload the new version. Attached are the diff and the working version of the draft. Regards, Greg . --000000000000dc44850597be1fa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
as was decided at the meeting, an explanatio= n of using an address from the Internal host loopback interface address ran= ge has been added into the Security Consideration section:
NEW TE= XT:
=C2=A0 =C2=A0This document recommends using an address from t= he Internal host
=C2=A0 =C2=A0loopback addresses range as the destinatio= n IP address in the inner
=C2=A0 =C2=A0IP header. Using such address pre= vents the forwarding of the
=C2=A0 =C2=A0encapsulated BFD control messag= e by a transient node in case the
=C2=A0 =C2=A0VXLAN tunnel is broken as= according to [RFC1812]:

=C2=A0 =C2=A0 =C2=A0 A router SHOULD NOT fo= rward, except over a loopback interface, any
=C2=A0 =C2=A0 =C2=A0 packet= that has a destination address on network 127.=C2=A0 A router
=C2=A0 = =C2=A0 =C2=A0 MAY have a switch that allows the network manager to disable = these
=C2=A0 =C2=A0 =C2=A0 checks.=C2=A0 If such a switch is provided, i= t MUST default to
=C2=A0 =C2=A0 =C2=A0 performing the checks.
<= div>
Welcome your comments and suggestions. If the update is = acceptable, will upload the new version.

Attached = are the diff and the working version of the draft.

Regards,
Greg
.

--000000000000dc44850597be1fa0-- --000000000000dc44870597be1fa2 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-bfd-vxlan-09.txt" Content-Disposition: attachment; filename="draft-ietf-bfd-vxlan-09.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k36ok6yn0 CgoKCkJGRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIFBhbGxhZ2F0dGksIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWTXdhcmUKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFBhcmFnaXJpCkV4cGly ZXM6IE1heSAyMiwgMjAyMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBD b250cmlidXRvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVi4gR292aW5kYW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gTXVkaWdvbmRhCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNj bwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBHLiBNaXJza3kKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciAxOSwgMjAxOQoKCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTgogICAgICAgICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLWJmZC12eGxhbi0wOQoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZwogICBEZXRl Y3Rpb24gKEJGRCkgcHJvdG9jb2wgaW4gcG9pbnQtdG8tcG9pbnQgVmlydHVhbCBlWHRlbnNpYmxl IExvY2FsCiAgIEFyZWEgTmV0d29yayAoVlhMQU4pIHR1bm5lbHMgZm9ybWluZyB1cCBhbiBvdmVy bGF5IG5ldHdvcmsuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMg b2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXkgMjIsIDIwMjAuCgpDb3B5cmln aHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNv bnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVU RiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMK ICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0 aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0CgoKClBhbGxhZ2F0dGksIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMjAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJGRCBmb3IgVlhMQU4gICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAxOQoKCiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0 cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3Qg TGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVu dHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgMgogICAyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3Vt ZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgICAyLjEuICBUZXJtaW5vbG9n eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAg Mi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgMwogICAzLiAgRGVwbG95bWVudCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgNC4gIEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9u IG92ZXIgVlhMQU4gVHVubmVsIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDUuICBSZWNlcHRp b24gb2YgQkZEIFBhY2tldCBmcm9tIFZYTEFOIFR1bm5lbCAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NwogICAgIDUuMS4gIERlbXVsdGlwbGV4aW5nIG9mIHRoZSBCRkQgUGFja2V0ICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDgKICAgNi4gIFVzZSBvZiB0aGUgU3BlY2lmaWMgVk5JIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgIDcuICBFY2hvIEJGRCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICA4LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDgKICAgOS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgIDEwLiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAxMS4gQWNrbm93bGVk Z21lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkK ICAgMTIuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA5CiAgICAgMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAgIDEyLjIuICBJbmZvcm1hdGlvbmFs IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgQXV0aG9y cycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEwCgoxLiAgSW50cm9kdWN0aW9uCgogICAiVmlydHVhbCBlWHRlbnNpYmxlIExvY2FsIEFy ZWEgTmV0d29yayIgKFZYTEFOKSBbUkZDNzM0OF0gcHJvdmlkZXMgYW4KICAgZW5jYXBzdWxhdGlv biBzY2hlbWUgdGhhdCBhbGxvd3MgYnVpbGRpbmcgYW4gb3ZlcmxheSBuZXR3b3JrIGJ5CiAgIGRl Y291cGxpbmcgdGhlIGFkZHJlc3Mgc3BhY2Ugb2YgdGhlIGF0dGFjaGVkIHZpcnR1YWwgaG9zdHMg ZnJvbSB0aGF0CiAgIG9mIHRoZSBuZXR3b3JrLgoKICAgT25lIHVzZSBvZiBWWExBTiBpcyBpbiBk YXRhIGNlbnRlcnMgaW50ZXJjb25uZWN0aW5nIHZpcnR1YWwgbWFjaGluZXMKICAgKFZNcykgb2Yg YSB0ZW5hbnQuICBWWExBTiBhZGRyZXNzZXMgcmVxdWlyZW1lbnRzIG9mIHRoZSBMYXllciAyIGFu ZAogICBMYXllciAzIGRhdGEgY2VudGVyIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgaW4gdGhlIHBy ZXNlbmNlIG9mIFZNcyBpbgogICBhIG11bHRpLXRlbmFudCBlbnZpcm9ubWVudCBieSBwcm92aWRp bmcgYSBMYXllciAyIG92ZXJsYXkgc2NoZW1lIG9uIGEKICAgTGF5ZXIgMyBuZXR3b3JrIFtSRkM3 MzQ4XS4gIEFub3RoZXIgdXNlIGlzIGFzIGFuIGVuY2Fwc3VsYXRpb24gZm9yCiAgIEV0aGVybmV0 IFZQTiBbUkZDODM2NV0uCgogICBUaGlzIGRvY3VtZW50IGlzIHdyaXR0ZW4gYXNzdW1pbmcgdGhl IHVzZSBvZiBWWExBTiBmb3IgdmlydHVhbGl6ZWQKICAgaG9zdHMgYW5kIHJlZmVycyB0byBWTXMg YW5kIFZYTEFOIFR1bm5lbCBFbmQgUG9pbnRzIChWVEVQcykgaW4KICAgaHlwZXJ2aXNvcnMuICBI b3dldmVyLCB0aGUgY29uY2VwdHMgYXJlIGVxdWFsbHkgYXBwbGljYWJsZSB0byBub24tCiAgIHZp cnR1YWxpemVkIGhvc3RzIGF0dGFjaGVkIHRvIFZURVBzIGluIHN3aXRjaGVzLgoKICAgSW4gdGhl IGFic2VuY2Ugb2YgYSByb3V0ZXIgaW4gdGhlIG92ZXJsYXksIGEgVk0gY2FuIGNvbW11bmljYXRl IHdpdGgKICAgYW5vdGhlciBWTSBvbmx5IGlmIHRoZXkgYXJlIG9uIHRoZSBzYW1lIFZYTEFOIHNl Z21lbnQuICBWTXMgYXJlCiAgIHVuYXdhcmUgb2YgVlhMQU4gdHVubmVscyBhcyBhIFZYTEFOIHR1 bm5lbCBpcyB0ZXJtaW5hdGVkIG9uIGEgVlRFUC4KCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAg ICBFeHBpcmVzIE1heSAyMiwgMjAyMCAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICBOb3Zl bWJlciAyMDE5CgoKICAgVlRFUHMgYXJlIHJlc3BvbnNpYmxlIGZvciBlbmNhcHN1bGF0aW5nIGFu ZCBkZWNhcHN1bGF0aW5nIGZyYW1lcwogICBleGNoYW5nZWQgYW1vbmcgVk1zLgoKICAgQWJpbGl0 eSB0byBtb25pdG9yIHBhdGggY29udGludWl0eSwgaS5lLiwgcGVyZm9ybSBwcm9hY3RpdmUKICAg Y29udGludWl0eSBjaGVjayAoQ0MpIGZvciBwb2ludC10by1wb2ludCAocDJwKSBWWExBTiB0dW5u ZWxzLCBpcwogICBpbXBvcnRhbnQuICBUaGUgYXN5bmNocm9ub3VzIG1vZGUgb2YgQkZELCBhcyBk ZWZpbmVkIGluIFtSRkM1ODgwXSwgaXMKICAgdXNlZCB0byBtb25pdG9yIGEgcDJwIFZYTEFOIHR1 bm5lbC4KCiAgIEluIHRoZSBjYXNlIHdoZXJlIGEgTXVsdGljYXN0IFNlcnZpY2UgTm9kZSAoTVNO KSAoYXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gMy4zIG9mIFtSRkM4MjkzXSkgcmVzaWRlcyBi ZWhpbmQgYSBOZXR3b3JrIFZpcnR1YWxpemF0aW9uCiAgIEVuZHBvaW50IChOVkUpLCB0aGUgbWVj aGFuaXNtcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcHBseSBhbmQKICAgY2FuLCB0aGVy ZWZvcmUsIGJlIHVzZWQgdG8gdGVzdCB0aGUgY29ubmVjdGl2aXR5IGZyb20gdGhlIHNvdXJjZSBO VkUKICAgdG8gdGhlIE1TTi4KCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2Yg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbgogICAoQkZEKSBwcm90b2NvbCB0byBl bmFibGUgbW9uaXRvcmluZyBjb250aW51aXR5IG9mIHRoZSBwYXRoIGJldHdlZW4KICAgVlhMQU4g VlRFUHMsIHBlcmZvcm1pbmcgYXMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2ludHMsIGFu ZC9vcgogICBhdmFpbGFiaWxpdHkgb2YgYSByZXBsaWNhdG9yIG11bHRpY2FzdCBzZXJ2aWNlIG5v ZGUuCgoyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50CgoyLjEuICBUZXJtaW5v bG9neQoKICAgQkZEIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24KCiAgIENDIENv bnRpbnVpdHkgQ2hlY2sKCiAgIHAycCBQb2ludC10by1wb2ludAoKICAgTVNOIE11bHRpY2FzdCBT ZXJ2aWNlIE5vZGUKCiAgIE5WRSBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuZHBvaW50CgogICBW RkkgVmlydHVhbCBGb3J3YXJkaW5nIEluc3RhbmNlCgogICBWTSBWaXJ0dWFsIE1hY2hpbmUKCiAg IFZOSSBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNlZ21lbnQgSUQpCgogICBW VEVQIFZYTEFOIFR1bm5lbCBFbmQgUG9pbnQKCiAgIFZYTEFOIFZpcnR1YWwgZVh0ZW5zaWJsZSBM b2NhbCBBcmVhIE5ldHdvcmsKCjIuMi4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09N TUVOREVEIiwgIk1BWSIsIGFuZAogICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRv IGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBCQ1AKCgoKUGFsbGFnYXR0aSwgZXQgYWwu ICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAyMCAgICAgICAgICAgICAgICAgIFtQYWdlIDNdCgwK SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAg ICBOb3ZlbWJlciAyMDE5CgoKICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25s eSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgoz LiAgRGVwbG95bWVudAoKICAgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhlIHNjZW5hcmlvIHdpdGgg dHdvIHNlcnZlcnMsIGVhY2ggb2YgdGhlbQogICBob3N0aW5nIHR3byBWTXMuICBUaGUgc2VydmVy cyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRlIHR3byBWWExBTgogICB0dW5uZWxzIHdpdGggVlhM QU4gTmV0d29yayBJZGVudGlmaWVyIChWTkkpIG51bWJlciAxMDAgYW5kIDIwMAogICByZXNwZWN0 aXZlbHkuICBTZXBhcmF0ZSBCRkQgc2Vzc2lvbnMgY2FuIGJlIGVzdGFibGlzaGVkIGJldHdlZW4g dGhlCiAgIFZURVBzIChJUDEgYW5kIElQMikgZm9yIG1vbml0b3JpbmcgZWFjaCBvZiB0aGUgVlhM QU4gdHVubmVscyAoVk5JIDEwMAogICBhbmQgMjAwKS4gIEFuIGltcGxlbWVudGF0aW9uIHRoYXQg c3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUKICAgYWJsZSB0byBjb250cm9sIHRo ZSBudW1iZXIgb2YgQkZEIHNlc3Npb25zIHRoYXQgY2FuIGJlIGNyZWF0ZWQKICAgYmV0d2VlbiB0 aGUgc2FtZSBwYWlyIG9mIFZURVBzLiAgQkZEIHBhY2tldHMgaW50ZW5kZWQgZm9yIGEgVlRFUCBN VVNUCiAgIE5PVCBiZSBmb3J3YXJkZWQgdG8gYSBWTSBhcyBhIFZNIG1heSBkcm9wIEJGRCBwYWNr ZXRzIGxlYWRpbmcgdG8gYQogICBmYWxzZSBuZWdhdGl2ZS4gIFRoaXMgbWV0aG9kIGlzIGFwcGxp Y2FibGUgd2hldGhlciB0aGUgVlRFUCBpcyBhCiAgIHZpcnR1YWwgb3IgcGh5c2ljYWwgZGV2aWNl LgoKCiAgICAgICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKICAgICAgfCAgICAgICAgU2Vy dmVyIDEgICAgICAgICAgfAogICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8CiAgICAg IHwgfFZNMS0xICAgIHwgIHxWTTEtMiAgICB8IHwKICAgICAgfCB8Vk5JIDEwMCAgfCAgfFZOSSAy MDAgIHwgfAogICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8CiAgICAgIHwgKy0tLS0t LS0tLSsgICstLS0tLS0tLS0rIHwKICAgICAgfCAgICAgICAgVlRFUCAoSVAxKSAgICAgICAgfAog ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0rCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgIExheWVyIDMgICB8CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tfCAgIE5ldHdvcmsgICB8CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t KwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICBWVEVQIChJUDIpICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCB8Vk0yLTEgICAgfCAgfFZNMi0yICAgIHwgfAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfFZOSSAxMDAgIHwgIHxWTkkgMjAwICB8 IHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICB8 ICB8ICAgICAgICAgfCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICBTZXJ2ZXIgMiAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCgoK ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IFJlZmVyZW5jZSBWWExBTiBEb21haW4KCgoK ClBhbGxhZ2F0dGksIGV0IGFsLiAgICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMjAgICAgICAgICAg ICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJGRCBmb3Ig VlhMQU4gICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxOQoKCiAgIEF0IHRoZSBzYW1lIHRpbWUs IGEgc2VydmljZSBsYXllciBCRkQgc2Vzc2lvbiBtYXkgYmUgdXNlZCBiZXR3ZWVuIHRoZQogICB0 ZW5hbnRzIG9mIFZURVBzIElQMSBhbmQgSVAyIHRvIHByb3ZpZGUgZW5kLXRvLWVuZCBmYXVsdCBt YW5hZ2VtZW50LgogICBJbiBzdWNoIGNhc2UsIGZvciBWVEVQcyBCRkQgQ29udHJvbCBwYWNrZXRz IG9mIHRoYXQgc2Vzc2lvbiBhcmUKICAgaW5kaXN0aW5ndWlzaGFibGUgZnJvbSBkYXRhIHBhY2tl dHMuCgogICBBcyBwZXIgU2VjdGlvbiA0LCB0aGUgaW5uZXIgZGVzdGluYXRpb24gSVAgYWRkcmVz cyBTSE9VTEQgYmUgc2V0IHRvCiAgIG9uZSBvZiB0aGUgbG9vcGJhY2sgYWRkcmVzc2VzICgxMjcv OCByYW5nZSBmb3IgSVB2NCBhbmQKICAgMDowOjA6MDowOkZGRkY6N0YwMDowLzEwNCByYW5nZSBm b3IgSVB2NikuICBUaGVyZSBjb3VsZCBiZSBhIGZpcmV3YWxsCiAgIGNvbmZpZ3VyZWQgb24gVlRF UCB0byBibG9jayBsb29wYmFjayBhZGRyZXNzZXMgaWYgc2V0IGFzIHRoZQogICBkZXN0aW5hdGlv biBJUCBpbiB0aGUgaW5uZXIgSVAgaGVhZGVyLiAgSXQgaXMgUkVDT01NRU5ERUQgdG8gYWxsb3cK ICAgYWRkcmVzc2VzIGZyb20gdGhlIGxvb3BiYWNrIHJhbmdlIHRocm91Z2ggYSBmaXJld2FsbCBv bmx5IGlmIGl0IGlzCiAgIHVzZWQgYXMgdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaW4gdGhl IGlubmVyIElQIGhlYWRlciwgYW5kIHRoZQogICBkZXN0aW5hdGlvbiBVRFAgcG9ydCBpcyBzZXQg dG8gMzc4NCBbUkZDNTg4MV0uCgo0LiAgQkZEIFBhY2tldCBUcmFuc21pc3Npb24gb3ZlciBWWExB TiBUdW5uZWwKCiAgIEJGRCBwYWNrZXQgTVVTVCBiZSBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgdG8g YSByZW1vdGUgVlRFUCBhcwogICBleHBsYWluZWQgaW4gdGhpcyBzZWN0aW9uLiAgSW1wbGVtZW50 YXRpb25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUKICAgQkZEIHBhY2tldHMgZm9sbG93IHRoZSBz YW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4KICAgdGhlIHNlbmRl ciBzeXN0ZW0uCgogICBCRkQgcGFja2V0cyBhcmUgZW5jYXBzdWxhdGVkIGluIFZYTEFOIGFzIGRl c2NyaWJlZCBiZWxvdy4gIFRoZSBWWExBTgogICBwYWNrZXQgZm9ybWF0IGlzIGRlZmluZWQgaW4g U2VjdGlvbiA1IG9mIFtSRkM3MzQ4XS4gIFRoZSBPdXRlciBJUC9VRFAKICAgYW5kIFZYTEFOIGhl YWRlcnMgTVVTVCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbgogICBbUkZD NzM0OF0uCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAg ICBFeHBpcmVzIE1heSAyMiwgMjAyMCAgICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICBOb3Zl bWJlciAyMDE5CgoKICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzCiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgIH4gICAgICAgICAgICAgICAgICAgICAgT3V0ZXIgRXRoZXJuZXQgSGVhZGVyICAgICAg ICAgICAgICAgICAgICB+CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICB+ICAgICAgICAgICAgICAgICAgICAgICAgT3V0ZXIgSVB2WCBIZWFkZXIgICAgICAgICAgICAg ICAgICAgICAgfgogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfiAg ICAgICAgICAgICAgICAgICAgICAgIE91dGVyIFVEUCBIZWFkZXIgICAgICAgICAgICAgICAgICAg ICAgIH4KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAg ICAgICAgICAgICAgICAgICAgICBWWExBTiBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgICB+ CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAgICAg ICAgICAgICBJbm5lciBFdGhlcm5ldCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgfgogICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAg ICAgICAgIElubmVyIElQdlggSGVhZGVyICAgICAgICAgICAgICAgICAgICAgIH4KICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAgICAgICAgICAgICAgICAg ICAgSW5uZXIgVURQIEhlYWRlciAgICAgICAgICAgICAgICAgICAgICB+CiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAgICAgICAgICAgICAgICBCRkQg Q29udHJvbCBQYWNrZXQgICAgICAgICAgICAgICAgICAgICB+CiAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgRkNTICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAgICAgICAgICAgRmlndXJlIDI6IFZY TEFOIEVuY2Fwc3VsYXRpb24gb2YgQkZEIENvbnRyb2wgUGFja2V0CgogICBUaGUgQkZEIHBhY2tl dCBNVVNUIGJlIGNhcnJpZWQgaW5zaWRlIHRoZSBpbm5lciBFdGhlcm5ldCBmcmFtZSBvZiB0aGUK ICAgVlhMQU4gcGFja2V0LiAgVGhlIGNob2ljZSBvZiBEZXN0aW5hdGlvbiBNQUMgYW5kIERlc3Rp bmF0aW9uIElQCiAgIGFkZHJlc3NlcyBmb3IgdGhlIGlubmVyIEV0aGVybmV0IGZyYW1lIE1VU1Qg ZW5zdXJlIHRoYXQgdGhlIEJGRAogICBDb250cm9sIHBhY2tldCBpcyBub3QgZm9yd2FyZGVkIHRv IGEgdGVuYW50IGJ1dCBpcyBwcm9jZXNzZWQgbG9jYWxseQogICBhdCB0aGUgcmVtb3RlIFZURVAu ICBUaGUgaW5uZXIgRXRoZXJuZXQgZnJhbWUgY2FycnlpbmcgdGhlIEJGRAogICBDb250cm9sIHBh Y2tldC0gaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0OgoKICAgICAgRXRoZXJuZXQgSGVhZGVyOgoK CgpQYWxsYWdhdHRpLCBldCBhbC4gICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDIwICAgICAgICAg ICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBCRkQgZm9y IFZYTEFOICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTkKCgogICAgICAgICBEZXN0aW5hdGlv biBNQUM6IFRoaXMgTVVTVCBOT1QgYmUgb2Ygb25lIG9mIHRlbmFudCdzIE1BQwogICAgICAgICBh ZGRyZXNzZXMuICBUaGUgZGVzdGluYXRpb24gTUFDIGFkZHJlc3MgTUFZIGJlIHRoZSBhZGRyZXNz CiAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgZGVzdGluYXRpb24gVlRFUC4gIFRoZSBNQUMg YWRkcmVzcyBNQVkgYmUKICAgICAgICAgY29uZmlndXJlZCwgb3IgaXQgTUFZIGJlIGxlYXJuZWQg dmlhIGEgY29udHJvbCBwbGFuZSBwcm90b2NvbC4KICAgICAgICAgVGhlIGRldGFpbHMgb2YgaG93 IHRoZSBNQUMgYWRkcmVzcyBpcyBvYnRhaW5lZCBhcmUgb3V0c2lkZSB0aGUKICAgICAgICAgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgICAgICAgIFNvdXJjZSBNQUM6IE1BQyBhZGRyZXNzIGFz c29jaWF0ZWQgd2l0aCB0aGUgb3JpZ2luYXRpbmcgVlRFUAoKICAgICAgSVAgaGVhZGVyOgoKICAg ICAgICAgRGVzdGluYXRpb24gSVA6IElQIGFkZHJlc3MgTVVTVCBOT1QgYmUgb2Ygb25lIG9mIHRl bmFudCdzIElQCiAgICAgICAgIGFkZHJlc3Nlcy4gIFRoZSBJUCBhZGRyZXNzIFNIT1VMRCBiZSBz ZWxlY3RlZCBmcm9tIHRoZSByYW5nZQogICAgICAgICAxMjcvOCBmb3IgSVB2NCwgZm9yIElQdjYg LSBmcm9tIHRoZSByYW5nZQogICAgICAgICAwOjA6MDowOjA6RkZGRjo3RjAwOjAvMTA0LiAgQWx0 ZXJuYXRpdmVseSwgdGhlIGRlc3RpbmF0aW9uIElQCiAgICAgICAgIGFkZHJlc3MgTUFZIGJlIHNl dCB0byBWVEVQJ3MgSVAgYWRkcmVzcy4KCiAgICAgICAgIFNvdXJjZSBJUDogSVAgYWRkcmVzcyBv ZiB0aGUgb3JpZ2luYXRpbmcgVlRFUC4KCiAgICAgICAgIFRUTCBvciBIb3AgTGltaXQ6IE1VU1Qg YmUgc2V0IHRvIDEgdG8gZW5zdXJlIHRoYXQgdGhlIEJGRAogICAgICAgICBwYWNrZXQgaXMgbm90 IHJvdXRlZCB3aXRoaW4gdGhlIExheWVyIDMgdW5kZXJsYXkgbmV0d29yay4gIFRoaXMKICAgICAg ICAgYWRkcmVzc2VzIHRoZSBzY2VuYXJpbyB3aGVuIHRoZSBpbm5lciBJUCBkZXN0aW5hdGlvbiBh ZGRyZXNzIGlzCiAgICAgICAgIG9mIFZYTEFOIGdhdGV3YXkgYW5kIHRoZXJlIGlzIGEgcm91dGVy IGluIHVuZGVybGF5IHdoaWNoCiAgICAgICAgIHJlbW92ZXMgdGhlIFZYTEFOIGhlYWRlciwgdGhl biBpdCBpcyBwb3NzaWJsZSB0byByb3V0ZSB0aGUKICAgICAgICAgcGFja2V0IGFzIFZYTEFOICBn YXRld2F5IGFkZHJlc3MgaXMgcm91dGFibGUgYWRkcmVzcy4KCiAgICAgIFRoZSBmaWVsZHMgb2Yg dGhlIFVEUCBoZWFkZXIgYW5kIHRoZSBCRkQgQ29udHJvbCBwYWNrZXQgYXJlCiAgICAgIGVuY29k ZWQgYXMgc3BlY2lmaWVkIGluIFtSRkM1ODgxXS4KCjUuICBSZWNlcHRpb24gb2YgQkZEIFBhY2tl dCBmcm9tIFZYTEFOIFR1bm5lbAoKICAgT25jZSBhIHBhY2tldCBpcyByZWNlaXZlZCwgVlRFUCBN VVNUIHZhbGlkYXRlIHRoZSBwYWNrZXQuICBJZiB0aGUKICAgRGVzdGluYXRpb24gTUFDIG9mIHRo ZSBpbm5lciBFdGhlcm5ldCBmcmFtZSBtYXRjaGVzIG9uZSBvZiB0aGUgTUFDCiAgIGFkZHJlc3Nl cyBhc3NvY2lhdGVkIHdpdGggdGhlIFZURVAgdGhlIHBhY2tldCBNVVNUIGJlIHByb2Nlc3NlZAog ICBmdXJ0aGVyLiAgSWYgdGhlIERlc3RpbmF0aW9uIE1BQyBvZiB0aGUgaW5uZXIgRXRoZXJuZXQg ZnJhbWUgZG9lc24ndAogICBtYXRjaCBhbnkgb2YgVlRFUCdzIE1BQyBhZGRyZXNzZXMsIHRoZW4g dGhlIHByb2Nlc3Npbmcgb2YgdGhlCiAgIHJlY2VpdmVkIFZYTEFOIHBhY2tldCBNVVNUIGZvbGxv dyB0aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiA0LjEgW1JGQzczNDhdLiAg SWYgdGhlIEJGRCBzZXNzaW9uIGlzIHVzaW5nIHRoZSBNYW5hZ2VtZW50CiAgIFZOSSAoU2VjdGlv biA2KSwgQkZEIENvbnRyb2wgcGFja2V0cyB3aXRoIHVua25vd24gTUFDIGFkZHJlc3MgTVVTVAog ICBOT1QgYmUgZm9yd2FyZGVkIHRvIFZNcy4KCiAgIFRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBh bmQgdGhlIFRUTCBvZiB0aGUgaW5uZXIgSVAgcGFja2V0IE1VU1QgYmUKICAgdmFsaWRhdGVkIHRv IGRldGVybWluZSBpZiB0aGUgcmVjZWl2ZWQgcGFja2V0IGNhbiBiZSBwcm9jZXNzZWQgYnkKICAg QkZELgoKCgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAgICBFeHBpcmVzIE1heSAyMiwgMjAy MCAgICAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDE5CgoKNS4xLiAgRGVt dWx0aXBsZXhpbmcgb2YgdGhlIEJGRCBQYWNrZXQKCiAgIERlbXVsdGlwbGV4aW5nIG9mIElQIEJG RCBwYWNrZXQgaGFzIGJlZW4gZGVmaW5lZCBpbiBTZWN0aW9uIDMgb2YKICAgW1JGQzU4ODFdLiAg U2luY2UgbXVsdGlwbGUgQkZEIHNlc3Npb25zIG1heSBiZSBydW5uaW5nIGJldHdlZW4gdHdvCiAg IFZURVBzLCB0aGVyZSBuZWVkcyB0byBiZSBhIG1lY2hhbmlzbSBmb3IgZGVtdWx0aXBsZXhpbmcg cmVjZWl2ZWQgQkZECiAgIHBhY2tldHMgdG8gdGhlIHByb3BlciBzZXNzaW9uLiAgRm9yIGRlbXVs dGlwbGV4aW5nIHBhY2tldHMgd2l0aCBZb3VyCiAgIERpc2NyaW1pbmF0b3IgZXF1YWwgdG8gMCwg YSBCRkQgc2Vzc2lvbiBNVVNUIGJlIGlkZW50aWZpZWQgdXNpbmcgdGhlCiAgIGxvZ2ljYWwgbGlu ayBvdmVyIHdoaWNoIHRoZSBCRkQgQ29udHJvbCBwYWNrZXQgaXMgcmVjZWl2ZWQuICBJbiB0aGUK ICAgY2FzZSBvZiBWWExBTiwgdGhlIFZOSSBudW1iZXIgaWRlbnRpZmllcyB0aGF0IGxvZ2ljYWwg bGluay4gIElmIEJGRAogICBwYWNrZXQgaXMgcmVjZWl2ZWQgd2l0aCBub24temVybyBZb3VyIERp c2NyaW1pbmF0b3IsIHRoZW4gQkZEIHNlc3Npb24KICAgTVVTVCBiZSBkZW11bHRpcGxleGVkIG9u bHkgd2l0aCBZb3VyIERpc2NyaW1pbmF0b3IgYXMgdGhlIGtleS4KCjYuICBVc2Ugb2YgdGhlIFNw ZWNpZmljIFZOSQoKICAgSW4gbW9zdCBjYXNlcywgYSBzaW5nbGUgQkZEIHNlc3Npb24gaXMgc3Vm ZmljaWVudCBmb3IgdGhlIGdpdmVuIFZURVAKICAgdG8gbW9uaXRvciB0aGUgcmVhY2hhYmlsaXR5 IG9mIGEgcmVtb3RlIFZURVAsIHJlZ2FyZGxlc3Mgb2YgdGhlCiAgIG51bWJlciBvZiBWTklzLiAg V2hlbiB0aGUgc2luZ2xlIEJGRCBzZXNzaW9uIGlzIHVzZWQgdG8gbW9uaXRvciB0aGUKICAgcmVh Y2hhYmlsaXR5IG9mIHRoZSByZW1vdGUgVlRFUCwgYW4gaW1wbGVtZW50YXRpb24gU0hPVUxEIGNo b29zZSBhbnkKICAgb2YgdGhlIFZOSXMuICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgc3VwcG9ydCB0 aGUgdXNlIG9mIHRoZSBNYW5hZ2VtZW50CiAgIFZOSSBhcyBjb250cm9sIGFuZCBtYW5hZ2VtZW50 IGNoYW5uZWwgYmV0d2VlbiBWVEVQcy4gIFRoZSBzZWxlY3Rpb24KICAgb2YgdGhlIFZOSSBudW1i ZXIgb2YgdGhlIE1hbmFnZW1lbnQgVk5JIE1VU1QgYmUgY29udHJvbGxlZCB0aHJvdWdoCiAgIG1h bmFnZW1lbnQgcGxhbmUuICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgdXNlIFZOSSBudW1iZXIgMSBh cyB0aGUKICAgZGVmYXVsdCB2YWx1ZSBmb3IgdGhlIE1hbmFnZW1lbnQgVk5JLiAgQWxsIFZYTEFO IHBhY2tldHMgcmVjZWl2ZWQgb24KICAgdGhlIE1hbmFnZW1lbnQgVk5JIE1VU1QgYmUgcHJvY2Vz c2VkIGxvY2FsbHkgYW5kIE1VU1QgTk9UIGJlCiAgIGZvcndhcmRlZCB0byBhIHRlbmFudC4KCjcu ICBFY2hvIEJGRAoKICAgU3VwcG9ydCBmb3IgZWNobyBCRkQgaXMgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcyBkb2N1bWVudC4KCjguICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIHNwZWNp ZmljYXRpb24gaGFzIG5vIElBTkEgYWN0aW9uIHJlcXVlc3RlZC4gIFRoaXMgc2VjdGlvbiBtYXkg YmUKICAgZGVsZXRlZCBiZWZvcmUgdGhlIHB1YmxpY2F0aW9uLgoKOS4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zCgogICBUaGUgZG9jdW1lbnQgcmVxdWlyZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAg VFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJlCiAgIHVzZWQgYXMgYSBERG9TIGF0dGFjayB2ZWN0b3Iu ICBUaHVzIHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIGhhdmUKICAgdGhyb3R0bGluZyBpbiBwbGFj ZSB0byBjb250cm9sIHRoZSByYXRlIG9mIEJGRCBDb250cm9sIHBhY2tldHMgc2VudAogICB0byB0 aGUgY29udHJvbCBwbGFuZS4gIE9uIHRoZSBvdGhlciBoYW5kLCBvdmVyLWFnZ3Jlc3NpdmUgdGhy b3R0bGluZwogICBvZiBCRkQgQ29udHJvbCBwYWNrZXRzIG1heSBiZWNvbWUgdGhlIGNhdXNlIG9m IHRoZSBpbmFiaWxpdHkgdG8gZm9ybQogICBhbmQgbWFpbnRhaW4gQkZEIHNlc3Npb24gYXQgc2Nh bGUuICBIZW5jZSwgdGhyb3R0bGluZyBvZiBCRkQgQ29udHJvbAogICBwYWNrZXRzIFNIT1VMRCBi ZSBhZGp1c3RlZCB0byBwZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0cwogICBwcm9j ZWR1cmVzLgoKICAgVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzIHVzaW5nIGFuIGFkZHJlc3MgZnJv bSB0aGUgSW50ZXJuYWwgaG9zdAogICBsb29wYmFjayBhZGRyZXNzZXMgcmFuZ2UgYXMgdGhlIGRl c3RpbmF0aW9uIElQIGFkZHJlc3MgaW4gdGhlIGlubmVyCgoKClBhbGxhZ2F0dGksIGV0IGFsLiAg ICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMjAgICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJGRCBmb3IgVlhMQU4gICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAxOQoKCiAgIElQIGhlYWRlci4gIFVzaW5nIHN1Y2ggYWRkcmVzcyBwcmV2ZW50 cyB0aGUgZm9yd2FyZGluZyBvZiB0aGUKICAgZW5jYXBzdWxhdGVkIEJGRCBjb250cm9sIG1lc3Nh Z2UgYnkgYSB0cmFuc2llbnQgbm9kZSBpbiBjYXNlIHRoZQogICBWWExBTiB0dW5uZWwgaXMgYnJv a2VuIGFzIGFjY29yZGluZyB0byBbUkZDMTgxMl06CgogICAgICBBIHJvdXRlciBTSE9VTEQgTk9U IGZvcndhcmQsIGV4Y2VwdCBvdmVyIGEgbG9vcGJhY2sgaW50ZXJmYWNlLCBhbnkKICAgICAgcGFj a2V0IHRoYXQgaGFzIGEgZGVzdGluYXRpb24gYWRkcmVzcyBvbiBuZXR3b3JrIDEyNy4gIEEgcm91 dGVyCiAgICAgIE1BWSBoYXZlIGEgc3dpdGNoIHRoYXQgYWxsb3dzIHRoZSBuZXR3b3JrIG1hbmFn ZXIgdG8gZGlzYWJsZSB0aGVzZQogICAgICBjaGVja3MuICBJZiBzdWNoIGEgc3dpdGNoIGlzIHBy b3ZpZGVkLCBpdCBNVVNUIGRlZmF1bHQgdG8KICAgICAgcGVyZm9ybWluZyB0aGUgY2hlY2tzLgoK ICAgSWYgdGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGVzdGFibGlzaGluZyBtdWx0aXBsZSBC RkQgc2Vzc2lvbnMKICAgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBzLCB0aGVyZSBTSE9V TEQgYmUgYSBtZWNoYW5pc20gdG8KICAgY29udHJvbCB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc3Vj aCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBhY3RpdmUgYXQgdGhlCiAgIHNhbWUgdGltZS4KCiAgIE90 aGVyIHRoYW4gaW5uZXIgSVAgVFRMIHNldCB0byAxIGFuZCBsaW1pdCB0aGUgbnVtYmVyIG9mIEJG RCBzZXNzaW9ucwogICBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2YgVlRFUHMsIHRoaXMgc3BlY2lm aWNhdGlvbiBkb2VzIG5vdCByYWlzZSBhbnkKICAgYWRkaXRpb25hbCBzZWN1cml0eSBpc3N1ZXMg YmV5b25kIHRob3NlIG9mIHRoZSBzcGVjaWZpY2F0aW9ucwogICByZWZlcnJlZCB0byBpbiB0aGUg bGlzdCBvZiBub3JtYXRpdmUgcmVmZXJlbmNlcy4KCjEwLiAgQ29udHJpYnV0b3JzCgoKICAgUmVz aGFkIFJhaG1hbgogICBycmFobWFuQGNpc2NvLmNvbQogICBDaXNjbwoKCjExLiAgQWNrbm93bGVk Z21lbnRzCgogICBBdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgSmVmZiBIYWFzIG9mIEp1bmlw ZXIgTmV0d29ya3MgZm9yIGhpcwogICByZXZpZXdzIGFuZCBmZWVkYmFjayBvbiB0aGlzIG1hdGVy aWFsLgoKICAgQXV0aG9ycyB3b3VsZCBhbHNvIGxpa2UgdG8gdGhhbmsgTm9ibyBBa2l5YSwgTWFy YyBCaW5kZXJiZXJnZXIsCiAgIFNoYWhyYW0gRGF2YXJpLCBEb25hbGQgRS4gIEVhc3RsYWtlIDNy ZCwgYW5kIEFub29wIEdoYW53YW5pIGZvciB0aGUKICAgZXh0ZW5zaXZlIHJldmlld3MgYW5kIHRo ZSBtb3N0IGRldGFpbGVkIGFuZCBoZWxwZnVsIGNvbW1lbnRzLgoKMTIuICBSZWZlcmVuY2VzCgox Mi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMxODEyXSAgQmFrZXIsIEYuLCBFZC4s ICJSZXF1aXJlbWVudHMgZm9yIElQIFZlcnNpb24gNCBSb3V0ZXJzIiwKICAgICAgICAgICAgICBS RkMgMTgxMiwgRE9JIDEwLjE3NDg3L1JGQzE4MTIsIEp1bmUgMTk5NSwKICAgICAgICAgICAgICA8 aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMxODEyPi4KCgoKCgoKClBhbGxhZ2F0 dGksIGV0IGFsLiAgICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMjAgICAgICAgICAgICAgICAgICBb UGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJGRCBmb3IgVlhMQU4gICAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAxOQoKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWly ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAuMTc0 ODcvUkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkM1ODgwXSAgS2F0eiwgRC4gYW5kIEQuIFdh cmQsICJCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uCiAgICAgICAgICAgICAgKEJG RCkiLCBSRkMgNTg4MCwgRE9JIDEwLjE3NDg3L1JGQzU4ODAsIEp1bmUgMjAxMCwKICAgICAgICAg ICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1ODgwPi4KCiAgIFtSRkM1 ODgxXSAgS2F0eiwgRC4gYW5kIEQuIFdhcmQsICJCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0 ZWN0aW9uCiAgICAgICAgICAgICAgKEJGRCkgZm9yIElQdjQgYW5kIElQdjYgKFNpbmdsZSBIb3Ap IiwgUkZDIDU4ODEsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzU4ODEsIEp1bmUgMjAx MCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1ODgx Pi4KCiAgIFtSRkM3MzQ4XSAgTWFoYWxpbmdhbSwgTS4sIER1dHQsIEQuLCBEdWRhLCBLLiwgQWdh cndhbCwgUC4sIEtyZWVnZXIsCiAgICAgICAgICAgICAgTC4sIFNyaWRoYXIsIFQuLCBCdXJzZWxs LCBNLiwgYW5kIEMuIFdyaWdodCwgIlZpcnR1YWwKICAgICAgICAgICAgICBlWHRlbnNpYmxlIExv Y2FsIEFyZWEgTmV0d29yayAoVlhMQU4pOiBBIEZyYW1ld29yayBmb3IKICAgICAgICAgICAgICBP dmVybGF5aW5nIFZpcnR1YWxpemVkIExheWVyIDIgTmV0d29ya3Mgb3ZlciBMYXllciAzCiAgICAg ICAgICAgICAgTmV0d29ya3MiLCBSRkMgNzM0OCwgRE9JIDEwLjE3NDg3L1JGQzczNDgsIEF1Z3Vz dCAyMDE0LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzczNDg+LgoKICAgW1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNl IHZzIExvd2VyY2FzZSBpbiBSRkMKICAgICAgICAgICAgICAyMTE5IEtleSBXb3JkcyIsIEJDUCAx NCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LAogICAgICAgICAgICAgIE1heSAyMDE3 LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTc0Pi4KCjEyLjIuICBJbmZv cm1hdGlvbmFsIFJlZmVyZW5jZXMKCiAgIFtSRkM4MjkzXSAgR2hhbndhbmksIEEuLCBEdW5iYXIs IEwuLCBNY0JyaWRlLCBNLiwgQmFubmFpLCBWLiwgYW5kIFIuCiAgICAgICAgICAgICAgS3Jpc2hu YW4sICJBIEZyYW1ld29yayBmb3IgTXVsdGljYXN0IGluIE5ldHdvcmsKICAgICAgICAgICAgICBW aXJ0dWFsaXphdGlvbiBvdmVyIExheWVyIDMiLCBSRkMgODI5MywKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDODI5MywgSmFudWFyeSAyMDE4LAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgyOTM+LgoKICAgW1JGQzgzNjVdICBTYWphc3NpLCBB LiwgRWQuLCBEcmFrZSwgSi4sIEVkLiwgQml0YXIsIE4uLCBTaGVraGFyLCBSLiwKICAgICAgICAg ICAgICBVdHRhcm8sIEouLCBhbmQgVy4gSGVuZGVyaWNreCwgIkEgTmV0d29yayBWaXJ0dWFsaXph dGlvbgogICAgICAgICAgICAgIE92ZXJsYXkgU29sdXRpb24gVXNpbmcgRXRoZXJuZXQgVlBOIChF VlBOKSIsIFJGQyA4MzY1LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM4MzY1LCBNYXJj aCAyMDE4LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzgzNjU+LgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBTYW50b3NoIFBhbGxhZ2F0dGkgKGVkaXRv cikKICAgVk13YXJlCgogICBFbWFpbDogc2FudG9zaC5wYWxsYWdhdHRpQGdtYWlsLmNvbQoKCgoK CgpQYWxsYWdhdHRpLCBldCBhbC4gICAgICAgIEV4cGlyZXMgTWF5IDIyLCAyMDIwICAgICAgICAg ICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBCRkQgZm9y IFZYTEFOICAgICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTkKCgogICBTdWRhcnNhbiBQYXJhZ2ly aQogICBJbmRpdmlkdWFsIENvbnRyaWJ1dG9yCgogICBFbWFpbDogc3VkYXJzYW4uMjI1QGdtYWls LmNvbQoKCiAgIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuCiAgIENpc2NvCgogICBFbWFpbDogdmVu Z2dvdmlAY2lzY28uY29tCgoKICAgTWFsbGlrIE11ZGlnb25kYQogICBDaXNjbwoKICAgRW1haWw6 IG1tdWRpZ29uQGNpc2NvLmNvbQoKCiAgIEdyZWcgTWlyc2t5CiAgIFpURSBDb3JwLgoKICAgRW1h aWw6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKClBh bGxhZ2F0dGksIGV0IGFsLiAgICAgICAgRXhwaXJlcyBNYXkgMjIsIDIwMjAgICAgICAgICAgICAg ICAgIFtQYWdlIDExXQo= --000000000000dc44870597be1fa2 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bfd-vxlan-08.txt - draft-ietf-bfd-vxlan-09.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bfd-vxlan-08.txt - draft-ietf-bfd-vxlan-09.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k36okmmb1 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiIGNsYXNzPSJncl9fd3d3Nl9pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAg CiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2Nz cyI+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQgLSBkcmFmdC1p ZXRmLWJmZC12eGxhbi0wOS50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiAK ICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0gCiAgICB0 ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZhbWlseTog bW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9IAogICAg dGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQtc2l6ZTog MC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9 IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsg YmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gCiAgICAu aW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7 IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5saW5lYnIg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJh Y2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0 OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFB OyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAogICAgLnJp Z2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sgLmNvbnQg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJhY2tncm91 bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjog IzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFEOyB9IAog ICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IHBhZGRpbmc6IDJweCAwOyB9IAogICAgc3Bhbi5oaWRlIHsgZGlzcGxheTogbm9uZTsgY29sb3I6 ICNhYWE7fSAgICBhOmhvdmVyIHNwYW4geyBkaXNwbGF5OiBpbmxpbmU7IH0gICAgdHIuY2hhbmdl IHsgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsgfSAKICAgIHRyLmNoYW5nZSBhIHsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBjb2xvcjogYmxhY2sgfSAKICA8L3N0eWxlPiAKICAgICA8c2NyaXB0Pgp2 YXIgY2h1bmtfaW5kZXggPSAwOwp2YXIgb2xkX2NodW5rID0gbnVsbDsKCmZ1bmN0aW9uIGZvcm1h dF9jaHVuayhpbmRleCkgewogICAgdmFyIHByZWZpeCA9ICJkaWZmIjsKICAgIHZhciBzdHIgPSBp bmRleC50b1N0cmluZygpOwogICAgZm9yICh4PTA7IHg8KDQtc3RyLmxlbmd0aCk7ICsreCkgewog ICAgICAgIHByZWZpeCs9JzAnOwogICAgfQogICAgcmV0dXJuIHByZWZpeCArIHN0cjsKfQoKZnVu Y3Rpb24gZmluZF9jaHVuayhuKXsKICAgIHJldHVybiBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCd0 cltpZCQ9IicgKyBuICsgJyJdJyk7Cn0KCmZ1bmN0aW9uIGNoYW5nZV9jaHVuayhvZmZzZXQpIHsK ICAgIHZhciBpbmRleCA9IGNodW5rX2luZGV4ICsgb2Zmc2V0OwogICAgdmFyIG5ld19zdHI7CiAg ICB2YXIgbmV3X2NodW5rOwoKICAgIG5ld19zdHIgPSBmb3JtYXRfY2h1bmsoaW5kZXgpOwogICAg bmV3X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsKICAgIGlmICghbmV3X2NodW5rKSB7CiAg ICAgICAgcmV0dXJuOwogICAgfQogICAgaWYgKG9sZF9jaHVuaykgewogICAgICAgIG9sZF9jaHVu ay5zdHlsZS5vdXRsaW5lID0gIiI7CiAgICB9CiAgICBvbGRfY2h1bmsgPSBuZXdfY2h1bms7CiAg ICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIxcHggc29saWQgcmVkIjsKICAgIHdpbmRvdy5s b2NhdGlvbi5yZXBsYWNlKCIjIiArIG5ld19zdHIpCiAgICB3aW5kb3cuc2Nyb2xsQnkoMCwtMTAw KTsKICAgIGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9ua2V5ZG93biA9IGZ1bmN0 aW9uKGUpIHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBjYXNlIDc4OgogICAgICAgIGNo YW5nZV9jaHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNhc2UgODA6CiAgICAgICAgY2hhbmdl X2NodW5rKC0xKTsKICAgICAgICBicmVhazsKICAgIH0KfTsKICAgPC9zY3JpcHQ+IAo8L2hlYWQ+ IAo8Ym9keSBkYXRhLWdyLWMtcy1sb2FkZWQ9InRydWUiPiAKICA8dGFibGUgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+PHRyIGlkPSJwYXJ0LTEi IGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDgudHh0IiBzdHlsZT0iY29s b3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQiIHN0 eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQ8L2E+Jm5ic3A7PC90 aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJmZC12eGxhbi0wOS50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1p ZXRmLWJmZC12eGxhbi0wOS50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYu b3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWJmZC12eGxhbi0wOS50eHQiIHN0eWxlPSJjb2xv cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3Ry PiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij5CRkQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT LiBQYWxsYWdhdHRpLCBFZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5CRkQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBQYWxsYWdh dHRpLCBFZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2FyZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2FyZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFMuIFBhcmFnaXJpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIFBhcmFnaXJpPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE1heSA8c3BhbiBjbGFz cz0iZGVsZXRlIj40LCAyMDIwIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu ZGl2aWR1YWwgQ29udHJpYnV0b3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhw aXJlczogTWF5IDxzcGFuIGNsYXNzPSJpbnNlcnQiPjIyLCAyMDIwPC9zcGFuPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBDb250cmlidXRvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFYuIEdvdmluZGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFYuIEdvdmluZGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBNdWRp Z29uZGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBNdWRpZ29uZGE8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRy4gTWlyc2t5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ry4gTWlyc2t5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxz cGFuIGNsYXNzPSJkZWxldGUiPiBOb3ZlbWJlciAxPC9zcGFuPiwgMjAxOTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgMTk8L3NwYW4+ LCAyMDE5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQkZEIGZvciBWWExBTjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJmZC12eGxhbi0wPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDxzcGFuIGNsYXNzPSJpbnNl cnQiPjk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEZXRlY3Rpb24gKEJGRCkg cHJvdG9jb2wgaW4gcG9pbnQtdG8tcG9pbnQgVmlydHVhbCBlWHRlbnNpYmxlIExvY2FsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIGlu IHBvaW50LXRvLXBvaW50IFZpcnR1YWwgZVh0ZW5zaWJsZSBMb2NhbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgQXJlYSBOZXR3b3JrIChWWExBTikgdHVubmVscyBmb3JtaW5nIHVwIGFu IG92ZXJsYXkgbmV0d29yay48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBcmVh IE5ldHdvcmsgKFZYTEFOKSB0dW5uZWxzIGZvcm1pbmcgdXAgYW4gb3ZlcmxheSBuZXR3b3JrLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5TdGF0dXMgb2YgVGhpcyBNZW1vPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9InBhcnQtMiIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDM4PHNwYW4gY2xh c3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNr aXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3Jn L3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUgMzg8c3BhbiBj bGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0 cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDxzcGFuIGNs YXNzPSJkZWxldGUiPjQ8L3NwYW4+LCAyMDIwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1heSA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4yMjwvc3Bhbj4sIDIwMjAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5 cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdo dCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRG IFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCBy aWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1Ympl Y3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHBzOi8vdHJ1c3Rl ZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcvbGlj ZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0 aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMyIg Y2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlo dCNwYXJ0LTMiPjxlbT4gcGFnZSA4LCBsaW5lIDUxPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bh bj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5w eWh0I3BhcnQtMyI+PGVtPiBwYWdlIDgsIGxpbmUgNTE8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9z cGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZG9jdW1lbnQgcmVxdWlyZXMg c2V0dGluZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRvY3VtZW50IHJlcXVpcmVzIHNldHRpbmcgdGhl IGlubmVyIElQIFRUTCB0byAxLCB3aGljaCBjb3VsZCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgdXNlZCBhcyBhIEREb1MgYXR0YWNrIHZlY3Rvci4gIFRodXMgdGhlIGltcGxlbWVu dGF0aW9uIE1VU1QgaGF2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVzZWQg YXMgYSBERG9TIGF0dGFjayB2ZWN0b3IuICBUaHVzIHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIGhh dmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRocm90dGxpbmcgaW4gcGxhY2UgdG8g Y29udHJvbCB0aGUgcmF0ZSBvZiBCRkQgQ29udHJvbCBwYWNrZXRzIHNlbnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aHJvdHRsaW5nIGluIHBsYWNlIHRvIGNvbnRyb2wgdGhl IHJhdGUgb2YgQkZEIENvbnRyb2wgcGFja2V0cyBzZW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICB0byB0aGUgY29udHJvbCBwbGFuZS4gIE9uIHRoZSBvdGhlciBoYW5kLCBvdmVyLWFn Z3Jlc3NpdmUgdGhyb3R0bGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRv IHRoZSBjb250cm9sIHBsYW5lLiAgT24gdGhlIG90aGVyIGhhbmQsIG92ZXItYWdncmVzc2l2ZSB0 aHJvdHRsaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvZiBCRkQgQ29udHJvbCBw YWNrZXRzIG1heSBiZWNvbWUgdGhlIGNhdXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8gZm9ybTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIEJGRCBDb250cm9sIHBhY2tldHMgbWF5 IGJlY29tZSB0aGUgY2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBmb3JtPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBhbmQgbWFpbnRhaW4gQkZEIHNlc3Npb24gYXQgc2NhbGUuICBIZW5j ZSwgdGhyb3R0bGluZyBvZiBCRkQgQ29udHJvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGFuZCBtYWludGFpbiBCRkQgc2Vzc2lvbiBhdCBzY2FsZS4gIEhlbmNlLCB0aHJvdHRs aW5nIG9mIEJGRCBDb250cm9sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYWNrZXRz IFNIT1VMRCBiZSBhZGp1c3RlZCB0byBwZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0 czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBhY2tldHMgU0hPVUxEIGJlIGFk anVzdGVkIHRvIHBlcm1pdCBCRkQgdG8gd29yayBhY2NvcmRpbmcgdG8gaXRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm9jZWR1cmVzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIHByb2NlZHVyZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoaXMgZG9jdW1lbnQgcmVj b21tZW5kcyB1c2luZyBhbiBhZGRyZXNzIGZyb20gdGhlIEludGVybmFsIGhvc3Q8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBsb29wYmFjayBhZGRyZXNzZXMgcmFuZ2UgYXMg dGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MgaW4gdGhlIGlubmVyPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgSVAgaGVhZGVyIC4gVXNpbmcgc3VjaCBhZGRyZXNzIHByZXZl bnRzIHRoZSBmb3J3YXJkaW5nIG9mIHRoZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNl cnQiPiAgIGVuY2Fwc3VsYXRlZCBCRkQgY29udHJvbCBtZXNzYWdlIGJ5IGEgdHJhbnNpZW50IG5v ZGUgaW4gY2FzZSB0aGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBWWExB TiB0dW5uZWwgaXMgYnJva2VuIGFzIGFjY29yZGluZyB0byBbUkZDMTgxMl06PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgQSByb3V0ZXIgU0hPVUxEIE5PVCBmb3J3YXJkLCBleGNlcHQgb3ZlciBhIGxvb3Bi YWNrIGludGVyZmFjZSwgYW55PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg ICAgcGFja2V0IHRoYXQgaGFzIGEgZGVzdGluYXRpb24gYWRkcmVzcyBvbiBuZXR3b3JrIDEyNy4g IEEgcm91dGVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgTUFZIGhh dmUgYSBzd2l0Y2ggdGhhdCBhbGxvd3MgdGhlIG5ldHdvcmsgbWFuYWdlciB0byBkaXNhYmxlIHRo ZXNlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgY2hlY2tzLiAgSWYg c3VjaCBhIHN3aXRjaCBpcyBwcm92aWRlZCwgaXQgTVVTVCBkZWZhdWx0IHRvPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgcGVyZm9ybWluZyB0aGUgY2hlY2tzLjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IElmIHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBlc3RhYmxpc2hpbmcgbXVsdGlwbGUgQkZE IHNlc3Npb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSWYgdGhlIGltcGxl bWVudGF0aW9uIHN1cHBvcnRzIGVzdGFibGlzaGluZyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJldHdlZW4gdGhlIHNhbWUgcGFpciBvZiBWVEVQ cywgdGhlcmUgU0hPVUxEIGJlIGEgbWVjaGFuaXNtIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBzLCB0aGVyZSBTSE9VTEQg YmUgYSBtZWNoYW5pc20gdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbnRyb2wg dGhlIG1heGltdW0gbnVtYmVyIG9mIHN1Y2ggc2Vzc2lvbnMgdGhhdCBjYW4gYmUgYWN0aXZlIGF0 IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRyb2wgdGhlIG1heGlt dW0gbnVtYmVyIG9mIHN1Y2ggc2Vzc2lvbnMgdGhhdCBjYW4gYmUgYWN0aXZlIGF0IHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2FtZSB0aW1lLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHNhbWUgdGltZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgT3RoZXIgdGhhbiBpbm5lciBJUCBUVEwgc2V0IHRvIDEgYW5kIGxpbWl0IHRoZSBudW1i ZXIgb2YgQkZEIHNlc3Npb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgT3Ro ZXIgdGhhbiBpbm5lciBJUCBUVEwgc2V0IHRvIDEgYW5kIGxpbWl0IHRoZSBudW1iZXIgb2YgQkZE IHNlc3Npb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiZXR3ZWVuIHRoZSBzYW1l IHBhaXIgb2YgVlRFUHMsIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCByYWlzZSBhbnk8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiZXR3ZWVuIHRoZSBzYW1lIHBhaXIgb2Yg VlRFUHMsIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCByYWlzZSBhbnk8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGFkZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWVzIGJleW9uZCB0aG9z ZSBvZiB0aGUgc3BlY2lmaWNhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBhZGRpdGlvbmFsIHNlY3VyaXR5IGlzc3VlcyBiZXlvbmQgdGhvc2Ugb2YgdGhlIHNwZWNpZmlj YXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWZlcnJlZCB0byBpbiB0aGUg bGlzdCBvZiBub3JtYXRpdmUgcmVmZXJlbmNlcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICByZWZlcnJlZCB0byBpbiB0aGUgbGlzdCBvZiBub3JtYXRpdmUgcmVmZXJlbmNlcy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 InBhcnQtNCIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBj aGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3Jm Y2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSA5LCBsaW5lIDMxPHNwYW4gY2xhc3M9ImhpZGUi PiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRv IGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYv cmZjZGlmZi5weWh0I3BhcnQtNCI+PGVtPiBwYWdlIDksIGxpbmUgNDM8c3BhbiBjbGFzcz0iaGlk ZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmV2aWV3cyBhbmQgZmVlZGJh Y2sgb24gdGhpcyBtYXRlcmlhbC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBy ZXZpZXdzIGFuZCBmZWVkYmFjayBvbiB0aGlzIG1hdGVyaWFsLjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBBdXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byB0aGFuayBOb2JvIEFr aXlhLCBNYXJjIEJpbmRlcmJlcmdlciw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBBdXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byB0aGFuayBOb2JvIEFraXlhLCBNYXJjIEJpbmRl cmJlcmdlciw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNoYWhyYW0gRGF2YXJpLCBE b25hbGQgRS4gIEVhc3RsYWtlIDNyZCwgYW5kIEFub29wIEdoYW53YW5pIGZvciB0aGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTaGFocmFtIERhdmFyaSwgRG9uYWxkIEUuICBF YXN0bGFrZSAzcmQsIGFuZCBBbm9vcCBHaGFud2FuaSBmb3IgdGhlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBleHRlbnNpdmUgcmV2aWV3cyBhbmQgdGhlIG1vc3QgZGV0YWlsZWQgYW5k IGhlbHBmdWwgY29tbWVudHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXh0 ZW5zaXZlIHJldmlld3MgYW5kIHRoZSBtb3N0IGRldGFpbGVkIGFuZCBoZWxwZnVsIGNvbW1lbnRz LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4xMi4gIFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+MTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+MTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDYiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPltSRkMxODEyXSAgQmFrZXIsIEYuLCBFZC4sICJSZXF1aXJlbWVudHMgZm9yIElQ IFZlcnNpb24gNCBSb3V0ZXJzIiw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4g ICAgICAgICAgICAgIFJGQyAxODEyLCBET0kgMTAuMTc0ODcvUkZDMTgxMiwgSnVuZSAxOTk1LDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMTgxMiZndDsuPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBC cmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5 IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUmVxdWlyZW1l bnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjEx OSwgTWFyY2ggMTk5Nyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg Jmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgW1JGQzU4ODBdICBLYXR6LCBELiBhbmQgRC4gV2FyZCwgIkJpZGlyZWN0aW9uYWwg Rm9yd2FyZGluZyBEZXRlY3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UkZDNTg4MF0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5n IERldGVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAoQkZE KSIsIFJGQyA1ODgwLCBET0kgMTAuMTc0ODcvUkZDNTg4MCwgSnVuZSAyMDEwLDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgKEJGRCkiLCBSRkMgNTg4MCwgRE9J IDEwLjE3NDg3L1JGQzU4ODAsIEp1bmUgMjAxMCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTg4 MCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7 aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1ODgwJmd0Oy48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzU4ODFdICBLYXR6LCBELiBhbmQgRC4gV2FyZCwg IkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBbUkZDNTg4MV0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rp b25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2Nv bG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNo YW5nZXMuIDYgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJz dGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjQgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+ PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MjAgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3Ro Pjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBj bGFzcz0ic21hbGwiPjxicj5UaGlzIGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAx LjQ3LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDov L3d3dy50b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLyI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwvdHI+CiAgIDwvdGJvZHk+PC90YWJsZT4KICAgCiAg IAo8L2JvZHk+PC9odG1sPg== --000000000000dc44870597be1fa2-- From nobody Thu Nov 21 18:48:57 2019 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 0E4BF12012E; Thu, 21 Nov 2019 18:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 pnEr8uS3k5xQ; Thu, 21 Nov 2019 18:48:55 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBBF12012A; Thu, 21 Nov 2019 18:48:55 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 13B7F1E342; Thu, 21 Nov 2019 21:52:56 -0500 (EST) Date: Thu, 21 Nov 2019 21:52:55 -0500 From: Jeffrey Haas To: rtgwg@ietf.org Cc: rtg-bfd@ietf.org Subject: BFD chair response to presentation on draft-mirmin-bfd-extended Message-ID: <20191122025255.GW21134@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Fri, 22 Nov 2019 02:48:57 -0000 In the interest of permitting the presentations to move smoothly at this Friday's rtgwg session, I withheld my comments from microphone. However, please consider these comments for the record for IETF-106. Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. rtgwg is indeed intended to be a general purpose dispatch group for work without a home, but that's not the case for BFD. Secondly, Reshad and I intentionally did not schedule work on BFD extension work, including Greg's presentation, for this IETF. This is because there is open charter discussions we're starting with the IESG on this space. ----- Specific comments on BFD extension work and the charter discussions: During prior IETFs, and culminating at IETF-105, we've seen regular work to try to stuff BFD with additional features of various forms. The litmus test generally used for BFD's core use case over the years has been "what do you want to hear every 3.3ms?" To that end, things that enhance BFD's core continuity verification uses cases have ended up in the protocol. Somewhat similar to other popular protocols such as DNS and BGP, BFD has nice properties that make it an appealing place to try to extend. In particular, it's a continuing conversation between two systems. During IETF-105, the IPPM group members attending explicitly noted that they did not want to see their mechanisms present in BFD and did not consider it a good fit. As part of that discussion, the chairs noted that one option potentially open is that we permit the "BFDv2" option we have discussed at IETF-105 and previous to permit an option where we do not use the core BFDv1 session used for continuity for these extensions, and use a different protocol version and port set to enable the other use cases. Thus, the discussion with the IESG is whether BFD hands over the "gift" of a general and mature mechanism for a conversation between two systems that may be generally extended to carry "interesting" information. This addresses Tony Li's point about "please don't make BFD difficult to implement in hardware". ----- Specific comments on draft-mirmin-bfd-extended: The somewhat peculiar extension mechanism shown in Greg's draft was originally seeded by work I started in BFD for draft-ietf-bfd-large-packets. In fairness to history, this was similar to work that was done in OSPF years back for how the authentication mechanism was spliced onto the protocol. The one sentence description of that use case is "make the packet padded to test MTU". It's a hack, but one that does a reasonable job of its use case. However, with regard to leveraging this hack for a general purpose extension mechanism, I don't find it a good fit. BFDv1 does not expect to find information regarding the packet or state machine outside of the main PDU. It is likely a new version number will need to be used to establish future semantics. (Per prior discussion in the working group.) The capabilities mechanism will likely require either integration into some form of an updated state machine for the new version header, or a different form. IMO, I find it likely that a "capability advertisement" mechanism would be necessary rather than negotiation to avoid a wholesale replacement of the BFD state machinery. And if we replace that much of the machinery, let's just stop calling this BFD at all and move on. With regard to IPPM style content for the draft, I refer you to the IPPM members comments above from IETF-105. With regard to authentication, there are two possibilities here: - Faster authentication of BFD style packets is covered by work completing BFD WGLC draft-ietf-bfd-optimitizing-authentication. I'd encourage other working groups in need of a faster per-packet authentication mechanism to consider whether it's an appropriate fit. - In the case that such a future BFD, or mechanism built on similar machinery, want a way to autenticate the payload different from the headers, there will likely need to be discussion about not only what envelope is used, but also strength vs. periodicity. (And if you don't need this stuff periodically, why use something like BFD?) -- Jeff From nobody Thu Nov 21 19:28:47 2019 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 DD1CC12084A; Thu, 21 Nov 2019 19:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a99GGise; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LuG5KNPy 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 XPh4GUSho71z; Thu, 21 Nov 2019 19:28:43 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A8A1120836; Thu, 21 Nov 2019 19:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7094; q=dns/txt; s=iport; t=1574393323; x=1575602923; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=a99GGise6XwDsJxKkJJww4jPVjZKLWBuqbRlku+Vk5VmAO2jJ28uHulT kG5jiX8GTzLJvVGoVdpPv9wk0xoJc+UUSkLk5oPX49XpkaTZmEp7rNYY9 8Xm7HufyoWeuz6Hb99V71r4HiJtf9PF82p4g57rv9VHGeF2h5FvteMbdu A=; IronPort-PHdr: =?us-ascii?q?9a23=3A0JLRHB/3ner5Af9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSKAEv3LP/CZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAAKVddd/5pdJa1kGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gUtQBYFEIAQLKoQqg0YDim2COpgmglIDVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4IRJDgTAgMNAQEEAQEBAgEFBG2FNwyFUgIBAxIREQw?= =?us-ascii?q?BATcBDwIBCA4MAhkNAgICMBUQAgQBDQUigwCCRwMuAQKiegKBOIhgdYEygn4?= =?us-ascii?q?BAQWCSYI/GIIXCYEOKIwWGoFAP4ERJwwTgkw+hEUXgnkygiyNB4MPnh4Kgiu?= =?us-ascii?q?VUBuCPodqj3COSJoMAgQCBAUCDgEBBYFpIoFYcBVlAYJBUBEUhkgMF4NQilN?= =?us-ascii?q?0gSiQHQEB?= X-IronPort-AV: E=Sophos;i="5.69,228,1571702400"; d="scan'208";a="375711072" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Nov 2019 03:28:42 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAM3Sgsx011617 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Nov 2019 03:28:42 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 21:28:41 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 22:28:40 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 21 Nov 2019 21:28:40 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nZj97V4i2Czita78o+9aPDRQC3fMkBV1pm7DTptQN3fX1Y61NBgNCcFPhM4rhUFsAqR2VdPaG3QWd+V5S7dofFCwS9R1QnGKOFb3OX6qudcGghqJ2NBE4kstGFZTvXMAOVwGQUZYuBup7+4bMtqkD0tRimoxidbljS4Jdl+xv98ka/2gmpu21VuLw6uYsuVlN9OcgvDEzfAOI+16sb7U8E7MNeICJ1XHYz3ap4xYFevwl3G9ra2HLMXvUAPGvkvyOTjlruFmaOUG7dKubv35t2k5hdIGIOMIympTtx3gqHLzTSLfJ9zXF1ZeYO2x0f1WNN/LwTlYAXMCa9eH3qhm+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=g80ASk5ssyRk/oPYo3N0PvCOhO8B3t6cxGaiNs7EknWqxLfRKeebhS51K2kPf3Lew3OvxtI0kM8DwEwXUsh8yn+0H8PDBiQDs1wewlq8Yxs6KsiheoyxcpElC1inNY357Z7t1fek9dqMnuNOl8jNFbQYClzFYLxJlTkPPEBV6JpVO1cRcunB5p7zF6RfqzCxJCawLJLHTcFQgOIUOY1atBewhvTOPG3AA3qK0DnO1k7wpZoDtPmMtPsKNs+FkGaG7iEJ5+jxLgfFxa9UONvB9D0dxxZrxlt2+MQRDF51AbyfTTiSZJxRV5Djj3xVUyDpmTVfoo5jL6fie9vm9fBBHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y55crl5vaQgyT0GrO+C/t0wvtHi4DIFCnk7MgyjvDlo=; b=LuG5KNPyN4FtifXYX3pYmNsnR1WblKY9er0XyE8I5pqhj9ksJPFNZyuFRGS9jWwmyaftuiDtylTPtvU3zVY6OzR+mJiql3vwxx6U7/nZ2sFIK7aJ9dBAcGcNWvIVWAdN0Po8X+xbYCiXmQaKSwdRHrThKsLR5gBbZyLNHFL4exk= Received: from BYAPR11MB3061.namprd11.prod.outlook.com (20.177.224.85) by BYAPR11MB2757.namprd11.prod.outlook.com (52.135.229.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Fri, 22 Nov 2019 03:28:39 +0000 Received: from BYAPR11MB3061.namprd11.prod.outlook.com ([fe80::c9f1:5bf6:d43f:ddc1]) by BYAPR11MB3061.namprd11.prod.outlook.com ([fe80::c9f1:5bf6:d43f:ddc1%5]) with mapi id 15.20.2451.032; Fri, 22 Nov 2019 03:28:39 +0000 From: "Rakesh Gandhi (rgandhi)" To: Jeffrey Haas , "rtgwg@ietf.org" CC: "rtg-bfd@ietf.org" Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Topic: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Index: AQHVoN9rOKFV6n8KJUCeo0/1v97X/6eXDjkA Date: Fri, 22 Nov 2019 03:28:39 +0000 Message-ID: References: <20191122025255.GW21134@pfrc.org> In-Reply-To: <20191122025255.GW21134@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com; x-originating-ip: [2001:420:c0dc:1002::1a5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c5ae4f9-0a78-4046-48c4-08d76efc1127 x-ms-traffictypediagnostic: BYAPR11MB2757: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02296943FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(189003)(199004)(11346002)(446003)(76176011)(36756003)(6246003)(2616005)(186003)(102836004)(4326008)(14454004)(33656002)(25786009)(46003)(2906002)(6116002)(6506007)(478600001)(99286004)(4001150100001)(2501003)(6436002)(64756008)(6486002)(7736002)(76116006)(66476007)(66946007)(229853002)(66556008)(305945005)(14444005)(256004)(66446008)(91956017)(8676002)(81156014)(5660300002)(81166006)(58126008)(8936002)(71190400001)(71200400001)(110136005)(316002)(6512007)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2757; H:BYAPR11MB3061.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: g3zE2zGHi1pRVRuq4t9qUOFujGw3hXAmo2mAf7SNOBxU6nm9SyhoCl9zh3hISzBEzFpYKv6Cl5H+TQKYVnNjfdLjEk9IHq/ha+f+d0p9yEBNRL2rpw3kRuy4oVu/+hpkb8hbU7p45FCNVYRTN5wnSYjrpdSHYmlUEN31x2yENkBp8UZf+3gFJ7jfJmtr07kaKZ+hN6WHWnXy2IQqf6LyoMcTJePbgSw4Fr4PB5AavgxdjAxx3FMxdZN/+Wv8jGVkEFbyMZYBYfCP/LXDaT9NeobcgxRFT8hr/p27Ofm49fHtGKou2GWqOWLjWwhwRkcxqDHlpJCf2lv78whLIryExQoZyc4XqBsna2qSKBL/T42JcSM1j5IT9lWD9ZJERETG1BkVBWz+yLTtNQcX0FxvnqHC24dDWHiPjFR5XSNGY4aXlDIhJNgDOBN0yGtxrq4L x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <054A19B6C1D7F04F98EBFCD3B79B8A15@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2c5ae4f9-0a78-4046-48c4-08d76efc1127 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 03:28:39.2559 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AZgLtP0OyOfDwiQHGVoLq0/LrwXiLk21DZp5UyjSobDpSrLgr8q+9CpGQvWfGWTfMTbJRZe5gvc7FvVQoM1PSg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2757 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: 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: Fri, 22 Nov 2019 03:28:46 -0000 SGkgV0dzLA0KVGhpcyB3YXMgZ3JlYXRseSBkaXNjdXNzZWQgaW4gdGhlIEJGRCBXRyBtZWV0aW5n IGluIE1vbnRyZWFsLCBhbmQgdGhhdCB0aGVyZSB3YXMgTk8gc3VwcG9ydCB0byBjb21wbGljYXRl IHRoZSBCRkQgZm9yIElQUE0gdXNlLWNhc2VzLiBUaGVyZSBhcmUgbnVtYmVyIG9mIGV4aXN0aW5n IHByb3RvY29scyAoT1dBTVAsIFRXQU1QLCBSRkM2Mzc0LCBTVEFNUCwgSU9BTSwgZXRjLikgZGVz aWduZWQsIGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCBmb3IgSVBQTSB1c2UtY2FzZXMgYWxyZWFk eS4gSSBhbSBzdXJwcmlzZWQgdGhhdCB0aGUgdGV4dCBpcyBzdGlsbCBwcmVzZW50IGluIHRoZSBs YXRlc3QgdmVyc2lvbiAoMDIpIG9mIHRoZSBkcmFmdCAoU2VjdGlvbiAzLjQpIGFuZCBwcmVzZW50 ZWQgaW4gYW5vdGhlciBXRy4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0K77u/T24gMjAxOS0xMS0y MiwgMTA6NDkgQU0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiIDxydGctYmZk LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMub3JnPiB3cm90ZToNCg0K ICAgIEluIHRoZSBpbnRlcmVzdCBvZiBwZXJtaXR0aW5nIHRoZSBwcmVzZW50YXRpb25zIHRvIG1v dmUgc21vb3RobHkgYXQgdGhpcw0KICAgIEZyaWRheSdzIHJ0Z3dnIHNlc3Npb24sIEkgd2l0aGhl bGQgbXkgY29tbWVudHMgZnJvbSBtaWNyb3Bob25lLiAgSG93ZXZlciwNCiAgICBwbGVhc2UgY29u c2lkZXIgdGhlc2UgY29tbWVudHMgZm9yIHRoZSByZWNvcmQgZm9yIElFVEYtMTA2Lg0KICAgIA0K ICAgIEZpcnN0bHksIEknbSBzdXJwcmlzZWQgdGhlIGNoYWlycyBoYWQgYSBCRkQgcHJlc2VudGF0 aW9uIGF0IHJ0Z3dnLiAgcnRnd2cgaXMNCiAgICBpbmRlZWQgaW50ZW5kZWQgdG8gYmUgYSBnZW5l cmFsIHB1cnBvc2UgZGlzcGF0Y2ggZ3JvdXAgZm9yIHdvcmsgd2l0aG91dCBhDQogICAgaG9tZSwg YnV0IHRoYXQncyBub3QgdGhlIGNhc2UgZm9yIEJGRC4NCiAgICANCiAgICBTZWNvbmRseSwgUmVz aGFkIGFuZCBJIGludGVudGlvbmFsbHkgZGlkIG5vdCBzY2hlZHVsZSB3b3JrIG9uIEJGRCBleHRl bnNpb24NCiAgICB3b3JrLCBpbmNsdWRpbmcgR3JlZydzIHByZXNlbnRhdGlvbiwgZm9yIHRoaXMg SUVURi4gIFRoaXMgaXMgYmVjYXVzZSB0aGVyZQ0KICAgIGlzIG9wZW4gY2hhcnRlciBkaXNjdXNz aW9ucyB3ZSdyZSBzdGFydGluZyB3aXRoIHRoZSBJRVNHIG9uIHRoaXMgc3BhY2UuDQogICAgDQog ICAgLS0tLS0NCiAgICANCiAgICBTcGVjaWZpYyBjb21tZW50cyBvbiBCRkQgZXh0ZW5zaW9uIHdv cmsgYW5kIHRoZSBjaGFydGVyIGRpc2N1c3Npb25zOg0KICAgIA0KICAgIER1cmluZyBwcmlvciBJ RVRGcywgYW5kIGN1bG1pbmF0aW5nIGF0IElFVEYtMTA1LCB3ZSd2ZSBzZWVuIHJlZ3VsYXIgd29y ayB0bw0KICAgIHRyeSB0byBzdHVmZiBCRkQgd2l0aCBhZGRpdGlvbmFsIGZlYXR1cmVzIG9mIHZh cmlvdXMgZm9ybXMuICBUaGUgbGl0bXVzIHRlc3QNCiAgICBnZW5lcmFsbHkgdXNlZCBmb3IgQkZE J3MgY29yZSB1c2UgY2FzZSBvdmVyIHRoZSB5ZWFycyBoYXMgYmVlbiAid2hhdCBkbyB5b3UNCiAg ICB3YW50IHRvIGhlYXIgZXZlcnkgMy4zbXM/IiAgVG8gdGhhdCBlbmQsIHRoaW5ncyB0aGF0IGVu aGFuY2UgQkZEJ3MgY29yZQ0KICAgIGNvbnRpbnVpdHkgdmVyaWZpY2F0aW9uIHVzZXMgY2FzZXMg aGF2ZSBlbmRlZCB1cCBpbiB0aGUgcHJvdG9jb2wuDQogICAgDQogICAgU29tZXdoYXQgc2ltaWxh ciB0byBvdGhlciBwb3B1bGFyIHByb3RvY29scyBzdWNoIGFzIEROUyBhbmQgQkdQLCBCRkQgaGFz DQogICAgbmljZSBwcm9wZXJ0aWVzIHRoYXQgbWFrZSBpdCBhbiBhcHBlYWxpbmcgcGxhY2UgdG8g dHJ5IHRvIGV4dGVuZC4gIEluDQogICAgcGFydGljdWxhciwgaXQncyBhIGNvbnRpbnVpbmcgY29u dmVyc2F0aW9uIGJldHdlZW4gdHdvIHN5c3RlbXMuDQogICAgDQogICAgRHVyaW5nIElFVEYtMTA1 LCB0aGUgSVBQTSBncm91cCBtZW1iZXJzIGF0dGVuZGluZyBleHBsaWNpdGx5IG5vdGVkIHRoYXQg dGhleQ0KICAgIGRpZCBub3Qgd2FudCB0byBzZWUgdGhlaXIgbWVjaGFuaXNtcyBwcmVzZW50IGlu IEJGRCBhbmQgZGlkIG5vdCBjb25zaWRlciBpdA0KICAgIGEgZ29vZCBmaXQuDQogICAgDQogICAg QXMgcGFydCBvZiB0aGF0IGRpc2N1c3Npb24sIHRoZSBjaGFpcnMgbm90ZWQgdGhhdCBvbmUgb3B0 aW9uIHBvdGVudGlhbGx5DQogICAgb3BlbiBpcyB0aGF0IHdlIHBlcm1pdCB0aGUgIkJGRHYyIiBv cHRpb24gd2UgaGF2ZSBkaXNjdXNzZWQgYXQgSUVURi0xMDUgYW5kDQogICAgcHJldmlvdXMgdG8g cGVybWl0IGFuIG9wdGlvbiB3aGVyZSB3ZSBkbyBub3QgdXNlIHRoZSBjb3JlIEJGRHYxIHNlc3Np b24gdXNlZA0KICAgIGZvciBjb250aW51aXR5IGZvciB0aGVzZSBleHRlbnNpb25zLCBhbmQgdXNl IGEgZGlmZmVyZW50IHByb3RvY29sIHZlcnNpb24NCiAgICBhbmQgcG9ydCBzZXQgdG8gZW5hYmxl IHRoZSBvdGhlciB1c2UgY2FzZXMuDQogICAgDQogICAgVGh1cywgdGhlIGRpc2N1c3Npb24gd2l0 aCB0aGUgSUVTRyBpcyB3aGV0aGVyIEJGRCBoYW5kcyBvdmVyIHRoZSAiZ2lmdCIgb2YgYQ0KICAg IGdlbmVyYWwgYW5kIG1hdHVyZSBtZWNoYW5pc20gZm9yIGEgY29udmVyc2F0aW9uIGJldHdlZW4g dHdvIHN5c3RlbXMgdGhhdCBtYXkNCiAgICBiZSBnZW5lcmFsbHkgZXh0ZW5kZWQgdG8gY2Fycnkg ImludGVyZXN0aW5nIiBpbmZvcm1hdGlvbi4NCiAgICANCiAgICBUaGlzIGFkZHJlc3NlcyBUb255 IExpJ3MgcG9pbnQgYWJvdXQgInBsZWFzZSBkb24ndCBtYWtlIEJGRCBkaWZmaWN1bHQgdG8NCiAg ICBpbXBsZW1lbnQgaW4gaGFyZHdhcmUiLg0KICAgIA0KICAgIC0tLS0tDQogICAgDQogICAgU3Bl Y2lmaWMgY29tbWVudHMgb24gZHJhZnQtbWlybWluLWJmZC1leHRlbmRlZDoNCiAgICANCiAgICBU aGUgc29tZXdoYXQgcGVjdWxpYXIgZXh0ZW5zaW9uIG1lY2hhbmlzbSBzaG93biBpbiBHcmVnJ3Mg ZHJhZnQgd2FzDQogICAgb3JpZ2luYWxseSBzZWVkZWQgYnkgd29yayBJIHN0YXJ0ZWQgaW4gQkZE IGZvciBkcmFmdC1pZXRmLWJmZC1sYXJnZS1wYWNrZXRzLg0KICAgIEluIGZhaXJuZXNzIHRvIGhp c3RvcnksIHRoaXMgd2FzIHNpbWlsYXIgdG8gd29yayB0aGF0IHdhcyBkb25lIGluIE9TUEYgeWVh cnMNCiAgICBiYWNrIGZvciBob3cgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3YXMgc3Bs aWNlZCBvbnRvIHRoZSBwcm90b2NvbC4NCiAgICBUaGUgb25lIHNlbnRlbmNlIGRlc2NyaXB0aW9u IG9mIHRoYXQgdXNlIGNhc2UgaXMgIm1ha2UgdGhlIHBhY2tldCBwYWRkZWQgdG8NCiAgICB0ZXN0 IE1UVSIuICBJdCdzIGEgaGFjaywgYnV0IG9uZSB0aGF0IGRvZXMgYSByZWFzb25hYmxlIGpvYiBv ZiBpdHMgdXNlIGNhc2UuDQogICAgDQogICAgSG93ZXZlciwgd2l0aCByZWdhcmQgdG8gbGV2ZXJh Z2luZyB0aGlzIGhhY2sgZm9yIGEgZ2VuZXJhbCBwdXJwb3NlIGV4dGVuc2lvbg0KICAgIG1lY2hh bmlzbSwgSSBkb24ndCBmaW5kIGl0IGEgZ29vZCBmaXQuICBCRkR2MSBkb2VzIG5vdCBleHBlY3Qg dG8gZmluZA0KICAgIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgcGFja2V0IG9yIHN0YXRlIG1h Y2hpbmUgb3V0c2lkZSBvZiB0aGUgbWFpbiBQRFUuDQogICAgSXQgaXMgbGlrZWx5IGEgbmV3IHZl cnNpb24gbnVtYmVyIHdpbGwgbmVlZCB0byBiZSB1c2VkIHRvIGVzdGFibGlzaCBmdXR1cmUNCiAg ICBzZW1hbnRpY3MuICAoUGVyIHByaW9yIGRpc2N1c3Npb24gaW4gdGhlIHdvcmtpbmcgZ3JvdXAu KQ0KICAgIA0KICAgIFRoZSBjYXBhYmlsaXRpZXMgbWVjaGFuaXNtIHdpbGwgbGlrZWx5IHJlcXVp cmUgZWl0aGVyIGludGVncmF0aW9uIGludG8gc29tZQ0KICAgIGZvcm0gb2YgYW4gdXBkYXRlZCBz dGF0ZSBtYWNoaW5lIGZvciB0aGUgbmV3IHZlcnNpb24gaGVhZGVyLCBvciBhIGRpZmZlcmVudA0K ICAgIGZvcm0uICBJTU8sIEkgZmluZCBpdCBsaWtlbHkgdGhhdCBhICJjYXBhYmlsaXR5IGFkdmVy dGlzZW1lbnQiIG1lY2hhbmlzbQ0KICAgIHdvdWxkIGJlIG5lY2Vzc2FyeSByYXRoZXIgdGhhbiBu ZWdvdGlhdGlvbiB0byBhdm9pZCBhIHdob2xlc2FsZSByZXBsYWNlbWVudA0KICAgIG9mIHRoZSBC RkQgc3RhdGUgbWFjaGluZXJ5LiAgQW5kIGlmIHdlIHJlcGxhY2UgdGhhdCBtdWNoIG9mIHRoZSBt YWNoaW5lcnksDQogICAgbGV0J3MganVzdCBzdG9wIGNhbGxpbmcgdGhpcyBCRkQgYXQgYWxsIGFu ZCBtb3ZlIG9uLg0KICAgIA0KICAgIFdpdGggcmVnYXJkIHRvIElQUE0gc3R5bGUgY29udGVudCBm b3IgdGhlIGRyYWZ0LCBJIHJlZmVyIHlvdSB0byB0aGUgSVBQTQ0KICAgIG1lbWJlcnMgY29tbWVu dHMgYWJvdmUgZnJvbSBJRVRGLTEwNS4NCiAgICANCiAgICBXaXRoIHJlZ2FyZCB0byBhdXRoZW50 aWNhdGlvbiwgdGhlcmUgYXJlIHR3byBwb3NzaWJpbGl0aWVzIGhlcmU6DQogICAgLSBGYXN0ZXIg YXV0aGVudGljYXRpb24gb2YgQkZEIHN0eWxlIHBhY2tldHMgaXMgY292ZXJlZCBieSB3b3JrIGNv bXBsZXRpbmcNCiAgICAgIEJGRCBXR0xDIGRyYWZ0LWlldGYtYmZkLW9wdGltaXRpemluZy1hdXRo ZW50aWNhdGlvbi4gIEknZCBlbmNvdXJhZ2Ugb3RoZXINCiAgICAgIHdvcmtpbmcgZ3JvdXBzIGlu IG5lZWQgb2YgYSBmYXN0ZXIgcGVyLXBhY2tldCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdG8N CiAgICAgIGNvbnNpZGVyIHdoZXRoZXIgaXQncyBhbiBhcHByb3ByaWF0ZSBmaXQuDQogICAgLSBJ biB0aGUgY2FzZSB0aGF0IHN1Y2ggYSBmdXR1cmUgQkZELCBvciBtZWNoYW5pc20gYnVpbHQgb24g c2ltaWxhcg0KICAgICAgbWFjaGluZXJ5LCB3YW50IGEgd2F5IHRvIGF1dGVudGljYXRlIHRoZSBw YXlsb2FkIGRpZmZlcmVudCBmcm9tIHRoZQ0KICAgICAgaGVhZGVycywgdGhlcmUgd2lsbCBsaWtl bHkgbmVlZCB0byBiZSBkaXNjdXNzaW9uIGFib3V0IG5vdCBvbmx5IHdoYXQNCiAgICAgIGVudmVs b3BlIGlzIHVzZWQsIGJ1dCBhbHNvIHN0cmVuZ3RoIHZzLiBwZXJpb2RpY2l0eS4gIChBbmQgaWYg eW91IGRvbid0IG5lZWQNCiAgICAgIHRoaXMgc3R1ZmYgcGVyaW9kaWNhbGx5LCB3aHkgdXNlIHNv bWV0aGluZyBsaWtlIEJGRD8pDQogICAgDQogICAgLS0gSmVmZg0KICAgIA0KICAgIA0KDQo= From nobody Thu Nov 21 20:40:59 2019 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 E82161200B2; Thu, 21 Nov 2019 20:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v5k6hnN3Ol7Q; Thu, 21 Nov 2019 20:40:54 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 E868B12006E; Thu, 21 Nov 2019 20:40:53 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id p18so5778607ljc.6; Thu, 21 Nov 2019 20:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PSWNbP3uuVVKFrme0t1iicq9q/YXwN4faSDI7Y/9aCc=; b=eVPsTtOTwIUTUaB5BFo9ZbwGdAe4Arj5Od5Rpq44ZmbSVc2ooqJwmLQ4fGIj86AmkH qSC0OElJXZC2m6pdvTFQLkpqSYcAGuqs7NpY51XTNt4WVufrsm2mUn694lAReswJh2pG 6jaUCnJndaSdSZqgdskQ5dPifTZQA6dAaGh9wgRmBfGhiOCV1nC0u7AJD2usLzKgR2MQ sVis5lXh2rnWYqASfOUi5g6ugKZRx5ZK680w8pz6IdnGbeyXPlVt7BrW9OmOkZv7/LGz pTCRSBClva8x+U0rAO3HI0poAhKafmsAn5eQ/dESF+SxqH/79pOxYonE6zAhfK+hq8N5 EFPg== 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=PSWNbP3uuVVKFrme0t1iicq9q/YXwN4faSDI7Y/9aCc=; b=m7xR+bWacyfuGn9nIx9tKb0faCo50ipTIsRo+NF4lSOhuygxKDOU63E9H7CCnwPFHT Pr3EPq/3Kra5I1gvtJg0eCuXl9WuDILATJU0xhfe8jCVEmlw3WH57F9cZr7XFtJQDyCP tUtDhEeQkoblvcXqUJiq8KpKY8aPxA9BJLNY/ba6vAmtcKWqKwAu5kNVvkO95KEuEpQM Uhz0F6R2+weM/7X8K0ICz4hhKAzjyGypjxPfdm5K1FxDhztX+O8yIuTkL3zvT+tCN7Rv Mtdw5B7BEgntf45yIIOstNyULgEBb3KINtEmTvMBgFR8hIZEzG4sYrJl+MrWLxbO0MbZ 6FlA== X-Gm-Message-State: APjAAAWWrRl6iPJ2i+u5nojSCUKkD8KKhtpmKgAPWcqo59V5Nv0Iy3uP XcQydbsvV0uF8UFZZC7ogdSyYXyf6VPbbLTa9Ug= X-Google-Smtp-Source: APXvYqxYDWm5CaSRrSI7qabuaLyRyP6THwqL209z8ZKfPwHu2yvOzLf6Q6sYePWaTXYzD60T/ZbFQmE5fSXSqq9lx50= X-Received: by 2002:a2e:7013:: with SMTP id l19mr10378631ljc.201.1574397651838; Thu, 21 Nov 2019 20:40:51 -0800 (PST) MIME-Version: 1.0 References: <20191122025255.GW21134@pfrc.org> In-Reply-To: From: Greg Mirsky Date: Fri, 22 Nov 2019 12:40:40 +0800 Message-ID: Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended To: "Rakesh Gandhi (rgandhi)" Cc: Jeffrey Haas , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c5eced0597e804a8" Archived-At: 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: Fri, 22 Nov 2019 04:40:57 -0000 --000000000000c5eced0597e804a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rakesh, thank you for sharing your thoughts about this work. Please find my notes in-line tagged GIM>>. Regards, Greg On Fri, Nov 22, 2019 at 11:28 AM Rakesh Gandhi (rgandhi) wrote: > Hi WGs, > This was greatly discussed in the BFD WG meeting in Montreal, and that > there was NO support to complicate the BFD for IPPM use-cases. GIM>> The draft was presented to RIFT WG some number of meetings ago. The feedback received was that the ability to use a single OAM protocol for the failure detection and loss measurement is of interest. > There are number of existing protocols (OWAMP, TWAMP, RFC6374, STAMP, > IOAM, etc.) designed, implemented and deployed for IPPM use-cases already= . > I am surprised that the text is still present in the latest version (02) = of > the draft (Section 3.4) and presented in another WG. > GIM>> I will remind that this is the individual draft. If you feel strongly that some content should be removed, please ask WG Chairs for WG Adoption Poll. Once the draft is adopted, hen, by all means, the WG will define the scope, add/remove sections. > > Thanks, > Rakesh > > > =EF=BB=BFOn 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" < > rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote: > > In the interest of permitting the presentations to move smoothly at > this > Friday's rtgwg session, I withheld my comments from microphone. > However, > please consider these comments for the record for IETF-106. > > Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. > rtgwg is > indeed intended to be a general purpose dispatch group for work > without a > home, but that's not the case for BFD. > > Secondly, Reshad and I intentionally did not schedule work on BFD > extension > work, including Greg's presentation, for this IETF. This is because > there > is open charter discussions we're starting with the IESG on this spac= e. > > ----- > > Specific comments on BFD extension work and the charter discussions: > > During prior IETFs, and culminating at IETF-105, we've seen regular > work to > try to stuff BFD with additional features of various forms. The > litmus test > generally used for BFD's core use case over the years has been "what > do you > want to hear every 3.3ms?" To that end, things that enhance BFD's co= re > continuity verification uses cases have ended up in the protocol. > > Somewhat similar to other popular protocols such as DNS and BGP, BFD > has > nice properties that make it an appealing place to try to extend. In > particular, it's a continuing conversation between two systems. > > During IETF-105, the IPPM group members attending explicitly noted > that they > did not want to see their mechanisms present in BFD and did not > consider it > a good fit. > > As part of that discussion, the chairs noted that one option > potentially > open is that we permit the "BFDv2" option we have discussed at > IETF-105 and > previous to permit an option where we do not use the core BFDv1 > session used > for continuity for these extensions, and use a different protocol > version > and port set to enable the other use cases. > > Thus, the discussion with the IESG is whether BFD hands over the > "gift" of a > general and mature mechanism for a conversation between two systems > that may > be generally extended to carry "interesting" information. > > This addresses Tony Li's point about "please don't make BFD difficult > to > implement in hardware". > > ----- > > Specific comments on draft-mirmin-bfd-extended: > > The somewhat peculiar extension mechanism shown in Greg's draft was > originally seeded by work I started in BFD for > draft-ietf-bfd-large-packets. > In fairness to history, this was similar to work that was done in OSP= F > years > back for how the authentication mechanism was spliced onto the > protocol. > The one sentence description of that use case is "make the packet > padded to > test MTU". It's a hack, but one that does a reasonable job of its us= e > case. > > However, with regard to leveraging this hack for a general purpose > extension > mechanism, I don't find it a good fit. BFDv1 does not expect to find > information regarding the packet or state machine outside of the main > PDU. > It is likely a new version number will need to be used to establish > future > semantics. (Per prior discussion in the working group.) > > The capabilities mechanism will likely require either integration int= o > some > form of an updated state machine for the new version header, or a > different > form. IMO, I find it likely that a "capability advertisement" > mechanism > would be necessary rather than negotiation to avoid a wholesale > replacement > of the BFD state machinery. And if we replace that much of the > machinery, > let's just stop calling this BFD at all and move on. > > With regard to IPPM style content for the draft, I refer you to the > IPPM > members comments above from IETF-105. > > With regard to authentication, there are two possibilities here: > - Faster authentication of BFD style packets is covered by work > completing > BFD WGLC draft-ietf-bfd-optimitizing-authentication. I'd encourage > other > working groups in need of a faster per-packet authentication > mechanism to > consider whether it's an appropriate fit. > - In the case that such a future BFD, or mechanism built on similar > machinery, want a way to autenticate the payload different from the > headers, there will likely need to be discussion about not only wha= t > envelope is used, but also strength vs. periodicity. (And if you > don't need > this stuff periodically, why use something like BFD?) > > -- Jeff > > > > --000000000000c5eced0597e804a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rakesh,
thank you for sharing your= thoughts about this work. Please find my notes in-line tagged GIM>>.=

Regards,
Greg

On Fri, Nov 22, 2019= at 11:28 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote:
Hi WGs,
This was greatly discussed in the BFD WG meeting in Montreal, and that ther= e was NO support to complicate the BFD for IPPM use-cases.
GIM>> The draft was presented to RIFT WG some number of meetings ag= o. The feedback received was that the ability to use a single OAM protocol = for the failure detection and loss measurement is of interest.
There are number of existing pro= tocols (OWAMP, TWAMP, RFC6374, STAMP, IOAM, etc.) designed, implemented and= deployed for IPPM use-cases already. I am surprised that the text is still= present in the latest version (02) of the draft (Section 3.4) and presente= d in another WG.
GIM>> I will remind that this i= s the individual draft. If you feel strongly that some content should be re= moved, please ask WG Chairs for WG Adoption Poll. Once the draft is adopted= , hen, by all means, the WG will define the scope, add/remove sections.

Thanks,
Rakesh


=EF=BB=BFOn 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas&q= uot; <rtg-= bfd-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote:

=C2=A0 =C2=A0 In the interest of permitting the presentations to move smoot= hly at this
=C2=A0 =C2=A0 Friday's rtgwg session, I withheld my comments from micro= phone.=C2=A0 However,
=C2=A0 =C2=A0 please consider these comments for the record for IETF-106.
=C2=A0 =C2=A0 Firstly, I'm surprised the chairs had a BFD presentation = at rtgwg.=C2=A0 rtgwg is
=C2=A0 =C2=A0 indeed intended to be a general purpose dispatch group for wo= rk without a
=C2=A0 =C2=A0 home, but that's not the case for BFD.

=C2=A0 =C2=A0 Secondly, Reshad and I intentionally did not schedule work on= BFD extension
=C2=A0 =C2=A0 work, including Greg's presentation, for this IETF.=C2=A0= This is because there
=C2=A0 =C2=A0 is open charter discussions we're starting with the IESG = on this space.

=C2=A0 =C2=A0 -----

=C2=A0 =C2=A0 Specific comments on BFD extension work and the charter discu= ssions:

=C2=A0 =C2=A0 During prior IETFs, and culminating at IETF-105, we've se= en regular work to
=C2=A0 =C2=A0 try to stuff BFD with additional features of various forms.= =C2=A0 The litmus test
=C2=A0 =C2=A0 generally used for BFD's core use case over the years has= been "what do you
=C2=A0 =C2=A0 want to hear every 3.3ms?"=C2=A0 To that end, things tha= t enhance BFD's core
=C2=A0 =C2=A0 continuity verification uses cases have ended up in the proto= col.

=C2=A0 =C2=A0 Somewhat similar to other popular protocols such as DNS and B= GP, BFD has
=C2=A0 =C2=A0 nice properties that make it an appealing place to try to ext= end.=C2=A0 In
=C2=A0 =C2=A0 particular, it's a continuing conversation between two sy= stems.

=C2=A0 =C2=A0 During IETF-105, the IPPM group members attending explicitly = noted that they
=C2=A0 =C2=A0 did not want to see their mechanisms present in BFD and did n= ot consider it
=C2=A0 =C2=A0 a good fit.

=C2=A0 =C2=A0 As part of that discussion, the chairs noted that one option = potentially
=C2=A0 =C2=A0 open is that we permit the "BFDv2" option we have d= iscussed at IETF-105 and
=C2=A0 =C2=A0 previous to permit an option where we do not use the core BFD= v1 session used
=C2=A0 =C2=A0 for continuity for these extensions, and use a different prot= ocol version
=C2=A0 =C2=A0 and port set to enable the other use cases.

=C2=A0 =C2=A0 Thus, the discussion with the IESG is whether BFD hands over = the "gift" of a
=C2=A0 =C2=A0 general and mature mechanism for a conversation between two s= ystems that may
=C2=A0 =C2=A0 be generally extended to carry "interesting" inform= ation.

=C2=A0 =C2=A0 This addresses Tony Li's point about "please don'= ;t make BFD difficult to
=C2=A0 =C2=A0 implement in hardware".

=C2=A0 =C2=A0 -----

=C2=A0 =C2=A0 Specific comments on draft-mirmin-bfd-extended:

=C2=A0 =C2=A0 The somewhat peculiar extension mechanism shown in Greg's= draft was
=C2=A0 =C2=A0 originally seeded by work I started in BFD for draft-ietf-bfd= -large-packets.
=C2=A0 =C2=A0 In fairness to history, this was similar to work that was don= e in OSPF years
=C2=A0 =C2=A0 back for how the authentication mechanism was spliced onto th= e protocol.
=C2=A0 =C2=A0 The one sentence description of that use case is "make t= he packet padded to
=C2=A0 =C2=A0 test MTU".=C2=A0 It's a hack, but one that does a re= asonable job of its use case.

=C2=A0 =C2=A0 However, with regard to leveraging this hack for a general pu= rpose extension
=C2=A0 =C2=A0 mechanism, I don't find it a good fit.=C2=A0 BFDv1 does n= ot expect to find
=C2=A0 =C2=A0 information regarding the packet or state machine outside of = the main PDU.
=C2=A0 =C2=A0 It is likely a new version number will need to be used to est= ablish future
=C2=A0 =C2=A0 semantics.=C2=A0 (Per prior discussion in the working group.)=

=C2=A0 =C2=A0 The capabilities mechanism will likely require either integra= tion into some
=C2=A0 =C2=A0 form of an updated state machine for the new version header, = or a different
=C2=A0 =C2=A0 form.=C2=A0 IMO, I find it likely that a "capability adv= ertisement" mechanism
=C2=A0 =C2=A0 would be necessary rather than negotiation to avoid a wholesa= le replacement
=C2=A0 =C2=A0 of the BFD state machinery.=C2=A0 And if we replace that much= of the machinery,
=C2=A0 =C2=A0 let's just stop calling this BFD at all and move on.

=C2=A0 =C2=A0 With regard to IPPM style content for the draft, I refer you = to the IPPM
=C2=A0 =C2=A0 members comments above from IETF-105.

=C2=A0 =C2=A0 With regard to authentication, there are two possibilities he= re:
=C2=A0 =C2=A0 - Faster authentication of BFD style packets is covered by wo= rk completing
=C2=A0 =C2=A0 =C2=A0 BFD WGLC draft-ietf-bfd-optimitizing-authentication.= =C2=A0 I'd encourage other
=C2=A0 =C2=A0 =C2=A0 working groups in need of a faster per-packet authenti= cation mechanism to
=C2=A0 =C2=A0 =C2=A0 consider whether it's an appropriate fit.
=C2=A0 =C2=A0 - In the case that such a future BFD, or mechanism built on s= imilar
=C2=A0 =C2=A0 =C2=A0 machinery, want a way to autenticate the payload diffe= rent from the
=C2=A0 =C2=A0 =C2=A0 headers, there will likely need to be discussion about= not only what
=C2=A0 =C2=A0 =C2=A0 envelope is used, but also strength vs. periodicity.= =C2=A0 (And if you don't need
=C2=A0 =C2=A0 =C2=A0 this stuff periodically, why use something like BFD?)<= br>
=C2=A0 =C2=A0 -- Jeff



--000000000000c5eced0597e804a8-- From nobody Thu Nov 21 20:49:41 2019 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 61248120103; Thu, 21 Nov 2019 20:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pLqy9VKMqld0; Thu, 21 Nov 2019 20:49:34 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 BF0AF12002F; Thu, 21 Nov 2019 20:49:33 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id r15so1527025lff.2; Thu, 21 Nov 2019 20:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Brie0+wSIUm/zmZQialELETkmf0R/Hl5KmtfxxDZHt0=; b=hbVjDfTKcCSuHguGrPgOFC+EhaRoiYZcKZMGWGNzdw05fKKW+Y/++vCZJCrC2EclX7 Mnp6UrW2Kv9LGC2Zc2E9BRvnxmCT2Zxuy8NGVq+RQxHqwdfWnua500aVDvQb1T7KK3Ux FzICmUXTFModQ7lnHxfW+WIFF0zoOvXodtDuh+JRHb/ZTAmDG2KbcNbqMlaA7Ch1/yHh CcdIth3slUe+e3PkFJIXv0XL5IX1Jn5VgAI9KSapQ8wjHgRaiEnfArxC3CLaNBMP73wf qRdF1TC/KjeePmlI6uBWyLgJQSWKSztrsAkOZ/azUrm8VG1MRg6l97ZLcQUOQegRP3p8 YaYw== 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=Brie0+wSIUm/zmZQialELETkmf0R/Hl5KmtfxxDZHt0=; b=IMUBB4jOamRvSh2ij2y9P/IdB31DqbrWZtAzcCJx80zMZR963B5sZCFIUmn/BAtR8b gltUU7G9Y7M1c/XwWJz0orGwGtYxGTHT+9Ue3dRsUHRjfcuVQuoTy5DsTAkwymUo3Smz ug4zoPA1wMsO7800Ha7RGN2u9/ZomIpWccll+6R3fGxd/PtJq/o1ElS7MpFgvrhfNtCV TYk3bGJFPliwUj3PIUXNhuqM9Grs3re2dio2cUVZ9RuZcRLslceLbRQX2DwCKApP8T1a HRktOzvCY9CbpYDnq3F6R+ovoN3UdjEPSm2MNx0hIWaDyTU31mmq9vC6Aa0XUpRWZVia 2gww== X-Gm-Message-State: APjAAAVqmmTEebE6N4+EzCr2rj1vA6J8VB9erAUZTQikPu21l/Y3bTOx owlUoNt82wlGZaVus6V2os4nWVQEsw0w9vzZw/DTlKhe X-Google-Smtp-Source: APXvYqy6M6Q9RIR2nn51Xs8VfJtpbNX3mcWoHeQqBg5IM3AtSbZcKTL2rTMrYYzKMErd3nZmGRws/uNnJYjqE+Q2WtM= X-Received: by 2002:a19:8a46:: with SMTP id m67mr10448292lfd.73.1574398171940; Thu, 21 Nov 2019 20:49:31 -0800 (PST) MIME-Version: 1.0 References: <20191122025255.GW21134@pfrc.org> In-Reply-To: <20191122025255.GW21134@pfrc.org> From: Greg Mirsky Date: Fri, 22 Nov 2019 12:49:20 +0800 Message-ID: Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended To: Jeffrey Haas Cc: RTGWG , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000c60bdb0597e8238f" Archived-At: 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: Fri, 22 Nov 2019 04:49:36 -0000 --000000000000c60bdb0597e8238f Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for sharing the history of discussions at BFD WG related to this work. There have been many exciting and inspiring discussions, and I've tried to give credit to everyone who has influenced this work. It was not our intention to seek a place for this work outside the BFD WG but to share information, invite comments, and encourage discussion. With the comments about u-BFD, I think, we've received a helpful and important case to work on. If by making this presentation, I've left the impression that authors are trying to bypass the BFD WG, then I apologize as that has never been our intention. Regards, Greg On Fri, Nov 22, 2019 at 10:49 AM Jeffrey Haas wrote: > In the interest of permitting the presentations to move smoothly at this > Friday's rtgwg session, I withheld my comments from microphone. However, > please consider these comments for the record for IETF-106. > > Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. rtgwg > is > indeed intended to be a general purpose dispatch group for work without a > home, but that's not the case for BFD. > > Secondly, Reshad and I intentionally did not schedule work on BFD extension > work, including Greg's presentation, for this IETF. This is because there > is open charter discussions we're starting with the IESG on this space. > > ----- > > Specific comments on BFD extension work and the charter discussions: > > During prior IETFs, and culminating at IETF-105, we've seen regular work to > try to stuff BFD with additional features of various forms. The litmus > test > generally used for BFD's core use case over the years has been "what do you > want to hear every 3.3ms?" To that end, things that enhance BFD's core > continuity verification uses cases have ended up in the protocol. > > Somewhat similar to other popular protocols such as DNS and BGP, BFD has > nice properties that make it an appealing place to try to extend. In > particular, it's a continuing conversation between two systems. > > During IETF-105, the IPPM group members attending explicitly noted that > they > did not want to see their mechanisms present in BFD and did not consider it > a good fit. > > As part of that discussion, the chairs noted that one option potentially > open is that we permit the "BFDv2" option we have discussed at IETF-105 and > previous to permit an option where we do not use the core BFDv1 session > used > for continuity for these extensions, and use a different protocol version > and port set to enable the other use cases. > > Thus, the discussion with the IESG is whether BFD hands over the "gift" of > a > general and mature mechanism for a conversation between two systems that > may > be generally extended to carry "interesting" information. > > This addresses Tony Li's point about "please don't make BFD difficult to > implement in hardware". > > ----- > > Specific comments on draft-mirmin-bfd-extended: > > The somewhat peculiar extension mechanism shown in Greg's draft was > originally seeded by work I started in BFD for > draft-ietf-bfd-large-packets. > In fairness to history, this was similar to work that was done in OSPF > years > back for how the authentication mechanism was spliced onto the protocol. > The one sentence description of that use case is "make the packet padded to > test MTU". It's a hack, but one that does a reasonable job of its use > case. > > However, with regard to leveraging this hack for a general purpose > extension > mechanism, I don't find it a good fit. BFDv1 does not expect to find > information regarding the packet or state machine outside of the main PDU. > It is likely a new version number will need to be used to establish future > semantics. (Per prior discussion in the working group.) > > The capabilities mechanism will likely require either integration into some > form of an updated state machine for the new version header, or a different > form. IMO, I find it likely that a "capability advertisement" mechanism > would be necessary rather than negotiation to avoid a wholesale replacement > of the BFD state machinery. And if we replace that much of the machinery, > let's just stop calling this BFD at all and move on. > > With regard to IPPM style content for the draft, I refer you to the IPPM > members comments above from IETF-105. > > With regard to authentication, there are two possibilities here: > - Faster authentication of BFD style packets is covered by work completing > BFD WGLC draft-ietf-bfd-optimitizing-authentication. I'd encourage other > working groups in need of a faster per-packet authentication mechanism to > consider whether it's an appropriate fit. > - In the case that such a future BFD, or mechanism built on similar > machinery, want a way to autenticate the payload different from the > headers, there will likely need to be discussion about not only what > envelope is used, but also strength vs. periodicity. (And if you don't > need > this stuff periodically, why use something like BFD?) > > -- Jeff > > --000000000000c60bdb0597e8238f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for sharing the history of discussi= ons at BFD WG related to this work. There have been many exciting and inspi= ring discussions, and I've tried to give credit to everyone who has inf= luenced this work.
It was not our intention to seek a place for t= his work outside the BFD WG but to share information, invite comments, and = encourage discussion. With the comments about u-BFD, I think, we've rec= eived a helpful and important case to work on.
If by making this = presentation, I've left the impression that authors are trying to bypas= s the BFD WG, then I apologize as that has never been our intention.
<= div>
Regards,
Greg

On Fri, Nov 22, 2019 at 10:= 49 AM Jeffrey Haas <jhaas@pfrc.org= > wrote:
In t= he interest of permitting the presentations to move smoothly at this
Friday's rtgwg session, I withheld my comments from microphone.=C2=A0 H= owever,
please consider these comments for the record for IETF-106.

Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.=C2= =A0 rtgwg is
indeed intended to be a general purpose dispatch group for work without a home, but that's not the case for BFD.

Secondly, Reshad and I intentionally did not schedule work on BFD extension=
work, including Greg's presentation, for this IETF.=C2=A0 This is becau= se there
is open charter discussions we're starting with the IESG on this space.=

-----

Specific comments on BFD extension work and the charter discussions:

During prior IETFs, and culminating at IETF-105, we've seen regular wor= k to
try to stuff BFD with additional features of various forms.=C2=A0 The litmu= s test
generally used for BFD's core use case over the years has been "wh= at do you
want to hear every 3.3ms?"=C2=A0 To that end, things that enhance BFD&= #39;s core
continuity verification uses cases have ended up in the protocol.

Somewhat similar to other popular protocols such as DNS and BGP, BFD has nice properties that make it an appealing place to try to extend.=C2=A0 In<= br> particular, it's a continuing conversation between two systems.

During IETF-105, the IPPM group members attending explicitly noted that the= y
did not want to see their mechanisms present in BFD and did not consider it=
a good fit.

As part of that discussion, the chairs noted that one option potentially open is that we permit the "BFDv2" option we have discussed at IE= TF-105 and
previous to permit an option where we do not use the core BFDv1 session use= d
for continuity for these extensions, and use a different protocol version and port set to enable the other use cases.

Thus, the discussion with the IESG is whether BFD hands over the "gift= " of a
general and mature mechanism for a conversation between two systems that ma= y
be generally extended to carry "interesting" information.

This addresses Tony Li's point about "please don't make BFD di= fficult to
implement in hardware".

-----

Specific comments on draft-mirmin-bfd-extended:

The somewhat peculiar extension mechanism shown in Greg's draft was
originally seeded by work I started in BFD for draft-ietf-bfd-large-packets= .
In fairness to history, this was similar to work that was done in OSPF year= s
back for how the authentication mechanism was spliced onto the protocol. The one sentence description of that use case is "make the packet padd= ed to
test MTU".=C2=A0 It's a hack, but one that does a reasonable job o= f its use case.

However, with regard to leveraging this hack for a general purpose extensio= n
mechanism, I don't find it a good fit.=C2=A0 BFDv1 does not expect to f= ind
information regarding the packet or state machine outside of the main PDU.<= br> It is likely a new version number will need to be used to establish future<= br> semantics.=C2=A0 (Per prior discussion in the working group.)

The capabilities mechanism will likely require either integration into some=
form of an updated state machine for the new version header, or a different=
form.=C2=A0 IMO, I find it likely that a "capability advertisement&quo= t; mechanism
would be necessary rather than negotiation to avoid a wholesale replacement=
of the BFD state machinery.=C2=A0 And if we replace that much of the machin= ery,
let's just stop calling this BFD at all and move on.

With regard to IPPM style content for the draft, I refer you to the IPPM members comments above from IETF-105.

With regard to authentication, there are two possibilities here:
- Faster authentication of BFD style packets is covered by work completing<= br> =C2=A0 BFD WGLC draft-ietf-bfd-optimitizing-authentication.=C2=A0 I'd e= ncourage other
=C2=A0 working groups in need of a faster per-packet authentication mechani= sm to
=C2=A0 consider whether it's an appropriate fit.
- In the case that such a future BFD, or mechanism built on similar
=C2=A0 machinery, want a way to autenticate the payload different from the<= br> =C2=A0 headers, there will likely need to be discussion about not only what=
=C2=A0 envelope is used, but also strength vs. periodicity.=C2=A0 (And if y= ou don't need
=C2=A0 this stuff periodically, why use something like BFD?)

-- Jeff

--000000000000c60bdb0597e8238f-- From nobody Thu Nov 21 23:44:47 2019 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 70D211200B5; Thu, 21 Nov 2019 23:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=V8iGMnbw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hZuZo0lz 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 qvBXebAZJYd1; Thu, 21 Nov 2019 23:44:44 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39FE12000F; Thu, 21 Nov 2019 23:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5166; q=dns/txt; s=iport; t=1574408683; x=1575618283; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H1vzWpnVzlWJfBauhsHBl2lZNbTSM/jRB3XChWzhR5k=; b=V8iGMnbwSe7xRjI6jS6EBSyO1fE3rL/VsB93FDr3yiRQmzwBEEMisb7Z gLHtGWz/NLYolMDljRFGNlAtJqLJ3tFSOQ83XCi4LSNzgEg7lQXtth0Bs +R0PnFGrinF6osx2BlGOKP6xAGYw5L7AXyBmO87CEUpyWSzHOu+Id57bX s=; X-IPAS-Result: =?us-ascii?q?A0CwAACykNdd/4wNJK1kGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYF+gUtQBYFEIAQLKodwA4ptgl+YAYJSA1QJAQEBDAEBLQIBAYRAA?= =?us-ascii?q?oIoJDgTAgMBAQEDAgMCAQEEAQEBAgEFBG2FNwyFUQEBAQEDEigGAQE3AQsEA?= =?us-ascii?q?gEIDgMEAQEfEDIdCAIEAQ0FCBqFRwMuAaImAoE4iGCCJ4J+AQEFhRQYghcJg?= =?us-ascii?q?TaMFhqBQD+BEUaCTD6ER4NAgiyNB6EtCoIrlWuCPodqj3COSJoMAgQCBAUCD?= =?us-ascii?q?gEBBYFpIoFYcBWDJ1ARFIZIDBeDUIpTdIEokB0BAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AVjMXDBzuhRNg6jfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuKCEvgJvPwYAQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.69,115,1571702400"; d="scan'208";a="385942154" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Nov 2019 07:44:42 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xAM7ig35019299 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Nov 2019 07:44:42 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Nov 2019 01:44:41 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 Nov 2019 01:44:41 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 22 Nov 2019 02:44:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H25iEHbvAEto6ycm65tt07UytMiPvfH3Ew0g5hLTXKfpXVsf5xfKdLDEG4SSWs0debDwHTutmiPZNAZ1j9Y7imyZZYlhfTR556Mzhn9HpuQTlTvvz+LaW1ahPgt9YxXnX0lk/YXNfLEVgFIhmPMk/TarY/6EfFJC7ZimK/1XjRFZ3M3E7HHpd6eoLkGiwLVqpiuF6TWo7kY/8O7Anz8bwraV28v7ebCjwoohZDH8HZrn4s+kXKusa2nTiXHbeYC4ic1P8TWn4WG37PvDUhLFrXl7VWSyKhHokcdSfdbZVBqtk9n531hynwowrZkKiy0lJ5J9e+weUfEpmyJyLc2DVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xsM17FoxWCYDpRfJ8JZm5A37uZ01iQVmgsuZ5DwDv5s=; b=NQGCFbBbB6ffMZfSSc65AG0wzZw2bgYndIq1JuOY9bd5VjjUKmOInYEB10LFrcTrgWKxm47DFEmyG4ixbvm6AsY6vGMpW+h4is96N1wZMoYxGNeVoPRDBU4v6Vq2eRyT6AmEAJhU46zV3RbLWHIQ9Wpmq1EYL1OYZYay2sLFh5NLGy3CdUSvXqKdOHB0tu3T8pR5UaTGlWB4tPJlfgQst53S5eb2s1MiZDn+WXcM8ghUDeob+U3fBV7sHnWI4fB3LeGWCnMty/TTQgi/yLrKdTFpb0UiEQtW41zJzxwa8HGfXdZBR+u7p0Ypv3v178Bfeiv0mc+ZFDHOWsmSu3yS4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xsM17FoxWCYDpRfJ8JZm5A37uZ01iQVmgsuZ5DwDv5s=; b=hZuZo0lz8e1UfCh2Hpe+/a5BrN0YH5EldqP7rSts42C/YYa3F/Mpob2jM3Dey4QTFjTasjYKn/w+0uSq8rAj8AKK9FtHqZN3wN2XKKFPsBbJtkOpCniZ+4E0f6IRvsSrMDrB++fxIsUVf395rP8omaoQ2TmsCF4Gw0qqFbZV0pw= Received: from MWHPR11MB1341.namprd11.prod.outlook.com (10.169.237.144) by MWHPR11MB1677.namprd11.prod.outlook.com (10.172.54.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Fri, 22 Nov 2019 07:44:39 +0000 Received: from MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::f53a:e78c:3a56:ed8b]) by MWHPR11MB1341.namprd11.prod.outlook.com ([fe80::f53a:e78c:3a56:ed8b%8]) with mapi id 15.20.2474.019; Fri, 22 Nov 2019 07:44:39 +0000 From: "Les Ginsberg (ginsberg)" To: Jeffrey Haas , "rtgwg@ietf.org" CC: "rtg-bfd@ietf.org" Subject: RE: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Topic: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Index: AQHVoN9rc8uw0iNrakS0E87yk9QAX6eWzrUQ Date: Fri, 22 Nov 2019 07:44:39 +0000 Message-ID: References: <20191122025255.GW21134@pfrc.org> In-Reply-To: <20191122025255.GW21134@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1004::5ec] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 549f01a8-8f49-43ef-c332-08d76f1fd494 x-ms-traffictypediagnostic: MWHPR11MB1677: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02296943FF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(13464003)(199004)(189003)(66446008)(71200400001)(7696005)(52536014)(6506007)(14444005)(6246003)(76176011)(71190400001)(446003)(256004)(186003)(4326008)(74316002)(9686003)(102836004)(6436002)(7736002)(66946007)(53546011)(305945005)(64756008)(46003)(66556008)(76116006)(5660300002)(66476007)(229853002)(25786009)(2906002)(86362001)(55016002)(11346002)(2501003)(6116002)(99286004)(316002)(8676002)(8936002)(81156014)(81166006)(478600001)(14454004)(110136005)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1677; H:MWHPR11MB1341.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2va/QGELLvsLtSc3y6sYwuMCQ8No961viEbTHg39xjFWUtvdHQmMOj5g1kt6HDjYwarfzgyJKb0jYtOyjeOTn6zBciIY7SDi+NcoKBcPk12NuEzyyXAvxRfzqfXDI/ova/4y7NyKryGQsA+PZ4I6SSiVGajME7J70v6tH3JJACk1ubORyIQxn3M4P1WYXcJlEmwPFkZYJMdTL0aNLmF+U33r/W5V8xJyOzX0KZ5A2WW1sFoy1Fs7Jgyh02vfCzfeQaYtu/aao2vgGX6nAmb9zAnp8Wi0TY8+EX0nCKOb3wVfoDSgpAOREhydZAiA3UOKbYwr7CsKwaLWPCKw40KVq0A071WZ1MkAjZCluIZZMT5O3vkreu0+nvN4N9O3EGC0czCe+C+pULBwC4V1WlCuvsjAtMxL7oMi9qzOFysqm0ZbM/q+gRjFMihggqeAsEg7 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 549f01a8-8f49-43ef-c332-08d76f1fd494 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 07:44:39.5393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Fr67A/bBTd+gvgzC3mDZmiO9J1je1tBGKSsd8B+N9lOChSaBo/E+UuaNVnCVZBASNnCIxCxkj9kfe/WMAR5snA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1677 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: 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: Fri, 22 Nov 2019 07:44:46 -0000 For the record, I agree with Jeff's summary and comments. I was really surprised that Greg did not wait until IETF 107 - which the BF= D chairs had already indicated would be the time to resume discussions of t= his work. However well intentioned, both the timing and the WG were inappropriate for= this presentation. Les > -----Original Message----- > From: Rtg-bfd On Behalf Of Jeffrey Haas > Sent: Thursday, November 21, 2019 6:53 PM > To: rtgwg@ietf.org > Cc: rtg-bfd@ietf.org > Subject: BFD chair response to presentation on draft-mirmin-bfd-extended >=20 > In the interest of permitting the presentations to move smoothly at this > Friday's rtgwg session, I withheld my comments from microphone. However, > please consider these comments for the record for IETF-106. >=20 > Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. rtgwg= is > indeed intended to be a general purpose dispatch group for work without a > home, but that's not the case for BFD. >=20 > Secondly, Reshad and I intentionally did not schedule work on BFD extensi= on > work, including Greg's presentation, for this IETF. This is because ther= e > is open charter discussions we're starting with the IESG on this space. >=20 > ----- >=20 > Specific comments on BFD extension work and the charter discussions: >=20 > During prior IETFs, and culminating at IETF-105, we've seen regular work = to > try to stuff BFD with additional features of various forms. The litmus t= est > generally used for BFD's core use case over the years has been "what do y= ou > want to hear every 3.3ms?" To that end, things that enhance BFD's core > continuity verification uses cases have ended up in the protocol. >=20 > Somewhat similar to other popular protocols such as DNS and BGP, BFD has > nice properties that make it an appealing place to try to extend. In > particular, it's a continuing conversation between two systems. >=20 > During IETF-105, the IPPM group members attending explicitly noted that t= hey > did not want to see their mechanisms present in BFD and did not consider = it > a good fit. >=20 > As part of that discussion, the chairs noted that one option potentially > open is that we permit the "BFDv2" option we have discussed at IETF-105 a= nd > previous to permit an option where we do not use the core BFDv1 session u= sed > for continuity for these extensions, and use a different protocol version > and port set to enable the other use cases. >=20 > Thus, the discussion with the IESG is whether BFD hands over the "gift" o= f a > general and mature mechanism for a conversation between two systems that > may > be generally extended to carry "interesting" information. >=20 > This addresses Tony Li's point about "please don't make BFD difficult to > implement in hardware". >=20 > ----- >=20 > Specific comments on draft-mirmin-bfd-extended: >=20 > The somewhat peculiar extension mechanism shown in Greg's draft was > originally seeded by work I started in BFD for draft-ietf-bfd-large-packe= ts. > In fairness to history, this was similar to work that was done in OSPF ye= ars > back for how the authentication mechanism was spliced onto the protocol. > The one sentence description of that use case is "make the packet padded = to > test MTU". It's a hack, but one that does a reasonable job of its use ca= se. >=20 > However, with regard to leveraging this hack for a general purpose extens= ion > mechanism, I don't find it a good fit. BFDv1 does not expect to find > information regarding the packet or state machine outside of the main PDU= . > It is likely a new version number will need to be used to establish futur= e > semantics. (Per prior discussion in the working group.) >=20 > The capabilities mechanism will likely require either integration into so= me > form of an updated state machine for the new version header, or a differe= nt > form. IMO, I find it likely that a "capability advertisement" mechanism > would be necessary rather than negotiation to avoid a wholesale replaceme= nt > of the BFD state machinery. And if we replace that much of the machinery= , > let's just stop calling this BFD at all and move on. >=20 > With regard to IPPM style content for the draft, I refer you to the IPPM > members comments above from IETF-105. >=20 > With regard to authentication, there are two possibilities here: > - Faster authentication of BFD style packets is covered by work completin= g > BFD WGLC draft-ietf-bfd-optimitizing-authentication. I'd encourage oth= er > working groups in need of a faster per-packet authentication mechanism = to > consider whether it's an appropriate fit. > - In the case that such a future BFD, or mechanism built on similar > machinery, want a way to autenticate the payload different from the > headers, there will likely need to be discussion about not only what > envelope is used, but also strength vs. periodicity. (And if you don't= need > this stuff periodically, why use something like BFD?) >=20 > -- Jeff From nobody Thu Nov 21 23:59:54 2019 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 EBB5C120033; Thu, 21 Nov 2019 23:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 16LrA1Ctg5Wj; Thu, 21 Nov 2019 23:59:50 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 6EE4112000F; Thu, 21 Nov 2019 23:59:50 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id r18so2951499pgu.13; Thu, 21 Nov 2019 23:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YiXkpnrW9QU+VIQCDhDDv3rCzjlmUbpPswGNv/n7fVs=; b=MzJCXlHUAi34ABN1OEeP+iOfIYOhppE1EAnheSM6S5lojdiGvOyBuC3+y+ru+twzNO 4t4ExR7M2jmrc0EXveStgpi+Xc1tVkhuIYhgl1IrDvtIzURHjmehIXMhEpQzoHVUx37y qOPMe4tci0T4cupcU5wCJHz01EcH0vqDhSx+19pWLfUy3EE/X2WVdBWqeoDBTagoX9ty xl8/2KwvUasSXIofytJv8EahVUBooMk2E2p2Nq1VZQquSjp98DPz73ty8ZYOcQOpKm2R YppSkgHn5BBfRnxcklN8aHwjKuhymazVBghDT4NXXJcr/36QWFqhEZWLESBDGA5zgmTy 3x1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YiXkpnrW9QU+VIQCDhDDv3rCzjlmUbpPswGNv/n7fVs=; b=GcJsXhWENA8hQTsaNbvE4IQVzcT6F8Uw4aMlUr+XIG94N/pdzpz9okJ/jL/SilF78E cU1HgOCphh7Hl7BIOQoF5RBQc8IiUI5IQHnkCLlvCKOSJ7VGWShoe9+gXwLRxXKGVUPD v8wua1qlhs+eOQNjTGtx0lZ6zcHagNkEaDKIaSyqpCqlp1+5blHMneL47ycXu4fum17z v/D2/+PePTIbOsNczPzZqk2JYCys9m1HmDzf2dTYSEaLnUXulPxpII2FAjroHTnesbVK X/t5oIkEDqZY1JWAfTi6XyMTvmQsYh5+vFgoUhLdlUOA9Bz9tiq0v6glRTGRLvqxZS2d vDUA== X-Gm-Message-State: APjAAAU6MbjFz1XTGVbAHJPVewYMbgjiMZ32dzlDee6mxFiLf8evqNig JgcbNmaVwPSeNuEV15J59zgLtbCK X-Google-Smtp-Source: APXvYqwtK11XjUdmiEjeFlFxfYIFVyOKOGPQZqxxRcGi6ODgQNExkqc6+j4dVyarzpRKecj/lcp5MA== X-Received: by 2002:a63:a741:: with SMTP id w1mr14058044pgo.26.1574409589870; Thu, 21 Nov 2019 23:59:49 -0800 (PST) Received: from [31.133.147.52] (dhcp-9334.meeting.ietf.org. [31.133.147.52]) by smtp.gmail.com with ESMTPSA id w8sm6102704pfi.60.2019.11.21.23.59.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Nov 2019 23:59:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jeff Tantsura Mime-Version: 1.0 (1.0) Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended Date: Fri, 22 Nov 2019 15:59:47 +0800 Message-Id: <595B700A-EECA-4314-9F13-00B441143EEC@gmail.com> References: Cc: Jeffrey Haas , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" In-Reply-To: To: "Les Ginsberg (ginsberg)" X-Mailer: iPhone Mail (17A878) Archived-At: 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: Fri, 22 Nov 2019 07:59:52 -0000 Jeff/Les, Point taken, thanks! Regards, Jeff > On Nov 22, 2019, at 15:44, Les Ginsberg (ginsberg) wr= ote: >=20 > =EF=BB=BFFor the record, I agree with Jeff's summary and comments. >=20 > I was really surprised that Greg did not wait until IETF 107 - which the B= FD chairs had already indicated would be the time to resume discussions of t= his work. > However well intentioned, both the timing and the WG were inappropriate fo= r this presentation. >=20 > Les >=20 >=20 >> -----Original Message----- >> From: Rtg-bfd On Behalf Of Jeffrey Haas >> Sent: Thursday, November 21, 2019 6:53 PM >> To: rtgwg@ietf.org >> Cc: rtg-bfd@ietf.org >> Subject: BFD chair response to presentation on draft-mirmin-bfd-extended >>=20 >> In the interest of permitting the presentations to move smoothly at this >> Friday's rtgwg session, I withheld my comments from microphone. However,= >> please consider these comments for the record for IETF-106. >>=20 >> Firstly, I'm surprised the chairs had a BFD presentation at rtgwg. rtgwg= is >> indeed intended to be a general purpose dispatch group for work without a= >> home, but that's not the case for BFD. >>=20 >> Secondly, Reshad and I intentionally did not schedule work on BFD extensi= on >> work, including Greg's presentation, for this IETF. This is because ther= e >> is open charter discussions we're starting with the IESG on this space. >>=20 >> ----- >>=20 >> Specific comments on BFD extension work and the charter discussions: >>=20 >> During prior IETFs, and culminating at IETF-105, we've seen regular work t= o >> try to stuff BFD with additional features of various forms. The litmus t= est >> generally used for BFD's core use case over the years has been "what do y= ou >> want to hear every 3.3ms?" To that end, things that enhance BFD's core >> continuity verification uses cases have ended up in the protocol. >>=20 >> Somewhat similar to other popular protocols such as DNS and BGP, BFD has >> nice properties that make it an appealing place to try to extend. In >> particular, it's a continuing conversation between two systems. >>=20 >> During IETF-105, the IPPM group members attending explicitly noted that t= hey >> did not want to see their mechanisms present in BFD and did not consider i= t >> a good fit. >>=20 >> As part of that discussion, the chairs noted that one option potentially >> open is that we permit the "BFDv2" option we have discussed at IETF-105 a= nd >> previous to permit an option where we do not use the core BFDv1 session u= sed >> for continuity for these extensions, and use a different protocol version= >> and port set to enable the other use cases. >>=20 >> Thus, the discussion with the IESG is whether BFD hands over the "gift" o= f a >> general and mature mechanism for a conversation between two systems that >> may >> be generally extended to carry "interesting" information. >>=20 >> This addresses Tony Li's point about "please don't make BFD difficult to >> implement in hardware". >>=20 >> ----- >>=20 >> Specific comments on draft-mirmin-bfd-extended: >>=20 >> The somewhat peculiar extension mechanism shown in Greg's draft was >> originally seeded by work I started in BFD for draft-ietf-bfd-large-packe= ts. >> In fairness to history, this was similar to work that was done in OSPF ye= ars >> back for how the authentication mechanism was spliced onto the protocol. >> The one sentence description of that use case is "make the packet padded t= o >> test MTU". It's a hack, but one that does a reasonable job of its use ca= se. >>=20 >> However, with regard to leveraging this hack for a general purpose extens= ion >> mechanism, I don't find it a good fit. BFDv1 does not expect to find >> information regarding the packet or state machine outside of the main PDU= .. >> It is likely a new version number will need to be used to establish futur= e >> semantics. (Per prior discussion in the working group.) >>=20 >> The capabilities mechanism will likely require either integration into so= me >> form of an updated state machine for the new version header, or a differe= nt >> form. IMO, I find it likely that a "capability advertisement" mechanism >> would be necessary rather than negotiation to avoid a wholesale replaceme= nt >> of the BFD state machinery. And if we replace that much of the machinery= , >> let's just stop calling this BFD at all and move on. >>=20 >> With regard to IPPM style content for the draft, I refer you to the IPPM >> members comments above from IETF-105. >>=20 >> With regard to authentication, there are two possibilities here: >> - Faster authentication of BFD style packets is covered by work completin= g >> BFD WGLC draft-ietf-bfd-optimitizing-authentication. I'd encourage othe= r >> working groups in need of a faster per-packet authentication mechanism t= o >> consider whether it's an appropriate fit. >> - In the case that such a future BFD, or mechanism built on similar >> machinery, want a way to autenticate the payload different from the >> headers, there will likely need to be discussion about not only what >> envelope is used, but also strength vs. periodicity. (And if you don't n= eed >> this stuff periodically, why use something like BFD?) >>=20 >> -- Jeff >=20 From nobody Fri Nov 22 13:35:28 2019 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 A3F8B120125; Fri, 22 Nov 2019 13:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=jxT/agB2; dkim=pass (1024-bit key) header.d=juniper.net header.b=WOCzPhWA 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 Xg_X7KppyS_N; Fri, 22 Nov 2019 13:35:17 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBB21200B4; Fri, 22 Nov 2019 13:35:17 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAMLX2xI011913; Fri, 22 Nov 2019 13:35:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=x2nF82bk2Maqf9Wr2HMPIebrftl+eR2bKQN6H1w1A6w=; b=jxT/agB2LGwKtTRGwaezMkg99xHrWpuUDukXj0z3rlEc+0GCFRFoh75DVdNJqYoxPQbc SaYASgAPnc6X5xsK/3TRa3yvczG8JKIFJW/bv0ii4glLLLhC4UFk/PVXHO0/PXwOTMci 4Hx0NjfJJnj1tX9Yr+xuDzQzXxcHHX3E96bdB3JWJ+Ofj9rZgMgzQsl9HG8SjO/BQgfs D1kEqZUAVyzkJGJHCTfZy2p23AoHbS1oxUUzz8ttEMVAEJkU5dt4osRZsWSmKKVm9scD M9VhrQJFtMoGlbO5wBDpbXCmjNs9uJHmPl3wBa90Ef4NA18zB7IdIlIFkUk4aqNNyR+c 1w== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2050.outbound.protection.outlook.com [104.47.40.50]) by mx0a-00273201.pphosted.com with ESMTP id 2wda99cqgf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 13:35:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A1xTtN2buWmm3kfn3DBeQGd91IOJvTBquZ75oxqA/Oe036g+5lWm/9kCM0WS5kZw86FQR2ca4peypqZsWEaGRf/czmLcpeXadGMdRVu5Zh2Ayxn18a7XmNBQxkJ+pTy5c65FJqeWgRKGTv971LKj7JY3wrG5qKKgoFNHdcVuPHENPl6Xo4lOcjXin0Vnt5aVXSSoUPq2f/DgnsUmW/eUqq1USVuxrx0NNB3s3iE1OMv+t8Bbf8EcDdkTx54oEFOSyH5TlVijURhZSjMBXL3EvCiupgUyGbFzwPlGfHATvLD06iliVGxpG3oS0pKKKTX3KVGpn5PLAFZdbrgQIP9sdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x2nF82bk2Maqf9Wr2HMPIebrftl+eR2bKQN6H1w1A6w=; b=JCEfNs+5m/MBVz/XE/C61XNzkCJnog3oI337/s4YCcgT/H9F361t2AF5m4GN4hh6cWcPPLPDYfffWYi46AOdkKyLveA/q/76+PfYF0456PsjQoCxcjV3524YGGi5u/nLeOcrqHpYtxCD7bmh094+dBA7jQYbXdqW5ZXXFIjtGfNsu8EQZtjwgmZMIQBxixbV7mUpdh/ABc2j6U0QODk/p7UY5jkf1y+FyaN1xSecD7hePpgxeGGYg9t7oba39qHwkOxHrchjacM+XYv1UIqZ4Pgl8vqiBj9UI2CFA0iB6/B3sG7Dh+inc+qZu8sEy8FRd6DPe7QktTbA5efwTiy1OQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x2nF82bk2Maqf9Wr2HMPIebrftl+eR2bKQN6H1w1A6w=; b=WOCzPhWAzf9ri9Q/55GfSi1f/szfjNidS4JzTj2YKmDpobmVEKTtZxxRYOEtiK7TifFb/STIvZkwsOHS5IrBsPEpuYtk+qxsPlUlRu+HU8Z0grr7DYLxnpH6Apt2281PK7GhYJaUXoZGP6c0WBbsH2f7DpJifSQN15my2PMdYoI= Received: from BYAPR05MB6069.namprd05.prod.outlook.com (20.178.196.149) by BYAPR05MB6008.namprd05.prod.outlook.com (20.178.55.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.16; Fri, 22 Nov 2019 21:35:13 +0000 Received: from BYAPR05MB6069.namprd05.prod.outlook.com ([fe80::c86c:ed2b:231e:795b]) by BYAPR05MB6069.namprd05.prod.outlook.com ([fe80::c86c:ed2b:231e:795b%2]) with mapi id 15.20.2474.021; Fri, 22 Nov 2019 21:35:13 +0000 From: Dave Katz To: "Les Ginsberg (ginsberg)" CC: Jeffrey Haas , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Topic: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Index: AQHVoN9nFqbwB2FutE22inBbkJmFM6eWz6SAgADoDgA= Date: Fri, 22 Nov 2019 21:35:12 +0000 Message-ID: <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> References: <20191122025255.GW21134@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.11) x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0242e67d-f861-4dd5-0f0e-08d76f93db9f x-ms-traffictypediagnostic: BYAPR05MB6008: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 02296943FF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(376002)(366004)(346002)(13464003)(199004)(189003)(6116002)(81156014)(6916009)(478600001)(3846002)(66946007)(8936002)(81166006)(66556008)(33656002)(66476007)(11346002)(446003)(2906002)(66446008)(256004)(14444005)(76116006)(64756008)(229853002)(6506007)(6246003)(305945005)(6486002)(6436002)(71190400001)(6512007)(50226002)(8676002)(25786009)(2616005)(71200400001)(316002)(53546011)(99286004)(4326008)(102836004)(186003)(54906003)(36756003)(26005)(5660300002)(66066001)(76176011)(14454004)(86362001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB6008; H:BYAPR05MB6069.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RjPX4J/98ARSjMafFcUfUT8doatMd85WT4U/ZkuXc9z42+O81GQUclDCIKbCOmPCBNnt6kN9T6Y5G3/COEQiZEP1npB9xQouZLk3zb2V/W1SxpTYsNwtbp9lUD4gqtM/jNPDFsZ1QLjpsbweD4thlCZqkp2H3DHjZ9a7HnjpGWhFR5sylATKoE0LprzDSbwFE/+z5FUP08SnByw/5AuIIP82P4P2ZTw62X3x/f/1PUjA5V/9LUjSLMfVWzBPtj9gXkswiugdwUwD5NTH/udoANnF7fkQYvuARmVIroovVeGIdcbUoqUQvE+B0zyKW5Z4LuOlV9XpfSrp4z0tmdX+w9uVQplnqSp/DLh3WFa1Yc3+yNl6OklgXjtgEyxGCnGvlEf2NWJO0qwcqQlZjT7ATnBnoOPGSbWFVgwFtd5v/+jbz3HUL8jlSdodgLp6o7Mx x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 0242e67d-f861-4dd5-0f0e-08d76f93db9f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2019 21:35:12.9705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3c4q+oR2kPNoqhtPzTbhNH5s0ukbPokEUcwIPw+TFgcyMvNF7nt+aeR0FxiDIsN4raTNUiNxSWCVoIHSknqAHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6008 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-22_05:2019-11-21,2019-11-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 malwarescore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 lowpriorityscore=0 clxscore=1011 phishscore=0 mlxscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911220173 Archived-At: 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: Fri, 22 Nov 2019 21:35:20 -0000 Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCBCRkQgd2FzIGludGVuZGVkIHRvIGJlIHNpbXBsZSBpbiBz ZW1hbnRpY3MgYW5kIGltcGxlbWVudGF0aW9uLiAgSXQgbWFrZXMgYSB0ZXJyaWJsZSB0cmFuc3Bv cnQgcHJvdG9jb2wgYmVjYXVzZSB0aGUgcGFja2V0IGxhdGVuY3kgaXMgdXR0ZXJseSB1bnByZWRp Y3RhYmxlIChvbmUgb2YgdGhlIHR3byBnb2FscyBmb3IgdGhlIHByb3RvY29sIHdhcyB0byBtYWtl IHRoZSBkZXRlY3Rpb24gdGltZSwgYW5kIHRodXMgdGhlIGludGVycGFja2V0IHRpbWUsIGNoYW5n ZWFibGUgaW4gcmVhbHRpbWUgd2l0aG91dCBhZmZlY3RpbmcgdGhlIHNlc3Npb24gc3RhdGUpLiAg V2hlbiB5b3UgdGhyb3cgaW4gRGVtYW5kIE1vZGUsIHRoZSBsYXRlbmN5IG1heSBiZSB1bmJvdW5k ZWQuDQoNClBhcnQgb2YgdGhlIGlzc3VlIGlzIHRoYXQgdGhlIElFVEYgaGFzbuKAmXQgYm90aGVy ZWQgdG8gcHV0IHRvZ2V0aGVyIGEgc2V0IG9mIGdlbmVyaWMgdHJhbnNwb3J0cyB0byBidWlsZCB0 aGluZ3MgbGlrZSB0aGlzIG9uIHRvcCBvZi4gIE9TUEYgaXMgYSBwcmV0dHkgc2ltcGxlIHJvdXRp bmcgcHJvdG9jb2wgYnVpbHQgb24gdG9wIG9mIGEgdmVyeSBjb21wbGV4IHJlbGlhYmxlIG11bHRp Y2FzdCB0cmFuc3BvcnQgd2l0aCBjZXJ0YWluIHNlbWFudGljczsgIHRoZSB3b3JsZCB3b3VsZCBi ZSBhIGJldHRlciBwbGFjZSBpZiB0aGUgdHdvIGhhZCBiZWVuIHNlcGFyYXRlZCBhdCBiaXJ0aCBh bmQgdGhlIHRyYW5zcG9ydCB3YXMgZ2VuZXJhbGl6ZWQuDQoNCkluIHRoZSBjYXNlIG9mIEJGRCwg dGhlIHRyYW5zcG9ydCBzZW1hbnRpYyBpcyB1bmljYXN0IHJlbGlhYmlsaXR5IGJ5IHBlcmlvZGlj aXR5LCB3aXRoIGxpdmVuZXNzIGRldGVjdGlvbi4gIEl0IHdvdWxkIGJlIHN0dXBpZCBzaW1wbGUg dG8gYnVpbGQgYSBwcm90b2NvbCB0aGF0IGhhZCB0aGUgc2FtZSByZXBldGl0aXZlIHNlbWFudGlj cyAgYnV0IGNvdWxkIGNhcnJ5IGFueXRoaW5nLiAgSWYgdGhlIHJlbGlhYmxlIHNlc3Npb24tZG93 biBzZW1hbnRpY3MgYXJlIGludGVyZXN0aW5nLCB0aGVzZSBjb3VsZCBiZSBpbmNsdWRlZCBhcyB3 ZWxsLiAgV2hhdOKAmXMgbm90IG5lZWRlZCBpcyBhbnkgb2YgdGhlIGhpZ2hlciBsYXllciBzdHVm ZiwgdGhlIGFkYXB0aXZlIHRpbWVycywgZGVtYW5kIG1vZGUsIGVjaG8gbW9kZSwgbXVsdGlwb2lu dCBtb2RlLCBldGMuIGV0Yy4NCg0KSeKAmXZlIGJlZW4gcXVvdGVkIGluIHRoZSBwYXN0IHRoYXQg QkdQLCB1c2VkIGFzIGEgdHJhbnNwb3J0LCBpcyDigJxUQ1Agd2l0aCBiZWFyZC7igJ0gIEl0IHdv dWxkIGhhdmUgYmVlbiB0cml2aWFsIHRvIHNwbGl0IG91dCB0aGUgbWluaW1hbCBzZW1hbnRpY3Mg dGhlIGFjdHVhbCBCR1AgcHJvdG9jb2wgYnJvdWdodCB0byB0aGUgdGFibGUuDQoNClRoZSBwcm9i bGVtIGlzIHRoYXQgdGhpcyBpcyBwcm90b2NvbCBoYWNrZXJ5LCBwbGFpbiBhbmQgc2ltcGxlLCBh bmQgaXQgcXVpY2tseSBiZWNvbWVzIGF0IGNyb3NzIHB1cnBvc2VzIHdpdGggdGhlIG5vdC1yZWFs bHktYS10cmFuc3BvcnQtcHJvdG9jb2wgY2hvc2VuIHRvIGNhcnJ5IGl0ICjigJxUaGF04oCZcyBP Sywgd2UgZG9u4oCZdCBuZWVkIHZhcmlhYmxlIHRpbWVyc+KApuKAnSkNCg0KSWYgQkZE4oCZcyB0 cmFuc3BvcnQgc2VtYW50aWNzIGFyZSB0aGF0IGludGVyZXN0aW5nLCBzb21lb25lIGNvdWxkIHRh a2UgYSB3ZWVrIGFuZCB3aGlwIHVwIGEgdHJhbnNwb3J0IHRoYXQgbG9va3MgcmF0aGVyIGxpa2Ug QkZEIGJ1dCBpcyBwcm9wZXJseSBzdWl0ZWQgZm9yIHRoZSBwdXJwb3NlLiAgVGhhdCB3b3VsZCBt YWtlIGFsbCBvZiB0aGVzZSBpc3N1ZXMgZ28gYXdheSwgYW5kIHdvdWxkIHByb3ZpZGUgYSBjb21t b24gbWVjaGFuaXNtIHRoYXQgY291bGQgYmUgdXNlZCBtb3JlIGJyb2FkbHksIGFuZCBzb21lb25l IHdvdWxkIGhhdmUgYW4gUkZDIHRvIGJlIHByb3VkIG9mLg0KDQpJIGd1ZXNzIHRoZSBpcm9ueSBv ZiBhbGwgb2YgdGhpcyBpcyB0aGF0IHdoZW4gdGhlIEJGRCBXRyB3YXMgZm9ybWVkIGl0IHdhcyBl eHBlY3RlZCB0byBiZSB0aGUgc2hvcnRlc3QtbGl2ZWQgV0cgaW4gaGlzdG9yeS4gIE5vdyBJIHN1 c3BlY3QgaXTigJlzIGdvaW5nIGZvciBhIHJlY29yZCBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLiAg Oy0pDQoNCuKAlERhdmUNCg0KPiBPbiBOb3YgMjIsIDIwMTksIGF0IDI6NDQgQU0sIExlcyBHaW5z YmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gRm9yIHRo ZSByZWNvcmQsIEkgYWdyZWUgd2l0aCBKZWZmJ3Mgc3VtbWFyeSBhbmQgY29tbWVudHMuDQo+IA0K PiBJIHdhcyByZWFsbHkgc3VycHJpc2VkIHRoYXQgR3JlZyBkaWQgbm90IHdhaXQgdW50aWwgSUVU RiAxMDcgLSB3aGljaCB0aGUgQkZEIGNoYWlycyBoYWQgYWxyZWFkeSBpbmRpY2F0ZWQgd291bGQg YmUgdGhlIHRpbWUgdG8gcmVzdW1lIGRpc2N1c3Npb25zIG9mIHRoaXMgd29yay4NCj4gSG93ZXZl ciB3ZWxsIGludGVudGlvbmVkLCBib3RoIHRoZSB0aW1pbmcgYW5kIHRoZSBXRyB3ZXJlIGluYXBw cm9wcmlhdGUgZm9yIHRoaXMgcHJlc2VudGF0aW9uLg0KPiANCj4gICBMZXMNCj4gDQo+IA0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEplZmZyZXkgSGFhcw0KPj4gU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDIxLCAyMDE5IDY6NTMgUE0NCj4+IFRvOiBydGd3Z0BpZXRmLm9yZw0KPj4g Q2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IEJGRCBjaGFpciByZXNwb25zZSB0byBw cmVzZW50YXRpb24gb24gZHJhZnQtbWlybWluLWJmZC1leHRlbmRlZA0KPj4gDQo+PiBJbiB0aGUg aW50ZXJlc3Qgb2YgcGVybWl0dGluZyB0aGUgcHJlc2VudGF0aW9ucyB0byBtb3ZlIHNtb290aGx5 IGF0IHRoaXMNCj4+IEZyaWRheSdzIHJ0Z3dnIHNlc3Npb24sIEkgd2l0aGhlbGQgbXkgY29tbWVu dHMgZnJvbSBtaWNyb3Bob25lLiAgSG93ZXZlciwNCj4+IHBsZWFzZSBjb25zaWRlciB0aGVzZSBj b21tZW50cyBmb3IgdGhlIHJlY29yZCBmb3IgSUVURi0xMDYuDQo+PiANCj4+IEZpcnN0bHksIEkn bSBzdXJwcmlzZWQgdGhlIGNoYWlycyBoYWQgYSBCRkQgcHJlc2VudGF0aW9uIGF0IHJ0Z3dnLiAg cnRnd2cgaXMNCj4+IGluZGVlZCBpbnRlbmRlZCB0byBiZSBhIGdlbmVyYWwgcHVycG9zZSBkaXNw YXRjaCBncm91cCBmb3Igd29yayB3aXRob3V0IGENCj4+IGhvbWUsIGJ1dCB0aGF0J3Mgbm90IHRo ZSBjYXNlIGZvciBCRkQuDQo+PiANCj4+IFNlY29uZGx5LCBSZXNoYWQgYW5kIEkgaW50ZW50aW9u YWxseSBkaWQgbm90IHNjaGVkdWxlIHdvcmsgb24gQkZEIGV4dGVuc2lvbg0KPj4gd29yaywgaW5j bHVkaW5nIEdyZWcncyBwcmVzZW50YXRpb24sIGZvciB0aGlzIElFVEYuICBUaGlzIGlzIGJlY2F1 c2UgdGhlcmUNCj4+IGlzIG9wZW4gY2hhcnRlciBkaXNjdXNzaW9ucyB3ZSdyZSBzdGFydGluZyB3 aXRoIHRoZSBJRVNHIG9uIHRoaXMgc3BhY2UuDQo+PiANCj4+IC0tLS0tDQo+PiANCj4+IFNwZWNp ZmljIGNvbW1lbnRzIG9uIEJGRCBleHRlbnNpb24gd29yayBhbmQgdGhlIGNoYXJ0ZXIgZGlzY3Vz c2lvbnM6DQo+PiANCj4+IER1cmluZyBwcmlvciBJRVRGcywgYW5kIGN1bG1pbmF0aW5nIGF0IElF VEYtMTA1LCB3ZSd2ZSBzZWVuIHJlZ3VsYXIgd29yayB0bw0KPj4gdHJ5IHRvIHN0dWZmIEJGRCB3 aXRoIGFkZGl0aW9uYWwgZmVhdHVyZXMgb2YgdmFyaW91cyBmb3Jtcy4gIFRoZSBsaXRtdXMgdGVz dA0KPj4gZ2VuZXJhbGx5IHVzZWQgZm9yIEJGRCdzIGNvcmUgdXNlIGNhc2Ugb3ZlciB0aGUgeWVh cnMgaGFzIGJlZW4gIndoYXQgZG8geW91DQo+PiB3YW50IHRvIGhlYXIgZXZlcnkgMy4zbXM/IiAg VG8gdGhhdCBlbmQsIHRoaW5ncyB0aGF0IGVuaGFuY2UgQkZEJ3MgY29yZQ0KPj4gY29udGludWl0 eSB2ZXJpZmljYXRpb24gdXNlcyBjYXNlcyBoYXZlIGVuZGVkIHVwIGluIHRoZSBwcm90b2NvbC4N Cj4+IA0KPj4gU29tZXdoYXQgc2ltaWxhciB0byBvdGhlciBwb3B1bGFyIHByb3RvY29scyBzdWNo IGFzIEROUyBhbmQgQkdQLCBCRkQgaGFzDQo+PiBuaWNlIHByb3BlcnRpZXMgdGhhdCBtYWtlIGl0 IGFuIGFwcGVhbGluZyBwbGFjZSB0byB0cnkgdG8gZXh0ZW5kLiAgSW4NCj4+IHBhcnRpY3VsYXIs IGl0J3MgYSBjb250aW51aW5nIGNvbnZlcnNhdGlvbiBiZXR3ZWVuIHR3byBzeXN0ZW1zLg0KPj4g DQo+PiBEdXJpbmcgSUVURi0xMDUsIHRoZSBJUFBNIGdyb3VwIG1lbWJlcnMgYXR0ZW5kaW5nIGV4 cGxpY2l0bHkgbm90ZWQgdGhhdCB0aGV5DQo+PiBkaWQgbm90IHdhbnQgdG8gc2VlIHRoZWlyIG1l Y2hhbmlzbXMgcHJlc2VudCBpbiBCRkQgYW5kIGRpZCBub3QgY29uc2lkZXIgaXQNCj4+IGEgZ29v ZCBmaXQuDQo+PiANCj4+IEFzIHBhcnQgb2YgdGhhdCBkaXNjdXNzaW9uLCB0aGUgY2hhaXJzIG5v dGVkIHRoYXQgb25lIG9wdGlvbiBwb3RlbnRpYWxseQ0KPj4gb3BlbiBpcyB0aGF0IHdlIHBlcm1p dCB0aGUgIkJGRHYyIiBvcHRpb24gd2UgaGF2ZSBkaXNjdXNzZWQgYXQgSUVURi0xMDUgYW5kDQo+ PiBwcmV2aW91cyB0byBwZXJtaXQgYW4gb3B0aW9uIHdoZXJlIHdlIGRvIG5vdCB1c2UgdGhlIGNv cmUgQkZEdjEgc2Vzc2lvbiB1c2VkDQo+PiBmb3IgY29udGludWl0eSBmb3IgdGhlc2UgZXh0ZW5z aW9ucywgYW5kIHVzZSBhIGRpZmZlcmVudCBwcm90b2NvbCB2ZXJzaW9uDQo+PiBhbmQgcG9ydCBz ZXQgdG8gZW5hYmxlIHRoZSBvdGhlciB1c2UgY2FzZXMuDQo+PiANCj4+IFRodXMsIHRoZSBkaXNj dXNzaW9uIHdpdGggdGhlIElFU0cgaXMgd2hldGhlciBCRkQgaGFuZHMgb3ZlciB0aGUgImdpZnQi IG9mIGENCj4+IGdlbmVyYWwgYW5kIG1hdHVyZSBtZWNoYW5pc20gZm9yIGEgY29udmVyc2F0aW9u IGJldHdlZW4gdHdvIHN5c3RlbXMgdGhhdA0KPj4gbWF5DQo+PiBiZSBnZW5lcmFsbHkgZXh0ZW5k ZWQgdG8gY2FycnkgImludGVyZXN0aW5nIiBpbmZvcm1hdGlvbi4NCj4+IA0KPj4gVGhpcyBhZGRy ZXNzZXMgVG9ueSBMaSdzIHBvaW50IGFib3V0ICJwbGVhc2UgZG9uJ3QgbWFrZSBCRkQgZGlmZmlj dWx0IHRvDQo+PiBpbXBsZW1lbnQgaW4gaGFyZHdhcmUiLg0KPj4gDQo+PiAtLS0tLQ0KPj4gDQo+ PiBTcGVjaWZpYyBjb21tZW50cyBvbiBkcmFmdC1taXJtaW4tYmZkLWV4dGVuZGVkOg0KPj4gDQo+ PiBUaGUgc29tZXdoYXQgcGVjdWxpYXIgZXh0ZW5zaW9uIG1lY2hhbmlzbSBzaG93biBpbiBHcmVn J3MgZHJhZnQgd2FzDQo+PiBvcmlnaW5hbGx5IHNlZWRlZCBieSB3b3JrIEkgc3RhcnRlZCBpbiBC RkQgZm9yIGRyYWZ0LWlldGYtYmZkLWxhcmdlLXBhY2tldHMuDQo+PiBJbiBmYWlybmVzcyB0byBo aXN0b3J5LCB0aGlzIHdhcyBzaW1pbGFyIHRvIHdvcmsgdGhhdCB3YXMgZG9uZSBpbiBPU1BGIHll YXJzDQo+PiBiYWNrIGZvciBob3cgdGhlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3YXMgc3Bs aWNlZCBvbnRvIHRoZSBwcm90b2NvbC4NCj4+IFRoZSBvbmUgc2VudGVuY2UgZGVzY3JpcHRpb24g b2YgdGhhdCB1c2UgY2FzZSBpcyAibWFrZSB0aGUgcGFja2V0IHBhZGRlZCB0bw0KPj4gdGVzdCBN VFUiLiAgSXQncyBhIGhhY2ssIGJ1dCBvbmUgdGhhdCBkb2VzIGEgcmVhc29uYWJsZSBqb2Igb2Yg aXRzIHVzZSBjYXNlLg0KPj4gDQo+PiBIb3dldmVyLCB3aXRoIHJlZ2FyZCB0byBsZXZlcmFnaW5n IHRoaXMgaGFjayBmb3IgYSBnZW5lcmFsIHB1cnBvc2UgZXh0ZW5zaW9uDQo+PiBtZWNoYW5pc20s IEkgZG9uJ3QgZmluZCBpdCBhIGdvb2QgZml0LiAgQkZEdjEgZG9lcyBub3QgZXhwZWN0IHRvIGZp bmQNCj4+IGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgcGFja2V0IG9yIHN0YXRlIG1hY2hpbmUg b3V0c2lkZSBvZiB0aGUgbWFpbiBQRFUuLg0KPj4gSXQgaXMgbGlrZWx5IGEgbmV3IHZlcnNpb24g bnVtYmVyIHdpbGwgbmVlZCB0byBiZSB1c2VkIHRvIGVzdGFibGlzaCBmdXR1cmUNCj4+IHNlbWFu dGljcy4gIChQZXIgcHJpb3IgZGlzY3Vzc2lvbiBpbiB0aGUgd29ya2luZyBncm91cC4pDQo+PiAN Cj4+IFRoZSBjYXBhYmlsaXRpZXMgbWVjaGFuaXNtIHdpbGwgbGlrZWx5IHJlcXVpcmUgZWl0aGVy IGludGVncmF0aW9uIGludG8gc29tZQ0KPj4gZm9ybSBvZiBhbiB1cGRhdGVkIHN0YXRlIG1hY2hp bmUgZm9yIHRoZSBuZXcgdmVyc2lvbiBoZWFkZXIsIG9yIGEgZGlmZmVyZW50DQo+PiBmb3JtLiAg SU1PLCBJIGZpbmQgaXQgbGlrZWx5IHRoYXQgYSAiY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IiBt ZWNoYW5pc20NCj4+IHdvdWxkIGJlIG5lY2Vzc2FyeSByYXRoZXIgdGhhbiBuZWdvdGlhdGlvbiB0 byBhdm9pZCBhIHdob2xlc2FsZSByZXBsYWNlbWVudA0KPj4gb2YgdGhlIEJGRCBzdGF0ZSBtYWNo aW5lcnkuICBBbmQgaWYgd2UgcmVwbGFjZSB0aGF0IG11Y2ggb2YgdGhlIG1hY2hpbmVyeSwNCj4+ IGxldCdzIGp1c3Qgc3RvcCBjYWxsaW5nIHRoaXMgQkZEIGF0IGFsbCBhbmQgbW92ZSBvbi4NCj4+ IA0KPj4gV2l0aCByZWdhcmQgdG8gSVBQTSBzdHlsZSBjb250ZW50IGZvciB0aGUgZHJhZnQsIEkg cmVmZXIgeW91IHRvIHRoZSBJUFBNDQo+PiBtZW1iZXJzIGNvbW1lbnRzIGFib3ZlIGZyb20gSUVU Ri0xMDUuDQo+PiANCj4+IFdpdGggcmVnYXJkIHRvIGF1dGhlbnRpY2F0aW9uLCB0aGVyZSBhcmUg dHdvIHBvc3NpYmlsaXRpZXMgaGVyZToNCj4+IC0gRmFzdGVyIGF1dGhlbnRpY2F0aW9uIG9mIEJG RCBzdHlsZSBwYWNrZXRzIGlzIGNvdmVyZWQgYnkgd29yayBjb21wbGV0aW5nDQo+PiAgQkZEIFdH TEMgZHJhZnQtaWV0Zi1iZmQtb3B0aW1pdGl6aW5nLWF1dGhlbnRpY2F0aW9uLiAgSSdkIGVuY291 cmFnZSBvdGhlcg0KPj4gIHdvcmtpbmcgZ3JvdXBzIGluIG5lZWQgb2YgYSBmYXN0ZXIgcGVyLXBh Y2tldCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gdG8NCj4+ICBjb25zaWRlciB3aGV0aGVyIGl0 J3MgYW4gYXBwcm9wcmlhdGUgZml0Lg0KPj4gLSBJbiB0aGUgY2FzZSB0aGF0IHN1Y2ggYSBmdXR1 cmUgQkZELCBvciBtZWNoYW5pc20gYnVpbHQgb24gc2ltaWxhcg0KPj4gIG1hY2hpbmVyeSwgd2Fu dCBhIHdheSB0byBhdXRlbnRpY2F0ZSB0aGUgcGF5bG9hZCBkaWZmZXJlbnQgZnJvbSB0aGUNCj4+ ICBoZWFkZXJzLCB0aGVyZSB3aWxsIGxpa2VseSBuZWVkIHRvIGJlIGRpc2N1c3Npb24gYWJvdXQg bm90IG9ubHkgd2hhdA0KPj4gIGVudmVsb3BlIGlzIHVzZWQsIGJ1dCBhbHNvIHN0cmVuZ3RoIHZz LiBwZXJpb2RpY2l0eS4gIChBbmQgaWYgeW91IGRvbid0IG5lZWQNCj4+ICB0aGlzIHN0dWZmIHBl cmlvZGljYWxseSwgd2h5IHVzZSBzb21ldGhpbmcgbGlrZSBCRkQ/KQ0KPj4gDQo+PiAtLSBKZWZm DQo+IA0KDQo= From nobody Fri Nov 22 14:08:02 2019 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 3443E120137 for ; Fri, 22 Nov 2019 14:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 OxsEZAJsp4i6 for ; Fri, 22 Nov 2019 14:07:59 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 8F38B12013B for ; Fri, 22 Nov 2019 14:07:59 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id y10so9590590qto.3 for ; Fri, 22 Nov 2019 14:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eNwuriUPpIuLZGdN18SgZNmsQvbQub45CMLE4si87xM=; b=Onw9dyhi7i1X1Cqed8mnOPEJHWGg02DT/WzEHJaUyE33HOEBAycrm0ZAY/HndXjWpX VeXClTgt5aWsOlhgHj7LwkJR862A28jgaJFCOZKIRFDiUFVSm/KW6D1V4jzEmgvy4tOn WWZJVqwGVtBwaWMVeCByd8nSQhOGwYg+QjyVUusAeX9+9T0tpUuy3TaQoUtgSclkEsd/ MhD5td044679qDz/i65Wbg82SWkD5Tk2ZnIn5Cm8hxdw1QKBR26MqEQdGJrFC6eSRCGT i5L3W/ckehQ+WeUCvIuv2U8EDrmxzfw5PLWqfSY6UU5lJoqPbTd6N1k6QLL+uCKHC5mO YU+w== 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=eNwuriUPpIuLZGdN18SgZNmsQvbQub45CMLE4si87xM=; b=DwEnUhnuaiY02DSokwbfUAv1KuhnKweb/Iy7jvEuuC/P3EGTOmTi2PjT2ASngNNxGG P7etusf5s65y8CTIPkFzncJfdGHj0lRl9erng5/sys9hE2jNB4Ftj7Ykt57J4my4cfSy QIRjsVbZ+Z5x3Opkc5BritOcQHEVvCJoWeeBg+i0TEANhWLG/XTGnATixHY/wKj+xrUh 7wN+YsAF/tfnA+3vBTOz8kpgiyxlxu8esUn/EDsX46QgLNqwZe6ztoHTk6kFlSE+Vpm+ /8T4yAKsxJ0tuGw5ycm7cFk7iNfT+W/jRW1k3FOcAk3ShUaq7hIATOPSvnhM9esoIjE1 RsWQ== X-Gm-Message-State: APjAAAUPggHPNLoiz5g76IslcfJsM2mammhHJNfKCseRqWTSlofauZy6 gTZ7/p3o0Zc5HYkS9L8DHH2BF4E8VcM9pUX6hl480g== X-Google-Smtp-Source: APXvYqzIVncXtEZNtxe7pFOxwICF40ngu5E5dC8Qtx7/ij665Z9mqbEYlyLapP5HDCWD1pyhIP5X6SJLH07qJJskgEs= X-Received: by 2002:ac8:1017:: with SMTP id z23mr5415233qti.94.1574460478545; Fri, 22 Nov 2019 14:07:58 -0800 (PST) MIME-Version: 1.0 References: <20191122025255.GW21134@pfrc.org> <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> In-Reply-To: <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> From: Robert Raszuk Date: Fri, 22 Nov 2019 23:07:50 +0100 Message-ID: Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended To: Dave Katz Cc: "Les Ginsberg (ginsberg)" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" Content-Type: multipart/alternative; boundary="00000000000089754c0597f6a521" Archived-At: 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: Fri, 22 Nov 2019 22:08:01 -0000 --00000000000089754c0597f6a521 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, I=E2=80=99ve been quoted in the past that BGP, used as a transport, is =E2= =80=9CTCP with > beard.=E2=80=9D It would have been trivial to split out the minimal sema= ntics the > actual BGP protocol brought to the table. > BGP just because "it is there already" now transports link state database and one SAFI of it is being called a link state protocol. Just because it is there regardless of its p2mp nature is also being used for p2p configuration push including ACLs. It seems that BFD is heading the same way - again on the very same basis - "it is there" - so let's use it. > Part of the issue is that the IETF hasn=E2=80=99t bothered to put togethe= r a set > of generic transports to build things like this on top of. Spot on ! Except IETF does not ship router's code :). Vendors do. And till we see a generic transport perhaps ZeroMQ message bus like OpenR uses being shipped across at least few vendors existing protocols will get abused more and more ... Best, R. --00000000000089754c0597f6a521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

I=E2=80=99ve been quot= ed in the past that BGP, used as a transport, is =E2=80=9CTCP with beard.= =E2=80=9D=C2=A0 It would have been trivial to split out the minimal semanti= cs the actual BGP protocol brought to the table.

<= /div>
BGP just because=C2=A0"it is there already" = now transports link state database and one SAFI of it is being called a lin= k state protocol. Just because it is there regardless of its p2mp nature is= also being used for p2p configuration push including ACLs.=C2=A0
=

It seems that BFD is heading the same way - again on th= e very same basis - "it is there" - so let's use it.=C2=A0
=C2=A0
Part of the issue is that the IETF hasn=E2=80=99t bothered to put toget= her a set of generic transports to build things like this on top of.=C2=A0<= /blockquote>

Spot on !=C2=A0

<= div>Except=C2=A0IETF does not ship router's code :). Vendors do.=C2=A0 = And till we see a generic transport perhaps ZeroMQ message bus like OpenR u= ses being shipped=C2=A0across at least few vendors existing protocols will = get abused more and more ...=C2=A0

Best,
=
R.

--00000000000089754c0597f6a521-- From nobody Fri Nov 22 19:48:57 2019 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 336F61208F7; Fri, 22 Nov 2019 19:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=vtAabo8w; dkim=pass (1024-bit key) header.d=juniper.net header.b=Hlkt5xua 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 NL1IcrM_-18B; Fri, 22 Nov 2019 19:48:55 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171A01208F4; Fri, 22 Nov 2019 19:48:55 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAN3mqa7031530; Fri, 22 Nov 2019 19:48:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=y61Rwu+p004zH7IQwoE+EB8m7K/Qr7mQyNOK2kKkJjg=; b=vtAabo8wFvGOwuBQK7VeqBVDtIJkfO/X9c8HHWEZIFDuL2sbCuJlihBtreBaIYhk5uY1 uY3W/HdDEOzcJmWQZIBQGuI413f0Aj9D7z67vVh+bwh9mOhUn1E7BPJXgIgkNykzmfnX L7SOasNqOYzCZE7rUnXVVslMZcrc2KytZANHVQYG9deUB5ECoYGISj14ryQMAXpmU+6L 04NaSvNJtvGbQYgNyPUMruewifiC3fwdOVHaSzTQ/Jk0dbIoFndABBzo5dnpBabeeP64 qVCQtlQiNOQ1TmFrFYRSJI3DXtyxlBnLP0HOdFpEOXHIMjq19jCuQgqaIzJS3RkN9vc8 Rg== Received: from nam10-bn7-obe.outbound.protection.outlook.com ([104.47.70.108]) by mx0a-00273201.pphosted.com with ESMTP id 2weufs83bt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 19:48:52 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZiVSr7AbaC6m1S+vhIC4XH8jYl9ogeau0wbJJwWMi8FVGpqE7PbLBOSwJOoq4PCZtaJjLeJBGVWcFSOj53kPdas+WpfFXNsxHCuNMDs5OB25LDF+MGZ0AxUVTfOYXNz15A5CiyWATDLBiuZa0yJ8rrCctCwSNUSjDj56OA5ZUkIxLs4Dz8zIo6cXvxOoq80UTaYOnpcW9xKcAQ7q9yJdMyEfDEz3zbcY0ngSoFEz8+Ted3Z0eRMFEw8qy0bTgeuVvlsDkPzcPZnYtN3e+eoXEcG5vqA2hp6hrL8lWwX9R55ps/5OD05gN4TeMkkRWsUYMx/cfVUzuqGBJyWpwxuL+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y61Rwu+p004zH7IQwoE+EB8m7K/Qr7mQyNOK2kKkJjg=; b=jqWp/XDrNC6ewfZmVHHoxiBqJb/XOHrSGZFcNnLfZiN0SXl34cPEPrsdKKbAa6svuH3a89v1ex+Y67+ki3hnsc1+siqWxWfRm+7meF3ZE9ObXqA5R0mzIqzHWMx9FCucCPh7vPifbwTqlLg9NsPXeOH+Y31Gg/V9MYsF2WmbyvY0QjtE0BKKoKUHcbP7gd/luQpH70siPhelpklOJ7PH361wvCRuaUeh0J280mOYFi/y6NpQhynpGpJKlcnrv9dyh7q2K1n4QnuoiZC4CC9GEgdhqbDJvCrWtHlXmvVtVqjHmGoRFOLGIq6dUPB5XRxoGmC6TLhnRqHRyp7VV66Gxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y61Rwu+p004zH7IQwoE+EB8m7K/Qr7mQyNOK2kKkJjg=; b=Hlkt5xuaQje5/uo5SE9MSZCD1y6R2J4gUCFRtWJ7OnvW49R5YoetBw6V3R6qDH3U04H7/wHSDrrsEfyMDFDeLBg+ev1NDNcxR0PwSrAEWrNJgPu+ZCZXk+WrDN62LoyGgqB6yu5k2syP3lpFXoOriCoZWgrWz1EZFB+hMU/L8E0= Received: from BYAPR05MB6069.namprd05.prod.outlook.com (20.178.196.149) by BYAPR05MB4118.namprd05.prod.outlook.com (52.135.196.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.8; Sat, 23 Nov 2019 03:48:49 +0000 Received: from BYAPR05MB6069.namprd05.prod.outlook.com ([fe80::c86c:ed2b:231e:795b]) by BYAPR05MB6069.namprd05.prod.outlook.com ([fe80::c86c:ed2b:231e:795b%2]) with mapi id 15.20.2495.013; Sat, 23 Nov 2019 03:48:49 +0000 From: Dave Katz To: Robert Raszuk CC: Dave Katz , "Les Ginsberg (ginsberg)" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Topic: BFD chair response to presentation on draft-mirmin-bfd-extended Thread-Index: AQHVoN9nFqbwB2FutE22inBbkJmFMw== Date: Sat, 23 Nov 2019 03:48:49 +0000 Message-ID: <87F9ED2C-12C9-43A5-A275-3731AD1AC601@juniper.net> References: <20191122025255.GW21134@pfrc.org> <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.11) x-originating-ip: [66.129.242.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 74aa3c6d-0053-4acb-b284-08d76fc80cfc x-ms-traffictypediagnostic: BYAPR05MB4118: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(376002)(366004)(346002)(39860400002)(189003)(199004)(256004)(2616005)(6246003)(6506007)(36756003)(86362001)(186003)(26005)(446003)(11346002)(6436002)(6486002)(33656002)(3846002)(4326008)(102836004)(71200400001)(25786009)(316002)(54906003)(76176011)(6116002)(6916009)(81156014)(53546011)(71190400001)(81166006)(8936002)(2906002)(66446008)(66946007)(66066001)(229853002)(66574012)(14454004)(7736002)(478600001)(8676002)(50226002)(6512007)(54896002)(66556008)(64756008)(76116006)(236005)(99286004)(5660300002)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4118; H:BYAPR05MB6069.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ka3EE8Q4/zp3LFPTZn/IueiFy6zn/Y73X4HhH1PA9R+H3pjDZQQk/R3sQzVnRV3ZqjSxp80/DG0EpQemQXDNZJAN1avgBgTxPg0V4IAcetaH9j/PGcSsPaO+dzc/dogXL8Ot+2ahPV5eabJlMPmCVD8GuniNeLdD1rBd2NuEK5RYtMNtu5XmBVrZFUpsNsjtuYVpKWAlXv8EDYoB+L5K0VmfKk9rbGyj9vH5Qz2hlhbK7hXZ0rvnJi3xKPA9CoYKX3iHPdwLzPRwpXqspT8Wf8sDyFYkyiHeu8klQpTmhK4uG8mQj2Dw1k2OV2tDToTBK6HOv5NnU7BjimvC9eJbDSktItwHVlmAgk4nl+wZkZJ92sfgs+7hI+SnosrHwQuwNHSRlXezgE5VfkoI8i86Ua6mE5Ls0BETdWGvyXqzLkNe7izOOussGiWHHa7cItGx x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_87F9ED2C12C943A5A2753731AD1AC601junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 74aa3c6d-0053-4acb-b284-08d76fc80cfc X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2019 03:48:49.6475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X+Xq1pyJDODFf6LpFJ6TN2r/TUkKtR89w+cDCBjkIZZaMtvQO9HJiCUGVGPq2QZnjOmTc8L3bwvsaewePy2YBA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4118 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-22_06:2019-11-21,2019-11-22 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 mlxscore=0 suspectscore=0 malwarescore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1011 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911230033 Archived-At: 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: Sat, 23 Nov 2019 03:48:56 -0000 --_000_87F9ED2C12C943A5A2753731AD1AC601junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIE5vdiAyMiwgMjAxOSwgYXQgNTowNyBQTSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJh c3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4gd3JvdGU6DQoNCkhpIERhdmUsDQoN CknigJl2ZSBiZWVuIHF1b3RlZCBpbiB0aGUgcGFzdCB0aGF0IEJHUCwgdXNlZCBhcyBhIHRyYW5z cG9ydCwgaXMg4oCcVENQIHdpdGggYmVhcmQu4oCdICBJdCB3b3VsZCBoYXZlIGJlZW4gdHJpdmlh bCB0byBzcGxpdCBvdXQgdGhlIG1pbmltYWwgc2VtYW50aWNzIHRoZSBhY3R1YWwgQkdQIHByb3Rv Y29sIGJyb3VnaHQgdG8gdGhlIHRhYmxlLg0KDQpCR1AganVzdCBiZWNhdXNlICJpdCBpcyB0aGVy ZSBhbHJlYWR5IiBub3cgdHJhbnNwb3J0cyBsaW5rIHN0YXRlIGRhdGFiYXNlIGFuZCBvbmUgU0FG SSBvZiBpdCBpcyBiZWluZyBjYWxsZWQgYSBsaW5rIHN0YXRlIHByb3RvY29sLiBKdXN0IGJlY2F1 c2UgaXQgaXMgdGhlcmUgcmVnYXJkbGVzcyBvZiBpdHMgcDJtcCBuYXR1cmUgaXMgYWxzbyBiZWlu ZyB1c2VkIGZvciBwMnAgY29uZmlndXJhdGlvbiBwdXNoIGluY2x1ZGluZyBBQ0xzLg0KDQpJdCBz ZWVtcyB0aGF0IEJGRCBpcyBoZWFkaW5nIHRoZSBzYW1lIHdheSAtIGFnYWluIG9uIHRoZSB2ZXJ5 IHNhbWUgYmFzaXMgLSAiaXQgaXMgdGhlcmUiIC0gc28gbGV0J3MgdXNlIGl0Lg0KDQpTaWdoLiAg UHJvdG9jb2wgbWFscHJhY3RpY2UsIElNSE8uICBJIGd1ZXNzIG90aGVyIHBlb3BsZSBhcmVu4oCZ dCBlbWJhcnJhc3NlZCBhcyBlYXNpbHkgYXMgSS4NCg0KDQpQYXJ0IG9mIHRoZSBpc3N1ZSBpcyB0 aGF0IHRoZSBJRVRGIGhhc27igJl0IGJvdGhlcmVkIHRvIHB1dCB0b2dldGhlciBhIHNldCBvZiBn ZW5lcmljIHRyYW5zcG9ydHMgdG8gYnVpbGQgdGhpbmdzIGxpa2UgdGhpcyBvbiB0b3Agb2YuDQoN ClNwb3Qgb24gIQ0KDQpFeGNlcHQgSUVURiBkb2VzIG5vdCBzaGlwIHJvdXRlcidzIGNvZGUgOiku IFZlbmRvcnMgZG8uICBBbmQgdGlsbCB3ZSBzZWUgYSBnZW5lcmljIHRyYW5zcG9ydCBwZXJoYXBz IFplcm9NUSBtZXNzYWdlIGJ1cyBsaWtlIE9wZW5SIHVzZXMgYmVpbmcgc2hpcHBlZCBhY3Jvc3Mg YXQgbGVhc3QgZmV3IHZlbmRvcnMgZXhpc3RpbmcgcHJvdG9jb2xzIHdpbGwgZ2V0IGFidXNlZCBt b3JlIGFuZCBtb3JlIOKApg0KDQpDaGlja2VucyBhbmQgZWdncy4gIFBlcmhhcHMgc29tZSBsaWtl LW1pbmRlZCB2ZW5kb3IgZm9sayB3b3VsZCBsaWtlIHRvIGRvIHNvbWV0aGluZyBhYm91dCBpdOKA pg0KDQrigJREYXZlDQoNCg0KQmVzdCwNClIuDQoNCg0K --_000_87F9ED2C12C943A5A2753731AD1AC601junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9u IE5vdiAyMiwgMjAxOSwgYXQgNTowNyBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJvYmVydEByYXN6dWsubmV0IiBjbGFzcz0iIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+SGkgRGF2ZSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQs MjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpJ4oCZdmUgYmVlbiBxdW90ZWQgaW4gdGhlIHBh c3QgdGhhdCBCR1AsIHVzZWQgYXMgYSB0cmFuc3BvcnQsIGlzIOKAnFRDUCB3aXRoIGJlYXJkLuKA nSZuYnNwOyBJdCB3b3VsZCBoYXZlIGJlZW4gdHJpdmlhbCB0byBzcGxpdCBvdXQgdGhlIG1pbmlt YWwgc2VtYW50aWNzIHRoZSBhY3R1YWwgQkdQIHByb3RvY29sIGJyb3VnaHQgdG8gdGhlIHRhYmxl LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CR1AganVzdCBi ZWNhdXNlJm5ic3A7JnF1b3Q7aXQgaXMgdGhlcmUgYWxyZWFkeSZxdW90OyBub3cgdHJhbnNwb3J0 cyBsaW5rIHN0YXRlIGRhdGFiYXNlIGFuZCBvbmUgU0FGSSBvZiBpdCBpcyBiZWluZyBjYWxsZWQg YSBsaW5rIHN0YXRlIHByb3RvY29sLiBKdXN0IGJlY2F1c2UgaXQgaXMgdGhlcmUgcmVnYXJkbGVz cyBvZiBpdHMgcDJtcCBuYXR1cmUgaXMgYWxzbyBiZWluZyB1c2VkIGZvciBwMnAgY29uZmlndXJh dGlvbiBwdXNoIGluY2x1ZGluZw0KIEFDTHMuJm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCBzZWVt cyB0aGF0IEJGRCBpcyBoZWFkaW5nIHRoZSBzYW1lIHdheSAtIGFnYWluIG9uIHRoZSB2ZXJ5IHNh bWUgYmFzaXMgLSAmcXVvdDtpdCBpcyB0aGVyZSZxdW90OyAtIHNvIGxldCdzIHVzZSBpdC4mbmJz cDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQpTaWdoLiAmbmJzcDtQcm90b2NvbCBtYWxwcmFjdGljZSwgSU1I Ty4gJm5ic3A7SSBndWVzcyBvdGhlciBwZW9wbGUgYXJlbuKAmXQgZW1iYXJyYXNzZWQgYXMgZWFz aWx5IGFzIEkuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQpQYXJ0IG9mIHRoZSBpc3N1ZSBp cyB0aGF0IHRoZSBJRVRGIGhhc27igJl0IGJvdGhlcmVkIHRvIHB1dCB0b2dldGhlciBhIHNldCBv ZiBnZW5lcmljIHRyYW5zcG9ydHMgdG8gYnVpbGQgdGhpbmdzIGxpa2UgdGhpcyBvbiB0b3Agb2Yu Jm5ic3A7PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TcG90IG9uICEmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkV4Y2VwdCZuYnNwO0lFVEYg ZG9lcyBub3Qgc2hpcCByb3V0ZXIncyBjb2RlIDopLiBWZW5kb3JzIGRvLiZuYnNwOyBBbmQgdGls bCB3ZSBzZWUgYSBnZW5lcmljIHRyYW5zcG9ydCBwZXJoYXBzIFplcm9NUSBtZXNzYWdlIGJ1cyBs aWtlIE9wZW5SIHVzZXMgYmVpbmcgc2hpcHBlZCZuYnNwO2Fjcm9zcyBhdCBsZWFzdCBmZXcgdmVu ZG9ycyBleGlzdGluZyBwcm90b2NvbHMgd2lsbCBnZXQgYWJ1c2VkIG1vcmUgYW5kIG1vcmUg4oCm Jm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5DaGlja2VucyBhbmQg ZWdncy4gJm5ic3A7UGVyaGFwcyBzb21lIGxpa2UtbWluZGVkIHZlbmRvciBmb2xrIHdvdWxkIGxp a2UgdG8gZG8gc29tZXRoaW5nIGFib3V0IGl04oCmPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj7igJREYXZlPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlIu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_87F9ED2C12C943A5A2753731AD1AC601junipernet_-- From nobody Sat Nov 23 02:37:45 2019 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 E7312120898 for ; Sat, 23 Nov 2019 02:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 wqaW1oJJpVXb for ; Sat, 23 Nov 2019 02:37:42 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 82C68120288 for ; Sat, 23 Nov 2019 02:37:42 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id y10so11044326qto.3 for ; Sat, 23 Nov 2019 02:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EgDivIgqG5Ehdm1dX+VVzZdMA4UF8AUdfjPUFKxzUOk=; b=UmhWtW88rer9ceNEpfLz7y4HJe+/V3TnA/u9sklPtZjWMWN3z4e8Sszd/zNj3q5fU1 O5fJ8ePsAZKvTEmz3m717hweFww3UUdVRAfA/NbAK5R0tbrleIzvkKoIBQvyx9pf2dg0 gXENAly+gYFiJVQJLIxWBD1yk8UybbjXNgWV3+TZGUyIBI28uKYUr/bMRH0Denqs/1RM vpI9EODGqIQVo5/e6mTWV8i9Rq/VEfZP6diwGpHr73m0Z/C+8D6rYurS1BNEnC9Qzu+n iSGejyTQhIRuCjz58btj+6DF5mHYFf5Ryzyirwolmv57rCT6+n/VisF0QZIOm6tEFsCH zMVQ== 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=EgDivIgqG5Ehdm1dX+VVzZdMA4UF8AUdfjPUFKxzUOk=; b=cy8dET3W+p5Fq/LWyXMRfqk59ZiILLWKfOEwKeHRl4xjlZ7besvgbj6Host16DdT0i 0IVyeMpR2tdPFIp6Ol6uCsJFlzkBCR0NmCb0UflJO1nf1lPkFlCZ6CvQP8w/lNjtTwo6 pUd5Hxaf/QmkDgNIg8C2P5E8ZvDmAxGI0BuxXGr4fv+JQmgwrE2Z1VlskMCPAIJCFmqN Zif+PWDSPWL+Fdi0lD6aAoQF5oNRzm9ATeGyZ7EuyDDkfnSRGGymkR3Fn83Pxlzi5rep YdMfhidrAnk3MyEon8c/Zw2SsWNSWgBj9pl0u1s7ocSOapAoKzYdKs+uYkzBDlPXKLUF BUMA== X-Gm-Message-State: APjAAAWL0jQHSjohX9AHHm1hxjVEA1ju3vD5q0SicppmQ1mZEjTGYrH8 CVipR/5voXUd2uL0HjpYCIYaKmk6gJDAfzVB9bhHxw== X-Google-Smtp-Source: APXvYqwjVXZtKNmhcHtSqMuwmy6mNpOJ8aX2OjaAyoL7zWmSGQ5KD4UD2m0U9Trt8SfTX6t4u4krogjMHOOXWs+qApA= X-Received: by 2002:aed:36a1:: with SMTP id f30mr4911144qtb.154.1574505461278; Sat, 23 Nov 2019 02:37:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sat, 23 Nov 2019 11:37:33 +0100 Message-ID: Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths To: Alexander Vainshtein , Shraddha Hegde Cc: "spring@ietf.org" , "rtgwg@ietf.org" , rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary="000000000000b795db0598011ece" Archived-At: 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: Sat, 23 Nov 2019 10:37:45 -0000 --000000000000b795db0598011ece Content-Type: text/plain; charset="UTF-8" Hi Sasha, On the surface your suggestion may look cool - but if you zoom in - I do not think it will work in practice. See - one of the biggest value of BFD is its offload to line card's hardware. And in most cases it is ingress line card to the box. So if you instruct such hardware to respond to SID address loopback you still did not gain much in terms of detection router's fabric failures, remote LC failure or control plane issues which could soon result in box failure. The catalogue of router failures is of course much more colorful. If you ask BFD to be responded by RP/RE it no longer has the BFD advantage. IMHO the best way to detect node failure is actually to send the probes *across* the node under test to its peers. The way I would think of establishing such m-hop sessions would be fully automated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]" where local BFD subsystem would create N sessions to IGP peers of the node we are to protect. LSDB has those peers so no new protocol extension is needed, perhaps even no new IETF draft is required :). N would be the limit of such sessions in case the node under protection has say 10s of peers. Default could be perhaps even 1. Thx, Robert. On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > Shraddha, Robert and all, > Regarding Robert's question: > I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) > prefixes serving as Nose SIDs of R8 and R7 respectively could be used as > such a trigger by R7? Such a session would not respond to link failures, > and I find it problematic to imagine a scenario when it would be kept UP in > the case of a real node failure. > > Of course such a session would have to be slow enough not to react to link > failures. But it still couks be much faster than IGP conversion IMHO. > > My 2c, > Sasha > > Such > > > Get Outlook for Android > > ------------------------------ > *From:* spring on behalf of Robert Raszuk < > robert@raszuk.net> > *Sent:* Friday, November 22, 2019, 11:22 > *To:* Shraddha Hegde > *Cc:* spring@ietf.org; rtgwg@ietf.org > *Subject:* Re: [spring] Draft for Node protection of intermediate nodes > in SR Paths > > Hi Shraddha, > > I have one question to the document. > > As you know the critical element for the effective protection of any > scheme is the failure detection. On that your draft seems to have just one > little paragraph: > > Note that R7 activates the node-protecting backup path when it > detects that the link to R8 has failed. R7 does not know that node > R8 has actually failed. However, the node-protecting backup path is > computed assuming that the failure of the link to R8 implies that R8 > has failed. > > > Well IMO this is not enough. Specifically there can be a lot of types of > node failure when link is still up. Moreover there can be even running BFD > across the link just fine when say fabric failure occurs at R8. > > While this is not solely issue with this draft, it is our common IETF > failure to provide correct means of detecting end to end path or fragments > of path failures (I am specifically not calling them segment here :). > > For example I propose that to effectively detect R8 failure as node > failure which is the topic of your proposal a mechanism is clearly defined > and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, > R4-R9, R3-R9 > > Many thx, > Robert. > > > On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde 40juniper.net@dmarc.ietf..org <40juniper.net@dmarc.ietf.org>> wrote: > >> WG, >> >> This is the draft I pointed out that talks about solutions for providing >> node-protection. >> It covers Anycast case as well as keeping forwarding plane longer. >> >> *https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05* >> >> >> Review and comments solicited. >> >> Rgds >> Shraddha >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> > > --000000000000b795db0598011ece Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sasha,

On the surfa= ce your suggestion may look cool - but if you zoom in - I do not think it w= ill work in practice.=C2=A0

See - one of the bigge= st value of BFD is its offload to line card's hardware. And in most cas= es it is ingress line card to the box. So if you instruct such hardware to = respond to SID address loopback you still did not gain much in terms of det= ection router's fabric failures, remote LC failure or control=C2=A0plan= e issues which could soon result in box failure. The catalogue of router fa= ilures is of course much more colorful.=C2=A0

If y= ou ask BFD to be responded by RP/RE it no longer has the BFD advantage.=C2= =A0

IMHO the best way to detect node failure=C2=A0= is actually to send the probes *across* the node under test to its peers.= =C2=A0

The way I would think of establishing such = m-hop sessions would be fully automated with one knob per IGP adj. ex: &quo= t;bfd detect-node-failure [max N]" where local BFD subsystem would cre= ate N sessions to IGP peers of the node we are to protect. LSDB has those p= eers so no new protocol extension=C2=A0is needed, perhaps even no new IETF = draft is required :). N would be the limit of such sessions in case the nod= e under protection has say 10s of peers. Default could be perhaps even 1.= =C2=A0

Thx,
Robert.

=

= On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein <Alexander.Vainshtein@e= citele.com> wrote:
Shraddha, Robert and all,
Regarding Robert's question:=C2=A0
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) p= refixes serving as Nose SIDs of R8 and R7 respectively could be used as suc= h a trigger by R7? Such a session would not respond to link failures, and I= find it problematic to imagine a scenario when it would be kept UP in the case of a real node failure.

Of course such a session would have to be slow enough not to react to link = failures. But it still couks be much faster than IGP conversion IMHO.

My 2c,
Sasha

Such


Get Outlook for Android=
From: spring <spring-bounces@ietf.org> on behalf of Robe= rt Raszuk <robert= @raszuk.net>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: s= pring@ietf.org; rtg= wg@ietf.org
Subject: Re: [spring] Draft for Node protection of interme= diate nodes in SR Paths

Hi=C2=A0Shraddha,

I have one question to the document.=C2=A0

As you know the critical element for=C2=A0the effective protection of = any scheme is the failure detection. On that your draft seems to have just = one little paragraph:=C2=A0

   Note that R7 activates the node-protecting b=
ackup path when it
   detects that the link to R8 has failed.  R7 does not know that node
   R8 has actually failed.  However, the node-protecting backup path is
   computed assuming that the failure of the link to R8 implies that R8
   has failed.

Well IMO this is not enough. Specifically=C2=A0there can be a lot of t= ypes of node failure when link is still up. Moreover there can be even runn= ing BFD across the link just fine when say fabric failure occurs at R8.=C2= =A0

While this is not solely issue with this draft, it is our common IETF = failure to provide correct means of detecting end to end path or fragments = of path failures (I am specifically not calling them segment here :).=C2=A0=

For example I propose that to effectively detect R8 failure as node fa= ilure which is the topic of your proposal a mechanism is clearly defined an= d includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9= , R3-R9

Many thx,
Robert.


On Fri, Nov 22, 2019 at 4:38 AM Shrad= dha Hegde <shraddha=3D40juniper.net@dmarc.ietf..org> wrote:
WG,
=C2=A0
This is the draft I pointed out that talks about solutions for providi= ng node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
=C2=A0
Review and comments solicited.
=C2=A0
Rgds
Shraddha
=C2=A0
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
--000000000000b795db0598011ece-- From nobody Sat Nov 23 03:15:40 2019 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 3BC81120817; Sat, 23 Nov 2019 03:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ecitele.com header.b=NTgElqyT; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=sIE1J0U+ 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 hdDyBx5w3Ik1; Sat, 23 Nov 2019 03:15:36 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B80120251; Sat, 23 Nov 2019 03:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1574507732; i=@ecitele.com; bh=Z8i2Lgr1SUGyF9D/xedJqB3+W4WkHfs3Rb+mKnS4Cw4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=NTgElqyTS6cU8teYhVcDG3opVUERcb587xMVy18gPpyj4hZOah6NLKrTaiCVc0G5S 6XQ+jav6NFSwO/Rq6zn4FyggnIaVD/nIX9Fx/fZvHscLArKEvPK8TamRB3Jsvoxout ROD93kGUewMMYW+V3Mew8A1X2AzbtAOVlgshdgLY= Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 22/E5-16685-3D419DD5; Sat, 23 Nov 2019 11:15:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnl+JIrShJLcpLzFFi42IRetuzUfeSyM1 Ygw3XdS2aFjYxW3z+s43R4sKb38wWE5ZNZ7U4fuE3owOrx4llV1g9liz5yeSxe+MCpgDmKNbM vKT8igTWjMfdExkL9jYyVtxaHtfAuLagi5GLg1FgKbPEsz+vWSGcYywSy3e+YoZwNjNKnDg+i R3EYRFYyyxxfN9JIIeTQ0ign0miY28YSEJI4D6jxMttWxhBEmwCthKbVt9lA7FFBOIkWi/MB2 tgFiiSeDp7AliNsECQxNq/Z6FqgiU2rLnFAmE7SRx+9o4JxGYRUJX41nKGGcTmFYiVeL57NTP Esl1MErfetgI1cHBwAg1q+SIOUsMoICbx/dQaJohd4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8V oj5J4v7ThYwQcUWJTyv2sULYshKX5nczgoyXEFCW2PIiFiLsK/HiyjOoci2JznsLocZLSSw8/ 4Udws6RaNyyjQXCVpM4O7Edaq2MxOFVs6F6j7BJrFqdDgnDZIkTcz6zTGDUn4Xk6llAm5kF8i RunEqaBfa8oMTJmU9YIEp0JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMFklFmekZJbmJmTm 6hgYGuoaGxroGumaWeolVuol6qaW6yal5JUWJQEm9xPJiveLK3OScFL281JJNjMD0llLI4LqD cfant3qHGCU5mJREeZ9tvB4rxJeUn1KZkVicEV9UmpNafIhRhoNDSYL3tPDNWCHBotT01Iq0z BxgqoVJS3DwKInw6gLTrRBvcUFibnFmOkTqFGMgx4SXcxcxc+w8Og9IHp6+AEi++7kYSH5ctQ RIfgeTm+cuXcQsxJKXn5cqJc7LBDJIAGRQRmke3BpY/rjEKCslzMvIwMAgxFOQWpSbWYIq/4p RnINRSZjXG2QKT2ZeCdw1r4AOZQI69MeiayCHliQipKQamDj+vmR5nsU2206h59qUs7ucjnTl 5XvIrFHhSLzU1COj3lim8vxww4P+Y37fzggFu4VO9NmjzvuibFe5j9/UCNXP3YycBYtDDimfX DMt1lHkGpuk7eFlXRPUjDw/hlW1vT7PflaaQ+Mr38SbvD6ablmXPdqC7nY31HUVXOjb4Hukxe /x8u7qF60p2r3HguKbVrb2ND2x+NC87cbWt1uuR6pumurToH7J6otj0J3YIzM6Y6p0b0UaB7y Ojmt0l1I/9fNgbuu0xT3HrpxVKak45aF1dwPPxs4+D61e3o0vHruGvnPqPflv67euoqZtSQF+ 183fMRvr/T4zmeNrPFPxhl2597p+8Z+dcfjNBtYPSizFGYmGWsxFxYkAK9ToapoEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-226.messagelabs.com!1574507727!610671!1 X-Originating-IP: [18.237.140.177] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.44.22; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 10965 invoked from network); 23 Nov 2019 11:15:29 -0000 Received: from p01b.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-12.tower-226.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 23 Nov 2019 11:15:29 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MwIu7zTCYnuB/rOBbqwy01ZJHrxZG0famM6m2SCUbF9O2cTX2lWpcq0B5VN/AHg/133fLzJG9FOq+pk8h2dDaRwl1kCIl1F9kevij+AfJ6EsgszDoPV6+O4nusVCtZqVGED+4rtIGqSG+l48NhKqXUHiP6Bd5OYroJsWxVz9ZS8R0M9y2kT/AxU+jRB+uPLMmk/JVnFT661WZAv1MFGMos32GNGnvN+T4b+9LyNP0VdB16Z/6UmdWODP4rDrk9n/apg22xdcT8T0FPo4P40ZspEcKoMV5IDLfRAJ0jU+Yb4WjHXqhb6MZczqO/JyYRHXGpiBYci7Z9UO3D75/scrfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C1WOTXXomoleD4s4NVzkndLoAF3WfKZa8c0LcyjRLn8=; b=mQN5/CBbkqRMRbmrBDoJ+3VnF9KMYl+F8vsKYRX+Ax4RCWFgC2zOIZSRPt7zEhQ8nwxzG8LlBpTmF1KPnIvILpChQu+B+IWDSBoKsX/t5nqVZEqEQjH2KHNbLMB5/2Dfhy/MOU+nLmXPR4qZjsOKHi6y0mVRT34cSfB7dxTtwxeTqsI5JZMBsq8TMJoJM2A1hkMsGjevV352NoMARxL3cOhlvqbezyp8OjRHzW/RRFO8MjWvQrXWH65ypaa8NVqmgextARsCdv9++COhejG89f+OFEcP5g7rr/Y21MGqzgKgjxdZeBEKb/6T32DinO3A4ceErk4biwpnyfgkGsv+Gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C1WOTXXomoleD4s4NVzkndLoAF3WfKZa8c0LcyjRLn8=; b=sIE1J0U+sy9mgvp7eOs+OkiQWiK3w8WarB6zI1LVWH8jVY6yCpJ4fZV3G1lhsTNlqUnKCbmh5s2e/O391PCmhJAhUP5F0n0o+UDxUJfKPaVOpDjI2nLNShpwihk7hrIthUks/buNjf6OJgQiI+gyDFP4IIOCbF7ly2bUcdnX6UQ= Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB4752.eurprd03.prod.outlook.com (20.177.49.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.21; Sat, 23 Nov 2019 11:15:24 +0000 Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::7121:a122:386d:fcd4]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::7121:a122:386d:fcd4%5]) with mapi id 15.20.2474.022; Sat, 23 Nov 2019 11:15:24 +0000 From: Alexander Vainshtein To: Robert Raszuk , Shraddha Hegde CC: "spring@ietf.org" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Topic: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Index: AQHVoRZrVSAXH6RCc0yN7BSQBwB5daeYdILlgAAdWICAAAdUGQ== Date: Sat, 23 Nov 2019 11:15:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.176.80.188] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c48172e9-d6de-4e36-8420-08d770066faa x-ms-traffictypediagnostic: VI1PR03MB4752: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(39850400004)(366004)(396003)(199004)(189003)(54094003)(14454004)(2906002)(517774005)(86362001)(6436002)(45080400002)(440504004)(25786009)(6246003)(74316002)(66556008)(6116002)(64756008)(66946007)(966005)(478600001)(91956017)(76116006)(7736002)(11346002)(4326008)(52536014)(446003)(66446008)(3846002)(186003)(66476007)(81156014)(81166006)(606006)(229853002)(8676002)(8936002)(7696005)(76176011)(33656002)(99286004)(26005)(256004)(14444005)(66066001)(102836004)(316002)(54906003)(55016002)(54896002)(6306002)(110136005)(236005)(71200400001)(561944003)(9686003)(71190400001)(53546011)(66574012)(6506007)(5660300002)(5070765005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB4752; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR03MB383986D0D2E66226BFDEDF839D480VI1PR03MB3839eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: c48172e9-d6de-4e36-8420-08d770066faa X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2019 11:15:23.9396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: T+HVLd8+phdctjt1JrptiStybEQwLluEWt9y9JTRb3Qmzlcm354uPUAeFoiNAYleDsJWSplAbp3JGL1zYOiKOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4752 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: 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: Sat, 23 Nov 2019 11:15:38 -0000 --_000_VI1PR03MB383986D0D2E66226BFDEDF839D480VI1PR03MB3839eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, Lots of thanks for a prompt response. I respectfully disagree with your statement that BFD implementation is us= ually offloaded to the HW of the ingress line card. I do not think this c= an wor for MH BFD sessions because the ingress and egress line cards are n= ot known in advance and change with the routing changes A good multi-hop BFD implementation should be ready to overcome this. The= re are many ways to achieve that. A naive implementation that runs in SW o= f the control card is also possible of course. And they would sensd and re= ceive packets My 2c. Get Outlook for Android ________________________________ From: Robert Raszuk Sent: Saturday, November 23, 2019, 12:37 To: Alexander Vainshtein; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Sasha, On the surface your suggestion may look cool - but if you zoom in - I do n= ot think it will work in practice. See - one of the biggest value of BFD is its offload to line card's hardwa= re. And in most cases it is ingress line card to the box. So if you instru= ct such hardware to respond to SID address loopback you still did not gain= much in terms of detection router's fabric failures, remote LC failure or= control plane issues which could soon result in box failure. The catalogu= e of router failures is of course much more colorful. If you ask BFD to be responded by RP/RE it no longer has the BFD advantage= . IMHO the best way to detect node failure is actually to send the probes *a= cross* the node under test to its peers. The way I would think of establishing such m-hop sessions would be fully a= utomated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]" = where local BFD subsystem would create N sessions to IGP peers of the node= we are to protect. LSDB has those peers so no new protocol extension is n= eeded, perhaps even no new IETF draft is required :). N would be the limit= of such sessions in case the node under protection has say 10s of peers. = Default could be perhaps even 1. Thx, Robert. On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein > wrote: Shraddha, Robert and all, Regarding Robert's question: I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could be used as s= uch a trigger by R7? Such a session would not respond to link failures, an= d I find it problematic to imagine a scenario when it would be kept UP in = the case of a real node failure. Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO. My 2c, Sasha Such Get Outlook for Android ________________________________ From: spring > on = behalf of Robert Raszuk > Sent: Friday, November 22, 2019, 11:22 To: Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Shraddha, I have one question to the document. As you know the critical element for the effective protection of any schem= e is the failure detection. On that your draft seems to have just one litt= le paragraph: Note that R7 activates the node-protecting backup path when it detects that the link to R8 has failed. R7 does not know that node R8 has actually failed. However, the node-protecting backup path is computed assuming that the failure of the link to R8 implies that R8 has failed. Well IMO this is not enough. Specifically there can be a lot of types of n= ode failure when link is still up. Moreover there can be even running BFD = across the link just fine when say fabric failure occurs at R8. While this is not solely issue with this draft, it is our common IETF fail= ure to provide correct means of detecting end to end path or fragments of = path failures (I am specifically not calling them segment here :). For example I propose that to effectively detect R8 failure as node failur= e which is the topic of your proposal a mechanism is clearly defined and i= ncludes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, = R3-R9 Many thx, Robert. On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde > wrote: WG, This is the draft I pointed out that talks about solutions for providing n= ode-protection. It covers Anycast case as well as keeping forwarding plane longer. https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-p= aths-05 Review and comments solicited. Rgds Shraddha _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_VI1PR03MB383986D0D2E66226BFDEDF839D480VI1PR03MB3839eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,
Lots of thanks for a prompt response.

I respectfully disagree with your statement that BFD implementation  = is usually offloaded to the HW of the ingress line card.  I do not th= ink this can wor for MH BFD sessions because the ingress and egress line c= ards are not known in advance and change with the routing changes
A good  multi-hop BFD implementation should be ready to overcome this= . There are many ways to achieve that. A naive implementation that runs in= SW of the control card is also possible of course. And they would sensd a= nd receive packets 

My 2c.

From: Robert Raszuk <robert@= raszuk.net>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Sasha,

On the surface your suggestion may look cool - but if you zoom in - I= do not think it will work in practice. 

See - one of the biggest value of BFD is its offload to line card's h= ardware. And in most cases it is ingress line card to the box. So if you i= nstruct such hardware to respond to SID address loopback you still did not= gain much in terms of detection router's fabric failures, remote LC failure or control plane issues which cou= ld soon result in box failure. The catalogue of router failures is of cour= se much more colorful. 

If you ask BFD to be responded by RP/RE it no longer has the BFD adva= ntage. 

IMHO the best way to detect node failure is actually to send the= probes *across* the node under test to its peers. 

The way I would think of establishing such m-hop sessions would be fu= lly automated with one knob per IGP adj. ex: "bfd detect-node-failure= [max N]" where local BFD subsystem would create N sessions to IGP pe= ers of the node we are to protect. LSDB has those peers so no new protocol extension is needed, perhaps even no new IE= TF draft is required :). N would be the limit of such sessions in case the= node under protection has say 10s of peers. Default could be perhaps even= 1. 

Thx,
Robert.


On Sat, Nov 23, 2019 at 10:00 AM Ale= xander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Shraddha, Robert and all,
Regarding Robert's question: 
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could be used as s= uch a trigger by R7? Such a session would not respond to link failures, an= d I find it problematic to imagine a scenario when it would be kept UP in the case of a real node failure.

Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO.

My 2c,
Sasha

Such


Get Outlook for Android

From: spring <spring-bounces@ietf.org> on behalf of R= obert Raszuk <ro= bert@raszuk.net>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: = spring@ietf.org; rtgwg@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Shraddha,

I have one question to the document. 

As you know the critical element for the effective protection of= any scheme is the failure detection. On that your draft seems to have jus= t one little paragraph: 

   Note that R7 activates the nod=
e-protecting backup path when it
   detects that the link to R8 has failed.  R7 does not know that node
   R8 has actually failed.  However, the node-protecting backup path is
   computed assuming that the failure of the link to R8 implies that R8
   has failed.

Well IMO this is not enough. Specifically there can be a lot of = types of node failure when link is still up. Moreover there can be even ru= nning BFD across the link just fine when say fabric failure occurs at R8.&= nbsp;

While this is not solely issue with this draft, it is our common IETF= failure to provide correct means of detecting end to end path or fragment= s of path failures (I am specifically not calling them segment here :).&nb= sp;

For example I propose that to effectively detect R8 failure as node f= ailure which is the topic of your proposal a mechanism is clearly defined = and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4= -R9, R3-R9

Many thx,
Robert.


On Fri, Nov 22, 2019 at 4:38 AM Shra= ddha Hegde <shraddha=3D40juniper.net@dmarc.ietf..org> wrote:
WG,
 
This is the draft I pointed out that talks about solutions for provid= ing node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
 
Review and comments solicited.
 
Rgds
Shraddha
 
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
= https://www.ietf.org/mailman/listinfo/rtgwg


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_VI1PR03MB383986D0D2E66226BFDEDF839D480VI1PR03MB3839eurp_-- From nobody Sat Nov 23 06:45:05 2019 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 5DD15120043; Sat, 23 Nov 2019 06:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=BlPRTJH+; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=TzD315// 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 blgYAFwpnxpA; Sat, 23 Nov 2019 06:45:02 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB756120088; Sat, 23 Nov 2019 06:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1574520300; i=@ecitele.com; bh=Zf4K06WG7ym6UHYR/xOPHjveUGs85fYnBOHLRcWGCz4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=BlPRTJH+36fbCePI4ck0TgYec47l6p4oJuYsTUBfNhcT85XqzFewYbBerDBZtHAvJ j0smqJEfqMuqjfaTBHsGw/nhquY53tReSmDC36Xg9AtYACe31YqAc1sbT7DdrsSEN7 Rm0g+0ouA/+T88RPccZjYmywPO7DcvSftWVLSgm0= Received: from [85.158.142.203] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.eu-central-1.aws.symcld.net id 8F/2F-12313-AE549DD5; Sat, 23 Nov 2019 14:44:58 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupml+JIrShJLcpLzFFi42IRetuzUfeV681 YgxeTRCyaFjYxW3z+s43R4sKb38wWE5ZNZ7U4fuE3owOrx4llV1g9liz5yeSxe+MCpgDmKNbM vKT8igTWjL4zwgV7FzJWdF3YwdTAOKWHsYuRi4NRYCmzxMl9H9kgnGMsEv97/0A5mxklThyfx A7isAisZZbY/WkmM4gjJDCBSeLFrwmMEM59RokDj/qAMpwcbAK2EptW32UDsUUE4iRaL8xnB7 GZBYokns4GaeDkEBYIklj79yxUTbDEhjW3WCBsN4kpX9aBzWERUJVY03EbrJ5XIFbixfxV7BD LupkltvVsBBvKCbTgyiWIZYwCYhLfT61hglgmLnHryXwwW0JAQGLJnvPMELaoxMvH/1gh6pMk 7j9dyAgRV5T4tGIfK4QtK3FpfjdQnAPIVpbY8iIWIuwrcXrCbqiwlsTCOc4QYSmJhee/sEPYO RKt5zezQdhqEmcntkNtlZE4vGo2OKwkBI6wSax50w12mpBAssSJOZ9ZJjDqz0JyNYSdJ/H+cw /jLLD3BSVOznzCAhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxWiQVZaZnlOQmZuboGho Y6BoaGuua61qa6CVW6SbppZbqJqfmlRQlAiX1EsuL9Yorc5NzUvTyUks2MQLTXEohe9wOxt5P b/UOMUpyMCmJ8j7beD1WiC8pP6UyI7E4I76oNCe1+BCjDAeHkgSvusvNWCHBotT01Iq0zBxgy oVJS3DwKInwhoGkeYsLEnOLM9MhUqcYAzkmvJy7iJlj59F5QPLw9AVA8t3PxUDy46olQPI7mN w8d+kiZiGWvPy8VClx3j0ggwRABmWU5sGtgeWRS4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJW EeZtBpvBk5pXAXfMK6FAmoEN/LLoGcmhJIkJKqoHJ1zmd5/kBNo6owwu61Rf+NlsSJCret+el 1KHTyab/Nym80xec0fi9cbLZ+yMr5l1fvH3pfaMkz50H2DapchTstt1y/r3bh49BMvvvd1+/G Rc578I6CcVpZlfsOWRvv4o5+Hy+cZ3vaaFfxvGys1rPHH3R4ODov+zykseyQtM7p/cJHDi6ZG NwAz+rfbTSres7w0O/tCU0HOT4/dPDZmKe1U05Bh7r0BOR90+d6fy7X01tkfJu21vbp999Ihj dbR8zyceSrbyHz7fKNsTYfWv6qmznTfIK94NVPOzWR3P4fnFobQyamHJejMv3izJP7cv389ft e2RUYcjEzbz4TWnvS5eXS8332352u8eZethNiaU4I9FQi7moOBEAJmgQcp4EAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-248.messagelabs.com!1574520295!63011!1 X-Originating-IP: [18.237.140.177] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.44.22; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 28307 invoked from network); 23 Nov 2019 14:44:57 -0000 Received: from p01b.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-7.tower-248.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 23 Nov 2019 14:44:57 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XtQJSldIYP3UlgfEmzg1dMBU801yxqaJ0pmF4v+GrGjxKIc2cV8zfkmBXHpG9Qo3iuutz8F7DxrynkvNdluiitbmhJ98AAu/PBAqTfpy2tNTmWtArpCA0BAHjkDV4v8619dgG3nVbmYNlYsFIWgLPmiG0+BKTgwLCdX/Hx/PkOykR7q5008Sv/l/4Mu0L0RlJhvQfsti8YMUGaq/tKsuAK9O0qGy/OYYBhf/kW2zbykEyLFcrSJX5VksQ507kFVYA1IJ68GmgolhK2YcwUKvRsIAH7B/MJq1h8kKFQYTFQvm/10HxGWjgGE+Z0AjEqmir2hduIUJCtQHAWhTprUPJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gAY2D50xZCg7Xm0uskmTumDenF4/M+x3Vq6tVFmy19c=; b=kaGjvmIsqQUMGhlGyJFbz2Nm8rr/8BJbnWLFzFForp9cD8IIulA0R8LN6gfqGnGWC1hXA0Q8SNYgDg1jeNxKU/Z5A/fw938vsYjJHSC/lEZEFYBgNijMeYxIX5YllGX4xo0g6GdJLErV0Wz81WR+eFzss/erM+1ZlXfzzxh8aZeiV7wvCNyHu4I7yQxHw9pmR5cU1hZWaR3rRGIwicI8o+d+IrWw9z4Y5ITbWcv5Ap5LD9qF6r2cfdLI0Y9Na4najUXnn5L9d/LWFVZyuBDsIbfczHniFVopDt4WW/+Lz14sWLiLAhT0aB+Lz1EPaLpFnYa9OTe+WC4ZZeT9zsh60w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gAY2D50xZCg7Xm0uskmTumDenF4/M+x3Vq6tVFmy19c=; b=TzD315//QFVtqXytRs+19PheFOXyJdPSJp+JxWQlT9MBQKSzX6Gtz70ON1XYeARaBBH5NPurfHH1rn8GUgevJNikpdLEXzGnPNgwxMtlkrKu8u4j7WiPymHNprZYXM94ZXSd8miRoLi1RENFApAEn1FuOSHl9o5JoGmyo9R+iMo= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4737.eurprd03.prod.outlook.com (20.177.41.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Sat, 23 Nov 2019 14:44:53 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7554:6540:b0c0:800f]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7554:6540:b0c0:800f%7]) with mapi id 15.20.2474.022; Sat, 23 Nov 2019 14:44:53 +0000 From: Alexander Vainshtein To: Robert Raszuk , Shraddha Hegde CC: "spring@ietf.org" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Topic: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Index: AQHVoRZrVSAXH6RCc0yN7BSQBwB5daeYdILlgAAdWICAAAdUGYAAOqyG Date: Sat, 23 Nov 2019 14:44:53 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.176.80.188] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 35015747-92ed-40a6-d2f0-08d77023b355 x-ms-traffictypediagnostic: AM0PR03MB4737: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(366004)(39850400004)(376002)(54094003)(199004)(189003)(7696005)(4326008)(5070765005)(54906003)(110136005)(76116006)(91956017)(186003)(316002)(76176011)(99286004)(66446008)(64756008)(66556008)(66476007)(66946007)(52536014)(55016002)(9686003)(54896002)(6306002)(14444005)(256004)(236005)(71200400001)(71190400001)(6436002)(446003)(11346002)(66066001)(45080400002)(81166006)(8676002)(81156014)(5660300002)(8936002)(478600001)(229853002)(561944003)(74316002)(6116002)(3846002)(33656002)(7736002)(517774005)(440504004)(66574012)(606006)(86362001)(53546011)(6506007)(6246003)(102836004)(26005)(966005)(2906002)(14454004)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4737; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828FD21B1D69E3CB74F3AE49D480AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35015747-92ed-40a6-d2f0-08d77023b355 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2019 14:44:53.0237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U9TVI+48hFJgzih79D38pScPo9yd6b9R1dQ/lg/GT1rcCucMVdNWs4ddQMkuindzng1hcQVG81yj6JpE6ytmbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4737 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: 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: Sat, 23 Nov 2019 14:45:04 -0000 --_000_AM0PR03MB3828FD21B1D69E3CB74F3AE49D480AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, On the second thought, for the purpose of this draft (i.e. in the scope of= SR) it is possible to implement your suggestion by running S-BFD sessions= between R7 (as the initiator) and each other adjacency of R8 (acting as = Reflectors) of a SR policy with list of two SIDs: - protected adjacency between R7 and R8 - Node SID of the specific "other" adjacency of R8. If all these sessions fail, R7 can reliably consider R8 as failed. I am not sure this would be much better than multi-hop IP BFD, and it look= s much more complicated to me. What do you think? Get Outlook for Android ________________________________ From: Alexander Vainshtein Sent: Saturday, November 23, 2019, 13:15 To: Robert Raszuk; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Robert, Lots of thanks for a prompt response. I respectfully disagree with your statement that=20BFD implementation is = usually offloaded to the HW of the ingress line card. I do not think this= can wor for MH BFD sessions because the ingress and egress line cards are= not known in advance and change with the routing changes A good multi-hop BFD implementation should be ready to overcome this. The= re are many ways to achieve that. A naive implementation that runs in SW o= f the control card is also possible of course. And they would sensd and re= ceive packets My 2c. Get Outlook for Android ________________________________ From: Robert Raszuk Sent: Saturday, November 23, 2019, 12:37 To: Alexander Vainshtein; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Sasha, On the surface your suggestion may look cool - but if you zoom in - I do n= ot think it will work in practice. See - one of the biggest value of BFD is its offload to line card's hardwa= re. And in most cases it is ingress line card to the box. So if you instru= ct such hardware to respond to SID address loopback you still did not gain= much in terms of detection router's fabric failures, remote LC failure or= control plane issues which could soon result in box failure. The catalogu= e of router failures is of course much more colorful. If you ask BFD to be responded by RP/RE it no longer has the BFD advantage= . IMHO the best way to detect node failure is actually to send the probes *a= cross* the node under test to its peers. The way I would think of establishing such m-hop sessions would be fully a= utomated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]" = where local BFD subsystem would create N sessions to IGP peers of the node= we are to protect. LSDB has those peers so no new protocol extension is n= eeded, perhaps even no new IETF draft is required :). N would be the limit= of such sessions in case the node under protection has say 10s of peers. = Default could be perhaps even 1. Thx, Robert. On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein > wrote: Shraddha, Robert and all, Regarding Robert's question: I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could be used as s= uch a trigger by R7? Such a session would not respond to link failures, an= d I find it problematic to imagine a scenario when it would be kept UP in = the case of a real node failure. Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO. My 2c, Sasha Such Get Outlook for Android ________________________________ From: spring > on = behalf of Robert Raszuk > Sent: Friday, November 22, 2019, 11:22 To: Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Shraddha, I have one question to the document. As you know the critical element for the effective protection of any schem= e is the failure detection. On that your draft seems to have just one litt= le paragraph: Note that R7 activates the node-protecting backup path when it detects that the link to R8 has failed. R7 does not know that node R8 has actually failed. However, the node-protecting backup path is computed assuming that the failure of the link to R8 implies that R8 has failed. Well IMO this is not enough. Specifically there can be a lot of types of n= ode failure when link is still up. Moreover there can be even running BFD = across the link just fine when say fabric failure occurs at R8. While this is not solely issue with this draft, it is our common IETF fail= ure to provide correct means of detecting end to end path or fragments of = path failures (I am specifically not calling them segment here :). For example I propose that to effectively detect R8 failure as node failur= e which is the topic of your proposal a mechanism is clearly defined and i= ncludes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, = R3-R9 Many thx, Robert. On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde > wrote: WG, This is the draft I pointed out that talks about solutions for providing n= ode-protection. It covers Anycast case as well as keeping forwarding plane longer. https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-p= aths-05 Review and comments solicited. Rgds Shraddha _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828FD21B1D69E3CB74F3AE49D480AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,
On the second thought, for the purpose of this draft (i.e. in the scope of= SR) it is possible to implement your suggestion by running S-BFD sessions= between R7 (as the initiator) and each other adjacency of R8  (actin= g as Reflectors) of a SR policy with list of two SIDs:
- protected adjacency between R7 and R8
- Node SID of the specific "other" adjacency  of R8.

If all these sessions fail, R7 can reliably consider R8 as failed. 

I am not sure this would be much better than multi-hop IP BFD, and it look= s much more complicated to me. 


What do you think?




From: Alexander Vainshtein <= Alexander.Vainshtein@ecitele.com>
Sent: Saturday, November 23, 2019, 13:15
To: Robert Raszuk; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Robert,
Lots of thanks for a prompt response.

I respectfully disagree with your statement that BFD implementation  = is usually offloaded to the HW of the ingress line card.  I do not th= ink this can wor for MH BFD sessions because the ingress and egress line c= ards are not known in advance and change with the routing changes
A good  multi-hop BFD implementation should be ready to overcome this= . There are many ways to achieve that. A naive implementation that runs in= SW of the control card is also possible of course. And they would sensd a= nd receive packets 

My 2c.

From: Robert Raszuk <robert@= raszuk.net>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Sasha,

On the surface your suggestion may look cool - but if you zoom in - I= do not think it will work in practice. 

See - one of the biggest value of BFD is its offload to line card's h= ardware. And in most cases it is ingress line card to the box. So if you i= nstruct such hardware to respond to SID address loopback you still did not= gain much in terms of detection router's fabric failures, remote LC failure or control plane issues which cou= ld soon result in box failure. The catalogue of router failures is of cour= se much more colorful. 

If you ask BFD to be responded by RP/RE it no longer has the BFD adva= ntage. 

IMHO the best way to detect node failure is actually to send the= probes *across* the node under test to its peers. 

The way I would think of establishing such m-hop sessions would be fu= lly automated with one knob per IGP adj. ex: "bfd detect-node-failure= [max N]" where local BFD subsystem would create N sessions to IGP pe= ers of the node we are to protect. LSDB has those peers so no new protocol extension is needed, perhaps even no new IE= TF draft is required :). N would be the limit of such sessions in case the= node under protection has say 10s of peers. Default could be perhaps even= 1. 

Thx,
Robert.


On Sat, Nov 23, 2019 at 10:00 AM Ale= xander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Shraddha, Robert and all,
Regarding Robert's question: 
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could be used as s= uch a trigger by R7? Such a session would not respond to link failures, an= d I find it problematic to imagine a scenario when it would be kept UP in the case of a real node failure.

Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO.

My 2c,
Sasha

Such


Get Outlook for Android

From: spring <spring-bounces@ietf.org> on behalf of R= obert Raszuk <ro= bert@raszuk.net>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: = spring@ietf.org; rtgwg@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Shraddha,

I have one question to the document. 

As you know the critical element for the effective protection of= any scheme is the failure detection. On that your draft seems to have jus= t one little paragraph: 

   Note that R7 activates the nod=
e-protecting backup path when it
   detects that the link to R8 has failed.  R7 does not know that node
   R8 has actually failed.  However, the node-protecting backup path is
   computed assuming that the failure of the link to R8 implies that R8
   has failed.

Well IMO this is not enough. Specifically there can be a lot of = types of node failure when link is still up. Moreover there can be even ru= nning BFD across the link just fine when say fabric failure occurs at R8.&= nbsp;

While this is not solely issue with this draft, it is our common IETF= failure to provide correct means of detecting end to end path or fragment= s of path failures (I am specifically not calling them segment here :).&nb= sp;

For example I propose that to effectively detect R8 failure as node f= ailure which is the topic of your proposal a mechanism is clearly defined = and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4= -R9, R3-R9

Many thx,
Robert.


On Fri, Nov 22, 2019 at 4:38 AM Shra= ddha Hegde <shraddha=3D40juniper.net@dmarc.ietf..org> wrote:
WG,
 
This is the draft I pointed out that talks about solutions for provid= ing node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
 
Review and comments solicited.
 
Rgds
Shraddha
 
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
= https://www.ietf.org/mailman/listinfo/rtgwg



__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828FD21B1D69E3CB74F3AE49D480AM0PR03MB3828eurp_-- From nobody Sat Nov 23 07:14:28 2019 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 DF734120088; Sat, 23 Nov 2019 07:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=Sy+XHLOl; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=xF0KgsAj 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 hrVBpWYVeWiR; Sat, 23 Nov 2019 07:14:25 -0800 (PST) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18849120116; Sat, 23 Nov 2019 07:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1574522062; i=@ecitele.com; bh=hFvSUYWlQptOdilI89SHETrRaKdQP5o4JTw3RB5L9Ig=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=Sy+XHLOl7zfummT67TJy2h6SRgSIPEF0VCf2ubndki5A7JWv+sZ4e55dutRXQDePI UEhBwKVIgesTQqKpdMn2Xux3kpI7ReYZ8TsVTo7YEnZywYGPzyokC7S5VWvvoL4qSM HABTcmYeXOMj/N8R2ghUxgFu2Ea0bSjpeRZR/wP0= Received: from [46.226.52.203] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-west-1.aws.symcld.net id AD/1B-03226-CCC49DD5; Sat, 23 Nov 2019 15:14:20 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkl+JIrShJLcpLzFFi42IRetuzUfe0z81 Yg6tH1C2aFjYxW3z+s43R4sKb38wWE5ZNZ7U4fuE3owOrx4llV1g9liz5yeSxe+MCpgDmKNbM vKT8igTWjN1T7zMWrNnOWLFy1gWWBsYL8xm7GLk4GAWWMktc/bKHDcI5xiIxacMddghnM6PEi eOTwBwWgbXMEje7v4L1CAlMYJJ48XwiE4Rzn1FifcsHoAGcHGwCthKbVt8Fs0UE4iRaL8xnB7 GZBYokns6ewAhiCwsESaz9exaqJlhiw5pbLBC2n8SO21OZQGwWAVWJ/RdOgtXzCsRKTJ3zBMw WErgDdO0SIRCbE2j+nN+dYHFGATGJ76fWMEHsEpe49WQ+mC0hICCxZM95ZghbVOLl43+sEPVJ EvefLmSEiCtKfFqxjxXClpW4NL8bKM4BZCtLbHkRCxH2lThz5ygLRFhL4u9XToiwlMS7G+tYI OwciQ+PbkBtUpOYeOwT1AUyEodXzYbadItNYs8pW4hPkiVOzPnMMoFRfxaSoyHsPImpG18yzg J7XlDi5MwnLBBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo3lSUWZ6RkluYmaOrqGBga6 hoZGuoaWFrpGFXmKVbpJeaqlueWpxia6hXmJ5sV5xZW5yTopeXmrJJkZgikspOCazg7Hj01u9 Q4ySHExKorzPNl6PFeJLyk+pzEgszogvKs1JLT7EKMPBoSTBqwVMmkKCRanpqRVpmTnAdAuTl uDgURLhFQFJ8xYXJOYWZ6ZDpE4xBnJMeDl3ETPHzqPzgOTh6QuA5Lufi4Hkx1VLgOR3MLl57t JFzEIsefl5qVLivKkggwRABmWU5sGtgeWQS4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJWEebN BpvBk5pXAXfMK6FAmoEN/LLoGcmhJIkJKqoFpm8DvitXfv3n8VJjjdmZjn3n1SlGteTrSDxg6 0rmcDmzQCyh+a/UmxpBlf3xc4sUW5bttNx2yWY53uKk1H2zef7XStvtT1VJlxpsX75QzMHBNW j/x2bY1pWaP5jRPcem4l5Fjo/bWt+ychGawi8eVnzOeO66YNkP+Zv9J9aVLBU99fFNQuGLefl PFGSkFV9IMjfsDPESWv2/q756yMPm9v2z3a3WTAIVFM65eD//pxKdv1vCtu8etfc/CJGsGi8S e95ITHXt3WYpOfHu0NevnJVtj1XcL7+yKmPtq9fM9rzraO/cuYNXIOiQ5vX2S4r22x7tVFkcE vJv7m8vltIeuo6+3x9KnE96eXlhzd1mJEktxRqKhFnNRcSIAtceec5wEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-291.messagelabs.com!1574522056!62355!1 X-Originating-IP: [18.237.140.177] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.44.22; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 20777 invoked from network); 23 Nov 2019 15:14:18 -0000 Received: from p01b.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-13.tower-291.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 23 Nov 2019 15:14:18 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SAKtAtDm2TP7AS61NstLFbjY3Y8XuJ/xabItU+E9IHvDNnR29TtVbdj2BwqoNEroAHHz3+fOswMLQozP5mkkVmLp+dhbZEgxHXsmZtV3sQ1s7SP7Cn7X+5iATNGn8wXEfGhAo4DPL6FLECLA41RGe6FXg2NjNIKbVHnGn9rr7RGtXu9XuJDblIEIP6v68sDfQJaTZURLWXu76oh/aLOt32A7MEBWPkJhHcc7tR7ph93VWbol0UGDKvWOVVcUT36Zv725HLqjMV2pJu8qnniviQ3xEc0eeZQZHxhvcVivutGN5/0QFLZp7sk5NTX3gQpRIRipNoixYHWFJbOeV7QTHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Q1xsqK7af5NXJlOc8vF7hFTQ7W5WBFCYbV46aZ70n8=; b=BL4A6klO2g8Xi2xpFRdfDBJr+8QPnhqzKVUnaMUFNlYZwxq/yGSJd+YCVP9P64Yddh0u8tnoGWUNv9pb1dKzoDwstY+2IyiOIe4ijOpvoQ4T/UDt4jVrHekuUNcJPtqUhYOhpYMqSDeWKAJk8UIdDS25d+b30zdPhhXxUtmxZyzCNyhxgs8xfVZ1bHKK6XARShd5iwBdKuPnsPxeVnieq2pQJZqbOpw8Qsvr16KUqsQ9PYZiX1t3hyN1AAaBRPCECd0xLcW3T3uKUkW4DN0nZ/otRvwWT7fxpJJ0QeearLdJjrhUtxX8cOnmJj5bDiARrM2UU/+H0gZjfMqCH9TccQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Q1xsqK7af5NXJlOc8vF7hFTQ7W5WBFCYbV46aZ70n8=; b=xF0KgsAj0DHB0lz3ROHQm2w1nvYQY5HkTJkux9sZz3gN05zNd1GCh7AYliVv4JI+1i3JyfxOehidhE8GTdqT+zlBoU1U4L28ZL8DUIm0hGGUqawLXcteYWWbbRNJL0LqQawKH5y80c7dfW3GbN8HJdqtC1JezVAk2MKr9FItj4c= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4337.eurprd03.prod.outlook.com (20.177.41.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.22; Sat, 23 Nov 2019 15:14:12 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7554:6540:b0c0:800f]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::7554:6540:b0c0:800f%7]) with mapi id 15.20.2474.022; Sat, 23 Nov 2019 15:14:12 +0000 From: Alexander Vainshtein To: Robert Raszuk , Shraddha Hegde CC: "spring@ietf.org" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Topic: [spring] Draft for Node protection of intermediate nodes in SR Paths Thread-Index: AQHVoRZrVSAXH6RCc0yN7BSQBwB5daeYdILlgAAdWICAAAdUGYAAOqyGgAAJ1J4= Date: Sat, 23 Nov 2019 15:14:12 +0000 Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.176.80.188] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 86a53887-fa1d-4437-6973-08d77027cc30 x-ms-traffictypediagnostic: AM0PR03MB4337: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39850400004)(396003)(376002)(136003)(346002)(199004)(189003)(54094003)(51444003)(86362001)(446003)(11346002)(76176011)(5070765005)(478600001)(186003)(7696005)(102836004)(25786009)(2906002)(74316002)(53546011)(6506007)(6116002)(3846002)(6246003)(26005)(45080400002)(110136005)(236005)(55016002)(54906003)(81166006)(81156014)(54896002)(6306002)(9686003)(6436002)(316002)(14454004)(517774005)(66066001)(7736002)(606006)(440504004)(66574012)(66946007)(5660300002)(66556008)(64756008)(66446008)(66476007)(91956017)(76116006)(52536014)(2940100002)(8676002)(71190400001)(71200400001)(256004)(14444005)(33656002)(229853002)(561944003)(966005)(99286004)(4326008)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4337; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828F390A75FA57D65BAD2E29D480AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86a53887-fa1d-4437-6973-08d77027cc30 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2019 15:14:12.6915 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ilyTl5yrbC79DdAi4WHJYvx3BNpBBGaNmpE5Qs1+tQaCyPE8OsZTcB7qdsQ6Mg2CXwB68791eW2zz6PHv8EuBA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4337 X-CFilter-Loop: Reflected X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a Archived-At: 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: Sat, 23 Nov 2019 15:14:27 -0000 --_000_AM0PR03MB3828F390A75FA57D65BAD2E29D480AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And coming back to the draft in question: I think that it is about thecprotection action itself, anf this action may= be triggered by different events. This approach has been taken in the MPLS Egress Protection Framework = draft (now in the RFC Editor queue). Get Outlook for Android ________________________________ From: Alexander Vainshtein Sent: Saturday, November 23, 2019, 16:44 To: Robert Raszuk; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Robert, On the second thought, for the purpose of this draft (i.e. in the scope of= SR) it is possible to implement your suggestion by running S-BFD sessions= between R7 (as the initiator) and each other adjacency of R8 (acting as = Reflectors) of a SR policy with list of two SIDs: - protected adjacency between R7 and R8 - Node=20SID of the specific "other" adjacency of R8. If all these sessions fail, R7 can reliably consider R8 as failed. I am not sure this would be much better than multi-hop IP BFD, and it look= s much more complicated to me. What do you think? Get Outlook for Android ________________________________ From: Alexander Vainshtein Sent: Saturday, November 23, 2019, 13:15 To: Robert Raszuk; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Robert, Lots of thanks for a prompt response. I respectfully disagree with your statement that BFD implementation is us= ually offloaded to the HW of the ingress line card. I do not think this c= an wor for MH BFD sessions because the ingress and egress line cards are n= ot known in advance and change with the routing changes A good multi-hop BFD implementation should be ready to overcome this. The= re are many ways to achieve that. A naive implementation that runs in SW o= f the control card is also possible of course. And they would sensd and re= ceive packets My 2c. Get Outlook for Android ________________________________ From: Robert Raszuk Sent: Saturday, November 23, 2019, 12:37 To: Alexander Vainshtein; Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Sasha, On the surface your suggestion may look cool - but if you zoom in - I do n= ot think it will work in practice. See - one of the biggest value of BFD is its offload to line card's hardwa= re. And in most cases it is ingress line card to the box. So if you instru= ct such hardware to respond to SID address loopback you still did not gain= much in terms of detection router's fabric failures, remote LC failure or= control plane issues which could soon result in box failure. The catalogu= e of router failures is of course much more colorful. If you ask BFD to be responded by RP/RE it no longer has the BFD advantage= . IMHO the best way to detect node failure is actually to send the probes *a= cross* the node under test to its peers. The way I would think of establishing such m-hop sessions would be fully a= utomated with one knob per IGP adj. ex: "bfd detect-node-failure [max N]" = where local BFD subsystem would create N sessions to IGP peers of the node= we are to protect. LSDB has those peers so no new protocol extension is n= eeded, perhaps even no new IETF draft is required :). N would be the limit= of such sessions in case the node under protection has say 10s of peers. = Default could be perhaps even 1. Thx, Robert. On Sat, Nov 23, 2019 at 10:00 AM Alexander Vainshtein > wrote: Shraddha, Robert and all, Regarding Robert's question: I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could=20be used as= such a trigger by R7? Such a session would not respond to link failures, = and I find it problematic to imagine a scenario when it would be kept UP i= n the case of a real node failure. Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO. My 2c, Sasha Such Get Outlook for Android ________________________________ From: spring > on = behalf of Robert Raszuk > Sent: Friday, November 22, 2019, 11:22 To: Shraddha Hegde Cc: spring@ietf.org; rtgwg@ietf.org Subject: Re: [spring] Draft for Node protection of intermediate nodes in S= R Paths Hi Shraddha, I have one question to the document. As you know the critical element for the effective protection of any schem= e is the failure detection. On that your draft seems to have just one litt= le paragraph: Note that R7 activates the node-protecting backup path when it detects that the link to R8 has failed. R7 does not know that node R8 has actually failed. However, the node-protecting backup path is computed assuming that the failure of the link to R8 implies that R8 has failed. Well IMO this is not enough. Specifically there can be a lot of types of n= ode failure when link is still up. Moreover there can be even running BFD = across the link just fine when say fabric failure occurs at R8. While this is not solely issue with this draft, it is our common IETF fail= ure to provide correct means of detecting end to end path or fragments of = path failures (I am specifically not calling them segment here :). For example I propose that to effectively detect R8 failure as node failur= e which is the topic of your proposal a mechanism is clearly defined and i= ncludes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4-R9, = R3-R9 Many thx, Robert. On Fri, Nov 22, 2019 at 4:38 AM Shraddha Hegde > wrote: WG, This is the draft I pointed out that talks about solutions for providing n= ode-protection. It covers Anycast case as well as keeping forwarding plane longer. https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-p= aths-05 Review and comments solicited. Rgds Shraddha _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828F390A75FA57D65BAD2E29D480AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
And coming back to the draft in question: 
I think that it is about thecprotection action itself, anf this action may= be triggered by different events. 
 
This approach has been taken in the MPLS Egress Prote= ction Framework draft (now in the RFC Editor queue).




From: Alexander Vainshtein <= Alexander.Vainshtein@ecitele.com>
Sent: Saturday, November 23, 2019, 16:44
To: Robert Raszuk; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Robert,
On the second thought, for the purpose of this draft (i.e. in the scope of= SR) it is possible to implement your suggestion by running S-BFD sessions= between R7 (as the initiator) and each other adjacency of R8  (actin= g as Reflectors) of a SR policy with list of two SIDs:
- protected adjacency between R7 and R8
- Node SID of the specific "other" adjacency  of R8.

If all these sessions fail, R7 can reliably consider R8 as failed. 

I am not sure this would be much better than multi-hop IP BFD, and it look= s much more complicated to me. 


What do you think?




From: Alexander Vainshtein <= Alexander.Vainshtein@ecitele.com>
Sent: Saturday, November 23, 2019, 13:15
To: Robert Raszuk; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Robert,
Lots of thanks for a prompt response.

I respectfully disagree with your statement that BFD implementation  = is usually offloaded to the HW of the ingress line card.  I do not th= ink this can wor for MH BFD sessions because the ingress and egress line c= ards are not known in advance and change with the routing changes
A good  multi-hop BFD implementation should be ready to overcome this= . There are many ways to achieve that. A naive=20implementation that runs = in SW of the control card is also possible of course. And they would sensd= and receive packets 

My 2c.

From: Robert Raszuk <robert@= raszuk.net>
Sent: Saturday, November 23, 2019, 12:37
To: Alexander Vainshtein; Shraddha Hegde
Cc: spring@ietf.org; rtgwg@ietf.org; rtg-bfd@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Sasha,

On the surface your suggestion may look cool - but if you zoom in - I= do not think it will work in practice. 

See - one of the biggest value of BFD is its offload to line card's h= ardware. And in most cases it is ingress line card to the box. So if you i= nstruct such hardware to respond to SID address loopback you still did not= gain much in terms of detection router's fabric failures, remote LC failure or control plane issues which cou= ld soon result in box failure. The catalogue of router failures is of cour= se much more colorful. 

If you ask BFD to be responded by RP/RE it no longer has the BFD adva= ntage. 

IMHO the best way to detect node failure is actually to send the= probes *across* the node under test to its peers. 

The way I would think of establishing such m-hop sessions would be fu= lly automated with one knob per IGP adj. ex: "bfd detect-node-failure= [max N]" where local BFD subsystem would create N sessions to IGP pe= ers of the node we are to protect. LSDB has those peers so no new protocol extension is needed, perhaps even no new IE= TF draft is required :). N would be the limit of such sessions in case the= node under protection has say 10s of peers. Default could be perhaps even= 1. 

Thx,
Robert.


On Sat, Nov 23, 2019 at 10:00 AM Ale= xander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
Shraddha, Robert and all,
Regarding Robert's question: 
I wonder if multi-hop IP BFD session with addresses used as /32 (or /128) = prefixes serving as Nose SIDs of R8 and R7 respectively could be used as s= uch a trigger by R7? Such a session would not respond to link failures, an= d I find it problematic to imagine a scenario when it would be kept UP in the case of a real node failure.

Of course such a session would have to be slow enough not to react to link= failures. But it still couks be much faster than IGP conversion IMHO.

My 2c,
Sasha

Such


Get Outlook for Android

From: spring <spring-bounces@ietf.org> on behalf of R= obert Raszuk <ro= bert@raszuk.net>
Sent: Friday, November 22, 2019, 11:22
To: Shraddha Hegde
Cc: = spring@ietf.org; rtgwg@ietf.org
= Subject: Re: [spring] Draft for Node protection of interm= ediate nodes in SR Paths

Hi Shraddha,

I have one question to the document. 

As you know the critical element for the effective protection of= any scheme is the failure detection. On that your draft seems to have jus= t one little paragraph: 

   Note that R7 activates the nod=
e-protecting backup path when it
   detects that the link to R8 has failed.  R7 does not know that node
   R8 has actually failed.  However, the node-protecting backup path is
   computed assuming that the failure of the link to R8 implies that R8
   has failed.

Well IMO this is not enough. Specifically there can be a lot of = types of node failure when link is still up. Moreover there can be even ru= nning BFD across the link just fine when say fabric failure occurs at R8.&= nbsp;

While this is not solely issue with this draft, it is our common IETF= failure to provide correct means of detecting end to end path or fragment= s of path failures (I am specifically not calling them segment here :).&nb= sp;

For example I propose that to effectively detect R8 failure as node f= ailure which is the topic of your proposal a mechanism is clearly defined = and includes bi-dir data plane probes send between R7-R9, R3-R7, R4-R7, R4= -R9, R3-R9

Many thx,
Robert.


On Fri, Nov 22, 2019 at 4:38 AM Shra= ddha Hegde <shraddha=3D40juniper.net@dmarc.ietf..org> wrote:
WG,
 
This is the draft I pointed out that talks about solutions for provid= ing node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
 
Review and comments solicited.
 
Rgds
Shraddha
 
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
= https://www.ietf.org/mailman/listinfo/rtgwg




__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828F390A75FA57D65BAD2E29D480AM0PR03MB3828eurp_-- From nobody Wed Nov 27 11:59:52 2019 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 A06BF12097A for ; Wed, 27 Nov 2019 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MPART_ALT_DIFF_COUNT=1.112, 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 2T4w1ZcvS8W5 for ; Wed, 27 Nov 2019 11:59:49 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1F120A0C for ; Wed, 27 Nov 2019 11:59:49 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id F007B1E2F7; Wed, 27 Nov 2019 15:03:54 -0500 (EST) From: Jeffrey Haas Content-Type: multipart/alternative; boundary="Apple-Mail=_0272B170-762A-4E50-B222-E5DD75AE655E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 27 Nov 2019 14:59:46 -0500 Subject: Transcript - BFD at IETF-106 Message-Id: <77870EF2-BDB6-4163-9F1B-23BC345EC941@pfrc.org> To: rtg-bfd WG X-Mailer: Apple Mail (2.3601.0.10) Archived-At: 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: Wed, 27 Nov 2019 19:59:51 -0000 --Apple-Mail=_0272B170-762A-4E50-B222-E5DD75AE655E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you to Xiao Min who produced the following transcript of the = session from IETF 106. Here is a pointer to the meetecho recording: = https://play.conf.meetecho.com/Playout/?session=3DIETF106-BFD-20191119-171= 0 = -- Jeff --Apple-Mail=_0272B170-762A-4E50-B222-E5DD75AE655E Content-Type: multipart/mixed; boundary="Apple-Mail=_95FE81DC-6102-47BE-90D7-AA92DEB6B103" --Apple-Mail=_95FE81DC-6102-47BE-90D7-AA92DEB6B103 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Thank you to Xiao Min who produced the following transcript of the session from IETF 106.

Here is a pointer to the meetecho recording:

-- Jeff

--Apple-Mail=_95FE81DC-6102-47BE-90D7-AA92DEB6B103 Content-Disposition: attachment; filename=bfd-106-transcript.txt Content-Type: text/plain; x-unix-mode=0644; name="bfd-106-transcript.txt" Content-Transfer-Encoding: quoted-printable Chairs update: 5 mins - Jeff Haas Welcome to BFD. I'm Jeff Haas, Reshad is unable to co-chair for this = session, because he is unable to come Singapore. We have four sessions today. BFD for vxlan and BFD for large Packets have been through working group = last call. A presentation on one-armed BFD. BFD for vxlan: 15 minutes - Greg Mirsky Greg: So you can see it, it says The inner destination IP address SHOULD = use one of the loopback addresses. And again, that is because we were told = that their implementations that hard coded using different than that. And = we're not told that they can be configured to something else. Matthew: In the past, for the tunnelled BFD, it's always set to 127/8. Greg: I would say, even more generic, when we do any IP OAM over the = tunnel, we use loopback, LSP Ping or BFD, actually BFD follow the same because the = first one it was RFC4379, which changed the loopback in another RFC1122. Matthew: And that was for pretty good reason I think was something to do = if it gets extracted at the wrong ... Greg: Absolutely yes. Matthew: And we've also come across sort of interoperability issues with = things like earlier implementations of seamless BFD, and LSP BFD, where some implementations will check for 127/8 some won't, and some will discard = it if it is not 127/8. And I'm just worried that if you're implementing this on a = box that's also doing other flavors of BFD you're going to run into issues, = if you allow anything other than 127/8. Greg: Again, my understanding is that this is something that working = group can decide. Jeff: So, speaking personally rather than as chair, I think we all agree = that if you're writing this from scratch and you had a clean implementation, = the procedure here is the right thing to do. And the proper thing, likely to = do is the industry is just simply to pressure people to conform with this, = certainly know it's implemented, have that choice by making sure that your stuff = doesn't interoperate with things you consider broken. Martin: Could you at least write it down what's on the risk of not = respecting that SHOULD? Greg: OK, that will be easy. Matthew: Maybe in the security consideration section, right something to = say. Greg: That will be not a problem, absolutely. Jeff: Yeah, and my feeling of the consensus for the conversation is that = SHOULD gives the feature out there. It encourages people to do the right thing = and implementers that choose not to interoperate with them, have the option = to do so. Greg: Okay, so just add text in Security Consideration explaining a = choice, I probably pretty much cut and paste text from 4479 or 8029. Greg: Management VNI is a control signaling channel between VTEPs. So = any communication between them over this channel should be using, if we = decide, this MAC address, including BFD. Is there decision that we'll not = address that in this document? Jeff: I think that is the reasonable thing we do. That's the consensus = we currently have from the mail discussion. We provided a possible path = that allows us to edit after the fact, updating other RFCs is a reasonable = thing to do. And this means that we can unlock this document through the RFC = Queue, and depending on exactly how much work there is to do in NVO3 for such a = management document, maybe that comes out much faster than this. Greg: So Demand mode is not mentioned in the document explicitly. And is = that the indication that it's outside the scope of the draft? And if it's = outside the scope of the draft, should we have the same statement similar to in = regard to BFD Echo mode?=20 Jeff: In regard to BFD Echo mode, the consideration is traffic that = needs to be encapsulated outside the protocol. So that's the reason why it has to be explicitly said outside. For demand mode, unless there is a reason we = think that it breaks for some strange reason in this environment that we don't = need to mention it because it's just a supportive feature. Just leave it as = is. Greg: With that, I think that we have one action point to the editors to = edit text which is pretty clear, and then for the working group chairs to = decide what we do next. Jeff: So we've completed working group last call, you've gotten = substantial feedback, the amount of text change is part of the feedback has been = relatively small. So what that means is we've mostly converge on this point. So = once you've added the other item we can each take a quick editor's pass = through things, but the working group last call has concluded. And once we have = the new version we'll advance it to the IESG. ----- =20 BFD for Large Packets: 5 minutes - Jeff Haas No questions. ----- Using One-Arm BFD in Cloud Network: 10 minutes - Weiqiang Cheng Jeff: A little over a year ago, somebody may be aware of the broadband = forum TR-146 document, and this gave me, why people are asking about it is = because another standards organization had decided that they were going to try = to make use of a small piece of our functionality, but in a way that was not = well specified there, their document has errors in it. This is an understood = thing. Discussion is interesting, so you're the first to bring this to IETF to = ask about this. So, our problem is IETF is doing this to put a document = together that effectively publishes the scenario for BBF, maybe with corrections = and IETF context. Thank you for the presentation is that this is a helpful = piece of functionality. And you also gave an example of could we maybe extend = Yang, to cover this behavior. So that such things could be configured. So, there = is possibility for the work. And certainly if you wish to be one of the = authors on the document towards IETF, that can be done, but there are many process discussions that have to happen first. Weiqiang: No problem. I think it will be very useful because currently a = lot of overlay network is deployed that not only within the data center such as = the VxLAN, as well as you know, one system in the SD-WAN, especially for = some industry internet, so maybe that kind of function can be used in more application scenarios, that will be useful. Jeff: The issue that we do have to verify before we can start to = progress is since BBF is a standards body. Do they have an intellectual property restriction, and their proposal. So, even if they wanted to do work on = this, you'd have to figure out the status of that. Weiqiang: Yeah, I think the bfd is raised by IETF. I think IETF is the = host of the BFD. Les: This is a kind of interesting. But I'm wondering about the = interactions with the various forms of strict mode. I think that would be = problematic. Jeff: There's probably some sort of no commodity silicon then here that = happens to have a BFD echoes back programmed into their hardware and it makes = this cheap and easy. And people are just using that, but this could be ping, = you know, literally any mechanism could be used that test them to revoke activity.And you know, the BFD state machinery for clients can be used = echo it. Greg: Actually, thanks to bring the TR-146 to attention, I was not aware = of it. And when I read it, I believe they do use not only BFD echo, they use combination of poll/sequence to communicate diag modes. And actually = that's where I found more mistakes and misconceptions. And actually the good = thing is that BBF member meeting is one week from this week. Mach: I think this idea is very interesting and it's very useful for = some scenario. In my personal opinion I think there may be some protocol work = to be defined in this working group, because for the traditional BFD session = we need to set my discriminator, but for this one-armed BFD, we need to set both = my discriminator and your discriminator. So, there may be some different = protocol process to be done for this solution. Jeff: Based on my understanding, the whole issue here is that they don't = want to put any BFD machinery into the effectively the host devices like a = media gateway for cable networks that sort of thing, very dumb boxes. And = they're relying on the packet loop to simply fulfill the need. So, this is very = bad from the working group's pespective because we don't have any = negotiation that can help BFD sender to figure out packet speed receiver actually wants = to get. This is probably okay for the people who did this work because for their environment they knew what speed they're willing to support.=20 Mach: Yeah, for that aspect I think I agree with you there is no need = for some protocol extension between the local side and the remote side, but for = the local process, and based on the current process I think we need some modifications to the current process and to how to handle the = discriminators. Jeff: No discriminators, remember this is Echo, and it's literally just = IP packets. This is a very dumb mechanism. Matthew: On your kind of echoing yourself, there is another mechanism = called LSP self-ping, where you just address the packet yourself and send it = into an LSP, and it comes back. So I'm wondering about the negotiation you're = taling about is already you know negotiation with yourself because it's just a = route. Weiqiang: You just send it out. And because the remote side is very weak system, but it can echo the packet, and we can use very low speed BFD = packet rate, but we can check the link's quality, that's enough. Jeff: And call it a BFD packet is a little misleading. It's BFD echo = packets that are just data. It just happens to be a well-known port. Louis Chan: One direction maybe from the echo side is might not actually require the echo side to do anything, right? So, therefore actually for = trouble shooting we may specify the format so that the echo side can optionally = turned on to get the statistics, so that the trouble shoot to look at what = happened in the networks and look how many sections to be established. I think it = may be useful in some places but need to identify who are the sender, I think = that is important, which is the discriminator and then echo back the packet = itself. Greg: I think that this exchange brings very good question. That was = somewhere in the back of my mind, is it would be good in the document when we = write it, that explain what exactly can be verified and monitored using this = technique. So that to have right expectations, and I want to point out that echo = works only over a single hop. It could be a tunnel, but used to crossing a = single hop. Jeff: And relaying a question from Robert and jabber, was this spoofing protection considered in this echo mode? And Greg you just answered a = portion of the question, which is that it's single hop only. Beyond that, this = is just an echo functionality and the remote side exercises no protocol = behaviors at all. So it is up to the sender to put something into the packet that = they would recognize. You know, the BFD 5880 spec does not talk about that at all. Jeff: So I think the action for the working group is we'll continue = discussion in the mailing list, will discuss things with BBF and figure out how to = take this forward. ----- Jeff: And that concludes our content. We will probably be meeting in = Canada in the upcoming IETF. And thank you for coming to IETF 106. --Apple-Mail=_95FE81DC-6102-47BE-90D7-AA92DEB6B103 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_95FE81DC-6102-47BE-90D7-AA92DEB6B103-- --Apple-Mail=_0272B170-762A-4E50-B222-E5DD75AE655E-- From nobody Wed Nov 27 12:01:14 2019 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 8AC8312099E for ; Wed, 27 Nov 2019 12:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 dYV-onNnc5tv for ; Wed, 27 Nov 2019 12:01:10 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BE82A120C3E for ; Wed, 27 Nov 2019 12:00:59 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 7441B1E2F7; Wed, 27 Nov 2019 15:05:06 -0500 (EST) From: Jeffrey Haas Content-Type: multipart/mixed; boundary="Apple-Mail=_81AA80B2-EE3D-4CFE-A59F-90D075E96898" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Wed, 27 Nov 2019 15:00:58 -0500 Subject: BFD - IETF 106 minutes Message-Id: <8AE20029-4DA7-4F51-9035-0DC88D922D12@pfrc.org> To: rtg-bfd WG X-Mailer: Apple Mail (2.3601.0.10) Archived-At: 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: Wed, 27 Nov 2019 20:01:13 -0000 --Apple-Mail=_81AA80B2-EE3D-4CFE-A59F-90D075E96898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The following are the minutes from IETF-106 for BFD. Thanks to Xiao Min = for providing transcripts to help produce them. Please send comments on the minutes ASAP. -- Jeff --Apple-Mail=_81AA80B2-EE3D-4CFE-A59F-90D075E96898 Content-Disposition: attachment; filename=bfd-106-minutes.txt Content-Type: text/plain; x-unix-mode=0644; name="bfd-106-minutes.txt" Content-Transfer-Encoding: quoted-printable Bidirectional Forwarding Detection (bfd) IETF-106, Singapore Tuesday 17:10 Minutes taker, Xiao Min. Chairs update - see slides. - BFD for vxlan, presented later. - BFD for large packets, presented later. - BFD yang documents needed small change to accommodate BFD Unsolicited = WGLC. Reshad has sent update to RFC editor. - BFD authentication documents. We have weak, but positive direction to = send those to IESG. - Work deferred on BFDv2/extensions until next IETF. Seeking commentary = from IESG regarding charter discussion. BFD for vxlan - presented by Greg Mirsky: - Cover known open issues. - Main discussion remains on target addresses and whether to use the = 127/8 addresses always, or to permit implementations to deviate from that. + Interoperability issues are known when they're not consistent. + There are existing implementations that don't use 127/8. + A SHOULD is required here, along with discussion about not doing it = this way in the security considerations. (E.g. cut and paste from RFCs = 4379/8029) - Demand mode requires no additional text. - Echo mode is out of scope. - Once the above has been updated in the draft, we'll send to IESG. BFD for large packets - presented by Jeff Haas: - Presentation given, see slides. - Additional operational considerations integrated. - Need additional text covering S-BFD. - Will send back to group for continuing WGLC after this has been done. One-Armed BFD - presented by Weiqiang Cheng: - Presentation given, see slides. - Technology largely (completely?) overlaps TR-146 from BBF. - TR-146 has a number of errors. - Does BBF have IPR on this mechanism? - Comparison to LSP self-ping - Matthew Bocci points that we don't have any rate negotiation we can do = here. =20 + Weiqiang responds that for low rate, we can verify connectivity, and = maybe low-grade link quality metrics. - Greg Mirsky rightly points out this only works single-hop, and that = contents of echo packets may need to be discussed. Exactly what can we measure = using this technique? - Robert Raszuk (jabber) asks about spoofing. =20 + Greg had noted single hop. + Jeff: Sender would have to ensure packet contents provide security. - We will need to followup on this on the mailing list. --Apple-Mail=_81AA80B2-EE3D-4CFE-A59F-90D075E96898-- From nobody Wed Nov 27 12:18:03 2019 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 6891B120A7C; Wed, 27 Nov 2019 12:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 n5i49evbfEcF; Wed, 27 Nov 2019 12:17:59 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DF6DE120A79; Wed, 27 Nov 2019 12:17:59 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id AE4871E2F8; Wed, 27 Nov 2019 15:22:06 -0500 (EST) Date: Wed, 27 Nov 2019 15:22:06 -0500 From: Jeffrey Haas To: Dave Katz Cc: "Les Ginsberg (ginsberg)" , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended Message-ID: <20191127202206.GA18175@pfrc.org> References: <20191122025255.GW21134@pfrc.org> <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5013C7DE-81C0-44B6-B15B-8701527358E9@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Wed, 27 Nov 2019 20:18:01 -0000 Dave, On Fri, Nov 22, 2019 at 09:35:12PM +0000, Dave Katz wrote: > If BFD’s transport semantics are that interesting, someone could take a > week and whip up a transport that looks rather like BFD but is properly > suited for the purpose. That would make all of these issues go away, and > would provide a common mechanism that could be used more broadly, and > someone would have an RFC to be proud of. That's effectively what the discussion needs to be. And I agree, there's plumbing like demand and echo that can be gotten rid of. The adaptive timers are part of the charm that people seem to like, so I suspect that'd still be a thing people want. Just not necessarily 3ms granularity. :-) > I guess the irony of all of this is that when the BFD WG was formed it was > expected to be the shortest-lived WG in history. Now I suspect it’s going > for a record in the other direction. ;-) I still resent Alex Z. and co. for leading me into that trap. -- Jeff From nobody Wed Nov 27 12:26:52 2019 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 B0B9E1208B8; Wed, 27 Nov 2019 12:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 mJayXGWnqJZT; Wed, 27 Nov 2019 12:26:48 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67C120908; Wed, 27 Nov 2019 12:26:48 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3F3D41E2F8; Wed, 27 Nov 2019 15:30:55 -0500 (EST) Date: Wed, 27 Nov 2019 15:30:55 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: rtg-bfd WG , bfd-chairs@ietf.org, Martin Vigoureux Subject: Re: Update to BFD over VXLAN Message-ID: <20191127203055.GC18175@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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: Wed, 27 Nov 2019 20:26:51 -0000 Greg, On Wed, Nov 20, 2019 at 10:41:46AM +0800, Greg Mirsky wrote: > Dear All, > as was decided at the meeting, an explanation of using an address from the > Internal host loopback interface address range has been added into the > Security Consideration section: > NEW TEXT: > This document recommends using an address from the Internal host > loopback addresses range as the destination IP address in the inner > IP header. Using such address prevents the forwarding of the > encapsulated BFD control message by a transient node in case the > VXLAN tunnel is broken as according to [RFC1812]: > > A router SHOULD NOT forward, except over a loopback interface, any > packet that has a destination address on network 127. A router > MAY have a switch that allows the network manager to disable these > checks. If such a switch is provided, it MUST default to > performing the checks. I think the text above is largely right. There's a slight level of ambiguity since elsewhere in the document, we don't use the RFC 4379 notation, i.e. 0:0:0:0:0:FFFF:127/104: : : loopback addresses (127/8 range for IPv4 and : 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). I think if you explicitly call it out in the 7400 format, we may be all set. -- Jeff From nobody Fri Nov 29 13:22:09 2019 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 4188F120058; Fri, 29 Nov 2019 13:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KQkzKNszpDhp; Fri, 29 Nov 2019 13:22:06 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 8E7DD120048; Fri, 29 Nov 2019 13:22:06 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id d6so23562215lfc.0; Fri, 29 Nov 2019 13:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ektwn9TbZaXR+VBVtRLiiVdPpp6jrgInyzDDLtZ0Yo=; b=Pa6hrsGfQxxPeKh30NQnMszGMLZi0VtLKOtBpkJSCK36avXH1jKUT2LPJv+lrAy/fk ljV3gKek+tXZLOZPo3gsWsFQCoSGV8wmWyMfhUx0BvFuR905CdqSrZNjuqZxNAZ/vVkc veQuk5U8mo2YXFEnQ7Tj5I0gOXcuqH+xAEYrzuxAiYzCn2PKqpyGQuxEqzVGcaF0oYUm Oa5hcUBLA+g21rlg8lqMjPLqAHmjAXj7rOnVKLSxIpsbQ8qkcZYONRd/N0zsUGKiyBev ZV2lQ4WguM9Y1/Y09xLqDOMHIIReoYfdqndejvxMCbuQxvdU9XJrruRDdSQbjafgq8Gd EGkw== 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=9ektwn9TbZaXR+VBVtRLiiVdPpp6jrgInyzDDLtZ0Yo=; b=QcEGA6eSpNPjpaCcFBtzCVhjUlHaMl97KQ8lop+8ZQhiiZblo14HdRBcbgJGnhm9KH cptFiFnzu2gZbOxYghp0AGEdIn/rYqaRRiVd8V24ax3eIgYJkhXhdw0UkI8Ppt2qkB/P G6WdLFsq/KLBgVtBg13xCwUN8CAkHRcE40CJAHZFwoMepL8zxUNlJsNl7SvDRbrEtn4q S2gKdJr6McHAhZswYqO0/spwNAwSIF5UGiNwoi1/e4u4HhwnJPoW5DaXFMSC3SBM9FnC E+rdXQPndNF/cvs6VHjKL2LP2DeTvqcVajTRHrtSiRY8LfUrR6wIS8KSR9SPj3dwMqjr 8XLQ== X-Gm-Message-State: APjAAAWghSVcJy6BHPN7+QP6+IAEoGnc7SmZRSaY3lEtXeiN3rx7sMdW w8IwmLZIDGJNY33i2VvqXzwOft24VRWVAdsAdXk= X-Google-Smtp-Source: APXvYqwkRMdCttXckovWHN7p4tDwQiqdpY+rAnbqox/AkHNhDwBFN09fYEfvtgk7PkfiXgL+KVnZ43UhPRazinuR1tc= X-Received: by 2002:a05:6512:499:: with SMTP id v25mr34837078lfq.9.1575062524673; Fri, 29 Nov 2019 13:22:04 -0800 (PST) MIME-Version: 1.0 References: <20191127203055.GC18175@pfrc.org> In-Reply-To: <20191127203055.GC18175@pfrc.org> From: Greg Mirsky Date: Fri, 29 Nov 2019 13:21:53 -0800 Message-ID: Subject: Re: Update to BFD over VXLAN To: Jeffrey Haas Cc: rtg-bfd WG , bfd-chairs@ietf.org, Martin Vigoureux Content-Type: multipart/alternative; boundary="000000000000484449059882d28d" Archived-At: 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: Fri, 29 Nov 2019 21:22:08 -0000 --000000000000484449059882d28d Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for your suggestion. I've updated the text and will publish the new version of the draft shortly. Regards, Greg On Wed, Nov 27, 2019 at 12:26 PM Jeffrey Haas wrote: > Greg, > > > On Wed, Nov 20, 2019 at 10:41:46AM +0800, Greg Mirsky wrote: > > Dear All, > > as was decided at the meeting, an explanation of using an address from > the > > Internal host loopback interface address range has been added into the > > Security Consideration section: > > NEW TEXT: > > This document recommends using an address from the Internal host > > loopback addresses range as the destination IP address in the inner > > IP header. Using such address prevents the forwarding of the > > encapsulated BFD control message by a transient node in case the > > VXLAN tunnel is broken as according to [RFC1812]: > > > > A router SHOULD NOT forward, except over a loopback interface, any > > packet that has a destination address on network 127. A router > > MAY have a switch that allows the network manager to disable these > > checks. If such a switch is provided, it MUST default to > > performing the checks. > > I think the text above is largely right. > > There's a slight level of ambiguity since elsewhere in the document, we > don't use the RFC 4379 notation, i.e. 0:0:0:0:0:FFFF:127/104: > > > : > : loopback addresses (127/8 range for IPv4 and > : 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). > > I think if you explicitly call it out in the 7400 format, we may be all > set. > > -- Jeff > --000000000000484449059882d28d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for your suggestion. I've updat= ed the text and will publish the new version of the draft shortly.

Regards,
Greg

On Wed, Nov 27, 2019 at 12:26= PM Jeffrey Haas <jhaas@pfrc.org&g= t; wrote:
Greg,<= br>

On Wed, Nov 20, 2019 at 10:41:46AM +0800, Greg Mirsky wrote:
> Dear All,
> as was decided at the meeting, an explanation of using an address from= the
> Internal host loopback interface address range has been added into the=
> Security Consideration section:
> NEW TEXT:
>=C2=A0 =C2=A0 This document recommends using an address from the Intern= al host
>=C2=A0 =C2=A0 loopback addresses range as the destination IP address in= the inner
>=C2=A0 =C2=A0 IP header. Using such address prevents the forwarding of = the
>=C2=A0 =C2=A0 encapsulated BFD control message by a transient node in c= ase the
>=C2=A0 =C2=A0 VXLAN tunnel is broken as according to [RFC1812]:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0A router SHOULD NOT forward, except over a l= oopback interface, any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet that has a destination address on net= work 127.=C2=A0 A router
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY have a switch that allows the network ma= nager to disable these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0checks.=C2=A0 If such a switch is provided, = it MUST default to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0performing the checks.

I think the text above is largely right.

There's a slight level of ambiguity since elsewhere in the document, we=
don't use the RFC 4379 notation, i.e. 0:0:0:0:0:FFFF:127/104:


:
: loopback addresses (127/8 range for IPv4 and
:=C2=A0 =C2=A0 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).

I think if you explicitly call it out in the 7400 format, we may be all set= .

-- Jeff
--000000000000484449059882d28d-- From nobody Fri Nov 29 13:23:34 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 826EE120048; Fri, 29 Nov 2019 13:23:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-vxlan-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <157506260742.4822.4701890558658938125@ietfa.amsl.com> Date: Fri, 29 Nov 2019 13:23:27 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 21:23:27 -0000 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-09.txt Pages : 11 Date : 2019-11-29 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-09 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/ From nobody Fri Nov 29 13:28:15 2019 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 7C11A120058; Fri, 29 Nov 2019 13:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8QgdryPSb7Mz; Fri, 29 Nov 2019 13:28:12 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 1DB1C120048; Fri, 29 Nov 2019 13:28:12 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id s22so14289745ljs.7; Fri, 29 Nov 2019 13:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oC0zocTLfaJUXY34tJaWSDvJhQPC19WeXu2wXnvmtfk=; b=ALurwD34EmIotqdI8+N1mzSx7rvIdVYSuupYgbwut93HUYLdUaVv3zrs68/T1rwnP7 OczTQv9ZTyyZ60iz5R7gbFpB9jfOv2n+QzrzRZAoAQvRUe7FY5DoU1OntdNT1N5b04sG GE9E+sb+dHUqGD0r+cq1CJtZDnrfdvn+jmOjuDqTwVcwUc1vIaWKMD0NJjIpST6GUD8R yPwsXNtfLElaAJuZutCT7GdJFV3Mc5mEMmw9QwmgqN9skLes3WtRMzqEGxEsf0R0ZdDJ Y3hO3tbHAOLfOfGT+rmh5TQe1u5P1xnTekqUU2gfavC8PIPIVN2Wf50rret4+sHUqsPa kACQ== 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; bh=oC0zocTLfaJUXY34tJaWSDvJhQPC19WeXu2wXnvmtfk=; b=kpkHpjw+aTxI8i1hGblNvDjsUlrFSRgfnqdetEh8x7NwwmSz80ucCI8r4L1mgUa4WR gd8YKahpdgHNqU11nDwwWrb+Nkn19IDROZVxsa/kwGpiiQ+Fp43qHRhhicv5qy8PLKty hiDbH1bZSnSUVQPFVEMEO7b11bq+mNTfFcGaPiB6YuBmhiA/POC/lLv1dHDOk22OWNQQ rFLOz5w+6adWi5ipi6WuLB8AZly7beGPF1YFVoJ1d6mWEydWpVs/WQTM+sQiawDeBepP GKWH67aANuMszM1pAB3HXbzIxACiYWqXDSU7dCU/DQ3/j/og/H6XlpRx3ddxVKjzz3GY O5XQ== X-Gm-Message-State: APjAAAVwPrQgTQ4SOrQ9BcNm1uBkI+p/g9bqHuJ4nFlyZW6DmnZXoEhs WiXz6zCHgYp9Aw3f3QYiftyphtGFTjRImLkPNgN7jA== X-Google-Smtp-Source: APXvYqyaNFlrld59KNTBE3YNZqldgbyIN5W6QMmgLcnC4qkSkFMaNVrV4mqQVhYT5vLpPNbdNEH0kENFVgCGwv1JAzw= X-Received: by 2002:a2e:978d:: with SMTP id y13mr2217865lji.103.1575062890044; Fri, 29 Nov 2019 13:28:10 -0800 (PST) MIME-Version: 1.0 References: <157506260768.4822.2596294333502316658.idtracker@ietfa.amsl.com> In-Reply-To: <157506260768.4822.2596294333502316658.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 29 Nov 2019 13:27:58 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-vxlan-09.txt To: rtg-bfd WG , bfd-chairs@ietf.org, Martin Vigoureux Content-Type: multipart/alternative; boundary="0000000000000f621e059882e824" Archived-At: 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: Fri, 29 Nov 2019 21:28:14 -0000 --0000000000000f621e059882e824 Content-Type: text/plain; charset="UTF-8" Dear All, this version includes the update to the Security Considerations section regarding the use of an internal host loopback address as the destination IP address of the inner IP header, as discussed at the meeting in Singapore. Regards, Greg ---------- Forwarded message --------- From: Date: Fri, Nov 29, 2019 at 1:23 PM Subject: New Version Notification for draft-ietf-bfd-vxlan-09.txt To: Gregory Mirsky , Mallik Mudigonda < mmudigon@cisco.com>, Sudarsan Paragiri , Vengada Prasad Govindan , Santosh Pallagatti < santosh.pallagatti@gmail.com> A new version of I-D, draft-ietf-bfd-vxlan-09.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-bfd-vxlan Revision: 09 Title: BFD for VXLAN Document date: 2019-11-29 Group: bfd Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-09 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels forming up an overlay network. 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 --0000000000000f621e059882e824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
this version includes the update to the Secu= rity Considerations section regarding the use of an internal host loopback = address as the destination IP address of the inner IP header, as discussed = at the meeting in Singapore.

Regards,
Gr= eg

= ---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Nov 29, 2019 at 1:23 PM
Subject: New Version Notifica= tion for draft-ietf-bfd-vxlan-09.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigond= a <mmudigon@cisco.com>, Sud= arsan Paragiri <sudarsan.225@g= mail.com>, Vengada Prasad Govindan <venggovi@cisco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>



A new version of I-D, draft-ietf-bfd-vxlan-09.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A009
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2019-11-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-09.txt<= /a>
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-bfd-vxlan-09
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-09

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in point-to-point Virtual eXtensible = Local
=C2=A0 =C2=A0Area Network (VXLAN) tunnels forming up an overlay network.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--0000000000000f621e059882e824--
On Tue, Nov 5, 2019= at 5:59 PM Dinesh Dutt <didutt@gmai= l.com> wrote:
Anoop
,

I fear 0 may not be supported by a bunch of existing switching silicon.

Dinesh
On Nov 6, 2019, 7:08 AM +0530, Anoop Ghan= wani <anoop@a= lumni.duke.edu>, wrote:
Greg,

What is the resistance to getting an address assigned by IANA?

(Apologies if I missed the discussion.)

Also not sure about the value of the statement=C2=A0
>>
An implementation MAY use VNI number 1 as the
   default value for the Management VNI.
>>
What prompted this, and if we need to recommend a value, why not 0?

Thanks,
Anoop

On Tue, Nov 5, 2019 at 4:29 PM Dinesh= Dutt <didutt@gmai= l.com> wrote:
I understand Greg. Maybe suggest a value, rather than recommend it? It= s just to reduce configuration. The key parts are to not change the existin= g VXLAN forwarding behavior and ensure that BFD between VTEPs doesn't l= eak to tenants (which typically don't exist in case of a management VNI= ).=C2=A0

Dinesh

On Tue, Nov 5, 2019 at 11:24 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Dinesh,
I agree that using a particular MAC over the Management VNI will minim= ize configuration and thus reduce the operator's headache. I'm conc= erned that adding RECOMMENDATION to use the specific MAC address over the M= anagement VNI comes very close to requesting the assignment of the MAC for = the Management VNI.

Regards,
Greg

On Mon, Nov 4, 2019 at 9:36 AM Dinesh= Dutt <didutt@gmai= l.com> wrote:
I didn't suggest the use of a multicast MAC, any MAC would be fine= in the management VNI since there can be no tenant VMs on a management VNI= . I was recommending specifying a unicast MAC.

Santosh, as I mentioned to Joel, I don't want to add additional fo= rwarding requirements--such as VNI-specific behavior--in VXLAN. The existin= g mechanism is sufficient for the case we're discussing here. Just pick= a MAC in management VNI for the sake of configuration simplicity.

Dinesh

On Mon, Nov 4, 2019 at 8:30 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:

On Mon, Nov 4, 2019 at 5:14 AM Santos= h P K <santosh.pallagatti@gmail.com> wrote:
Anoop,
=C2=A0 =C2=A0Thanks for your comments. For non-managment VNI why do we= need to have multicast MAC address for backward=C2=A0compatibility for exi= sting implementation=C2=A0or there are any use cases such that we can avoid= learning of remote end VTEP?=C2=A0

Thanks
Santosh P K=C2=A0

On Mon, Nov 4, 2019 at 10:41 AM Anoop= Ghanwani <an= oop@alumni.duke.edu> wrote:
Hi Joel,

In that case I would propose the following text:

"Destination MAC: If the BFD ses= sion is not using the=C2=A0Manageme= nt VNI,
the destination MAC address MUST be the ad= dress
associated with the destination VTEP.=C2= =A0 If the BFD session uses
the Management VNI, it may use any MAC address, since use of the=C2=A0=
Management VNI ensures that these packets will never be forwarded to a= VM.
The MAC address may be configured, or it m= ay be learned via
a control plane protocol. The details of h= ow the MAC address
to be used is obtained are outside the sco= pe of this document."

That said, for non-Management VNI, do= we want to allow for flexibility
for an implementation to use a multic= ast MAC of their choosing?=C2=A0 If so, we
should probably add a sentence for that too.

Thanks,
Anoop


On Sun, Nov 3, 2019 at 7:52 PM Joel M= . Halpern <jmh@= joelhalpern.com> wrote:
Anoop, I think I at least= am misunderstanding you.
If one is using the management VNI, as I understand it there is no
tenant.=C2=A0 So there are no tenant MAC addresses.=C2=A0 (This is one of t= he
reasons I like using the management VNI.)


Yours,
Joel

On 11/3/2019 10:32 PM, Anoop Ghanwani wrote:
> Hi Greg,
>
> In the case of the management VNI, are we trying to say that we would<= br> > allow any MAC address other than a tenant MAC address?=C2=A0 I would s= uggest
> some more text be added to clarify what is permitted on the management=
> VLAN.=C2=A0 Assuming that we want to allow any MAC other than a tenant= MAC,
> how does this get enforced?=C2=A0 In other words, what can be done for= the
> network to protect itself if a sender violates this?
>
> One possible answer is to restrict the MAC address that may be used to=
> one that is owned by the VTEP or a "agreed on" multicast MAC= address.=C2=A0
> That means the receiver only needs to validate for those, and just
> treats everything else as data.
>
> Also, for interoperability purposes, it would be best to specify that = a
> receiver MUST be able to handle any valid MAC address for the BFD
> session, while a sender MAY pick any of them.
>
> Thanks,
> Anoop
>
> On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com
> <mailto:= gregimirsky@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Anoop,
>=C2=A0 =C2=A0 =C2=A0thank you for your comments and questions. Please f= ind my notes
>=C2=A0 =C2=A0 =C2=A0in-line tagged GIM>>.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <<= a href=3D"mailto:anoop@alumni.duke.edu" target=3D"_blank">anoop@alumni.duke= ..edu
>=C2=A0 =C2=A0 =C2=A0<mailto:anoop@alumni.duke.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Greg,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A few comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The draft has nits, specifically arou= nd the way the IPv6 address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is written.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In section 4:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packet MUST be encapsulated ->=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD packets MUST be encapsulated
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC: This MUST NOT be of = one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ad= dresses.=C2=A0 The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as= sociated with the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0co= nfigured, or it MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Th= e details of how the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sc= ope of this document.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It looks like we have removed the opt= ion of using a well-known
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA assigned MAC.=C2=A0 If so, why i= s the above a MAY and not a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST?=C2=A0 What else can it be?=C2= =A0 One interpretation is that it can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be anything unicast, or multicast, as= long as it's not a tenant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAC.=C2=A0 Is that the intent?=C2=A0 = If so, it would be better to state it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that way.=C2=A0 Also (and this is pur= ely editorial), I think it would
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be better if the first sentence above= were moved to the end of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the paragraph.
>
>=C2=A0 =C2=A0 =C2=A0GIM>> Yes, you're right, we've remove= d that option and have removed
>=C2=A0 =C2=A0 =C2=A0the request to IANA. I also agree that " MAY b= e the address
>=C2=A0 =C2=A0 =C2=A0associated with the destination VTEP" is not t= he right choice of
>=C2=A0 =C2=A0 =C2=A0normative language. On the other hand, MUST might b= e too restrictive
>=C2=A0 =C2=A0 =C2=A0if BFD session is using the Management VNI. Would t= he following
>=C2=A0 =C2=A0 =C2=A0update address your concern:
>=C2=A0 =C2=A0 =C2=A0OLD TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= This MUST NOT be of one of tenant's MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addresses.=C2=A0= The destination MAC address MAY be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The MAC address MAY be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured, or i= t MAY be learned via a control plane protocol.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The details of h= ow the MAC address is obtained are outside the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope of this do= cument.
>=C2=A0 =C2=A0 =C2=A0NEW TEXT:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination MAC:= If the BFD session is not using the
>=C2=A0 =C2=A0 =C2=A0Management VNI,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the destination = MAC address MUST be the address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with = the destination VTEP.=C2=A0 The Destination MAC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be one = of the tenant's MAC addresses.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The MAC address MAY be= configured, or it MAY be learned via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a control plane protoc= ol. The details of how the MAC address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is obtained are outsid= e the scope of this document.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"The inner Ethernet frame carryi= ng the BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Control packet- has the= following format:"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Extraneous '-' after packet.<= br> >
>=C2=A0 =C2=A0 =C2=A0GIM>> Thanks, will do that too.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Anoop
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, Nov 1, 2019 at 10:53 AM Greg = Mirsky
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>= ;> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dear All,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the new version include= s updates resulting from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussions of Joel'= ;s comments in the RtrDir review of BFD
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0over VXLAN draft, comme= nts from Anoop, and Dinesh. On behalf
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of editors, thank you f= or your constructive comments and for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sharing your expertise,= all much appreciated.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I hope we've addres= sed all your comments, and the draft can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proceed further.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---------- Forwarded me= ssage ---------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0From: <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org<= /a>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Fri, Nov 1, 2019 = at 10:45 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: New Version No= tification for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan-08= ..txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: Gregory Mirsky <= gregimirsky@gmai= l.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:gregimirsky@gmail.com>= ;>, Mallik Mudigonda
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mmudigon@cisco.com <mailto:mmudigon@cisco.com&= gt;>, Sudarsan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paragiri <sudarsan.225@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:sudarsan.225@gmail.com&= gt;>, Vengada Prasad Govindan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<venggovi@cisco.com <mailto:venggovi@cisco.com&= gt;>, Santosh
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pallagatti <santosh.pallagat= ti@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:santosh.pallagatti@gm= ail.com>>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, d= raft-ietf-bfd-vxlan-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully s= ubmitted by Greg Mirsky and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-vxlan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 BFD for VXLAN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 20= 19-11-01
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 bfd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-0= 8.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-vxlan-0= 8
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This docu= ment describes the use of the Bidirectional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Forwarding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Detection= (BFD) protocol in point-to-point Virtual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eXtensible Local
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Area Netw= ork (VXLAN) tunnels forming up an overlay network.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may= take a couple of minutes from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized vers= ion and diff are available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://= tools.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat >
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3