From nobody Sat Dec 1 08:44:32 2018 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 5BA91126CC7; Sat, 1 Dec 2018 08:44:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HQqMkBCrtkFG; Sat, 1 Dec 2018 08:44:28 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 AF4781241F6; Sat, 1 Dec 2018 08:44:27 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id c19-v6so7707110lja.5; Sat, 01 Dec 2018 08:44: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; bh=tJu/jWtWdkKkxDeIfY/bR/RlJhaY/ZdCLukb4e/mU0Y=; b=Hg7O6AKm1mDaWN6fhpTa1REcdpCvsvcYiyyQAKZVPLOTkT+eQL/dwUhqfGRGXHtY7y zIuhjJykR3w2C+zsis2PXPk6qV62TUITd7X9ybBlHNueqYrgeQBkiMhMZ1xdXB1r7rZE JxhJa7rpUh51dO4aCYzdKpIK75sdVfk93myXY3Iabab+aArNfl3dgCa28PrRxuXiUSdF SgKx0wA+YLtKRsuSsc6N9kVgfpHLhqs999yEQ+iBKsbLCjCqdo5NvsrSKnm7PLq2aJB9 CSoFehwMmSc6fsDDLISCei0uquUpqi1k+YYHeGVQ1DiPGR8C8gjaUrqLh+j8vZbDkBNd 9kQw== 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=tJu/jWtWdkKkxDeIfY/bR/RlJhaY/ZdCLukb4e/mU0Y=; b=A+eVkgnYpC2WT/w5IJqNc6DmmnIqYxj54ZVJxifEbIWNlT6zYpLOPlljq9Q9R5tLPg Iv2hCJBQIka5Q/hWSJCVlFGYQk9nzW3EFbfZjnn6Xj6+4zNkStN5XWK82d5aGAGx/54E TURk0ojxXWl2TLRuiILyWhaHNbSx1vyI8JhOSOzHwFMEe4SEVdwKx8JM/4tm6Bj0CJ17 qepChq8qXsA07WfE7vCc93TONC/PpEWUxcddREQNxlCinbxW69he8ZomBu6xFgnlphGG 5miqw+D955uuovrezQhTteX9GtTaSWrc0H1c5djWqW++OvgGFyypxHGA8KT0XbA1YnMN vi6g== X-Gm-Message-State: AA+aEWb9xR2Mmvy9v/3GZXg3+tCxZKO3QMHFZInVBMvsmUPDQipvsJD7 BL9gRztVoKuYKfK2LZhOGH24olN6TzvaE4ecws0zGA== X-Google-Smtp-Source: AFSGD/WUCsfOHt7x1yh2UTmJ4WYnerAHfr06itNF7HGWG7Hze1lWK0ha7cs+MY1Oe4j6CEeimohmpT9lKNL2g7EIQEM= X-Received: by 2002:a2e:851a:: with SMTP id j26-v6mr4700759lji.163.1543682665443; Sat, 01 Dec 2018 08:44:25 -0800 (PST) MIME-Version: 1.0 References: <154364704613.27556.7795104384190302181.idtracker@ietfa.amsl.com> In-Reply-To: <154364704613.27556.7795104384190302181.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Sat, 1 Dec 2018 08:44:14 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-bfd-p2mp-vrrp-use-case-03.txt To: rtg-bfd WG , RTGWG Content-Type: multipart/alternative; boundary="000000000000eb7906057bf8a02e" 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, 01 Dec 2018 16:44:30 -0000 --000000000000eb7906057bf8a02e Content-Type: text/plain; charset="UTF-8" Dear All, that is a technical refresh of the draft that describes an extension to VRRP that allows the Master to bootstrap p2mp BFD that can be used by VRRP Backup router(s) to monitor the Master and have sub-second convergence of the protocol. As I understand, RTGWG WG still maintains the open WG AP for the draft. Much appreciate your comments on the draft and the ongoing WGAP to both lists. Regards, Greg ---------- Forwarded message --------- From: Date: Fri, Nov 30, 2018 at 10:50 PM Subject: New Version Notification for draft-mirsky-bfd-p2mp-vrrp-use-case-03.txt To: Gregory Mirsky , Jeff Tantsura < jefftant.ietf@gmail.com> A new version of I-D, draft-mirsky-bfd-p2mp-vrrp-use-case-03.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-p2mp-vrrp-use-case Revision: 03 Title: Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Virtual Router Redundancy Protocol (VRRP) Use Case Document date: 2018-11-30 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-mirsky-bfd-p2mp-vrrp-use-case-03.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/ Htmlized: https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-p2mp-vrrp-use-case Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-p2mp-vrrp-use-case-03 Abstract: This document discusses use of Bidirectional Forwarding Detection (BFD) for multi-point networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second Master convergence and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798. 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 --000000000000eb7906057bf8a02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
that is=C2=A0a technical refresh of the draf= t that describes an extension to VRRP that allows the Master to bootstrap p= 2mp BFD that can be used by VRRP Backup router(s) to monitor the Master and= have sub-second convergence of the protocol. As I understand, RTGWG WG sti= ll maintains the open WG AP for the draft. Much appreciate your comments on= the draft and the ongoing WGAP to both lists.

Reg= ards,
Greg

---= ------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Fri, Nov 30, 2018 at 10:50 PM
Subject: New Version Notificati= on for draft-mirsky-bfd-p2mp-vrrp-use-case-03.txt
To: Gregory Mirsky <= ;gregimirsky@gmail.com>, Je= ff Tantsura <jefftant.ietf@gm= ail.com>



A new version of I-D, draft-mirsky-bfd-p2mp-vrrp-use-case-03.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-mirsky-bfd-p2mp-vrrp-us= e-case
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bidirectional Forwarding Detection= (BFD) for Multi-point Networks and Virtual Router Redundancy Protocol (VRR= P) Use Case
Document date:=C2=A0 2018-11-30
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mirsky-bfd-p2mp-vrrp-use-= case-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://= datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ie= tf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-03
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://d= atatracker.ietf.org/doc/html/draft-mirsky-bfd-p2mp-vrrp-use-case
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-bfd-p2mp-vrrp-use-case-0= 3

Abstract:
=C2=A0 =C2=A0This document discusses use of Bidirectional Forwarding Detect= ion
=C2=A0 =C2=A0(BFD) for multi-point networks to provide Virtual Router Redun= dancy
=C2=A0 =C2=A0Protocol (VRRP) with sub-second Master convergence and defines= the
=C2=A0 =C2=A0extension to bootstrap point-to-multipoint BFD session.

=C2=A0 =C2=A0This draft updates RFC 5798.




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

--000000000000eb7906057bf8a02e-- From nobody Wed Dec 5 09:13:28 2018 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 55221130ECA; Wed, 5 Dec 2018 09:13:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-bfd-multipoint-active-tail@ietf.org, Reshad Rahman , bfd-chairs@ietf.org, rrahman@cisco.com, rtg-bfd@ietf.org Subject: Ben Campbell's No Objection on draft-ietf-bfd-multipoint-active-tail-10: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154402999633.31877.2654337291739275640.idtracker@ietfa.amsl.com> Date: Wed, 05 Dec 2018 09:13:16 -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: Wed, 05 Dec 2018 17:13:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-bfd-multipoint-active-tail-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point. From nobody Sat Dec 8 18:23:53 2018 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 C0C6B130DC1; Sat, 8 Dec 2018 18:23:52 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xK9J9Ymdl2T6; Sat, 8 Dec 2018 18:23:49 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 DF73612F1AC; Sat, 8 Dec 2018 18:23:48 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id c19-v6so6671385lja.5; Sat, 08 Dec 2018 18:23:48 -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=SrIPt198yLQDo0dnkGVywIBhHtqSotHGZ709ifhpyAo=; b=bL0rc3VDx1SOmzvaIlhEX8TqjZUg+HWUkU53VpGJyqS6vbxANxpkGYFM1c5CqaFeS1 CmkgJQH2T9eIFUDbf5OB1QroSmH5hVMAwi9m5xmcltjv0zwY6GTcSu/WevYnmOOvp6kZ 2anOslD2Bh0fvciv/hzlwj2j/N8bt4B0O4olvxeg4XNGEpWIUl0nyr9p2IXZrsce9RkI 7U1pAJkXXt9mU2Ar69j58FSm7I7EKoujS1cVQeGTNBbSs/TSm4L7rcCgETbbyKFWA8WF 9DsBDHobI1C5OJKkL+6HHsIRyQopMbG0iWGXFDPA+7d5w84OzoUVeqKI59y/kpNC6Ktm n1Rw== 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=SrIPt198yLQDo0dnkGVywIBhHtqSotHGZ709ifhpyAo=; b=j10nNiNradoxaZR4CLGW1DwHAla+3ZeLnXwWiFoxS7Kod5nJ1nV2xErB74VjlVqZ07 Z64wsGh03PrlwfQGfXoonIAXtY5N+tB0UhsbbPwcHUx93zbqTZhBUrQpA/ydFsJgpMly Xrexwiq8wc9s+BJlwdWSzuSydvh7iXwEH9+c/yNArInLOuigCntpgF5UAc85XZp8OAdy HNo2PBlaKD3oOihOvAw7MvPhLSXQEj1sVrGvB7o7yWqLALNpWKC87NvxQMnmiCQ89dpS JiH7biwPYS6Ce1ykVxTrZYfIM5Xqxc5wbSF0n4kD4uyWF5HPhAngb9m2DOoNiaOCejpT spXg== X-Gm-Message-State: AA+aEWakW46NByW7ehSGAVRaReDov6vq6XUarisPVSx4EyEjhGVomKbM CFPFlSRPA7fC83wPH9TlGIoU2kd0erylwJDTk1k= X-Google-Smtp-Source: AFSGD/UyiuolSk1FFNZqO6CoDWegNMrPa85o4FmS+ZawcDZrJz74yy2gEl3brBATvZZaMgTNUUX+p0o41hl8p4yBoZs= X-Received: by 2002:a2e:92ca:: with SMTP id k10-v6mr4258481ljh.63.1544322226966; Sat, 08 Dec 2018 18:23:46 -0800 (PST) MIME-Version: 1.0 References: <15CB10A6-6AF4-460F-A71D-56F28D9D7784@cisco.com> <5BFD9FF7-DBF8-48E6-BF45-1D29AFB90034@cisco.com> <81371D06-2A1A-480F-B65D-FAF04E408A04@cisco.com> <88AC4C8C-C945-4B46-BA8D-42EDAA2EBEC8@cisco.com> In-Reply-To: <88AC4C8C-C945-4B46-BA8D-42EDAA2EBEC8@cisco.com> From: Greg Mirsky Date: Sat, 8 Dec 2018 18:23:35 -0800 Message-ID: Subject: Re: [mpls] MPLS WG adoption call for draft-mirsky-mpls-p2mp-bfd To: "Carlos Pignataro (cpignata)" Cc: mpls-chairs@ietf.org, mpls@ietf.org, rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000c1d525057c8d8921" 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: Sun, 09 Dec 2018 02:23:53 -0000 --000000000000c1d525057c8d8921 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, to answer your question the motivation of this work is to define the applicability of draft-ietf-bfd-multipoint and draft-ietf-bfd-multipoint-active-tail, including bootstrapping a BFD session, to p2mp MPLS LSPs. Regards, Greg On Sat, Nov 24, 2018 at 10:52 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi Greg, > > On Nov 21, 2018, at 7:00 AM, Greg Mirsky wrote: > > Hi Carlos, > apologies for the prolonged silence. Thank you for your consideration of > the proposed new text and the acknowledgment that we're converging. > > > I do not recall (nor can I find below) any text from me with any > acknowledgement of convergence. That is a misrepresentation. > > I do see you (not I) wrote below again (=E2=80=9CGlad that we're convergi= ng.=E2=80=9D) I > do not see the basis for that. > > I did tell Loa I saw progress (not convergence) but also that my main > question remained, in my humble opinion, unsatisfactorily answered. > > > Please find the new comments in-line tagged GIM3>>. > > Regards, > Greg > > On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> [Greg, Loa, responding to both on this single email reply] >> >> Hi, Loa, >> >> On Nov 6, 2018, at 1:49 PM, Loa Andersson wrote: >> >> Carlos, >> >> Since the a wg adoption poll I read your comments as that we are doing >> progress, and that we can address the rest during the wg process, >> correct? >> >> >> I agree we are making progress, thank you. Most questions can be >> addressed later, but only the very first question goes to the heart of a= n >> adoption poll. If we can close on that, the rest can be addressed later >> (note the same question is related also to the last question.) >> >> /Loa >> >> >> Hi, Greg, >> >> Thank you very much for your responses =E2=80=94 please see inline. >> >> On Nov 6, 2018, at 7:18 PM, Greg Mirsky wrote: >> >> Hi Carlos, >> thank you for your consideration of my responses. Glad that we're >> converging. Please find additional notes in-line tagged GIM2>>. >> >> Regards, >> Greg >> >> On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Hi Greg, >>> >>> Many thanks for your response and suggestions! Please see inline. >>> >>> On Nov 2, 2018, at 6:13 AM, Greg Mirsky wrote: >>> >>> Hi Carlos, >>> thank you for your comments. Please find my notes, answers in-line >>> tagged GIM>>. >>> >>> Regards, >>> Greg >>> >>> On Thu, Oct 25, 2018 at 8:47 PM Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> >>>> Hi, >>>> >>>> Cc BFD WG >>>> >>>> It would be useful to understand the use case motivation or >>>> applicability of this draft, other than it can be done. >>>> >>> GIM>> The motivation can be seen in the following (from another draft >>> that discusses OAM over G-ACh: >>> In some >>> environments, the overhead of extra IP/UDP encapsulations may be >>> considered as overburden and make using more compact G-ACh >>> encapsulation attractive. >>> Will add text in the draft. >>> >>> >>> CMP: Thank you very much. This is a good start, although it would be >>> useful to add precision into which environments specifically, and the >>> burden comparison between IP/UDP and G-ACh. >>> >> GIM2>> Thank you for agreeing to this, and I've added the text in the >> working verion. Will work on improving the text in the meantime. >> >> >> CMP: Sorry if I was not clear. Like I said, this is a good start and >> probably necessary (but not sufficient) text. >> >> CMP: Which environments specifically? At this point, the scope and targe= t >> of the work is not clear to me. That was my question. Is this for MPLS-T= P >> P2MP? If so, the underlying seems to have stalled: >> https://datatracker.ietf.org/doc/rfc7167/referencedby/ >> CMP: I think these two questions should be answered: 1. What specific >> environments? 2. How current solutions do not solve it (i.e., what is an= d >> can we quantify the overburden)? >> > GIM3>> Andy Malis has pointed to the requirements for proactive OAM, > particularly monitoring path continuity, listed in Section 4.1 RFC 4687. > > > Just to understand =E2=80=94 the basis of this work is Requirements from = RFC 4687 > from the year 2006? > > These are not specific to MPLS-TP but to OAM over p2mp MPLS LSP. The > following text has been added to the Security Considerations section in t= he > recenly uploaded -04 version of the draft: > > > Adding scope and rationale for some work in the Security Considerations > does not seem like the right sequentiality to set the stage. > > Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in > section 4.1 [RFC4687] to avoid congestion in the control plane or the > data plane caused by the rate of generating BFD control packets. An > operator SHOULD consider the amount of extra traffic generated by > p2mp BFD when selecting the interval at which the MultipointHead will > transmit BFD control packets. Also, the operator MAY consider the > size of the packet the MultipointHead transmits periodically as using > IP/UDP encapsulation adds up to 28 octets, which is more than 50% of > BFD control packet length, comparing to G-ACh encapsulation. > >> >> >>> >>>> I=E2=80=99m also increasingly concerned by confusing scope and definit= ion of >>>> specifications. >>>> >>>> For example: >>>> >>>> https://tools.ietf.org/html/draft-mirsky-mpls-p2mp-bfd-04#section-3.2 >>>> >>>> 3.2. Non-IP Encapsulation of Multipoint BFD >>>> >>>> Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP MUST use >>>> Generic Associated Channel (G-ACh) Label (GAL) [RFC5586] at the >>>> bottom of the label stack followed by Associated Channel Header >>>> (ACH). Channel Type field in ACH MUST be set to BFD CV [RFC6428]. >>>> >>>> >>>> First, there=E2=80=99s no definition for non-IP BFD in RFC 5586 =E2=80= =94 only in RFC >>>> 5885. >>>> >>> GIM>> RFC 5586 defined the use of GAL. I think that this reference is >>> appropriate. I agree that the second reference should be to RFC 5885, n= ot >>> RFC 6428. Will make the change. >>> >>> >>> CMP: Thank you. However, RFC 5885 is in the context of PW VCCV =E2=80= =94 is >>> there a missing definition in the specs for BFD over G-ACh generically? >>> >> GIM2>> I think that the following quote from RFC 5586 set the >> relationship between Channel Type field in PW ACH and G-ACh: >> Channel Types for the Associated Channel Header are allocated from >> the IANA "PW Associated Channel Type" registry [RFC4446]. >> I understand that that there's one and only one registry and channel >> values are equally applicable to PW ACH and G-ACh. And full name of the >> registry now is MPLS Generalized Associated Channel (G-ACh) Types >> (including Pseudowire Associated Channel Types). >> >> >> CMP: That is correct. I was curious as to whether additional control >> plane is needed for this support. >> >> >>> Second, the specification in RFC 6428 applies to MPLS Transport Profile >>>> only. NOT for MPLS, and explicitly NOT for P2MP! >>>> >>>> https://tools.ietf.org/html/rfc6428#section-1 >>>> >>>> This document specifies the BFD extension and behavior to satisfy t= he >>>> CC, proactive CV monitoring, and the RDI functional requirements fo= r >>>> both co-routed and associated bidirectional LSPs. Supported >>>> encapsulations include Generic Associated Channel Label (GAL) / >>>> Generic Associated Channel (G-ACh), Virtual Circuit Connectivity >>>> Verification (VCCV), and UDP/IP. Procedures for unidirectional >>>> point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for >>>> further study. >>>> >>>> >>>> So, no, this does not work. >>>> >>>> RFC 6428 does not have scope for P2MP. >>>> And RFC 5586 does not specify anything for BFD. Instead, what needs to >>>> be cited (appropriately and expanded) is RFC 5885 >>>> >>> GIM>> RFC 5586 specifies the use of GAL and G-ACh and the reference is >>> used in this context. >>> >>> >>> CMP: This is the same comment as above. >>> >>> >>>> https://tools.ietf.org/html/rfc6428#section-4 >>>> RFC 5884 - BFD CC in UDP/IP/LSP >>>> RFC 5885 - BFD CC in G-ACh >>>> >>> GIM>> I'd point that it is for p2p BFD CC, and p2mp BFD uses different >>> from p2p BFD method to demultiplex BFD control packets. >>> >>> >>> >>> CMP: Apologies I did not understand this response. >>> >> GIM2>> Apologies for sending partial explanation. P2MP BFD cannot use >> Your Discriminator field to demultiplex the recieved BFD control packet. >> BFD for Multipoint Networks defines the special procedure that requires = the >> use of Source ID. When the encapsulation of BFD control packet does not >> include IP/UDP header, the Source ID can be provided as Source MEP-ID TL= V >> in MPLS-TP BFD CV. This draft proposes the new IP Address TLV for that. >> Thus I have to correct myself and re-state the earlier text in the draft >> that the value in the Channel Type filed of G-ACh must be MPLS-TP CV >> (0x0023). >> >> >> CMP: I understood you said above that the reference to RFC6428 was >> incorrect. >> >> CMP: Now, just to understand the approach: >> >> CMP: Are you suggesting that the IP header is not used with BFD and >> instead a new TLV (of which information structure?) carries the IP addre= ss >> that you removed before? Seems like a musical-chairs arrangement of the >> data. I may very likely be missing something. Apologies in advance if th= at >> is the case. >> >> CMP: Also, is the applicability MPLS-TP? What is the normative reference >> for MPLS-TP P2MP? >> > GIM3>> I should have explained why I think that MPLS-TP CV message > (0x0023) type is more suitable than BFD Control, PW-ACH encapsulation > (without IP/UDP Headers) (0x0007). The latter includes only the BFD contr= ol > packet while the format of the former includes Source MEP-ID TLV that > immediately follows the BFD control packet. And with the new proposed IP > Address TLV the 0x0023 G-ACh channel works better for p2mp BFD over p2mp > MPLS LSP. Alternative, of course, would be to define the new G-ACh type f= or > p2mp BFD over p2mp MPLS LSP. > >> >> > Thanks =E2=80=94 I appreciate that a lot of packet formats could be drawn= . My > question is really regarding motivation for the work (the vague =E2=80=9C= In some > environments=E2=80=9D) > > Thanks, > > =E2=80=94 Carlos. > > Thanks, >> >> Carlos. >> >> >>> CMP: Thanks again for considering the comment to improve the document. >>> >>> Thanks, >>> >>> Carlos. >>> >>> >>> RFC 5085 - UDP/IP in G-ACh >>>> MPLS-TP - CC/CV in GAL/G-ACh or G-ACh >>>> >>>> >>>> >>>> Thanks, >>>> >>>> =E2=80=94 Carlos Pignataro >>>> >>>> On Oct 13, 2018, at 4:24 PM, Greg Mirsky wrote= : >>>> >>>> Dear WG Chairs, et al., >>>> as the author of the BFD for Multipoint Networks over >>>> Point-to-Multi-Point MPLS LSP (draft-mirsky-mpls-p2mp-bfd) I would lik= e to >>>> ask you to consider WG adoption call of the draft. The document addres= ses >>>> non-IP encapsulation of p2mp BFD over MPLS LSP that may be useful if t= he >>>> overhead of IP, particularly IPv6, encapsulation is the concern. The b= ase >>>> specification of BFD for Multipoint Networks is at this time in IESG L= C. >>>> >>>> Regards, >>>> Greg >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>>> >>>> >>> >> > --000000000000c1d525057c8d8921 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
to answer your question the motivation of t= his work is to define the applicability of draft-ietf-bfd-multipoint and dr= aft-ietf-bfd-multipoint-active-tail, including bootstrapping a BFD session,= to p2mp MPLS LSPs.

Regards,
Greg
<= /div>
On Sat, Nov 24, 2018 a= t 10:52 AM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi Greg,

On Nov 21, 2018, at 7:00 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Carlos,
apologies for the prolonged silence. Thank you for your consideration = of the proposed new text and the acknowledgment that we're converging.<= /div>

I do not recall (nor can I find below) any text from me with any ackno= wledgement of convergence. That is a misrepresentation.

I do see you (not I) wrote below again (=E2=80=9CGlad that we're c= onverging.=E2=80=9D) I do not see the basis for that.

I did tell Loa I saw progress (not convergence) but also that my main = question remained, in my humble opinion, unsatisfactorily answered.


Please find the new comments in-line tagged GIM3>>.

Regards,
Greg

On Wed, Nov 7, 2018 at 8:52 PM Carlos Pignataro (cpignata)= <cpignata@cisco= .com> wrote:
[Greg, Loa, responding to both on this single email reply]

Hi, Loa,

On Nov 6, 2018, at 1:49 PM, Loa Andersson <loa@pi.nu> wrote:

Carlos,

Since the a wg adoption poll I read your comments as that we are doing
progress, and that we can address the rest during the wg process,
correct?


I agree we are making progress, thank you. Most questions can be addre= ssed later, but only the very first question goes to the heart of an adopti= on poll. If we can close on that, the rest can be addressed later (note the= same question is related also to the last question.)

/Loa

Hi, Greg,

Thank you very much for your responses =E2=80=94 please see inline.

On Nov 6, 2018, at 7:18 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
thank you for your consideration of my responses. Glad that we're = converging. Please find additional notes in-line tagged GIM2>>.

Regards,
Greg

On Tue, Nov 6, 2018 at 12:11 AM Carlos Pignataro (cpignata= ) <cpignata@cisc= o.com> wrote:
Hi Greg,

Many thanks for your response and suggestions! Please see inline.

On Nov 2, 2018, at 6:13 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
thank you for your comments. Please find my notes, answers in-line tag= ged GIM>>.

Regards,
Greg

On Thu, Oct 25, 2018 at 8:47 PM Carlos Pignataro (cpignata= ) <cpignata@cisc= o.com> wrote:
Hi,

Cc BFD WG

It would be useful to understand the use case motivation or applicabil= ity of this draft, other than it can be done.
GIM>>=C2=A0 The motivation can be seen in the following (from an= other draft that discusses OAM over G-ACh:
=C2=A0 In some
=C2=A0 =C2=A0environments, the overhead of extra IP/UDP encapsulations= may be
=C2=A0 =C2=A0considered as overburden and make using more compact G-AC= h
=C2=A0 =C2=A0encapsulation attractive.
Will add text in the draft.

CMP: Thank you very much. This is a good start, although it would be u= seful to add precision into which environments specifically, and the burden= comparison between IP/UDP and G-ACh.
GIM2>> Thank you for agreeing to this, and I've added the te= xt in the working verion. Will work on improving the text in the meantime.<= /div>

CMP: Sorry if I was not clear. Like I said, this is a good start and p= robably necessary (but not sufficient) text.

CMP: Which environments specifically? At this point, the scope and tar= get of the work is not clear to me. That was my question. Is this for MPLS-= TP P2MP? If so, the underlying seems to have stalled:=C2=A0
https://datatracker.ietf.org/doc/rfc7167/referencedby/
CMP: I think these two questions should be answered: 1. What specific = environments? 2. How current solutions do not solve it (i.e., what is and c= an we quantify the overburden)?
GIM3>> Andy Malis has pointed to the requirements for proactive = OAM, particularly monitoring path continuity, listed in Section 4.1 RFC 468= 7.

Just to understand =E2=80=94 the basis of this work is Requirements fr= om RFC 4687 from the year 2006?

These are not specific to MPLS-TP but to OAM over p2mp MPLS LSP. The f= ollowing text has been added to the Security Considerations section in the = recenly uploaded -04 version of the draft:

Adding scope and rationale for some work in the Security Consideration= s does not seem like the right sequentiality to set the stage.

=C2=A0 =C2=A0Also, BFD for p2mp MPLS LSP MUST follow the requirements = listed in
=C2=A0 =C2=A0section 4.1 [RFC4687] to avoid congestion in the control = plane or the
=C2=A0 =C2=A0data plane caused by the rate of generating BFD control p= ackets.=C2=A0 An
=C2=A0 =C2=A0operator SHOULD consider the amount of extra traffic gene= rated by
=C2=A0 =C2=A0p2mp BFD when selecting the interval at which the Multipo= intHead will
=C2=A0 =C2=A0transmit BFD control packets.=C2=A0 Also, the operator MA= Y consider the
=C2=A0 =C2=A0size of the packet the MultipointHead transmits periodica= lly as using
=C2=A0 =C2=A0IP/UDP encapsulation adds up to 28 octets, which is more = than 50% of
=C2=A0 =C2=A0BFD control packet length, comparing to G-ACh encapsulati= on.



I=E2=80=99m also increasingly concerned by confusing scope and definit= ion of specifications.

For example:


3.2.=C2=A0 Non-IP Encapsulation of Multipoint BFD

=C2=A0 =C2=A0Non-IP encapsulation for multipoint BFD over p2mp MPLS LS= P MUST use
=C2=A0 =C2=A0Generic Associated Channel (G-ACh) Label (GAL) [RFC5586] = at the
=C2=A0 =C2=A0bottom of the label stack followed by Associated Channel = Header
=C2=A0 =C2=A0(ACH).=C2=A0 Channel Type field in ACH MUST be set to BFD= CV [RFC6428].


First, there=E2=80=99s no definition for non-IP BFD in RFC 5586 =E2=80= =94 only in RFC 5885.
GIM>> RFC 5586 defined the use of GAL. I think that this referen= ce is appropriate. I agree that the second reference should be to RFC 5885,= not RFC 6428. Will make the change.

CMP: Thank you. However, RFC 5885 is in the context of PW VCCV =E2=80= =94 is there a missing definition in the specs for BFD over G-ACh generical= ly?
GIM2>> I think that the following quote from RFC 5586 set the re= lationship between Channel Type field in PW ACH and G-ACh:
=C2=A0 =C2=A0 Channel Types for the Associated Channel Header are allo= cated from
=C2=A0 =C2=A0 the IANA "PW Associated Channel Type" registry= [RFC4446].=C2=A0
I understand that that there's one and only one registry and chann= el values are equally applicable to PW ACH and G-ACh. And full name of the = registry now is=C2=A0MPLS Generalized Associated Channel (G-ACh) Types (inc= luding Pseudowire Associated Channel Types).

CMP: That is correct. I was curious as to whether additional control p= lane is needed for this support.


Second, the specification in RFC 6428 applies to=C2=A0MPLS Transport P= rofile only. NOT for MPLS, and explicitly NOT for P2MP!


=C2=A0 =C2=A0This document specifies the BFD extension and behavior to= satisfy the
=C2=A0 =C2=A0CC, proactive CV monitoring, and the RDI functional requi= rements for
=C2=A0 =C2=A0both co-routed and associated bidirectional LSPs.=C2=A0 S= upported
=C2=A0 =C2=A0encapsulations include Generic Associated Channel Label (= GAL) /
=C2=A0 =C2=A0Generic Associated Channel (G-ACh), Virtual Circuit Conne= ctivity
=C2=A0 =C2=A0Verification (VCCV), and UDP/IP.=C2=A0 Procedures for uni= directional
=C2=A0 =C2=A0point-to-point (P2P) and point-to-multipoint (P2MP) LSPs = are for
=C2=A0 =C2=A0further study.


So, no, this does not work.

RFC 6428 does not have scope for P2MP.
And RFC 5586 does not specify anything for BFD. Instead, what needs to= be cited (appropriately and expanded) is RFC 5885
GIM>> RFC 5586 specifies the use of GAL and G-ACh and the refere= nce is used in this context.

CMP: This is the same comment as above.


=C2=A0 =C2=A0 =C2=A0=C2=A0RFC 5884 - BFD CC in UDP/IP/LSP
=C2=A0 =C2=A0 =C2=A0 RFC 5885 - BFD CC in G-ACh=C2=A0
GIM>> I'd point that it is for p2p BFD CC, and p2mp BFD uses= different from p2p BFD method to demultiplex BFD control packets.=C2=A0


CMP: Apologies I did not understand this response.
GIM2>> Apologies for sending partial explanation. P2MP BFD canno= t use Your Discriminator field to demultiplex the recieved BFD control pack= et. BFD for Multipoint Networks defines the special procedure that requires= the use of Source ID. When the encapsulation of BFD control packet does not include IP/UDP header, the So= urce ID can be provided as Source MEP-ID TLV in MPLS-TP BFD CV. This draft = proposes the new IP Address TLV for that. Thus I have to correct myself and= re-state the earlier text in the draft that the value in the Channel Type filed of G-ACh must be MPLS-TP CV= (0x0023).

CMP: I understood you said above that the reference to RFC6428 was inc= orrect.=C2=A0

CMP: Now, just to understand the approach:=C2=A0

CMP: Are you suggesting that the IP header is not used with BFD and in= stead a new TLV (of which information structure?) carries the IP address th= at you removed before? Seems like a musical-chairs arrangement of the data.= I may very likely be missing something. Apologies in advance if that is the case.

CMP: Also, is the applicability MPLS-TP? What is the normative referen= ce for MPLS-TP P2MP?
GIM3>> I should have explained why I think that MPLS-TP CV messa= ge (0x0023) type is more suitable than BFD Control, PW-ACH encapsulation (w= ithout IP/UDP Headers) (0x0007). The latter includes only the BFD control p= acket while the format of the former includes Source MEP-ID TLV that immediately follows the BFD control= packet. And with the new proposed IP Address TLV the 0x0023 G-ACh channel = works better for p2mp BFD over p2mp MPLS LSP. Alternative, of course, would= be to define the new G-ACh type for p2mp BFD over p2mp MPLS LSP.


Thanks =E2=80=94 I appreciate that a lot of packet formats could be dr= awn. My question is really regarding motivation for the work (the vague =E2= =80=9C In some environments=E2=80=9D)

Thanks,

=E2=80=94 Carlos.

Thanks,

Carlos.


CMP: Thanks again for considering the comment to improve the document.=

Thanks,

Carlos.


=C2=A0 =C2=A0 =C2=A0 RFC 5085 - UDP/IP in G-ACh
=C2=A0 =C2=A0 =C2=A0 =C2=A0MPLS-TP - CC/CV in GAL/G-ACh or G-ACh



Thanks,

=E2=80=94 Carlos Pignataro

On Oct 13, 2018, at 4:24 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear WG Chairs, et al.,
as the author of the BFD for Multipoint Networks over Point-to-Multi-P= oint MPLS LSP (draft-mirsky-mpls-p2mp-bfd) I would like to ask you to consi= der WG adoption call of the draft. The document addresses non-IP encapsulat= ion of p2mp BFD over MPLS LSP that may be useful if the overhead of IP, particularly IPv6, encapsula= tion is the concern. The base specification of BFD for Multipoint Networks = is at this time in IESG LC.

Regards,
Greg
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--000000000000c1d525057c8d8921-- From nobody Mon Dec 10 14:10:46 2018 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 C9DF0131281 for ; Mon, 10 Dec 2018 14:10: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 F9Wu3XK59qkT for ; Mon, 10 Dec 2018 14:10:43 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 919F4131280 for ; Mon, 10 Dec 2018 14:10:43 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 146961E2D7; Mon, 10 Dec 2018 17:09:54 -0500 (EST) Date: Mon, 10 Dec 2018 17:09:53 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20181210220953.GA6053@pfrc.org> References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> 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: Mon, 10 Dec 2018 22:10:45 -0000 Greg, Apologies for the long delay in reply. On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: > I respectfully ask to summarize the comments that were shared with you and > to publish them to the WG without naming the authors. Tersely: - The document is not addressing fundamental issues. - It is encumbered by IPR. - Observed list traffic regarding question on the feature was not satisfactorily converging. > And I have to admit that I don't understand your suggestion to use the > Errata. The procedures to apply the Demand mode described in the draft are > not in contradiction with RFC 5880, so the suggestion to use Errata > surprised me. I will respond on my own analysis in detail hopefully this week. I am awaiting the resolution of a particular bit of correspondence before determining the tenor of my response. -- Jeff From nobody Tue Dec 11 00:52:28 2018 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 CF67712F18C for ; Tue, 11 Dec 2018 00:52:26 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 qmKcVNc0j4sz for ; Tue, 11 Dec 2018 00:52:25 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 DBE0912777C for ; Tue, 11 Dec 2018 00:52:24 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id v1-v6so12256707ljd.0 for ; Tue, 11 Dec 2018 00:52:24 -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=K3cS6pPfWZxJbEfWPE24ZZSGZ0cG6hmebDA8p3XNBHs=; b=Lqc1eBRpWWo3QtYIfA9IflHNiLjjKYRLrWERSrR253CoTjhXGZgPtuaypzessF2UcZ TZLRqbjCKZnp6wLXVkIsCOgHrDTibe4ncobhoN2+VlrOWP292hf+XslxA/EQaTEEYWgS LdmQ3yehnURZaQZCR5qmu3MCDSRiJhmbA4QFyFa5/F9MuoLvNCML/aATxW3+WgZImcK4 +Tvs9kB2gTT9DXbf1udulm4bfOwBDuqMa9nLERhjtuCyVOE+9nU7rU38yX79put1eN4C uvjLYdL1hxW3jXVm++L7BmmJ0YnalqnnBYPcWJKB/ZhWZAXVbGCYU1QymPakg6p49la8 iFfQ== 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=K3cS6pPfWZxJbEfWPE24ZZSGZ0cG6hmebDA8p3XNBHs=; b=iuz3i04qddDScpTmM+nNT8djVMGYgpv+P8KXi+g8q6i2hVeWCYUmCDx0ZrFmBo5Na0 /V+RdAnS+4dDKaSjNkLAVgsRURD80/X6ORPkU6QbFz94dx80y9NbmooImrbRv8vvyuC/ Es79lEE1kDU58homF+gmUPMY8MfKuWccDL0Eo5zrsedLQjDeKZwXtwkqX3tyNts6NL8r WORMf9hTME9+pLfEKuPDQvWRIb5cCfoXL23trFj0N/uW1BNsGQwQ5dtNnlppgIwzc6CW wV/cjKWjli70DwacwZX+03mH7flmhPgLvJnavojgPgqZY4lsmI2uzBAMhLPofih7xqDn 0Y0Q== X-Gm-Message-State: AA+aEWZiurrfQNYutgEOAk7DQQ9aPXGBq6mBQn3MNinafUIWVppMElOw NR2qoEBECknTJIk8nUngENzCswhvtNyNEF/tZY5Z7g== X-Google-Smtp-Source: AFSGD/XRwdCYoS5Q7bitqD+fvjgDl9G7FuEk9Ubp6+ETCG1wieydCimnTjfZNOHEox+PwZwY5yL72Dlbqcbv0BB7ZV8= X-Received: by 2002:a2e:4819:: with SMTP id v25-v6mr10006895lja.2.1544518342919; Tue, 11 Dec 2018 00:52:22 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> In-Reply-To: <20181210220953.GA6053@pfrc.org> From: Greg Mirsky Date: Tue, 11 Dec 2018 08:52:11 +0000 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000002dc8fa057cbb33b4" 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, 11 Dec 2018 08:52:27 -0000 --0000000000002dc8fa057cbb33b4 Content-Type: text/plain; charset="UTF-8" Hi Jeff, et al., thank you for the update. I wanted to clarify the second item, the question related to the IPR Disclosure. The first disclosure used the "covenant not to assert" language. The second was to only update the filing status, not the licensing terms. I believe I've clarified that at the time of asking for WG AP. I was informed that there's the update to IPR Disclosure on this work submitted that restores the "covenant not to assert" language. I hope that can be taken into consideration by you and Reshad. Regards, Greg On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas wrote: > Greg, > > Apologies for the long delay in reply. > > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: > > I respectfully ask to summarize the comments that were shared with you > and > > to publish them to the WG without naming the authors. > > Tersely: > - The document is not addressing fundamental issues. > - It is encumbered by IPR. > - Observed list traffic regarding question on the feature was not > satisfactorily converging. > > > And I have to admit that I don't understand your suggestion to use the > > Errata. The procedures to apply the Demand mode described in the draft > are > > not in contradiction with RFC 5880, so the suggestion to use Errata > > surprised me. > > I will respond on my own analysis in detail hopefully this week. I am > awaiting the resolution of a particular bit of correspondence before > determining the tenor of my response. > > -- Jeff > --0000000000002dc8fa057cbb33b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff, et al.,
thank you for the update. I wanted to= clarify the second item, the question related to the IPR Disclosure. The f= irst disclosure used the "covenant not to assert" language. The s= econd was to only update the filing status, not the licensing terms. I beli= eve I've clarified that at the time of asking for WG AP. I was informed= that there's the update to IPR Disclosure on this work submitted that = restores the "covenant not to assert" language. I hope that can b= e taken into consideration by you and Reshad.

Rega= rds,
Greg

On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

Apologies for the long delay in reply.=C2=A0

On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> I respectfully ask to summarize the comments that were shared with you= and
> to publish them to the WG without naming the authors.

Tersely:
- The document is not addressing fundamental issues.
- It is encumbered by IPR.
- Observed list traffic regarding question on the feature was not
=C2=A0 satisfactorily converging.

> And I have to admit that I don't understand your suggestion to use= the
> Errata. The procedures to apply the Demand mode described in the draft= are
> not in contradiction with RFC 5880, so the suggestion to use Errata > surprised me.

I will respond on my own analysis in detail hopefully this week.=C2=A0 I am=
awaiting the resolution of a particular bit of correspondence before
determining the tenor of my response.

-- Jeff
--0000000000002dc8fa057cbb33b4-- From nobody Wed Dec 12 06:02:53 2018 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 A48F7130DD6; Wed, 12 Dec 2018 06:02:40 -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, 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 XaLD1Q257L84; Wed, 12 Dec 2018 06:02:39 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C2E63130DC0; Wed, 12 Dec 2018 06:02:36 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id BF2881E2D7; Wed, 12 Dec 2018 09:01:46 -0500 (EST) Date: Wed, 12 Dec 2018 09:01:46 -0500 From: Jeffrey Haas To: bess@ietf.org Cc: rtg-bfd@ietf.org Subject: BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited Message-ID: <20181212140145.GA22828@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: Wed, 12 Dec 2018 14:02:47 -0000 BESS Working Group members, https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 BFD has finished working group last call on BFD for Vxlan and is about ready to request publication as an RFC. A last minute comment suggested that we should consider inviting comment from your working group for expertise. We will be leaving the last call open until December 21 to leave time for final comments. -- Jeff (for BFD) From nobody Thu Dec 13 05:53:38 2018 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 DF674127133 for ; Thu, 13 Dec 2018 05:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 E-V-g92DozPG for ; Thu, 13 Dec 2018 05:53:33 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 14A441252B7 for ; Thu, 13 Dec 2018 05:53:33 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id v5so1614629lfe.7 for ; Thu, 13 Dec 2018 05:53:32 -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=FgCweWx2v6znNlMyfpP9U29HsMb36QJPb7EfbVcAIb8=; b=V61YOjcyFCGDiHdfg3aGEFoc0/3Rl2xQ8SadjhL8rx/FkhBAcZ7buEdgHBCrLZ/eDQ HhPyWnq/CRXw3Olix8agRZdUR9ALQNUhVleZLUAThp4D9TI6RBtO/7ytbvayJJ9j6buA jc4BsJwutiGfkvAdeJaVTeLDHivABdIBwbfsw0ajE6oaS78THq/MNMx1Cck+TcgrVsqH z0tjZArJOx/jzUZZPgcCzOcVks20eD7Cf/rKmBKqLz34sz91gRdY5ZESF2iOcoo0HLfO PLAheliK6STR8LAdqWRhL0aL8UoQYWk8jluOnSsrjWO8MjE7je9ngy3/qfXV5sfdiRbL syCw== 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=FgCweWx2v6znNlMyfpP9U29HsMb36QJPb7EfbVcAIb8=; b=rAop2KyFHm7twmutAwvZOrzkubthgTFwI/1+7tSzVlu7n/qNzTQ/Tjbk4EPbojCKH1 Y6WTnk8AsA/Wsv43NraJwrRbvlhHAMolg8m+fgksOse4di2dzSTDBtiOvSwMAc8nMySG QqQhTncXm8aoOvmJeyyq74S+RZSwIvcoQvXskeBgMMf2uClFcHycuzw9yBrItmanijnC sDkxCcI2RahlHc4jk1m5gof2AVSsHY3X9ymHploTk9iGpMV8L+6e5EDEN493qSblAqrn 4oGAbEl96TdOQVyWbdrwT2r6C4WPHJpNQjFxuqGTeVXwTgkOdzj2eYFb4/OFGQxMmeZI z+9Q== X-Gm-Message-State: AA+aEWYLMJE0OJSQTfwO8mJzYyx/azjk3IVkUZYHhvvhWmcAlZKIOiz3 77tL0t+y0PpFuAwJZCzWQgRsnZ4jwx8w3Nhs6bU= X-Google-Smtp-Source: AFSGD/XYSc2poIHfm8OZTbEG1DWoGK90zOFrButl+JIgo1lLXnQNiKQcCN6dt2AGGJ21rV7Rf8GCRCXmoPkjYKPCPnQ= X-Received: by 2002:a19:26ce:: with SMTP id m197mr13758618lfm.23.1544709210978; Thu, 13 Dec 2018 05:53:30 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> In-Reply-To: From: Greg Mirsky Date: Thu, 13 Dec 2018 13:53:19 +0000 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: rtg-bfd WG , Martin Vigoureux Content-Type: multipart/alternative; boundary="000000000000cd3f98057ce7a3f4" 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: Thu, 13 Dec 2018 13:53:36 -0000 --000000000000cd3f98057ce7a3f4 Content-Type: text/plain; charset="UTF-8" Hi Jeff, et al., I now would like to comment on the point of "not satisfactory convergence" of discussion. I assume that this is related to the discussion started by the message addressed to Xiao Min, not to the author of the draft. Oddly enough. But I've responded nevertheless. Two questions were raised and both were explained: - BFD Demand mode may be used to monitor the continuity of a path in one direction and we have two specifications, draft-ietf-bfd-multipoint and draft-ietf-bfd-multipoint-active-tail, that describe how that can be done without and with notification to the ingress BFD node; - indeed, it is the liveliness of the path between the BFD systems that are monitored. These were the questions and, in my opinion, both got answered. And now I got to wonder what other questions need to be addressed? Plans to implement? In my experience, evaluating a draft in WG AP I, explicitly or not, answer to these questions: - whether the document is coherent; - is it likely to be actually useful in operational networks; - is the document technically sound? And I cannot find any unaddressed question that falls into any of these categories. Much appreciate comments from BFD WG Chairs. Regards, Greg On Tue, Dec 11, 2018 at 8:52 AM Greg Mirsky wrote: > Hi Jeff, et al., > thank you for the update. I wanted to clarify the second item, the > question related to the IPR Disclosure. The first disclosure used the > "covenant not to assert" language. The second was to only update the filing > status, not the licensing terms. I believe I've clarified that at the time > of asking for WG AP. I was informed that there's the update to IPR > Disclosure on this work submitted that restores the "covenant not to > assert" language. I hope that can be taken into consideration by you and > Reshad. > > Regards, > Greg > > On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas wrote: > >> Greg, >> >> Apologies for the long delay in reply. >> >> On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: >> > I respectfully ask to summarize the comments that were shared with you >> and >> > to publish them to the WG without naming the authors. >> >> Tersely: >> - The document is not addressing fundamental issues. >> - It is encumbered by IPR. >> - Observed list traffic regarding question on the feature was not >> satisfactorily converging. >> >> > And I have to admit that I don't understand your suggestion to use the >> > Errata. The procedures to apply the Demand mode described in the draft >> are >> > not in contradiction with RFC 5880, so the suggestion to use Errata >> > surprised me. >> >> I will respond on my own analysis in detail hopefully this week. I am >> awaiting the resolution of a particular bit of correspondence before >> determining the tenor of my response. >> >> -- Jeff >> > --000000000000cd3f98057ce7a3f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff, et al.,
I now would like to comment on the po= int of "not satisfactory convergence" of discussion. I assume tha= t this is related to the discussion started by the=C2=A0message=C2=A0addressed to Xiao Min, not to the author of the draft.= Oddly enough. But I've responded nevertheless. Two questions were rais= ed and both were explained:
- BFD Demand mode may be used to moni= tor the continuity of a path in one direction and we have two specification= s, draft-ietf-bfd-multipoint and draft-ietf-bfd-multipoint-active-tail, tha= t describe how that can be done without and with notification to the ingres= s BFD node;
- indeed, it is the liveliness=C2=A0of the path betwe= en the=C2=A0BFD systems that=C2=A0are=C2=A0monitored.=C2=A0
These were the quest= ions and, in my opinion, both got answered. And now I got to wonder what ot= her questions need to be addressed? Plans to implement? In my experience, e= valuating a draft in WG AP I, explicitly or not, answer to these questions:=
  • whether the document is coherent;
  • is it likely t= o be actually useful in operational networks;
  • is the document techn= ically sound?=C2=A0=C2=A0
And I cannot find any unaddres= sed=C2=A0question that falls into any of these categories.
Much appreci= ate comments from BFD WG Chairs.

Regards,
Greg

On Tue, De= c 11, 2018 at 8:52 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Jeff, et al.,
thank you fo= r the update. I wanted to clarify the second item, the question related to = the IPR Disclosure. The first disclosure used the "covenant not to ass= ert" language. The second was to only update the filing status, not th= e licensing terms. I believe I've clarified that at the time of asking = for WG AP. I was informed that there's the update to IPR Disclosure on = this work submitted that restores the "covenant not to assert" la= nguage. I hope that can be taken into consideration by you and Reshad.

Regards,
Greg

On Mon, Dec 10, 2018 at 10:10 PM Jeffrey Haas = <jhaas@pfrc.org&= gt; wrote:
Greg,=

Apologies for the long delay in reply.=C2=A0

On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> I respectfully ask to summarize the comments that were shared with you= and
> to publish them to the WG without naming the authors.

Tersely:
- The document is not addressing fundamental issues.
- It is encumbered by IPR.
- Observed list traffic regarding question on the feature was not
=C2=A0 satisfactorily converging.

> And I have to admit that I don't understand your suggestion to use= the
> Errata. The procedures to apply the Demand mode described in the draft= are
> not in contradiction with RFC 5880, so the suggestion to use Errata > surprised me.

I will respond on my own analysis in detail hopefully this week.=C2=A0 I am=
awaiting the resolution of a particular bit of correspondence before
determining the tenor of my response.

-- Jeff
--000000000000cd3f98057ce7a3f4-- From nobody Thu Dec 13 06:28:57 2018 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 03984124BF6; Thu, 13 Dec 2018 06:28:51 -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-multipoint-19.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <154471133094.2555.14166290940611750040@ietfa.amsl.com> Date: Thu, 13 Dec 2018 06:28:51 -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: Thu, 13 Dec 2018 14:28:51 -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 Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Greg Mirsky Filename : draft-ietf-bfd-multipoint-19.txt Pages : 22 Date : 2018-12-13 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. This document updates RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-multipoint-19 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-19 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 Tue Dec 18 09:26:05 2018 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 5DB04130EB8; Tue, 18 Dec 2018 09:25:56 -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-mirsky-bfd-mpls-demand-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <154515395632.5595.14716151406552318351@ietfa.amsl.com> Date: Tue, 18 Dec 2018 09:25:56 -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: Tue, 18 Dec 2018 17:25:56 -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 in Demand Mode over Point-to-Point MPLS LSP Author : Greg Mirsky Filename : draft-mirsky-bfd-mpls-demand-04.txt Pages : 5 Date : 2018-12-18 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-04 https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-04 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 Tue Dec 18 10:08:49 2018 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 F3AB3131127; Tue, 18 Dec 2018 10:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ow2fX20kLE9o; Tue, 18 Dec 2018 10:08:38 -0800 (PST) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 30859130EC6; Tue, 18 Dec 2018 10:08:38 -0800 (PST) Received: by mail-vs1-f42.google.com with SMTP id n10so10526599vso.13; Tue, 18 Dec 2018 10:08:38 -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=T2P7M2ABhO5oOYBpISs79oYTENgbs3cwpEPm4HSM518=; b=VtAa7lvldRsY8x/RVnByVAGQxrx/e/mz8Cx4QxccUJ1ay4JnGaW+bfdSfhZxxLMVIp gkR0pF42MMq0Z6I62AYBJkTXRc2wjoCkf6J3SM6SFhAPatjM3kyM1HXVN6PiG/yh6Obr S/iuIOqTUjCYmRx+OlWdhotnEodpWvdpWn0Gm+UxQmm0CV8/2TM+ULLSp6ElCyEa/sPs p9cC5r5V5A4ce2gNyVqRu9RI5JxeZ+nF7JqMw9kftx77lx/5Rmt1SOVM6feAV3w21Ox0 spN7l+U0goDPJAOMBE2GEMDdQFfL1ckkpd92qX7BeUH5AGZ2/D7Gh2vu3G1OTw4mhPzY jshA== X-Gm-Message-State: AA+aEWboUU3u3Ttp7216cTDzg83vMIRcLJS5481bFckIQjMcJVviVrg2 1Ox7uUCVppqlDymBNTkSkWY/fS+r8kllq3VM0v0= X-Google-Smtp-Source: AFSGD/WUoV9O8hmkHTbhjOy9UrYAx0ntwCbs9/1QXdymctcwLvBfLAgrDb59j4ZjY8VH17w5z4j9t3fs0bIPG/5+xOY= X-Received: by 2002:a67:f851:: with SMTP id b17mr8764557vsp.23.1545156516717; Tue, 18 Dec 2018 10:08:36 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: <20181212140145.GA22828@pfrc.org> From: Anoop Ghanwani Date: Tue, 18 Dec 2018 10:08:23 -0800 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: Jeffrey Haas Cc: bess@ietf.org, rtg-bfd@ietf.org Content-Type: text/plain; charset="UTF-8" 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, 18 Dec 2018 18:08:41 -0000 I would change the introduction to the following to mention the use of VXLAN by BGP EVPN. Thanks, Anoop == "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an encapsulation scheme that allows building an overlay network by decoupling the address space of the attached virtual hosts from that of the network. One use of VXLAN is in data centers interconnecting VMs of a tenant. VXLAN addresses requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment, discussed in section 3 of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. Another use is as an encapsulation for EVPN [RFC 8365]. In the remainder of this document the terms VM and End Station are used interchangeably. In the absence of a router in the overlay, a VM can communicate with another VM only if they are on the same VXLAN segment. VMs are unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VXLAN Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs (hypervisor/TOR) are responsible for encapsulating and decapsulating frames exchanged among VMs. On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas wrote: > > BESS Working Group members, > > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 > > BFD has finished working group last call on BFD for Vxlan and is about ready > to request publication as an RFC. A last minute comment suggested that we > should consider inviting comment from your working group for expertise. > > We will be leaving the last call open until December 21 to leave time for > final comments. > > -- Jeff (for BFD) > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess From nobody Tue Dec 18 12:17:22 2018 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 DFA86130F19; Tue, 18 Dec 2018 12:17: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_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 lC5hEuM0MUo8; Tue, 18 Dec 2018 12:17:13 -0800 (PST) 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 74D89130F06; Tue, 18 Dec 2018 12:17:12 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id z13so13246900lfe.11; Tue, 18 Dec 2018 12:17: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 :cc; bh=h00a9xfJ5NRiyWzhMEbyvEMr2a7vO5Eolch+fVWOKZg=; b=qmZLxft8Wx73Zr0mUcfJSVnUoYeu2qWbycXCoT5yaRJEY73u1VeJQK0LiNAHZpfKW8 x0i30hasQ6IMqj8XsHsBRQP3VwpPIT9ibRCpOJscNGFfXGIfxEaBycqg2bzsYTFvruuC O/YgPUc88k3UsNlfeurdd/wxfqQhENcYHVvuMZOK9B9lHFcYihLLdmJLQTj4xU1W3bV6 VefWY3OyM389M1aXJGtLdOwcFPJ0k7OnuGUkg/7vJvGTNpQuChwQwRTxYbrhdBY4dlya 2w+AEK1wRpe2MGLYK8n9VzJhJVt7m93e0Sr0ZL4OhZf6WY/ic5O3coR7Pd5OpTcplASZ h69A== 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=h00a9xfJ5NRiyWzhMEbyvEMr2a7vO5Eolch+fVWOKZg=; b=Sq3Hr/WzaqBOX4CIiNPOKTso+nmF3x27kw3ZYO3KvzzlIxE5DWdpA1pfCOqjoZ7N4t /fe86EN7C501JyKvaJxssrgPD2GY68egq6g0ZpYIlO45UxofReG3eFr4YRNgHRhGfBtz reOEo4xe/u1IT8vkcR6RSsEmjKjxnAkKi8SAVuCLHmKVHQCuUtjRSYzmtq48eOaCXkXF yY5/4qwNU72WmGqiFgATiICZcfQ1q06gVkGjvkeF864/I/Mbn7djDmVN+QdYb262Kbxc vNpjVGAvbPm2CHanmLStyo2fR9BISGMPurSt3qwFq0P1PMvdPkMejp5lk1UphWHBsUNQ f2og== X-Gm-Message-State: AA+aEWZMc+7Q9z3FxMNeujO8T8XZerAlPDnFQuvA0bjb97TxFT4jYtVB uTOQq8a9gaiCvV6RLpaz2sZMD+2HcVLcW98qEI/W4g== X-Google-Smtp-Source: AFSGD/UYiFuQaj0ZRCsp40yBAEcDUvqvxTUU8VKiOZFLbNgQgW5vJ+Qz/grMVVIg0CuclfFFl/8Mz7d8D6il7QTxpbE= X-Received: by 2002:a19:c203:: with SMTP id l3mr10398599lfc.113.1545164230521; Tue, 18 Dec 2018 12:17:10 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: From: Greg Mirsky Date: Tue, 18 Dec 2018 20:16:59 +0000 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: Anoop Ghanwani Cc: Jeffrey Haas , rtg-bfd WG , BESS Content-Type: multipart/alternative; boundary="0000000000001479d5057d5195d6" 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, 18 Dec 2018 20:17:15 -0000 --0000000000001479d5057d5195d6 Content-Type: text/plain; charset="UTF-8" Hi Anoop, thank you for your comments and the suggested text. To clarify the extent of the update, would the following accurately reflect the change in Introduction you're proposing: OLD TEXT: VXLAN is typically deployed in data centers interconnecting virtualized hosts of a tenant. VXLAN addresses requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment, discussed in section 3 [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. NEW TEXT: One use of VXLAN is in data centers interconnecting VMs of a tenant. VXLAN addresses requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment, discussed in section 3 of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. Another use is as an encapsulation for EVPN [RFC 8365]. In the remainder of this document the terms VM and End Station are used interchangeably. If my understanding of the proposed update is correct, I'd be glad to use it (adding RFC 8365 as Informational reference). Should note that in the draft we never used "End Station". Perhaps the last sentence is not required. What do you think? Regards, Greg On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani wrote: > I would change the introduction to the following to mention the use of > VXLAN by BGP EVPN. > > Thanks, > Anoop > > == > > "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides > an encapsulation scheme that allows building an overlay network by > decoupling the address space of the attached virtual hosts from that > of the network. > > One use of VXLAN is in data centers interconnecting > VMs of a tenant. VXLAN addresses requirements of the > Layer 2 and Layer 3 data center network infrastructure in the > presence of VMs in a multi-tenant environment, discussed in section 3 > of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. > Another use is as an encapsulation for EVPN [RFC 8365]. > > In the remainder of this document the terms VM and End Station > are used interchangeably. > > In the absence of a router in the overlay, a VM can communicate with > another VM only if they are on the same VXLAN segment. VMs are > unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VXLAN > Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs (hypervisor/TOR) are > responsible for encapsulating and decapsulating frames exchanged > among VMs. > > On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas wrote: > > > > BESS Working Group members, > > > > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 > > > > BFD has finished working group last call on BFD for Vxlan and is about > ready > > to request publication as an RFC. A last minute comment suggested that > we > > should consider inviting comment from your working group for expertise. > > > > We will be leaving the last call open until December 21 to leave time for > > final comments. > > > > -- Jeff (for BFD) > > > > _______________________________________________ > > BESS mailing list > > BESS@ietf.org > > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > --0000000000001479d5057d5195d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anoop,
thank you for your comments= and the suggested text. To clarify the extent of the update, would the fol= lowing accurately reflect the change in Introduction you're proposing:<= /div>
OLD TEXT:
=C2=A0 =C2=A0VXLAN is typically deployed= in data centers interconnecting
=C2=A0 =C2=A0virtualized hosts o= f a tenant.=C2=A0 VXLAN addresses requirements of the
=C2=A0 =C2= =A0Layer 2 and Layer 3 data center network infrastructure in the
= =C2=A0 =C2=A0presence of VMs in a multi-tenant environment, discussed in se= ction 3
=C2=A0 =C2=A0[RFC7348], by providing Layer 2 overlay sche= me on a Layer 3 network.
NEW TEXT:
=C2=A0 One use= of VXLAN is in data centers interconnecting
=C2=A0 VMs of a tenant.=C2= =A0 VXLAN addresses requirements of the
=C2=A0 =C2=A0Layer 2 and Layer 3= data center network infrastructure in the
=C2=A0 =C2=A0presence of VMs = in a multi-tenant environment, discussed in section 3
=C2=A0 =C2=A0of [R= FC7348], by providing Layer 2 overlay scheme on a Layer 3 network.
=C2= =A0 =C2=A0Another use is as an encapsulation for EVPN [RFC 8365].

= =C2=A0 In the remainder of this document the terms VM and End Station
= =C2=A0 are used interchangeably.=C2=A0

If my under= standing of the proposed update is correct, I'd be glad to use it (addi= ng RFC 8365 as Informational reference).=C2=A0 Should note that in the draf= t=C2=A0we never=C2=A0used "End Station". Perhaps the last sentenc= e is not required.

What do you think?

Regards,
Greg

On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanw= ani <anoop@alumni.duke.edu&= gt; wrote:
I wou= ld change the introduction to the following to mention the use of
VXLAN by BGP EVPN.

Thanks,
Anoop

=3D=3D

=C2=A0 =C2=A0"Virtual eXtensible Local Area Network" (VXLAN) [RFC= 7348] provides
=C2=A0 =C2=A0an encapsulation scheme that allows building an overlay networ= k by
=C2=A0 =C2=A0decoupling the address space of the attached virtual hosts fro= m that
=C2=A0 =C2=A0of the network.

=C2=A0 One use of VXLAN is in data centers interconnecting
=C2=A0 VMs of a tenant.=C2=A0 VXLAN addresses requirements of the
=C2=A0 =C2=A0Layer 2 and Layer 3 data center network infrastructure in the<= br> =C2=A0 =C2=A0presence of VMs in a multi-tenant environment, discussed in se= ction 3
=C2=A0 =C2=A0of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3= network.
=C2=A0 =C2=A0Another use is as an encapsulation for EVPN [RFC 8365].

=C2=A0 In the remainder of this document the terms VM and End Station
=C2=A0 are used interchangeably.

=C2=A0 =C2=A0In the absence of a router in the overlay, a VM can communicat= e with
=C2=A0 =C2=A0another VM only if they are on the same VXLAN segment.=C2=A0 V= Ms are
=C2=A0 =C2=A0unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a = VXLAN
=C2=A0 =C2=A0Tunnel End Point (VTEP) (hypervisor/TOR).=C2=A0 VTEPs (hypervi= sor/TOR) are
=C2=A0 =C2=A0responsible for encapsulating and decapsulating frames exchang= ed
=C2=A0 =C2=A0among VMs.

On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> BESS Working Group members,
>
> https://tools.ietf.org/html/draft-ietf-bfd-v= xlan-04
>
> BFD has finished working group last call on BFD for Vxlan and is about= ready
> to request publication as an RFC.=C2=A0 A last minute comment suggeste= d that we
> should consider inviting comment from your working group for expertise= .
>
> We will be leaving the last call open until December 21 to leave time = for
> final comments.
>
> -- Jeff (for BFD)
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
--0000000000001479d5057d5195d6-- From nobody Tue Dec 18 13:09:00 2018 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 A0B14130F29; Tue, 18 Dec 2018 13:08:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rrahman@cisco.com, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org Subject: bfd - New Meeting Session Request for IETF 104 X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154516733962.5620.8911903018365937364.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2018 13:08:59 -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: Tue, 18 Dec 2018 21:08:59 -0000 A new meeting session request has just been submitted by Reshad Rahman, a Chair of the bfd working group. --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Reshad Rahman Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: idr grow rtgwg bess lisp netmod netconf Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Resources Requested: Special Requests: Monday to Thursday --------------------------------------------------------- From nobody Tue Dec 18 22:54:10 2018 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 65E5112D84D; Tue, 18 Dec 2018 22:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 7P6945j5IEqg; Tue, 18 Dec 2018 22:54:07 -0800 (PST) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.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 A94EC124408; Tue, 18 Dec 2018 22:54:06 -0800 (PST) Received: by mail-vs1-f49.google.com with SMTP id b74so11607789vsd.9; Tue, 18 Dec 2018 22:54:06 -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=lOUnZf/f0MCfH58VJBduZouzesYbefjQqJF16OtyD0Q=; b=Xzj2CDlVcNm711rlHFX9BjQEydYYqaLac2bhu24wGSJ+fpykIhl55ghCAvWJMv8XV8 byaK1sxLTQ2DxwU4ricSNDMSqVjoWZJXd4D1Y7dFL8iXIsY2KIdl+mt12WmePTpnPzIc c+23Ezi1+zXInk4Ito1fbkYlkZIRpblND6WxU9H/RuNTA8E28fZeWOV/eLyKMjyxOc1J yeZxjQQTxV3Yn+OK8ht0huGb/3nJ7nQ0NSpTHhEdlyOYZgmdeFFXZNf1DndPtIMBVdEc 27rvyuj5zTDA8KALw3A1xlQfCprP3ZeWhC0B1rqR8vDG2EFvX0qw8GQMShuuVke5IIdl G2Nw== X-Gm-Message-State: AA+aEWb3eS07MdoaoQLwd5pEdZQ6ZJKKq+0xHK28MPR1gDQmmv80evij fHbL6skD57y+8Q1Spf1pF9bmMEiLRL57OjE043o= X-Google-Smtp-Source: AFSGD/Vy+PmJNst2T/xUE1sGVU6i9ntbn4KYh5v+L/vfDisILo7QkgnkRv8/6DbcMm8c1zdsO1SDzpWyaPrOYCUjzKs= X-Received: by 2002:a67:f851:: with SMTP id b17mr9712393vsp.23.1545202445375; Tue, 18 Dec 2018 22:54:05 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: From: Anoop Ghanwani Date: Tue, 18 Dec 2018 22:53:54 -0800 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: Greg Mirsky Cc: Jeffrey Haas , rtg-bfd WG , BESS Content-Type: text/plain; charset="UTF-8" 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, 19 Dec 2018 06:54:09 -0000 Hi Greg, Yes this captures what I was trying to get added. Perhaps the last sentence can be changed to: "This document is written assuming the use of VXLAN for virtualized hosts and refers to VMs and VTEPs in hypervisors. However, the concepts are equally applicable to non-virtualized hosts attached to VTEPs in switches." Thanks, Anoop On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky wrote: > > Hi Anoop, > thank you for your comments and the suggested text. To clarify the extent of the update, would the following accurately reflect the change in Introduction you're proposing: > OLD TEXT: > VXLAN is typically deployed in data centers interconnecting > virtualized hosts of a tenant. VXLAN addresses requirements of the > Layer 2 and Layer 3 data center network infrastructure in the > presence of VMs in a multi-tenant environment, discussed in section 3 > [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. > NEW TEXT: > One use of VXLAN is in data centers interconnecting > VMs of a tenant. VXLAN addresses requirements of the > Layer 2 and Layer 3 data center network infrastructure in the > presence of VMs in a multi-tenant environment, discussed in section 3 > of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. > Another use is as an encapsulation for EVPN [RFC 8365]. > > In the remainder of this document the terms VM and End Station > are used interchangeably. > > If my understanding of the proposed update is correct, I'd be glad to use it (adding RFC 8365 as Informational reference). Should note that in the draft we never used "End Station". Perhaps the last sentence is not required. > > What do you think? > > Regards, > Greg > > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani wrote: >> >> I would change the introduction to the following to mention the use of >> VXLAN by BGP EVPN. >> >> Thanks, >> Anoop >> >> == >> >> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides >> an encapsulation scheme that allows building an overlay network by >> decoupling the address space of the attached virtual hosts from that >> of the network. >> >> One use of VXLAN is in data centers interconnecting >> VMs of a tenant. VXLAN addresses requirements of the >> Layer 2 and Layer 3 data center network infrastructure in the >> presence of VMs in a multi-tenant environment, discussed in section 3 >> of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. >> Another use is as an encapsulation for EVPN [RFC 8365]. >> >> In the remainder of this document the terms VM and End Station >> are used interchangeably. >> >> In the absence of a router in the overlay, a VM can communicate with >> another VM only if they are on the same VXLAN segment. VMs are >> unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VXLAN >> Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs (hypervisor/TOR) are >> responsible for encapsulating and decapsulating frames exchanged >> among VMs. >> >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas wrote: >> > >> > BESS Working Group members, >> > >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 >> > >> > BFD has finished working group last call on BFD for Vxlan and is about ready >> > to request publication as an RFC. A last minute comment suggested that we >> > should consider inviting comment from your working group for expertise. >> > >> > We will be leaving the last call open until December 21 to leave time for >> > final comments. >> > >> > -- Jeff (for BFD) >> > >> > _______________________________________________ >> > BESS mailing list >> > BESS@ietf.org >> > https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess From nobody Wed Dec 19 05:19:05 2018 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 59F46128766; Wed, 19 Dec 2018 05:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.566 X-Spam-Level: X-Spam-Status: No, score=-14.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 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 dB1p37OesNO2; Wed, 19 Dec 2018 05:19:01 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBED4126CB6; Wed, 19 Dec 2018 05:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6474; q=dns/txt; s=iport; t=1545225541; x=1546435141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ckrOaCd/aw5fGx2SF2azkQJCfWcD8ivXrMMl4q+jYSM=; b=XkvBa8bLgQgP2lSroeLSu75hzDqjhUY/yLKRNUD7OsltEKEvQBfqcaLg gq+o/haB5XaWBRIhX2eFMbfauL72i8C7EyjT/g49FnIcogMBiJBEA3Bmy bV69uzu3V+PfOicjoAevA1VxXdYW9QV/DtOUJkc2bH2XDHWlVJx/Yt2Yb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAyRBpc/4ENJK1kDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDc4gZi3yCDYkVjkiBews?= =?us-ascii?q?BARgLhEkCF4JSIjQJDQEDAQECAQECbRwMhT0BAQEDAQEhETcDCxACAQgYAgI?= =?us-ascii?q?mAgICHwYLFRACBAENBYMiAYFpAxUPp1GBL4QxAoENgkUNghgFgQuLNBeBQD+?= =?us-ascii?q?BEScfgkyCV0cBAQOBXheCcTGCJgKhATMJAocOhyGDMRiBXo97iUiBBYN0gRO?= =?us-ascii?q?KBwIRFIEnHziBVnAVOyoBgkGLHIUEO0ExjUiBHwEB?= X-IronPort-AV: E=Sophos;i="5.56,372,1539648000"; d="scan'208";a="215372905" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 13:18:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id wBJDIxxm019653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Dec 2018 13:18:59 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 07:18:58 -0600 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 19 Dec 2018 07:18:59 -0600 From: "Reshad Rahman (rrahman)" To: Anoop Ghanwani , Greg Mirsky CC: rtg-bfd WG , BESS Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited Thread-Topic: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited Thread-Index: AQHUkiOST4L9fHttUESm2QYbnfiVh6WFOaKAgAAj7oCAALH0AIAAF8QA Date: Wed, 19 Dec 2018 13:18:59 +0000 Message-ID: References: <20181212140145.GA22828@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.4.181110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.242.49] Content-Type: text/plain; charset="utf-8" Content-ID: <4B10B94606BAAC45AC9A87D14B3A16F6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-9.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: Wed, 19 Dec 2018 13:19:03 -0000 KzEgdG8gQW5vb3AncyBjb21tZW50cy4gSSd2ZSBtYWRlIHNpbWlsYXIgY29tbWVudCB0byBHcmVn IHByaXZhdGVseSwgYW5kIEFub29wJ3MgcHJvcG9zZWQgdGV4dCBjbGVhcnMgdGhpbmdzIHVwLg0K DQpSZWdhcmRzLA0KUmVzaGFkIChubyBoYXQpLg0KDQrvu79PbiAyMDE4LTEyLTE5LCAxOjU0IEFN LCAiUnRnLWJmZCBvbiBiZWhhbGYgb2YgQW5vb3AgR2hhbndhbmkiIDxydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGFub29wQGFsdW1uaS5kdWtlLmVkdT4gd3JvdGU6DQoNCiAg ICBIaSBHcmVnLA0KICAgIA0KICAgIFllcyB0aGlzIGNhcHR1cmVzIHdoYXQgSSB3YXMgdHJ5aW5n IHRvIGdldCBhZGRlZC4NCiAgICANCiAgICBQZXJoYXBzIHRoZSBsYXN0IHNlbnRlbmNlIGNhbiBi ZSBjaGFuZ2VkIHRvOg0KICAgIA0KICAgICJUaGlzIGRvY3VtZW50IGlzIHdyaXR0ZW4gYXNzdW1p bmcgdGhlIHVzZSBvZiBWWExBTiBmb3IgdmlydHVhbGl6ZWQNCiAgICBob3N0cyBhbmQgcmVmZXJz IHRvIFZNcyBhbmQgVlRFUHMgaW4gaHlwZXJ2aXNvcnMuICBIb3dldmVyLCB0aGUNCiAgICBjb25j ZXB0cyBhcmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIG5vbi12aXJ0dWFsaXplZCBob3N0cyBhdHRh Y2hlZCB0bw0KICAgIFZURVBzIGluIHN3aXRjaGVzLiINCiAgICANCiAgICBUaGFua3MsDQogICAg QW5vb3ANCiAgICANCiAgICBPbiBUdWUsIERlYyAxOCwgMjAxOCBhdCAxMjoxNyBQTSBHcmVnIE1p cnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiBIaSBBbm9v cCwNCiAgICA+IHRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBhbmQgdGhlIHN1Z2dlc3RlZCB0 ZXh0LiBUbyBjbGFyaWZ5IHRoZSBleHRlbnQgb2YgdGhlIHVwZGF0ZSwgd291bGQgdGhlIGZvbGxv d2luZyBhY2N1cmF0ZWx5IHJlZmxlY3QgdGhlIGNoYW5nZSBpbiBJbnRyb2R1Y3Rpb24geW91J3Jl IHByb3Bvc2luZzoNCiAgICA+IE9MRCBURVhUOg0KICAgID4gICAgVlhMQU4gaXMgdHlwaWNhbGx5 IGRlcGxveWVkIGluIGRhdGEgY2VudGVycyBpbnRlcmNvbm5lY3RpbmcNCiAgICA+ICAgIHZpcnR1 YWxpemVkIGhvc3RzIG9mIGEgdGVuYW50LiAgVlhMQU4gYWRkcmVzc2VzIHJlcXVpcmVtZW50cyBv ZiB0aGUNCiAgICA+ICAgIExheWVyIDIgYW5kIExheWVyIDMgZGF0YSBjZW50ZXIgbmV0d29yayBp bmZyYXN0cnVjdHVyZSBpbiB0aGUNCiAgICA+ICAgIHByZXNlbmNlIG9mIFZNcyBpbiBhIG11bHRp LXRlbmFudCBlbnZpcm9ubWVudCwgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMw0KICAgID4gICAgW1JG QzczNDhdLCBieSBwcm92aWRpbmcgTGF5ZXIgMiBvdmVybGF5IHNjaGVtZSBvbiBhIExheWVyIDMg bmV0d29yay4NCiAgICA+IE5FVyBURVhUOg0KICAgID4gICBPbmUgdXNlIG9mIFZYTEFOIGlzIGlu IGRhdGEgY2VudGVycyBpbnRlcmNvbm5lY3RpbmcNCiAgICA+ICAgVk1zIG9mIGEgdGVuYW50LiAg VlhMQU4gYWRkcmVzc2VzIHJlcXVpcmVtZW50cyBvZiB0aGUNCiAgICA+ICAgIExheWVyIDIgYW5k IExheWVyIDMgZGF0YSBjZW50ZXIgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBpbiB0aGUNCiAgICA+ ICAgIHByZXNlbmNlIG9mIFZNcyBpbiBhIG11bHRpLXRlbmFudCBlbnZpcm9ubWVudCwgZGlzY3Vz c2VkIGluIHNlY3Rpb24gMw0KICAgID4gICAgb2YgW1JGQzczNDhdLCBieSBwcm92aWRpbmcgTGF5 ZXIgMiBvdmVybGF5IHNjaGVtZSBvbiBhIExheWVyIDMgbmV0d29yay4NCiAgICA+ICAgIEFub3Ro ZXIgdXNlIGlzIGFzIGFuIGVuY2Fwc3VsYXRpb24gZm9yIEVWUE4gW1JGQyA4MzY1XS4NCiAgICA+ DQogICAgPiAgIEluIHRoZSByZW1haW5kZXIgb2YgdGhpcyBkb2N1bWVudCB0aGUgdGVybXMgVk0g YW5kIEVuZCBTdGF0aW9uDQogICAgPiAgIGFyZSB1c2VkIGludGVyY2hhbmdlYWJseS4NCiAgICA+ DQogICAgPiBJZiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBwcm9wb3NlZCB1cGRhdGUgaXMgY29y cmVjdCwgSSdkIGJlIGdsYWQgdG8gdXNlIGl0IChhZGRpbmcgUkZDIDgzNjUgYXMgSW5mb3JtYXRp b25hbCByZWZlcmVuY2UpLiAgU2hvdWxkIG5vdGUgdGhhdCBpbiB0aGUgZHJhZnQgd2UgbmV2ZXIg dXNlZCAiRW5kIFN0YXRpb24iLiBQZXJoYXBzIHRoZSBsYXN0IHNlbnRlbmNlIGlzIG5vdCByZXF1 aXJlZC4NCiAgICA+DQogICAgPiBXaGF0IGRvIHlvdSB0aGluaz8NCiAgICA+DQogICAgPiBSZWdh cmRzLA0KICAgID4gR3JlZw0KICAgID4NCiAgICA+IE9uIFR1ZSwgRGVjIDE4LCAyMDE4IGF0IDEw OjA4IEFNIEFub29wIEdoYW53YW5pIDxhbm9vcEBhbHVtbmkuZHVrZS5lZHU+IHdyb3RlOg0KICAg ID4+DQogICAgPj4gSSB3b3VsZCBjaGFuZ2UgdGhlIGludHJvZHVjdGlvbiB0byB0aGUgZm9sbG93 aW5nIHRvIG1lbnRpb24gdGhlIHVzZSBvZg0KICAgID4+IFZYTEFOIGJ5IEJHUCBFVlBOLg0KICAg ID4+DQogICAgPj4gVGhhbmtzLA0KICAgID4+IEFub29wDQogICAgPj4NCiAgICA+PiA9PQ0KICAg ID4+DQogICAgPj4gICAgIlZpcnR1YWwgZVh0ZW5zaWJsZSBMb2NhbCBBcmVhIE5ldHdvcmsiIChW WExBTikgW1JGQzczNDhdIHByb3ZpZGVzDQogICAgPj4gICAgYW4gZW5jYXBzdWxhdGlvbiBzY2hl bWUgdGhhdCBhbGxvd3MgYnVpbGRpbmcgYW4gb3ZlcmxheSBuZXR3b3JrIGJ5DQogICAgPj4gICAg ZGVjb3VwbGluZyB0aGUgYWRkcmVzcyBzcGFjZSBvZiB0aGUgYXR0YWNoZWQgdmlydHVhbCBob3N0 cyBmcm9tIHRoYXQNCiAgICA+PiAgICBvZiB0aGUgbmV0d29yay4NCiAgICA+Pg0KICAgID4+ICAg T25lIHVzZSBvZiBWWExBTiBpcyBpbiBkYXRhIGNlbnRlcnMgaW50ZXJjb25uZWN0aW5nDQogICAg Pj4gICBWTXMgb2YgYSB0ZW5hbnQuICBWWExBTiBhZGRyZXNzZXMgcmVxdWlyZW1lbnRzIG9mIHRo ZQ0KICAgID4+ICAgIExheWVyIDIgYW5kIExheWVyIDMgZGF0YSBjZW50ZXIgbmV0d29yayBpbmZy YXN0cnVjdHVyZSBpbiB0aGUNCiAgICA+PiAgICBwcmVzZW5jZSBvZiBWTXMgaW4gYSBtdWx0aS10 ZW5hbnQgZW52aXJvbm1lbnQsIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMNCiAgICA+PiAgICBvZiBb UkZDNzM0OF0sIGJ5IHByb3ZpZGluZyBMYXllciAyIG92ZXJsYXkgc2NoZW1lIG9uIGEgTGF5ZXIg MyBuZXR3b3JrLg0KICAgID4+ICAgIEFub3RoZXIgdXNlIGlzIGFzIGFuIGVuY2Fwc3VsYXRpb24g Zm9yIEVWUE4gW1JGQyA4MzY1XS4NCiAgICA+Pg0KICAgID4+ICAgSW4gdGhlIHJlbWFpbmRlciBv ZiB0aGlzIGRvY3VtZW50IHRoZSB0ZXJtcyBWTSBhbmQgRW5kIFN0YXRpb24NCiAgICA+PiAgIGFy ZSB1c2VkIGludGVyY2hhbmdlYWJseS4NCiAgICA+Pg0KICAgID4+ICAgIEluIHRoZSBhYnNlbmNl IG9mIGEgcm91dGVyIGluIHRoZSBvdmVybGF5LCBhIFZNIGNhbiBjb21tdW5pY2F0ZSB3aXRoDQog ICAgPj4gICAgYW5vdGhlciBWTSBvbmx5IGlmIHRoZXkgYXJlIG9uIHRoZSBzYW1lIFZYTEFOIHNl Z21lbnQuICBWTXMgYXJlDQogICAgPj4gICAgdW5hd2FyZSBvZiBWWExBTiB0dW5uZWxzIGFzIGEg VlhMQU4gdHVubmVsIGlzIHRlcm1pbmF0ZWQgb24gYSBWWExBTg0KICAgID4+ICAgIFR1bm5lbCBF bmQgUG9pbnQgKFZURVApIChoeXBlcnZpc29yL1RPUikuICBWVEVQcyAoaHlwZXJ2aXNvci9UT1Ip IGFyZQ0KICAgID4+ICAgIHJlc3BvbnNpYmxlIGZvciBlbmNhcHN1bGF0aW5nIGFuZCBkZWNhcHN1 bGF0aW5nIGZyYW1lcyBleGNoYW5nZWQNCiAgICA+PiAgICBhbW9uZyBWTXMuDQogICAgPj4NCiAg ICA+PiBPbiBXZWQsIERlYyAxMiwgMjAxOCBhdCA2OjAyIEFNIEplZmZyZXkgSGFhcyA8amhhYXNA cGZyYy5vcmc+IHdyb3RlOg0KICAgID4+ID4NCiAgICA+PiA+IEJFU1MgV29ya2luZyBHcm91cCBt ZW1iZXJzLA0KICAgID4+ID4NCiAgICA+PiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJmZC12eGxhbi0wNA0KICAgID4+ID4NCiAgICA+PiA+IEJGRCBoYXMgZmluaXNo ZWQgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gQkZEIGZvciBWeGxhbiBhbmQgaXMgYWJvdXQg cmVhZHkNCiAgICA+PiA+IHRvIHJlcXVlc3QgcHVibGljYXRpb24gYXMgYW4gUkZDLiAgQSBsYXN0 IG1pbnV0ZSBjb21tZW50IHN1Z2dlc3RlZCB0aGF0IHdlDQogICAgPj4gPiBzaG91bGQgY29uc2lk ZXIgaW52aXRpbmcgY29tbWVudCBmcm9tIHlvdXIgd29ya2luZyBncm91cCBmb3IgZXhwZXJ0aXNl Lg0KICAgID4+ID4NCiAgICA+PiA+IFdlIHdpbGwgYmUgbGVhdmluZyB0aGUgbGFzdCBjYWxsIG9w ZW4gdW50aWwgRGVjZW1iZXIgMjEgdG8gbGVhdmUgdGltZSBmb3INCiAgICA+PiA+IGZpbmFsIGNv bW1lbnRzLg0KICAgID4+ID4NCiAgICA+PiA+IC0tIEplZmYgKGZvciBCRkQpDQogICAgPj4gPg0K ICAgID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+PiA+IEJFU1MgbWFpbGluZyBsaXN0DQogICAgPj4gPiBCRVNTQGlldGYub3JnDQogICAg Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jlc3MNCiAgICA+Pg0K ICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgPj4gQkVTUyBtYWlsaW5nIGxpc3QNCiAgICA+PiBCRVNTQGlldGYub3JnDQogICAgPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZXNzDQogICAgDQogICAgDQoNCg== From nobody Wed Dec 19 06:29:05 2018 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 ACB7512867A; Wed, 19 Dec 2018 06:28:58 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 A44F_7Yc25l9; Wed, 19 Dec 2018 06:28:55 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 723EB1200B3; Wed, 19 Dec 2018 06:28:54 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id y11so15195311lfj.4; Wed, 19 Dec 2018 06:28:54 -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=0lE75dZWH+1tCRnLDQ5Qt/HpsRIfOI6tXfR5RVwjNBk=; b=pZZY1rZm6qVkg22D0zim5KaOXyKI9Xyq9oxz2V6z9xkRa9HGjMbYPIPhllNu8GShKk DIfaF37j0Fx2lTHtt7rNrB5bC0KqWdsz3vGLb9ThtSfzDcA+lNQJK2OiqtAww1yDHpRo 4j/FT0F3ZqxF0OJhbae6GlqYr1lRzVR3SJVAbtj/uVgZ04AwH4UNVlxf4Irl1q2CYi/F qPXHQDJcZ82IszAC6FDMSNvFNwMn+vNwzlDw8CUPpkQMlcdpSgykvuF9Ca/oFFd+2ws3 HtK//AQir4bFdLSQEYNRB9vq4QtXPauhdeRIH1FL/707buHJ8czPv/2uKx9lvy5mhx7C e2iQ== 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=0lE75dZWH+1tCRnLDQ5Qt/HpsRIfOI6tXfR5RVwjNBk=; b=YpXBv3sIGGhh+gqKke6dTYB8SjlfOfy1AsGPVLmb9KWsd+ezMy5LRbfZAfUM0+SlvH XcR50/Yifbobhq11OTv4c2f3Oa8WaVsrMFmgBNeNcNbhpxxEwBsgUFf2dDUNZIR7VDWt HsSphhnuz+5C7VsZ+FTSvNCYcDhyM6wlPLGohlg/1s3HSKDXjwg9VlEsGZGX2UGqvFnX ypT2Cggh9/MVXWQjStg4MNmCunLs2vVWhv8Ly2jl+Qr93Y/eOpZYJ5u/hM0AOZ4Bn9IO cBKVRUHt/j0gjhrjPsQziMfU4oef+qZEdVNfqN4Ce5wCWxqTcITXaRcwztYdBft+SsmB WghA== X-Gm-Message-State: AA+aEWY4HwXrsypggEA1+DgBGdZE5LpvakRu0oscrRZVaRm44rUrbdPl oPuvtD07E4kJTGpE3xRkEsebEQ6ykYitIRDQOtI= X-Google-Smtp-Source: AFSGD/VxmmdLr8uTejKOBkIWZ0gpBA3pM3gB9kI6+ATIazI9xzPfsbgPDMXlmLwED7Sxh6ZmjN2B+Tt7CL294swxd30= X-Received: by 2002:a19:c650:: with SMTP id w77mr13202198lff.56.1545229732438; Wed, 19 Dec 2018 06:28:52 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: From: Greg Mirsky Date: Wed, 19 Dec 2018 06:28:40 -0800 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: "Reshad Rahman (rrahman)" Cc: Anoop Ghanwani , rtg-bfd WG , BESS Content-Type: multipart/alternative; boundary="0000000000004c656e057d60d51a" 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, 19 Dec 2018 14:28:59 -0000 --0000000000004c656e057d60d51a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Anoop, thank you for the great text you've contributed. Accepted. I'll update the working text and publish later today. Kind regards, Greg On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) wrote: > +1 to Anoop's comments. I've made similar comment to Greg privately, and > Anoop's proposed text clears things up. > > Regards, > Reshad (no hat). > > =EF=BB=BFOn 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" < > rtg-bfd-bounces@ietf.org on behalf of anoop@alumni.duke.edu> wrote: > > Hi Greg, > > Yes this captures what I was trying to get added. > > Perhaps the last sentence can be changed to: > > "This document is written assuming the use of VXLAN for virtualized > hosts and refers to VMs and VTEPs in hypervisors. However, the > concepts are equally applicable to non-virtualized hosts attached to > VTEPs in switches." > > Thanks, > Anoop > > On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky > wrote: > > > > Hi Anoop, > > thank you for your comments and the suggested text. To clarify the > extent of the update, would the following accurately reflect the change i= n > Introduction you're proposing: > > OLD TEXT: > > VXLAN is typically deployed in data centers interconnecting > > virtualized hosts of a tenant. VXLAN addresses requirements of > the > > Layer 2 and Layer 3 data center network infrastructure in the > > presence of VMs in a multi-tenant environment, discussed in > section 3 > > [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 > network. > > NEW TEXT: > > One use of VXLAN is in data centers interconnecting > > VMs of a tenant. VXLAN addresses requirements of the > > Layer 2 and Layer 3 data center network infrastructure in the > > presence of VMs in a multi-tenant environment, discussed in > section 3 > > of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 > network. > > Another use is as an encapsulation for EVPN [RFC 8365]. > > > > In the remainder of this document the terms VM and End Station > > are used interchangeably. > > > > If my understanding of the proposed update is correct, I'd be glad > to use it (adding RFC 8365 as Informational reference). Should note that > in the draft we never used "End Station". Perhaps the last sentence is no= t > required. > > > > What do you think? > > > > Regards, > > Greg > > > > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani < > anoop@alumni.duke.edu> wrote: > >> > >> I would change the introduction to the following to mention the us= e > of > >> VXLAN by BGP EVPN. > >> > >> Thanks, > >> Anoop > >> > >> =3D=3D > >> > >> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] > provides > >> an encapsulation scheme that allows building an overlay network > by > >> decoupling the address space of the attached virtual hosts from > that > >> of the network. > >> > >> One use of VXLAN is in data centers interconnecting > >> VMs of a tenant. VXLAN addresses requirements of the > >> Layer 2 and Layer 3 data center network infrastructure in the > >> presence of VMs in a multi-tenant environment, discussed in > section 3 > >> of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 > network. > >> Another use is as an encapsulation for EVPN [RFC 8365]. > >> > >> In the remainder of this document the terms VM and End Station > >> are used interchangeably. > >> > >> In the absence of a router in the overlay, a VM can communicate > with > >> another VM only if they are on the same VXLAN segment. VMs are > >> unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a > VXLAN > >> Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs > (hypervisor/TOR) are > >> responsible for encapsulating and decapsulating frames exchange= d > >> among VMs. > >> > >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas > wrote: > >> > > >> > BESS Working Group members, > >> > > >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 > >> > > >> > BFD has finished working group last call on BFD for Vxlan and is > about ready > >> > to request publication as an RFC. A last minute comment > suggested that we > >> > should consider inviting comment from your working group for > expertise. > >> > > >> > We will be leaving the last call open until December 21 to leave > time for > >> > final comments. > >> > > >> > -- Jeff (for BFD) > >> > > >> > _______________________________________________ > >> > BESS mailing list > >> > BESS@ietf.org > >> > https://www.ietf.org/mailman/listinfo/bess > >> > >> _______________________________________________ > >> BESS mailing list > >> BESS@ietf.org > >> https://www.ietf.org/mailman/listinfo/bess > > > > --0000000000004c656e057d60d51a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anoop,
thank you for the great text you've cont= ributed. Accepted. I'll update the working text and publish later today= .

Kind regards,
Greg

On Wed, Dec 19, 2018 at 5:19 AM Res= had Rahman (rrahman) <rrahman@cisco= .com> wrote:
+1 to Anoop's comments. I've made similar comment to Greg priva= tely, and Anoop's proposed text clears things up.

Regards,
Reshad (no hat).

=EF=BB=BFOn 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani&= quot; <rtg= -bfd-bounces@ietf.org on behalf of anoop@alumni.duke.edu> wrote:

=C2=A0 =C2=A0 Hi Greg,

=C2=A0 =C2=A0 Yes this captures what I was trying to get added.

=C2=A0 =C2=A0 Perhaps the last sentence can be changed to:

=C2=A0 =C2=A0 "This document is written assuming the use of VXLAN for = virtualized
=C2=A0 =C2=A0 hosts and refers to VMs and VTEPs in hypervisors.=C2=A0 Howev= er, the
=C2=A0 =C2=A0 concepts are equally applicable to non-virtualized hosts atta= ched to
=C2=A0 =C2=A0 VTEPs in switches."

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Anoop

=C2=A0 =C2=A0 On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Anoop,
=C2=A0 =C2=A0 > thank you for your comments and the suggested text. To c= larify the extent of the update, would the following accurately reflect the= change in Introduction you're proposing:
=C2=A0 =C2=A0 > OLD TEXT:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 VXLAN is typically deployed in data centers= interconnecting
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 virtualized hosts of a tenant.=C2=A0 VXLAN = addresses requirements of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network inf= rastructure in the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 presence of VMs in a multi-tenant environme= nt, discussed in section 3
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 [RFC7348], by providing Layer 2 overlay sch= eme on a Layer 3 network.
=C2=A0 =C2=A0 > NEW TEXT:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0One use of VXLAN is in data centers intercon= necting
=C2=A0 =C2=A0 >=C2=A0 =C2=A0VMs of a tenant.=C2=A0 VXLAN addresses requi= rements of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network inf= rastructure in the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 presence of VMs in a multi-tenant environme= nt, discussed in section 3
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 of [RFC7348], by providing Layer 2 overlay = scheme on a Layer 3 network.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Another use is as an encapsulation for EVPN= [RFC 8365].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0In the remainder of this document the terms = VM and End Station
=C2=A0 =C2=A0 >=C2=A0 =C2=A0are used interchangeably.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If my understanding of the proposed update is correct, I= 'd be glad to use it (adding RFC 8365 as Informational reference).=C2= =A0 Should note that in the draft we never used "End Station". Pe= rhaps the last sentence is not required.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What do you think?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards,
=C2=A0 =C2=A0 > Greg
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani <anoop@alumni.duke.ed= u> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I would change the introduction to the following to = mention the use of
=C2=A0 =C2=A0 >> VXLAN by BGP EVPN.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thanks,
=C2=A0 =C2=A0 >> Anoop
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> =3D=3D
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 "Virtual eXtensible Local Area Net= work" (VXLAN) [RFC7348] provides
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 an encapsulation scheme that allows bui= lding an overlay network by
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 decoupling the address space of the att= ached virtual hosts from that
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 of the network.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0One use of VXLAN is in data centers inte= rconnecting
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0VMs of a tenant.=C2=A0 VXLAN addresses r= equirements of the
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network= infrastructure in the
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 presence of VMs in a multi-tenant envir= onment, discussed in section 3
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 of [RFC7348], by providing Layer 2 over= lay scheme on a Layer 3 network.
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Another use is as an encapsulation for = EVPN [RFC 8365].
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0In the remainder of this document the te= rms VM and End Station
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0are used interchangeably.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 In the absence of a router in the overl= ay, a VM can communicate with
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 another VM only if they are on the same= VXLAN segment.=C2=A0 VMs are
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 unaware of VXLAN tunnels as a VXLAN tun= nel is terminated on a VXLAN
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Tunnel End Point (VTEP) (hypervisor/TOR= ).=C2=A0 VTEPs (hypervisor/TOR) are
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 responsible for encapsulating and decap= sulating frames exchanged
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 among VMs.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas <jhaas@pfrc.org> wro= te:
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > BESS Working Group members,
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > https://tools.ietf.or= g/html/draft-ietf-bfd-vxlan-04
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > BFD has finished working group last call on BFD= for Vxlan and is about ready
=C2=A0 =C2=A0 >> > to request publication as an RFC.=C2=A0 A last = minute comment suggested that we
=C2=A0 =C2=A0 >> > should consider inviting comment from your work= ing group for expertise.
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > We will be leaving the last call open until Dec= ember 21 to leave time for
=C2=A0 =C2=A0 >> > final comments.
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > -- Jeff (for BFD)
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > _______________________________________________=
=C2=A0 =C2=A0 >> > BESS mailing list
=C2=A0 =C2=A0 >> > BESS@ietf.org
=C2=A0 =C2=A0 >> > https://www.ietf.org/mailman/l= istinfo/bess
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________
=C2=A0 =C2=A0 >> BESS mailing list
=C2=A0 =C2=A0 >> B= ESS@ietf.org
=C2=A0 =C2=A0 >> https://www.ietf.org/mailman/listin= fo/bess



--0000000000004c656e057d60d51a-- From nobody Wed Dec 19 07:01:38 2018 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 134AF126C7E; Wed, 19 Dec 2018 07:01:37 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 v_mboutvuA-4; Wed, 19 Dec 2018 07:01:34 -0800 (PST) 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 84CAF124BE5; Wed, 19 Dec 2018 07:01:33 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id g11-v6so17686559ljk.3; Wed, 19 Dec 2018 07:01: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=njeLZ7oswIvMtQQNu6M4ILi9Uqd3xqz+FCwDxNZeLK0=; b=fexThNLMB0r062ouI2KzVVYEtuaUUSr8ULJoOy9O8b1z/hXrtle6RXmO/46RoSNXO0 wRsCjMEsezsYkilkRwo1aO3y+PsOiMYMKfd6gEQjyRfxiq1EO6YFH5Q/u9y2oNmq90F3 5wxSXdNdXUJwZ9uJgHXOqse4UoBkLW72wOJe+2Gbx0svVZ7GCSvSACwGbbgWSwg2M9Fa +5n0NvCqIqul/g5a6Sxq7aJNOeUKaRb0JgQdiAYvoo4HpzEZV1k4AglmS+QsUReirAxK LY8t8Ei6fY8KKEe3rSkE69CqklKjT05GzUchxkANc+TF0MTc4EH3rC7M0qSPAb38pBkM cujg== 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=njeLZ7oswIvMtQQNu6M4ILi9Uqd3xqz+FCwDxNZeLK0=; b=C8pzF4MlKVT66SH1EQWLWpjxqN+T2Mm4+YUn2IkS1m8J73z6gUUd+USRNYJnM+HMTq aHlPfE04oQUT61nIJD/VATz6bM4XS3V81J+oZHvAvrXtaH0+gTUGETI6ANQ6KFDS7Ui/ NtxC22rVrcQu1fnoSi7rZrFwppWlN4X+6XZ8NEbTMn2qikQ2nKyWshFan+44dn8nPY8I B6ZYbNnym8qGc9TTULdvesvctD9/TisMVm3gzCocppAQ+bgJYKpSSMgbtk0XjaQL4Xqh mzlcIEVSHFrUxExVMk4XghkdLTfTSTrFj7DwlyfwPZDq/0O6VDvAz+pk8JNxMv84ISF4 8aWg== X-Gm-Message-State: AA+aEWblCJhTvyH8XefSzk5orAFkwR55jqQFgYFpDypD1fJ0lKuT1rpV ejx5myEFIXNxXVTghU4X7Z/HeKnUQswK6nzjScE= X-Google-Smtp-Source: AFSGD/WRCMH4sbbMANGLqsuPaSzIj/n/PsKi8o2dHZa1VUI1Fz9qpUlFEDKWxhgZiMBMy9vvqBAI7xe/JukY136pRl8= X-Received: by 2002:a2e:5109:: with SMTP id f9-v6mr4316301ljb.52.1545231691463; Wed, 19 Dec 2018 07:01:31 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: From: Greg Mirsky Date: Wed, 19 Dec 2018 07:01:20 -0800 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: "Reshad Rahman (rrahman)" Cc: Anoop Ghanwani , rtg-bfd WG , BESS Content-Type: multipart/alternative; boundary="00000000000010c291057d614a4b" 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, 19 Dec 2018 15:01:37 -0000 --00000000000010c291057d614a4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Anoop, et al., appreciate your check of the final version of the update to the draft. Below is the new text as in the working version: One use of VXLAN is in data centers interconnecting VMs of a tenant. VXLAN addresses requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VMs in a multi-tenant environment, discussed in section 3 [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 network. Another use is as an encapsulation for Ethernet VPN [RFC8365]. This document is written assuming the use of VXLAN for virtualized hosts and refers to VMs and VTEPs in hypervisors. However, the concepts are equally applicable to non-virtualized hosts attached to VTEPs in switches. Kind regards, Greg On Wed, Dec 19, 2018 at 6:28 AM Greg Mirsky wrote: > Hi Anoop, > thank you for the great text you've contributed. Accepted. I'll update th= e > working text and publish later today. > > Kind regards, > Greg > > On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) > wrote: > >> +1 to Anoop's comments. I've made similar comment to Greg privately, and >> Anoop's proposed text clears things up. >> >> Regards, >> Reshad (no hat). >> >> =EF=BB=BFOn 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" < >> rtg-bfd-bounces@ietf.org on behalf of anoop@alumni.duke.edu> wrote: >> >> Hi Greg, >> >> Yes this captures what I was trying to get added. >> >> Perhaps the last sentence can be changed to: >> >> "This document is written assuming the use of VXLAN for virtualized >> hosts and refers to VMs and VTEPs in hypervisors. However, the >> concepts are equally applicable to non-virtualized hosts attached to >> VTEPs in switches." >> >> Thanks, >> Anoop >> >> On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky >> wrote: >> > >> > Hi Anoop, >> > thank you for your comments and the suggested text. To clarify the >> extent of the update, would the following accurately reflect the change = in >> Introduction you're proposing: >> > OLD TEXT: >> > VXLAN is typically deployed in data centers interconnecting >> > virtualized hosts of a tenant. VXLAN addresses requirements of >> the >> > Layer 2 and Layer 3 data center network infrastructure in the >> > presence of VMs in a multi-tenant environment, discussed in >> section 3 >> > [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 >> network. >> > NEW TEXT: >> > One use of VXLAN is in data centers interconnecting >> > VMs of a tenant. VXLAN addresses requirements of the >> > Layer 2 and Layer 3 data center network infrastructure in the >> > presence of VMs in a multi-tenant environment, discussed in >> section 3 >> > of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 >> network. >> > Another use is as an encapsulation for EVPN [RFC 8365]. >> > >> > In the remainder of this document the terms VM and End Station >> > are used interchangeably. >> > >> > If my understanding of the proposed update is correct, I'd be glad >> to use it (adding RFC 8365 as Informational reference). Should note tha= t >> in the draft we never used "End Station". Perhaps the last sentence is n= ot >> required. >> > >> > What do you think? >> > >> > Regards, >> > Greg >> > >> > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani < >> anoop@alumni.duke.edu> wrote: >> >> >> >> I would change the introduction to the following to mention the >> use of >> >> VXLAN by BGP EVPN. >> >> >> >> Thanks, >> >> Anoop >> >> >> >> =3D=3D >> >> >> >> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] >> provides >> >> an encapsulation scheme that allows building an overlay networ= k >> by >> >> decoupling the address space of the attached virtual hosts fro= m >> that >> >> of the network. >> >> >> >> One use of VXLAN is in data centers interconnecting >> >> VMs of a tenant. VXLAN addresses requirements of the >> >> Layer 2 and Layer 3 data center network infrastructure in the >> >> presence of VMs in a multi-tenant environment, discussed in >> section 3 >> >> of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 >> network. >> >> Another use is as an encapsulation for EVPN [RFC 8365]. >> >> >> >> In the remainder of this document the terms VM and End Station >> >> are used interchangeably. >> >> >> >> In the absence of a router in the overlay, a VM can communicat= e >> with >> >> another VM only if they are on the same VXLAN segment. VMs ar= e >> >> unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a >> VXLAN >> >> Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs >> (hypervisor/TOR) are >> >> responsible for encapsulating and decapsulating frames exchang= ed >> >> among VMs. >> >> >> >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas >> wrote: >> >> > >> >> > BESS Working Group members, >> >> > >> >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 >> >> > >> >> > BFD has finished working group last call on BFD for Vxlan and i= s >> about ready >> >> > to request publication as an RFC. A last minute comment >> suggested that we >> >> > should consider inviting comment from your working group for >> expertise. >> >> > >> >> > We will be leaving the last call open until December 21 to leav= e >> time for >> >> > final comments. >> >> > >> >> > -- Jeff (for BFD) >> >> > >> >> > _______________________________________________ >> >> > BESS mailing list >> >> > BESS@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/bess >> >> >> >> _______________________________________________ >> >> BESS mailing list >> >> BESS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/bess >> >> >> >> --00000000000010c291057d614a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Anoop, et al.,
appreciate your che= ck of the final version of the update to the draft. Below is the new text a= s in the working version:
=C2=A0 =C2=A0One use of VXLAN is i= n data centers interconnecting VMs of a tenant.
=C2=A0 =C2=A0VXLA= N addresses requirements of the Layer 2 and Layer 3 data center
= =C2=A0 =C2=A0network infrastructure in the presence of VMs in a multi-tenan= t
=C2=A0 =C2=A0environment, discussed in section 3 [RFC7348], by = providing Layer 2
=C2=A0 =C2=A0overlay scheme on a Layer 3 networ= k.=C2=A0 Another use is as an
=C2=A0 =C2=A0encapsulation for Ethe= rnet VPN [RFC8365].

=C2=A0 =C2=A0This document is = written assuming the use of VXLAN for virtualized
=C2=A0 =C2=A0ho= sts and refers to VMs and VTEPs in hypervisors.=C2=A0 However, the
=C2=A0 =C2=A0concepts are equally applicable to non-virtualized hosts att= ached to
=C2=A0 =C2=A0VTEPs in switches.

Kind regards,
Greg

On Wed, Dec 19, 2018 at 6:28 AM Greg Mirsky <<= a href=3D"mailto:gregimirsky@gmail.com">gregimirsky@gmail.com> wrote= :
Hi Anoop,
thank you for the great text you've contributed. Accep= ted. I'll update the working text and publish later today.
Kind regards,
Greg

On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rr= ahman) <rrahman@c= isco.com> wrote:
+1 to Anoop's comments. I've made similar comment to Greg p= rivately, and Anoop's proposed text clears things up.

Regards,
Reshad (no hat).

=EF=BB=BFOn 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani&= quot; <rtg= -bfd-bounces@ietf.org on behalf of anoop@alumni.duke.edu> wrote:

=C2=A0 =C2=A0 Hi Greg,

=C2=A0 =C2=A0 Yes this captures what I was trying to get added.

=C2=A0 =C2=A0 Perhaps the last sentence can be changed to:

=C2=A0 =C2=A0 "This document is written assuming the use of VXLAN for = virtualized
=C2=A0 =C2=A0 hosts and refers to VMs and VTEPs in hypervisors.=C2=A0 Howev= er, the
=C2=A0 =C2=A0 concepts are equally applicable to non-virtualized hosts atta= ched to
=C2=A0 =C2=A0 VTEPs in switches."

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Anoop

=C2=A0 =C2=A0 On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Hi Anoop,
=C2=A0 =C2=A0 > thank you for your comments and the suggested text. To c= larify the extent of the update, would the following accurately reflect the= change in Introduction you're proposing:
=C2=A0 =C2=A0 > OLD TEXT:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 VXLAN is typically deployed in data centers= interconnecting
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 virtualized hosts of a tenant.=C2=A0 VXLAN = addresses requirements of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network inf= rastructure in the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 presence of VMs in a multi-tenant environme= nt, discussed in section 3
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 [RFC7348], by providing Layer 2 overlay sch= eme on a Layer 3 network.
=C2=A0 =C2=A0 > NEW TEXT:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0One use of VXLAN is in data centers intercon= necting
=C2=A0 =C2=A0 >=C2=A0 =C2=A0VMs of a tenant.=C2=A0 VXLAN addresses requi= rements of the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network inf= rastructure in the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 presence of VMs in a multi-tenant environme= nt, discussed in section 3
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 of [RFC7348], by providing Layer 2 overlay = scheme on a Layer 3 network.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Another use is as an encapsulation for EVPN= [RFC 8365].
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0In the remainder of this document the terms = VM and End Station
=C2=A0 =C2=A0 >=C2=A0 =C2=A0are used interchangeably.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > If my understanding of the proposed update is correct, I= 'd be glad to use it (adding RFC 8365 as Informational reference).=C2= =A0 Should note that in the draft we never used "End Station". Pe= rhaps the last sentence is not required.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > What do you think?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Regards,
=C2=A0 =C2=A0 > Greg
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani <anoop@alumni.duke.ed= u> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I would change the introduction to the following to = mention the use of
=C2=A0 =C2=A0 >> VXLAN by BGP EVPN.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thanks,
=C2=A0 =C2=A0 >> Anoop
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> =3D=3D
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 "Virtual eXtensible Local Area Net= work" (VXLAN) [RFC7348] provides
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 an encapsulation scheme that allows bui= lding an overlay network by
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 decoupling the address space of the att= ached virtual hosts from that
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 of the network.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0One use of VXLAN is in data centers inte= rconnecting
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0VMs of a tenant.=C2=A0 VXLAN addresses r= equirements of the
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Layer 2 and Layer 3 data center network= infrastructure in the
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 presence of VMs in a multi-tenant envir= onment, discussed in section 3
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 of [RFC7348], by providing Layer 2 over= lay scheme on a Layer 3 network.
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Another use is as an encapsulation for = EVPN [RFC 8365].
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0In the remainder of this document the te= rms VM and End Station
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0are used interchangeably.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 In the absence of a router in the overl= ay, a VM can communicate with
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 another VM only if they are on the same= VXLAN segment.=C2=A0 VMs are
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 unaware of VXLAN tunnels as a VXLAN tun= nel is terminated on a VXLAN
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Tunnel End Point (VTEP) (hypervisor/TOR= ).=C2=A0 VTEPs (hypervisor/TOR) are
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 responsible for encapsulating and decap= sulating frames exchanged
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 among VMs.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas <jhaas@pfrc.org> wro= te:
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > BESS Working Group members,
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > https://tools.ietf.or= g/html/draft-ietf-bfd-vxlan-04
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > BFD has finished working group last call on BFD= for Vxlan and is about ready
=C2=A0 =C2=A0 >> > to request publication as an RFC.=C2=A0 A last = minute comment suggested that we
=C2=A0 =C2=A0 >> > should consider inviting comment from your work= ing group for expertise.
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > We will be leaving the last call open until Dec= ember 21 to leave time for
=C2=A0 =C2=A0 >> > final comments.
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > -- Jeff (for BFD)
=C2=A0 =C2=A0 >> >
=C2=A0 =C2=A0 >> > _______________________________________________=
=C2=A0 =C2=A0 >> > BESS mailing list
=C2=A0 =C2=A0 >> > BESS@ietf.org
=C2=A0 =C2=A0 >> > https://www.ietf.org/mailman/l= istinfo/bess
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________
=C2=A0 =C2=A0 >> BESS mailing list
=C2=A0 =C2=A0 >> B= ESS@ietf.org
=C2=A0 =C2=A0 >> https://www.ietf.org/mailman/listin= fo/bess



--00000000000010c291057d614a4b-- From nobody Wed Dec 19 09:42:07 2018 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 AC838128766; Wed, 19 Dec 2018 09:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 9CK95cR8NMhB; Wed, 19 Dec 2018 09:41:56 -0800 (PST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (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 4F398130E81; Wed, 19 Dec 2018 09:41:56 -0800 (PST) Received: by mail-vs1-f50.google.com with SMTP id n10so571223vso.13; Wed, 19 Dec 2018 09:41: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:content-transfer-encoding; bh=bYeAzNV7lbe8KiHANc9JR0awaKQUUcaHbh118GS+U5Y=; b=VoPm9iU++D9uLmt3MRRDGqY0404tp0p9Fu+AN+BSjkEp/yp6d2AGYs6xhksEa0I7Xu E7SBBwhsAOjEs/LxtsaKD21X13pjHmJBAKqoZaTiARQ41hYbBFKaBlXWj23PELCUqPR/ QJwUkvsCR8Zi05ZMVJS6se8oRLY7/M0/aRoBfW4Jq/2QCS9j6tS5gSv62KX69H7QX8Fx y1RP8D/dJ7eWYkb1ciuoEl/Uc+yvAasi1oL18cYINObhz5BGAD/b43Q9q4pvL6E82B7m 71qND6iFjSWLh4V+MiUppsin+gKUV0JybleljNiYZqYejD9RlQCZDS37Ow1fATj/JPIc G7Vw== X-Gm-Message-State: AA+aEWbhaN57sDqt1JN7/VTrxBzXz08dfmXetDqCYKVY86T+uQyAdhCe 8VNT4aG6RKWm9wPsRJ1HbwOsugnKfQQBybKe+F8= X-Google-Smtp-Source: AFSGD/WAHabFI5guD+1KBhVW6LpME+qc+ixqFW+hhjAmzrk01Y5cfKw9qNzzaVuBePni/oNX3j3IBqLy1ZBDSZEWEIg= X-Received: by 2002:a67:ecc6:: with SMTP id i6mr4306411vsp.119.1545241315168; Wed, 19 Dec 2018 09:41:55 -0800 (PST) MIME-Version: 1.0 References: <20181212140145.GA22828@pfrc.org> In-Reply-To: From: Anoop Ghanwani Date: Wed, 19 Dec 2018 09:41:44 -0800 Message-ID: Subject: Re: [bess] BFD WGLC for draft-ietf-bfd-vxlan; BESS input solicited To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , rtg-bfd WG , BESS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 19 Dec 2018 17:41:59 -0000 Greg, This is fine. Thanks, Anoop On Wed, Dec 19, 2018 at 7:01 AM Greg Mirsky wrote: > > Hi Anoop, et al., > appreciate your check of the final version of the update to the draft. Be= low is the new text as in the working version: > One use of VXLAN is in data centers interconnecting VMs of a tenant. > VXLAN addresses requirements of the Layer 2 and Layer 3 data center > network infrastructure in the presence of VMs in a multi-tenant > environment, discussed in section 3 [RFC7348], by providing Layer 2 > overlay scheme on a Layer 3 network. Another use is as an > encapsulation for Ethernet VPN [RFC8365]. > > This document is written assuming the use of VXLAN for virtualized > hosts and refers to VMs and VTEPs in hypervisors. However, the > concepts are equally applicable to non-virtualized hosts attached to > VTEPs in switches. > > Kind regards, > Greg > > On Wed, Dec 19, 2018 at 6:28 AM Greg Mirsky wrote= : >> >> Hi Anoop, >> thank you for the great text you've contributed. Accepted. I'll update t= he working text and publish later today. >> >> Kind regards, >> Greg >> >> On Wed, Dec 19, 2018 at 5:19 AM Reshad Rahman (rrahman) wrote: >>> >>> +1 to Anoop's comments. I've made similar comment to Greg privately, an= d Anoop's proposed text clears things up. >>> >>> Regards, >>> Reshad (no hat). >>> >>> =EF=BB=BFOn 2018-12-19, 1:54 AM, "Rtg-bfd on behalf of Anoop Ghanwani" = wrote: >>> >>> Hi Greg, >>> >>> Yes this captures what I was trying to get added. >>> >>> Perhaps the last sentence can be changed to: >>> >>> "This document is written assuming the use of VXLAN for virtualized >>> hosts and refers to VMs and VTEPs in hypervisors. However, the >>> concepts are equally applicable to non-virtualized hosts attached t= o >>> VTEPs in switches." >>> >>> Thanks, >>> Anoop >>> >>> On Tue, Dec 18, 2018 at 12:17 PM Greg Mirsky wrote: >>> > >>> > Hi Anoop, >>> > thank you for your comments and the suggested text. To clarify th= e extent of the update, would the following accurately reflect the change i= n Introduction you're proposing: >>> > OLD TEXT: >>> > VXLAN is typically deployed in data centers interconnecting >>> > virtualized hosts of a tenant. VXLAN addresses requirements o= f the >>> > Layer 2 and Layer 3 data center network infrastructure in the >>> > presence of VMs in a multi-tenant environment, discussed in se= ction 3 >>> > [RFC7348], by providing Layer 2 overlay scheme on a Layer 3 ne= twork. >>> > NEW TEXT: >>> > One use of VXLAN is in data centers interconnecting >>> > VMs of a tenant. VXLAN addresses requirements of the >>> > Layer 2 and Layer 3 data center network infrastructure in the >>> > presence of VMs in a multi-tenant environment, discussed in se= ction 3 >>> > of [RFC7348], by providing Layer 2 overlay scheme on a Layer 3= network. >>> > Another use is as an encapsulation for EVPN [RFC 8365]. >>> > >>> > In the remainder of this document the terms VM and End Station >>> > are used interchangeably. >>> > >>> > If my understanding of the proposed update is correct, I'd be gla= d to use it (adding RFC 8365 as Informational reference). Should note that= in the draft we never used "End Station". Perhaps the last sentence is not= required. >>> > >>> > What do you think? >>> > >>> > Regards, >>> > Greg >>> > >>> > On Tue, Dec 18, 2018 at 10:08 AM Anoop Ghanwani wrote: >>> >> >>> >> I would change the introduction to the following to mention the = use of >>> >> VXLAN by BGP EVPN. >>> >> >>> >> Thanks, >>> >> Anoop >>> >> >>> >> =3D=3D >>> >> >>> >> "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] pro= vides >>> >> an encapsulation scheme that allows building an overlay netwo= rk by >>> >> decoupling the address space of the attached virtual hosts fr= om that >>> >> of the network. >>> >> >>> >> One use of VXLAN is in data centers interconnecting >>> >> VMs of a tenant. VXLAN addresses requirements of the >>> >> Layer 2 and Layer 3 data center network infrastructure in the >>> >> presence of VMs in a multi-tenant environment, discussed in s= ection 3 >>> >> of [RFC7348], by providing Layer 2 overlay scheme on a Layer = 3 network. >>> >> Another use is as an encapsulation for EVPN [RFC 8365]. >>> >> >>> >> In the remainder of this document the terms VM and End Station >>> >> are used interchangeably. >>> >> >>> >> In the absence of a router in the overlay, a VM can communica= te with >>> >> another VM only if they are on the same VXLAN segment. VMs a= re >>> >> unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a= VXLAN >>> >> Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs (hypervisor/= TOR) are >>> >> responsible for encapsulating and decapsulating frames exchan= ged >>> >> among VMs. >>> >> >>> >> On Wed, Dec 12, 2018 at 6:02 AM Jeffrey Haas wr= ote: >>> >> > >>> >> > BESS Working Group members, >>> >> > >>> >> > https://tools.ietf.org/html/draft-ietf-bfd-vxlan-04 >>> >> > >>> >> > BFD has finished working group last call on BFD for Vxlan and = is about ready >>> >> > to request publication as an RFC. A last minute comment sugge= sted that we >>> >> > should consider inviting comment from your working group for e= xpertise. >>> >> > >>> >> > We will be leaving the last call open until December 21 to lea= ve time for >>> >> > final comments. >>> >> > >>> >> > -- Jeff (for BFD) >>> >> > >>> >> > _______________________________________________ >>> >> > BESS mailing list >>> >> > BESS@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/bess >>> >> >>> >> _______________________________________________ >>> >> BESS mailing list >>> >> BESS@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/bess >>> >>> >>> From nobody Wed Dec 19 10:26:49 2018 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 2A07C130E96; Wed, 19 Dec 2018 10:26:47 -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-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <154524400713.1888.4227151897504927579@ietfa.amsl.com> Date: Wed, 19 Dec 2018 10:26:47 -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: Wed, 19 Dec 2018 18:26:47 -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-05.txt Pages : 12 Date : 2018-12-19 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-05 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-05 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 Wed Dec 19 10:30:11 2018 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 041C0130EB2; Wed, 19 Dec 2018 10:30:10 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K1SXHHLZFDvd; Wed, 19 Dec 2018 10:30:08 -0800 (PST) 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 31EAB130EA8; Wed, 19 Dec 2018 10:30:08 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id t9-v6so18267418ljh.6; Wed, 19 Dec 2018 10:30:08 -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=wIFE9zgAxOtCAlPIYvQLI6yqdh6nvws+kHEWcK2brcs=; b=Ty1j3q+SVSi3uKc6wOHO3OlRJYgFxwBeiJJ1kG/gFPFEShi16+zpJEIA1kbARyimS6 IKZUqwOUrB+2hO1ts9Yi4is+yBH1IDXQ7xEYJlp8+rBdxA8Clq16lQdzVOlWOoTu5PEN HUwr4zgL3OutFkz034RMO5ufmwCtBgwvbNOUtfMWtAlyhn47+JRpkfr+REiflr3xChei PSMBZycKWkLdZC7nrwx2Ajk/xXVvIl4hzSPopHLvrFILBw3xsIFVSD+K/64fBIbvY9D9 /EJjTik32QnagvpGUYwDOM9EC3rGrrwE6xcFmtiGUxLw0AYGyVtRz4QJ/1JpYs8Hu9+u 8p8g== 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=wIFE9zgAxOtCAlPIYvQLI6yqdh6nvws+kHEWcK2brcs=; b=c7gGqYPvHOYzYLgOkPfeDZX99wgKVAEJIhCYkOUj5lwY6vC27ilPqBZ5Nbo2FuecP9 1L5/yfBmvsZ0ARZytSCN+oblf6cp8a2QLAueaq2DdjCnkkn2ew5B8remP0eBxtHWiBYN 0Io5yljlg863okSP6lo2Zz6L2GWMSoHpXz8WlFUTQ0unspJ3w5oUQrW/EAxPJ6L7a474 xLHBl4MQVC3yygckRcimzshQ0kDQHGp4Mp9k7qtwMRbdoUO43xT7mDI5L/lX7EIs5VxI MoKnHSklGfg/Z858YHHPRA/j2xYKZo4BisgaYSiZL7vHjYuyRKWU8mRccfAWVGxPewz8 3gOw== X-Gm-Message-State: AA+aEWYIAx4KAwHJmnHonZ9RW4+HjcVXyYixGwnuhyYuPms6bcA3HjuJ UIyW0bqHS8saEpleYei5BFgIKhVHl244RGyWjFqyuw== X-Google-Smtp-Source: AFSGD/VUsQ3U6hLWWBIefjRXqj8bIQwGGOYTNQM3XwD84s1DgxSUVKY/sY90crjLNys9GV46nX5KmPkW5e9K0u0yOv0= X-Received: by 2002:a2e:92ca:: with SMTP id k10-v6mr13191338ljh.63.1545244205851; Wed, 19 Dec 2018 10:30:05 -0800 (PST) MIME-Version: 1.0 References: <154524400728.1888.18058633058130863398.idtracker@ietfa.amsl.com> In-Reply-To: <154524400728.1888.18058633058130863398.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 19 Dec 2018 10:29:54 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-vxlan-05.txt To: rtg-bfd WG , bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb2872057d64338e" 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, 19 Dec 2018 18:30:10 -0000 --000000000000fb2872057d64338e Content-Type: text/plain; charset="UTF-8" Dear All, updates to address comments WGLC comments by Anoop Ghanwani (many thanks to Anoop for the comments and the text contributed in course of our discussion). Regards, Greg ---------- Forwarded message --------- From: Date: Wed, Dec 19, 2018 at 10:26 AM Subject: New Version Notification for draft-ietf-bfd-vxlan-05.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-05.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-bfd-vxlan Revision: 05 Title: BFD for VXLAN Document date: 2018-12-19 Group: bfd Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-05 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks. 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 --000000000000fb2872057d64338e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
updates to address comments WGLC comments by= Anoop Ghanwani (many thanks to Anoop for the comments and the text contrib= uted in course of our discussion).

Regards,
<= div>Greg

---------- Forw= arded message ---------
From: <internet-drafts@ietf.org>
Date: We= d, Dec 19, 2018 at 10:26 AM
Subject: New Version Notification for draft-= ietf-bfd-vxlan-05.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigonda <mmudigon@cisco.com>, Sudarsan Paragir= i <sparagiri@juniper.net>= ;, Vengada Prasad Govindan <venggo= vi@cisco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>


A new version of I-D, draft-ietf-bfd-vxlan-05.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=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2018-12-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-05.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-05
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-05

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in Virtual eXtensible Local Area Netw= ork
=C2=A0 =C2=A0(VXLAN) overlay networks.




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

--000000000000fb2872057d64338e-- From nobody Wed Dec 19 11:12:14 2018 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 A6802130EBB; Wed, 19 Dec 2018 11:12: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 zvh9tL9d6bSY; Wed, 19 Dec 2018 11:12:10 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C6DA1130EBA; Wed, 19 Dec 2018 11:12:10 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id B425A1E2D7; Wed, 19 Dec 2018 14:11:17 -0500 (EST) Date: Wed, 19 Dec 2018 14:11:17 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: rtg-bfd WG , bfd-chairs@ietf.org Subject: Re: Fwd: New Version Notification for draft-ietf-bfd-vxlan-05.txt Message-ID: <20181219191116.GA17647@pfrc.org> References: <154524400728.1888.18058633058130863398.idtracker@ietfa.amsl.com> 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, 19 Dec 2018 19:12:13 -0000 Greg, Thanks for integrating what appears to be the final comments on the draft. Our intent is to send this off to the IESG on Friday if there's no further feedback. -- Jeff On Wed, Dec 19, 2018 at 10:29:54AM -0800, Greg Mirsky wrote: > updates to address comments WGLC comments by Anoop Ghanwani (many thanks to > Anoop for the comments and the text contributed in course of our > discussion). > > Regards, > Greg > > ---------- Forwarded message --------- > From: > Date: Wed, Dec 19, 2018 at 10:26 AM > Subject: New Version Notification for draft-ietf-bfd-vxlan-05.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-05.txt > has been successfully submitted by Greg Mirsky and posted to the > IETF repository. > > Name: draft-ietf-bfd-vxlan > Revision: 05 > Title: BFD for VXLAN > Document date: 2018-12-19 > Group: bfd > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-05 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-05 > > Abstract: > This document describes the use of the Bidirectional Forwarding > Detection (BFD) protocol in Virtual eXtensible Local Area Network > (VXLAN) overlay networks. > > > > > 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 Fri Dec 21 19:59:18 2018 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 7B409130FF6; Fri, 21 Dec 2018 19:59:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-bfd-multipoint@ietf.org, Reshad Rahman , bfd-chairs@ietf.org, rrahman@cisco.com, rtg-bfd@ietf.org Subject: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT) X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154545115049.20244.825410624604585914.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2018 19:59:10 -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: Sat, 22 Dec 2018 03:59:11 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-bfd-multipoint-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! The original Comment portion of my ballot is preserved below for posterity. I am told that the normal usage of the bare term "BFD" has the connotation of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing pseudowires and other more "exotic" encapsulations), so I am not including this in my DISCUSS section. However, it seems unusual to limit the scope of a document in some "random" subsection (here, Section 5.8) with no mention in the general Introduction or Abstract. Is there an improvement to make here? Section 4 [...] If no BFD Control packets are received by a tail for a detection time, the tail declares the path to having failed. For some applications this is the only mechanism necessary; the head can remain ignorant of the tails. It sounds like this might be better said as "the head can remain ignorant of the status of connectivity to the tails"? (That is, the head needs to know at least something about the tails in order to send anything to them, so it is not fully ignorant.) The head of a multipoint BFD session may wish to be alerted to the tails' connectivity (or lack thereof). Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document and are discussed in [I-D.ietf-bfd-multipoint-active-tail]. nit: "outside the scope" Section 5.7 It's a little unclear to me why tails must demultiplex on the identity of the multipoint path; (that is, why My Discriminator isinsufficient). Presumably this is just a failing on my end, of course. [...] Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping may use control plane, e.g., as described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this document. nit: some articles are missing here; maybe "a BFD session", "in the case of", and "the control plane". Section 5.12.2 MultipointTail sessions MAY be destroyed immediately upon leaving Up state, since tail will transmit no packets. Otherwise, MultipointTail sessions SHOULD be maintained as long as BFD Control packets are being received by it (which by definition will indicate that the head is not Up). Would it be more clear to say "indicate that the head is not Up yet" to distinguish from the case in the first paragraph (where a non-Up state *transition* Section 8 It may be appropriate to make stronger statements about the weakness of MD5 than were valid at the time of 5880's publication. (SHA1 is also not doing so great, but I won't block this work on updating the hash function options.) It would be good to either refer to the bit about shared keys in Section 6 or just move it to this section entirely. From nobody Mon Dec 24 03:17:53 2018 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 7DC99130EEC; Mon, 24 Dec 2018 03:17:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'BFD for Multipoint Networks' to Proposed Standard (draft-ietf-bfd-multipoint-19.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Reshad Rahman , rrahman@cisco.com, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154565026551.13027.11117849656793223288.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2018 03:17:45 -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: Mon, 24 Dec 2018 11:17:46 -0000 The IESG has approved the following document: - 'BFD for Multipoint Networks' (draft-ietf-bfd-multipoint-19.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ Technical Summary This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Working Group Summary The document was discussed multiple times with participation from multiple members of the BFD WG. Most of the discussions took place in 2014/2015 when most of the work occurred, but there have been some recent discussions in 2017/18. The document has been reviewed multiple times on the BFD WG mailing list. Document Quality There is one known implementation Personnel Reshad Rahman is the document shepherd, BFD WG co-chair Martin Vigoureux is the Responsible AD. From nobody Mon Dec 24 03:20:46 2018 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 48144130F0E; Mon, 24 Dec 2018 03:20:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" Subject: Protocol Action: 'BFD Multipoint Active Tails.' to Proposed Standard (draft-ietf-bfd-multipoint-active-tail-10.txt) X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Reshad Rahman , rrahman@cisco.com, rtg-bfd@ietf.org, draft-ietf-bfd-multipoint-active-tail@ietf.org, martin.vigoureux@nokia.com, bfd-chairs@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154565044528.12885.8808785702557638203.idtracker@ietfa.amsl.com> Date: Mon, 24 Dec 2018 03:20:45 -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: Mon, 24 Dec 2018 11:20:45 -0000 The IESG has approved the following document: - 'BFD Multipoint Active Tails.' (draft-ietf-bfd-multipoint-active-tail-10.txt) as Proposed Standard This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Alvaro Retana, Deborah Brungard and Martin Vigoureux. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/ Technical Summary This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks. Working Group Summary The document was discussed multiple times with participation from multiple members of the BFD WG. The discussions on whether a separate draft (v/s move to appendix) was needed for active-tail went on for a while but consensus was reached. Most of the technical discussions took place in 2014/2015 when the active-tail functionality was still part of the multipoint draft (i.e. before the split). The technical discussions were mostly on the notification mechanisms to the head, whether they are all needed and how the operate. Document Quality The document has been reviewed multiple times on the BFD WG mailing list. There is no known implementation of this draft. Personnel Reshad Rahman is the document shepherd, BFD WG co-chair. Martin Vigoureux is the responsible AD. From nobody Wed Dec 26 09:20:27 2018 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 DED201310EE; Wed, 26 Dec 2018 09:20:25 -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 7at2_p2WgXD2; Wed, 26 Dec 2018 09:20:24 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7EADE1310E0; Wed, 26 Dec 2018 09:20:24 -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 3BBAD1E27A; Wed, 26 Dec 2018 12:19:30 -0500 (EST) From: Jeffrey Haas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Wed, 26 Dec 2018 12:20:22 -0500 Subject: draft-ietf-bfd-vxlan nits Cc: "rtg-bfd@ietf. org" To: draft-ietf-bfd-vxlan@ietf.org Message-Id: <80667306-D8B3-4041-BE7B-9C2E5E4EE2DD@pfrc.org> X-Mailer: Apple Mail (2.3445.101.1) 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, 26 Dec 2018 17:20:26 -0000 As part of doing my shepherd review for BFD for VXLAN, I noted three = details that should be attended to prior to the document being submitted = to the IESG: There is a missing IPR attestation from Sudarsan. I have unicasted him = to request this to be done. In the document: IANA has assigned TBA as a dedicated MAC address from the IANA 8-bit unicast MAC address registry to be used as the Destination MAC address of the inner Ethernet of VXLAN when carrying BFD control packets. I believe this is intended to be 48-bit, not 8-bit? Authors would like to thank Jeff Hass of Juniper Networks for his reviews and feedback on this material. It'd be nice to get the typo in my name corrected. :-) -- Jeff= From nobody Wed Dec 26 09:32:09 2018 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 01802131123; Wed, 26 Dec 2018 09:32: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_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 Pk9bNcrtOmEM; Wed, 26 Dec 2018 09:32:05 -0800 (PST) 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 3A70213111F; Wed, 26 Dec 2018 09:32:05 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id u18so11221943lff.10; Wed, 26 Dec 2018 09:32: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=Dm7UPpyjUggznqVVxx2CTcjagkjZnGlxE2aRprUfMYA=; b=XVH0sBAhaR12cDZTxoHytsOk7BOLTyx3aJiyKCMGPP+KsSeIxnLVb85nnYeeFXBKlJ bgMwLCRkqhBHu0g4a7/qDhshY+SdC6lQO1bY3VkkcPwRjB2dnurV/4ybgLlMPC5jljRf dhy3GhXfLkRBBAZcryFp2Vs00bpoS2SbDDCnbPoOYTr9H8OSmR3QdwAHzwrnMTrImkWO 5/dPsBkEd79wIqUMnaSc8/vpbYO59I6uhdhuqr1hKNjQaYYTRk8zVBmb1TLYMliEgwHU cVUIVfJbTjk0eU40BptRA7LS8xQuVpuG2EVXC2Nh54oZ580H6eo+31I5xzuYpupZvQ83 I21w== 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=Dm7UPpyjUggznqVVxx2CTcjagkjZnGlxE2aRprUfMYA=; b=K3eR59v1FWV0Yg7zkA6CyZ4Lq+HsThGu6OLLHqhSILkq/0F9mB/TwtSxV7tbBB8WB5 b34a9pX8e2X5jc9FWhS7IBIdji9fAalpaLFlsYiDeu4PtlkWrelSACdjDmyeXJkYXdoU DH3xi8rLUsPJ6PysaM+Li6mFIdw66TUw2I/K87IlbJbd8r5LFQUQfrvH7qbYgTKyIbvl fJp1NNOanyJPLZMn0Lf69rg1mHovDB23BiINlP606Z7E7zHnZY+JJFI2tY0hNfHh/+xU D1wMwtNkWjANNnoVHU+ClO4zRCRu8FmJ7CmVtyu52+5VdY5ozByiV0RemGHHrt+MIDKs vlsQ== X-Gm-Message-State: AA+aEWYFf+Gc1/tFs5BmGZv53P9MQQ4ePJg7wU9UZEREzRrio+WWQlIx 6tfv/T3ohiefKxzbLg91L5gPD7SvxUVcgMxHyPJmeQ== X-Google-Smtp-Source: AFSGD/VH/JcxkcaUDL3y9AtxaBDzbOtKKvFX/S/K9QE7HqgGV3MgOR2vyzs53wdovBEpcnkvBjcn3OTMpo7aMJY4kFQ= X-Received: by 2002:a19:c014:: with SMTP id q20mr9529248lff.16.1545845523102; Wed, 26 Dec 2018 09:32:03 -0800 (PST) MIME-Version: 1.0 References: <80667306-D8B3-4041-BE7B-9C2E5E4EE2DD@pfrc.org> In-Reply-To: <80667306-D8B3-4041-BE7B-9C2E5E4EE2DD@pfrc.org> From: Greg Mirsky Date: Wed, 26 Dec 2018 09:31:50 -0800 Message-ID: Subject: Re: draft-ietf-bfd-vxlan nits To: Jeffrey Haas Cc: draft-ietf-bfd-vxlan@ietf.org, rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000484292057df035d0" 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, 26 Dec 2018 17:32:08 -0000 --000000000000484292057df035d0 Content-Type: text/plain; charset="UTF-8" Hi Jeff, my apologies for these errors. Will fix them all today. Regards, Greg On Wed, Dec 26, 2018, 09:20 Jeffrey Haas As part of doing my shepherd review for BFD for VXLAN, I noted three > details that should be attended to prior to the document being submitted to > the IESG: > There is a missing IPR attestation from Sudarsan. I have unicasted him to > request this to be done. > In the document: > > IANA has assigned TBA as a dedicated MAC address from the IANA 8-bit > unicast MAC address registry to be used as the Destination MAC > address of the inner Ethernet of VXLAN when carrying BFD control > packets. > > I believe this is intended to be 48-bit, not 8-bit? > > Authors would like to thank Jeff Hass of Juniper Networks for his > reviews and feedback on this material. > > It'd be nice to get the typo in my name corrected. :-) > > -- Jeff --000000000000484292057df035d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
my apologies for these errors. = Will fix them all today.=C2=A0

Regards,=C2=A0
Greg=C2=A0

On Wed, Dec 26, 2018, 09:20 Jeffrey= Haas <jhaas@pfrc.org wrote:
As part of doing my shepherd review for = BFD for VXLAN, I noted three details that should be attended to prior to th= e document being submitted to the IESG:
There is a missing IPR attestation from Sudarsan.=C2=A0 I have unicasted hi= m to request this to be done.
In the document:

=C2=A0 =C2=A0IANA has assigned TBA as a dedicated MAC address from the IANA= 8-bit
=C2=A0 =C2=A0unicast MAC address registry to be used as the Destination MAC=
=C2=A0 =C2=A0address of the inner Ethernet of VXLAN when carrying BFD contr= ol
=C2=A0 =C2=A0packets.

I believe this is intended to be 48-bit, not 8-bit?

=C2=A0 =C2=A0Authors would like to thank Jeff Hass of Juniper Networks for = his
=C2=A0 =C2=A0reviews and feedback on this material.

It'd be nice to get the typo in my name corrected. :-)

-- Jeff
--000000000000484292057df035d0-- From nobody Wed Dec 26 11:04:29 2018 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 D15CF1311B7; Wed, 26 Dec 2018 11:04:20 -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-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <154585106079.9403.1234800601344937323@ietfa.amsl.com> Date: Wed, 26 Dec 2018 11:04:20 -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: Wed, 26 Dec 2018 19:04:21 -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-06.txt Pages : 12 Date : 2018-12-26 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-06 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-06 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 Wed Dec 26 11:06:00 2018 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 C8B8F131201; Wed, 26 Dec 2018 11:05:58 -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_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 qZcs8Mg1BkUV; Wed, 26 Dec 2018 11:05:56 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 AFFB41311FE; Wed, 26 Dec 2018 11:05:55 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id z13so11338203lfe.11; Wed, 26 Dec 2018 11:05:55 -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=YHdwtzAN8wlCOt8Jtknby/cQj+5Jk9ZZ0PeIikwa3ck=; b=UGW1BFveeX/23qTBxk4mTlEz7SgZadioEMgDcQui6BO6r5u6m2s9dUnPXf1RuyupOJ WEUIbLFEbfFx5QonlPkYgRYpdd0HOz6tc+76oWqxKWFXl5mYvGwR/5XClgD1Fixx6OBn A8t1wPM/wbLtz8RMKh7svCnDAc8212b4o2GW45FQvLLVz0a/U0mrIu2c9KmWEtEtAW3D vVm58yP9JdddTzkkx6w5tS45aDd6kAiI4GhZXDKIAdKA50yQhZ7Bcd4eL193M+hyvzrE ciyG+yQEj2xZvt8+tGggNcask9z2DGWu4Tizfwjo1z0cWB8KMl45RjKrfVxpNqXDqTMo BJrQ== 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=YHdwtzAN8wlCOt8Jtknby/cQj+5Jk9ZZ0PeIikwa3ck=; b=CWndUDYS0R//owKyZl35T6HTqg9yZdJ6vJr+YZKam6Ww0aWsSRgpNjh6WpKexcMV5R a6N3QdpPtDlFwC734RH6xdYJuAHL1HTRZzPnDB10grgGqKPOC7thCM0D2Ju0+YKGYwMR YuTCjUUw2k2D2EcPUts3zlhufoPDDoHTGGeY9MoCOHB69zGfXW8K9X4stq2mYOE3H55Y 7DIVB0YQzYjTWqg/A6gVRSMt/jB3ulyO+ppciKvKi2CvUC6C9VK1JY9MMV3GnqRlJAQu QDsi9NnmGD2/AQjW2OWOOolS0pwRxY7YgP1ve1bebq7x7aEDPlKsYp8qxokSABP9C21X 00GA== X-Gm-Message-State: AA+aEWbnzUFDIq7S+MZHRLkbiw1/cJiFDxC8sbZrVkviTX4j4bZjXIGR eW0kWHygaLUgR92lq1KxoKZnGmnNrPb4yRxhvmSJNg== X-Google-Smtp-Source: AFSGD/USc/BrYchfvcpoqFQNh09YywO3HuWegf+EVOtUjtcVRtgGV14n37t9DAHCdZZaVpUHZ9eOG84C6Rjr35FbqAI= X-Received: by 2002:a19:26ce:: with SMTP id m197mr10183865lfm.23.1545851153251; Wed, 26 Dec 2018 11:05:53 -0800 (PST) MIME-Version: 1.0 References: <154585106098.9403.2061090033463996972.idtracker@ietfa.amsl.com> In-Reply-To: <154585106098.9403.2061090033463996972.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 26 Dec 2018 11:05:42 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-ietf-bfd-vxlan-06.txt To: rtg-bfd WG , bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000dd8595057df18408" 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, 26 Dec 2018 19:05:59 -0000 --000000000000dd8595057df18408 Content-Type: text/plain; charset="UTF-8" Dear All, fixed two errors pointed out by Jeff. Happy New Year to All! Regards, Greg ---------- Forwarded message --------- From: Date: Wed, Dec 26, 2018 at 11:04 AM Subject: New Version Notification for draft-ietf-bfd-vxlan-06.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-06.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-bfd-vxlan Revision: 06 Title: BFD for VXLAN Document date: 2018-12-26 Group: bfd Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-06.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-vxlan-06 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-06 Abstract: This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks. 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 --000000000000dd8595057df18408 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
fixed two errors pointed out by Jeff.
<= div>
Happy New Year to All!

Regards,=
Greg

--------= -- Forwarded message ---------
From: <internet-drafts@ietf.org>
D= ate: Wed, Dec 26, 2018 at 11:04 AM
Subject: New Version Notification for= draft-ietf-bfd-vxlan-06.txt
To: Gregory Mirsky <gregimirsky@gmail.com>, Mallik Mudigonda <mmudigon@cisco.com>, Sudarsan Pa= ragiri <sparagiri@juniper.net>, Vengada Prasad Govindan <v= enggovi@cisco.com>, Santosh Pallagatti <santosh.pallagatti@gmail.com>


A new version of I-D, draft-ietf-bfd-vxlan-06.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=A006
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD for VXLAN
Document date:=C2=A0 2018-12-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-06.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-06
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-06

Abstract:
=C2=A0 =C2=A0This document describes the use of the Bidirectional Forwardin= g
=C2=A0 =C2=A0Detection (BFD) protocol in Virtual eXtensible Local Area Netw= ork
=C2=A0 =C2=A0(VXLAN) overlay networks.




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

--000000000000dd8595057df18408-- From nobody Thu Dec 27 15:06:02 2018 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 A00CE130E9D; Thu, 27 Dec 2018 15:05:55 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NGLV3NQay5WT; Thu, 27 Dec 2018 15:05:52 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 47C021294D0; Thu, 27 Dec 2018 15:05:49 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id x85-v6so17397368ljb.2; Thu, 27 Dec 2018 15:05:49 -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=gE+7jgWfV0FFXVF21XB7I0In+h3XuQI0hgjR5Hv9OjY=; b=CBOve3DmC8FG8h2wlpcj4gq15BlviE9OWm+u1igYtAKFWIocuJem9z/D6etDPRXtg0 V7NedfFKwvQ7dSYlEoyXG2crxFWxHOZQigax12bpndeEUzbNXP4buZ3m6R3tXawDFyyN FXAEwuufDMEs5VcVgZ2rHuuDAvMFzUtGdI7BjaORO/pdkoXT78KgwWbs6BkJ1QmwpWDp aG/ihV2koYDAO/fW0oAKVpz6wWAkrKY1wGFerzdrr330Ue8wOoK5HWw6QMmVHM3Vlm/n s9YHuq4GR0gEZ3OHqIBPVemqb7LbKzy1GmCguC3pq9IvLs4f4vJK/WbgUEvLeIRHoZLO EReQ== 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=gE+7jgWfV0FFXVF21XB7I0In+h3XuQI0hgjR5Hv9OjY=; b=apemrcZO9ifiOfjT0B5sCunT+5/bm3Uta0rU+Vi6rnCUl/qYTJzySUT2bbZStHobko NM01C+hVGd/3qOOp2v3hKWD2a+opZlAk6KiAaJyVkX6b7/dNo6+7ScwxllQcQlbwnSda ZmGd6NtnBqaCdLP4TH/9CCplqVUKLrGD+Th5KCNLr5FSbrJU+bzN4l/ojBHhA/NgNbLf oAPzTOfnZDeA9IbZr4HgmNAvODjenFiOfuDADyNjVF1Njl68G6p9gH6K1lSilGSIR0iC uSQ0bt1K/GTLimFCWKLNqCVLYhFGENyMWYPSRUJl0SMGpWNI8i4q+biYedufzJG1ndRS oXCQ== X-Gm-Message-State: AJcUukdHg7C9DGW/9Vze43GNPtjqghuFPR+V/8Dlohdxhg+MhqDEKhPE 7lheDHTuEXpv/YeoGWsDE3tQZnJwsPyd8T1xOSg= X-Google-Smtp-Source: ALg8bN7kM3PYSyTPiUW8pX/oTItmuk48qCjZiNNxJzte+Zuw7xCHHJ48mMRv3GtJiDyDaid7SI7nMHmm/yKGLCqzMTo= X-Received: by 2002:a2e:92ca:: with SMTP id k10-v6mr14427338ljh.63.1545951947259; Thu, 27 Dec 2018 15:05:47 -0800 (PST) MIME-Version: 1.0 References: <154545115049.20244.825410624604585914.idtracker@ietfa.amsl.com> In-Reply-To: <154545115049.20244.825410624604585914.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Thu, 27 Dec 2018 15:05:37 -0800 Message-ID: Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bfd-multipoint-19: (with COMMENT) To: Benjamin Kaduk Cc: The IESG , "Reshad Rahman (rrahman)" , draft-ietf-bfd-multipoint@ietf.org, rtg-bfd WG , bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a80252057e08fcef" 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: Thu, 27 Dec 2018 23:05:56 -0000 --000000000000a80252057e08fcef Content-Type: text/plain; charset="UTF-8" Hi Benjamin, thank you for the comments and suggestions. Please find my answers, notes in-line and tagged GIM>>. Would you agree I roll them in when working with the RFC Editor? Happy New Year to All! Regards, Greg On Fri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bfd-multipoint-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for addressing my Discuss points! The original Comment portion > of my ballot is preserved below for posterity. > > I am told that the normal usage of the bare term "BFD" has the connotation > of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing > pseudowires and other more "exotic" encapsulations), so I am not including > this in my DISCUSS section. However, it seems unusual to limit the scope > of a document in some "random" subsection (here, Section 5.8) with no > mention in the general Introduction or Abstract. Is there an improvement > to make here? > GIM>> Will add the following in the Introduction: This document defines IP/UDP encapsulation of BFD Control message in multipoint networks. Use of other types of encapsulation of the BFD Control message are outside the scope of this document. > > Section 4 > > [...] If no > BFD Control packets are received by a tail for a detection time, the > tail declares the path to having failed. For some applications this > is the only mechanism necessary; the head can remain ignorant of the > tails. > > It sounds like this might be better said as "the head can remain ignorant > of the status of connectivity to the tails"? (That is, the head needs to > know at least something about the tails in order to send anything to them, > so it is not fully ignorant.) > GIM>> Yes, agree. Would imagine that the head would stop sending BFD control messages if there's no, at least, one tail. Will update. > > The head of a multipoint BFD session may wish to be alerted to the > tails' connectivity (or lack thereof). Details of how the head keeps > track of tails and how tails alert their connectivity to the head are > outside scope of this document and are discussed in > [I-D.ietf-bfd-multipoint-active-tail]. > > nit: "outside the scope" > GIM>> Thank you. > > Section 5.7 > > It's a little unclear to me why tails must demultiplex on the identity of > the > multipoint path; (that is, why My Discriminator isinsufficient). > Presumably this is just a failing on my end, of course. > GIM>> My Discriminator is not globally unique as it is allocated per MultipointHead. Thus, it is possible, that a tail that belongs to several multipoint paths, will receive BFD control packets from different heads but with the same My Discriminator value. > > [...] Bootstrapping BFD session to multipoint MPLS LSP in > case of penultimate hop popping may use control plane, e.g., as > described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the > scope of this document. > > nit: some articles are missing here; maybe "a BFD session", "in the case > of", and "the control plane". > GIM>> Thank you, agree to all three. > > Section 5.12.2 > > MultipointTail sessions MAY be destroyed immediately upon leaving Up > state, since tail will transmit no packets. > > Otherwise, MultipointTail sessions SHOULD be maintained as long as > BFD Control packets are being received by it (which by definition > will indicate that the head is not Up). > > Would it be more clear to say "indicate that the head is not Up yet" to > distinguish from the case in the first paragraph (where a non-Up state > *transition* > GIM>> The second paragraph is to explain the behavior of a MultipointTail if the MultipointHead acts as described in section 5.12.1. Perhaps we can leave the text as is? > > Section 8 > > It may be appropriate to make stronger statements about the weakness of MD5 > than were valid at the time of 5880's publication. (SHA1 is also not doing > so great, but I won't block this work on updating the hash function > options.) > GIM>> Would the following text be acceptable (with both RFCs as Informational reference): Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm [RFC6151] and Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194] refer to the recent escalating series of attacks on MD5 and SHA-1 as the reason to consider stronger algorithms. It would be good to either refer to the bit about shared keys in Section 6 > or just move it to this section entirely. > GIM>> Merge sections 6 and 8? Section 7 will be removed in the final text and these sections become adjacent. Perhaps can leave them as is, would you agree? --000000000000a80252057e08fcef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,
thank you for the comments and = suggestions. Please find my answers, notes in-line and tagged GIM>>. = Would you agree I roll them in when working with the RFC Editor?
=
Happy New Year to All!

Regards,
Greg

On F= ri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Benjamin Kaduk has entered the followin= g ballot position for
draft-ietf-bfd-multipoint-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ie= tf-bfd-multipoint/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points!=C2=A0 The original Comment port= ion
of my ballot is preserved below for posterity.

I am told that the normal usage of the bare term "BFD" has the co= nnotation
of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing
pseudowires and other more "exotic" encapsulations), so I am not = including
this in my DISCUSS section.=C2=A0 However, it seems unusual to limit the sc= ope
of a document in some "random" subsection (here, Section 5.8) wit= h no
mention in the general Introduction or Abstract.=C2=A0 Is there an improvem= ent
to make here?
GIM>> Will add the following in th= e Introduction:
This document defines IP/UDP encapsulation o= f BFD Control message in multipoint networks. Use of other types of encapsu= lation of the BFD Control message are outside the scope of this document.

Section 4

=C2=A0 =C2=A0[...] If no
=C2=A0 =C2=A0BFD Control packets are received by a tail for a detection tim= e, the
=C2=A0 =C2=A0tail declares the path to having failed.=C2=A0 For some applic= ations this
=C2=A0 =C2=A0is the only mechanism necessary; the head can remain ignorant = of the
=C2=A0 =C2=A0tails.

It sounds like this might be better said as "the head can remain ignor= ant
of the status of connectivity to the tails"?=C2=A0 (That is, the head = needs to
know at least something about the tails in order to send anything to them,<= br> so it is not fully ignorant.)
GIM>> Yes, agree. = Would imagine that the head would stop sending BFD control messages if ther= e's no, at least, one tail.
Will update.=C2=A0

=C2=A0 =C2=A0The head of a multipoint BFD session may wish to be alerted to= the
=C2=A0 =C2=A0tails' connectivity (or lack thereof).=C2=A0 Details of ho= w the head keeps
=C2=A0 =C2=A0track of tails and how tails alert their connectivity to the h= ead are
=C2=A0 =C2=A0outside scope of this document and are discussed in
=C2=A0 =C2=A0[I-D.ietf-bfd-multipoint-active-tail].

nit: "outside the scope"
GIM>> Thank y= ou.=C2=A0

Section 5.7

It's a little unclear to me why tails must demultiplex on the identity = of the
multipoint path; (that is, why My Discriminator isinsufficient).
Presumably this is just a failing on my end, of course.
GIM>> My Discriminator is not globally unique as it is allocated pe= r MultipointHead. Thus, it is possible, that a tail that belongs to several= multipoint paths, will receive BFD control packets from different heads bu= t with the same My Discriminator value.

=C2=A0 =C2=A0[...] Bootstrapping BFD session to multipoint MPLS LSP in
=C2=A0 =C2=A0case of penultimate hop popping may use control plane, e.g., a= s
=C2=A0 =C2=A0described in [I-D.ietf-bess-mvpn-fast-failover], and is outsid= e the
=C2=A0 =C2=A0scope of this document.

nit: some articles are missing here; maybe "a BFD session", "= ;in the case
of", and "the control plane".
GIM>&g= t; Thank you, agree to all three.=C2=A0

Section 5.12.2

=C2=A0 =C2=A0MultipointTail sessions MAY be destroyed immediately upon leav= ing Up
=C2=A0 =C2=A0state, since tail will transmit no packets.

=C2=A0 =C2=A0Otherwise, MultipointTail sessions SHOULD be maintained as lon= g as
=C2=A0 =C2=A0BFD Control packets are being received by it (which by definit= ion
=C2=A0 =C2=A0will indicate that the head is not Up).

Would it be more clear to say "indicate that the head is not Up yet&qu= ot; to
distinguish from the case in the first paragraph (where a non-Up state
*transition*
GIM>> The second paragraph is to ex= plain the behavior of a MultipointTail if the MultipointHead acts as descri= bed in section 5.12.1. Perhaps we can leave the text as is?=C2=A0

Section 8

It may be appropriate to make stronger statements about the weakness of MD5=
than were valid at the time of 5880's publication.=C2=A0 (SHA1 is also = not doing
so great, but I won't block this work on updating the hash function
options.)
GIM>> Would the following text be acce= ptable (with both RFCs as Informational reference):
=C2=A0 Update= d Security Considerations for the MD5 Message-Digest and the HMAC-MD5
=
=C2=A0 =C2=A0Algorithm [RFC6151] and Security Considerations for the S= HA-0 and
=C2=A0 =C2=A0SHA-1 Message-Digest Algorithm [RFC6194] re= fer to the recent escalating series of
=C2=A0 =C2=A0attacks on MD= 5 and SHA-1 as the reason to consider stronger algorithms.

It would be good to either refer to the bit about shared keys in Section 6<= br> or just move it to this section entirely.
GIM>> = Merge sections 6 and 8? Section 7 will be removed in the final text and the= se sections become adjacent. Perhaps can leave them as is, would you agree?=
--000000000000a80252057e08fcef--