Re: WGLC for BFD Multipoint documents (last round)

Greg Mirsky <gregimirsky@gmail.com> Mon, 29 January 2018 18:04 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4839612FA94 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Jan 2018 10:04:12 -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 0w-Whjrge_h3 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Jan 2018 10:04:05 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 55E8012FA83 for <rtg-bfd@ietf.org>; Mon, 29 Jan 2018 10:04:04 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id 63so11311684lfv.4 for <rtg-bfd@ietf.org>; Mon, 29 Jan 2018 10:04:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=urClA5bVJmFGYBUISIn7oY3ymkwRtgklgvVFHwQZBwQ=; b=numU9dj8DWl5evLPO13pQaED055G9592hJuMX7ni5PCZP32EYbgN8ClzVe3y1QuHmr lCnvH43FuHy5aiQ6juaOvBrqN7jaTwmZOJJrKLXJ4ZUv1xZrFO4g/nFMZwKsCEhEo7TA qNXReRjceqLpePqKVcRLrrSTxKRER7NT9rlgRja1fefxLf20iJYmRRY4IUmKQssoCEmJ g+ywG6DXY3Me8L9ItkCTXtyslBdLgiKfHJnAWl9zQPN96EWA0YAfb4EEWoCFWT8zVCUn Tgw+2c3BL3VOzG3FzG6K4TPS2h2PQJASchbuqMwlHe+QksW81wwn8ppJmEp/g0pFdp4k RrCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=urClA5bVJmFGYBUISIn7oY3ymkwRtgklgvVFHwQZBwQ=; b=tGm1q0K3uJ2nAfFyTRCgwJmPC/hU3dg4QAcc8FzYlslvWRamMHb4CTShs2Ta6JA+iq UwGjh7A+O8WFn7UcFXTLdLKb4jCH856uhMXlqBiRt0IJScZAYo93+eeFNUdMoXnEvlXc qd5p7APpTHf3UiujoCanOFlmhvHxyKnoxDsxBEPAMZq9ZpovBGd1CbK0LfhkbnHnoaou N4t31vn8Du3iHJyGXqOXB+aHzkkBMxBUPLLKNSsopmTdt8C9jvUnADIrLnOoJk0vxQdO i/wdJX0aSDefP5Efgg9ufNsIsuArsJH8QRWv8M4zYeQcu/nvXmYWXg7RHqGt+d0hr/Mw ybWg==
X-Gm-Message-State: AKwxytelbkJz7c8lWyA2gC62OBQsKlwc6hqEByuvDD5Arw9ahzF8d9pp wRMN9YtonQZo9OFMcono4Xx7m9P7q0wryP1lli4=
X-Google-Smtp-Source: AH8x227uNCUBjEkINmImHfq2eHIL22Gjq403S7rY5AMmqZohSgILGfg2/2vzpffLx59mR9xFRXIJNGPrUMfFUVSRrLY=
X-Received: by 10.46.68.93 with SMTP id r90mr6381218lja.13.1517249042095; Mon, 29 Jan 2018 10:04:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.83.91 with HTTP; Mon, 29 Jan 2018 10:04:01 -0800 (PST)
In-Reply-To: <7F1C8A95-18DE-42D0-9DF5-A6920ED4029F@cisco.com>
References: <20171213172443.GC8708@pfrc.org> <CA+RyBmX6PHczvwEzc4UNqBioK8qv=wTfyeHg9j04EJNe1Uv0wA@mail.gmail.com> <746F74E2-7DFC-41A7-879F-4054CF95475C@cisco.com> <CA+RyBmWqGPTkBek+a0N+BaFr9QZ+xEKvWT5oRxPBuhFsQcizcw@mail.gmail.com> <38B53F72-66B9-4E8F-8BCE-C28A2C283D38@cisco.com> <20171219160537.GH8708@pfrc.org> <CA+RyBmWQTH9N9cCOHJ_9BgvfDGLGFgrsKrMj8mmqGm-V=5KLSw@mail.gmail.com> <20171220171322.GE8708@pfrc.org> <7C073038-8E7D-4735-82A4-97592AA9B34B@cisco.com> <CA+RyBmXanVpKKmyXP9+yuh4z2H4qAeN4jH2xEMx7ddiSHViV3g@mail.gmail.com> <DB3B0F10-4BD8-4096-8875-2E476064E77A@cisco.com> <491F0297-F2AB-4377-A013-1050FDBBB709@cisco.com> <CA+RyBmVXO0o09k-DYY69E2sKdKiU5YBf-h=PnBgerx+HF=ryfg@mail.gmail.com> <44B4B608-7A2B-4E95-A5F7-116896C57028@cisco.com> <0714A770-BF3F-4EF8-A302-A478439A5B13@cisco.com> <5F69E3D1-19E1-45F7-926D-61449E1F09B2@cisco.com> <CA+RyBmWMwom+2=jWHfvSr9AG=WPCnhYJ6uC9HVonVFh9McaysQ@mail.gmail.com> <E14FF8C0-082B-4D52-89F6-0CBAF9CD4181@cisco.com> <CA+RyBmUOpBgVho0SPsp9FB=ymFV29q_2EY2k8uOf-O4gfpTmyw@mail.gmail.com> <CA+RyBmXs_gRjeUk9gx0653WkvjDfztD-cgNw=mNX+66Whj_AFw@mail.gmail.com> <639B40D7-F79B-4546-93B3-55812C880217@cisco.com> <CA+RyBmUEG2L4ExWRCvLYVMs=BL5OsGRpfD0a9RLEvu+4Avhy9A@mail.gmail.com> <E816D829-7F6D-478A-9DE6-F5C5A177B981@cisco.com> <CA+RyBmUeJi5Rttr+5PiNUBEo1cr10pvcg=twC3Biz+c6xT7iGQ@mail.gmail.com> <28FBFF19-27FD-41DB-A0CF-29DC3CED119A@cisco.com> <CA+RyBmVh_uKZ8rT+03YhhF4W6qiDBRmeK9BtbUEo_ZuTdzkfBw@mail.gmail.com> <A44E5437-C394-4110-9FFC-99EA06D8186D@cisco.com> <CA+RyBmVNU6bt2KVw+=xsFU0J3fmoBNX9QP8GF+eCbPzbyWTSjg@mail.gmail.com> <7F1C8A95-18DE-42D0-9DF5-A6920ED4029F@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 29 Jan 2018 10:04:01 -0800
Message-ID: <CA+RyBmXyT4UbfP_y7KuuoABp1TQ5db2x_R-4az-bGP=7d2ssGQ@mail.gmail.com>
Subject: Re: WGLC for BFD Multipoint documents (last round)
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1a682830b5910563ee12b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nHDq2YDmR-k-nIsn5YmYiL-1J7M>
X-Mailman-Approved-At: Mon, 29 Jan 2018 11:47:56 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 18:04:12 -0000

Hi Reshad,
nits fixed and the new text below:
OLD TEXT
A number of values of the state variable are added to the base BFD…
NEW TEXT
A number of new values of the state variable bfd.SessionType are added to
the base BFD…
Would you accept this update?

Regards,
Greg

On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <rrahman@cisco.com>;
wrote:

> Hi Greg,
>
>
>
>    - Section 4.2. s/The head has a session of type MultipointHead Section
>    4.4.1/ The head has a session of type MultipointHead, as defined in Section
>    4.4.1, /
>    - Section 4.4.1. “A number of values of the state variable are added
>    to the base BFD…”. That sentence needs rewording IMO but maybe I’m just
>    missing what it’s trying to convey.
>    - Section 4.6. s/Active role , / Active role, /
>    - Section 4.10. “MUST send packets with P bit set.”. Did we agree on
>    “MUST send packets with *the* P bit set.”?
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Saturday, January 27, 2018 at 11:38 PM
>
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> many thanks for your guidance and support. Should I upload the new version
> of the draft?
>
>
>
> Kind regards,
>
> Greg
>
>
>
> PS. Diff and the current working version are attached.
>
>
>
> On Sat, Jan 27, 2018 at 6:36 PM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>; wrote:
>
> Thanks Greg. PSI <RR2>.
>
>
>
> I think we’ve closed on these comments.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Friday, January 26, 2018 at 7:42 PM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad, et. al,
>
> thank you for your kind consideration of the update. I'm applied all the
> changes you've agreed to. Remaining are few nits I wanted to confirm with
> you and one update that is not editorial:
>
> In 4.13.1
> <https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.13.1>;.
> Reception of BFD Control Packets
>
> OLD TEXT:
>
> Else (bfd.SessionType is not PointToPoint)
>
> NEW TEXT
>
> Else (bfd.SessionType is MultipointTail)
>
> Please find my notes in-line tagged GIM2>>.
>
>
>
> Kind regards,
>
> Greg
>
>
>
> On Fri, Jan 26, 2018 at 7:14 AM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>; wrote:
>
> Hi Greg,
>
>
>
> Thank you for the prompt response. The changes look good. Some nits I may
> missed during my review and nits on new rev:
>
>    - 3 Overview. s/Details of how head keeps track/Details of how heads
>    keep track/ (or if singular “of how a head keeps track”)
>
> GIM2>> I think that singular is consistent with the preceding sentence 'A
> head may wish to be alerted to the tails' connectivity (or lack thereof).'
> And because there's 'a head' should the next reference be 'the head', thus
> making 'Details of how the head keeps track ...'?
>
> <RR2> Good.
>
>
>    -
>    - 4.2 Session Model. References to Section 4.4.1 were added but
>    consider making a change e.g adding () around the reference or “, as
>    defined in Section 4.4.1, “ .
>
> GIM2>> Done
>
>
>    -
>    - 4.4.1 New State Variable Values. First paragraph starts “A number
>    values of the state variable are added to the base BFD…”. Should be “A
>    number of values…”? Or reword that paragraph to something along the lines
>    of “A number of values are added to some existing state variables defined
>    in the base BFD…”
>
> GIM2>> Used the former 'A number of values ...'
>
> <RR2> Ack.
>
>
>    -
>    - 4.10 Timer Manipulation. s/However to indicate a change in the
>    packets MultipointHead session MUST send packets with P bit set.
>    MultipointTail session/However to indicate a change in the packets,
>    MultipointHead sessions MUST send packets with the P bit set.
>    MultipointTail sessions/
>
> GIM2>> Or should it be 'However, to indicate a change in the packets,
> MultipointHead MUST send packets with the P bit set.'?
>
> <RR2> Good.
>
>
>    -
>
>
>
> Please see inline <RR>.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Thursday, January 25, 2018 at 4:46 PM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> sincere thank you for your help and support. In this note I'll address
> Shepherd Write-up on BFD for Multipoint Networks draft (active tails will
> be addressed in the separate response shortly). Please find my responses to
> your comments in-line tagged GIM>>. Attached are diffs to the updated
> version and the current working text.
>
>
>
> : (16) Will publication of this document change the status of any
>
> : existing RFCs? Are those RFCs listed on the title page header, listed
>
> : in the abstract, and discussed in the introduction? If the RFCs are not
>
> : listed in the Abstract and Introduction, explain why, and point to the
>
> : part of the document where the relationship of this document to the
>
> : other RFCs is discussed. If this information is not in the document,
>
> : explain why the WG considers it unnecessary.
>
> This document will update RFCs 5880 and 7880. They are not in the title
> page header.
>
> GIM>> Fixed.
>
>
>
> - General. There are a few instances where singular is used instead of
> plural (e.g. for session, packet) and also where “a” or “the” is missing. I
> have tried to indicate all such occurrences below.
>
> - General. A few sentences have the period ‘.’ before the closing
> parenthesis instead of after, e.g.  in 4.9 “(… than it did previously.)”. I
> have not called out all of them, search for “.)”
>
> GIM>> Got 10+ of those
>
>
>
> - General. s/this protocol/Multipoint BFD/?
>
> GIM>>
>
> - General. Use of term tree e.g. multipoint tree. Should we use path
> instead?
>
> - Abstract. Remove “Comments on this draft…”
>
> GIM>> Done
>
> - 1 Introduction. “Details of tail notification…”. Add reference to
> draft-ietf-bfd-multipoint-active-tail?
>
> GIM>> Current text puts them outside the scope. I agree that alternative
> may be to point to draft-ietf-bfd-multipoint-active-tail directly, though
> then we have new informational reference. Perhaps
>
> OLD TEXT
>
> Details of tail notification to head are outside the scope of this
> document.
>
> NEW TEXT
>
> Details of tail notification to head are outside the scope of this
> document and are discussed in [I_D.ietf-bfd-multipoint-active-tail].
>
>
>
> Acceptable?
>
> <RR> Yes.
>
>
>
> - 1 Introduction. s/is not being used in context/is not being used in the
> context/
>
> GIM>> Done
>
> - 1 Introduction. Add reference to [RFC5880] after “… and adds to the base
> BFD specification.”
>
> GIM>> Done
>
> - 1 Introduction. Remove “It is the intention of the authors to fold…”
>
> GIM>> Done
>
> - 2 Goals. Not sure about “multicast or multipoint medium”, maybe
> “multipoint or multicast path”?
>
> GIM>> Would "Another goal is for the mechanism to work on any multipoint
> network segments or multicast technologies" work?
>
> <RR> I am fine with something along the lines of "Another goal is for the
> mechanism to work on any multicast technology."
>
>
>
> - 2 Goals. “… multipoint paths with multiple heads” should that be
> “multipoint-to-multipoint”?
>
> GIM>> Yes, indeed. Would referring to multipoint explicitly as
> point-to-multipoint make it more clear?
>
> OLD TEXT
>
> A further goal is to support multiple, overlapping multipoint paths, as
> well as multipoint paths with multiple heads...
>
> NEW TEXT
>
> A further goal is to support multiple, overlapping point-to-multipoint
> paths, as well as multipoint-to-multipoint paths  ...
>
> <RR> Yes.
>
>
>
> - 2 Goals. Remove “A final goal is to integrate multipoint operation…”. If
> this is still relevant we need clarification on how this is being done. May
> need to also explain what is meant by “relatively easy”
>
> GIM>> Agree and done.
>
> - 2 Goals. s/any tails/any tail/
>
> - 2 Goals. s/It is a non-goal/It is not a goal/?
>
> GIM>> Done and done
>
> - 3 Overview. s/Details of how head keeps track/Details of how heads keep
> track/. Add reference to draft-ietf-bfd-multipoint-active-tail after that
> sentence?
>
> GIM>> Not sure that changing to plural in this sentence is warranted. I
> interpret it as reference to a single p2mp BFD session. Would you agree?
>
> <RR> You’re right, no need for plural. So “Details of how a head keeps
> track”?
>
>
>
> GIM>> RE: reference to the active tails draft. As noted above, it will
> introduce new informational reference. Any concern with that?
>
> <RR> No need for reference to active-tail.
>
>
>
> - 3 Overview. s/Head may wish/A head may wish/
>
> GIM>> Done
>
> - 3 Overview. s/it’s connectivity/its connectivity/
>
> GIM>> I think that more extensive change is required here:
>
> OLD TEXT
>
> ... how tails alert it's connectivity to head ...
>
> NEW TEXT
>
> ... how tails alert their connectivity to the head ...
>
> or
>
> ... how tail alerts its connectivity to the head ...
>
> Acceptable? Which one?
>
> <RR> I’d go for “…how tails alert their connectivity to the head…”.
>
>
>
> - 4.1 Multipoint BFD Control Packets. Add reference to [RFC5880] after
> “…via the setting of the M bit.”
>
> GIM>> Done
>
> - 4.2 Session Model. s/from the head over multicast path/from the head
> over the multicast path/.
>
> - 4.2 Session Model. MultipointHead and MultipointTail: add reference for
> each to section 4.4.1 where they are defined.
>
> GIM>> Done and done
>
>
>
> - 4.4.1 New State Variables. Already discussed splitting this into new
> variables and new values.
>
> - 4.4.1 New State Variables. Already discussed taking bfd.SilentTail out
> of draft-ietf-bfd-multipoint
>
> - 4.4.2 State Variable Initialization and Maintenance. s/defined in
> section 6.8.1 of the [RFC5880] needs/defined in section 6.8.1 of [RFC5880]
> need/
>
> GIM>> Done
>
> - 4.5 State Machine. s/Session of type/Sessions of type/
>
> - 4.5 State Machine. s/and must be ignored/and MUST be ignored/
>
> GIM>> Done and done
>
> - 4.5 State Machine. Should there be a state machine for the head or is it
> too simple since no packets are received from tail? e.g. if the multipoint
> path goes down does the MultipointHead session go down?
>
> GIM>> I think that the very last sentence addresses your question:
>
>    Sessions of type MultipointHead never receive packets and have no
>
>    Detection Timer, and as such all state transitions are
>
>    administratively driven.
>
> <RR> Ack.
>
>
>
> - 4.6 Session Establishment. s/Unlike Point-to-point/Unlike point-to-point/
>
> GIM>> Done
>
> - 4.6 Session Establishment. “Except when terminating BFD service…”, does
> terminating mean shutting down (as in admin down)?
>
> GIM>> Yes, I think that is exactly as you've described. Should that be
> clarified, e.g. "Except when administratively terminating BFD service ..."?
>
> <RR> “Except when administratively terminating the BFD service”?
>
>
>
> - 4.6 Session establishment. Active and passive roles: add reference to
> the appropriate section of [RFC5880].
>
> GIM>> Like to Section 6.1 Overview in RFC 5880? How I would refer to the
> particular section in XML?
>
> <RR> Just reference to [5880] is fine.
>
>
>
> - 4.7 Discriminators and Packet Demultiplexing. s/over the MultipointHead
> session with/over the Multipoint path va the MultipointHead session with/
>
> GIM>> Done as s/over the MultipointHead session with/over the multipoint
> path via the MultipointHead session with/
>
>
>
> - 4.7. s/PointToPoint/point-to-point/. PointToPoint is to be used only
> when referring to bfd.SessionType.
>
> - 4.7. s/Bootstrapping BFD session to a multipoint LSP/Bootstrapping a BFD
> session to multipoint MPLS LSP/
>
> - 4.8 Packet consumption on tails. s/for a multicast group/for an IP
> multicast group/
>
> - 4.8. s/For multipoint LSP/For multipoint LSPs/
>
> - 4.8. s/encapsulation of BFD control packet/encapsulation of BFD control
> packets/
>
> GIM>> Done to all the above
>
> - For IPv4/IPv6 address range, add reference to [RFC5884]?
>
> GIM>> I think that first use of martian addresses as IP DA was for LSP
> Ping RFC4379 now RFC8029. Should refer to RFC8029?
>
> <RR> Yes.
>
>
>
> - 4.8. s/Packet identified as BFD packet/Packets identified as BFD packets/
>
> - 4.8. s/used,/is used,/
>
> GIM>> Done and done
>
> - 4.10 Timer Manipulation. s/However to indicate change in packet/However
> to indicate a change in the packets, /
>
> - 4.10. s/MUST send packet with P bit/MUST send packets with P bit/
>
> - 4.10/ s/MultipointHead MAY also/A MultipointHead session MAY also/
>
> GIM>> Done * 3
>
> - 4.11 Detection times. s/Since the MultipointHead session never receives
> packets, it does not/Since MultipointHead sessions never receive packets,
> they do not/
>
> - 4.11 Detection times. s/the Detection Time/the detection time/
>
> GIM>> Done and done
>
> - 4.13 Base Specification Text Replacement. Clarify here or in the
> introduction that processing for point-to-point BFD does NOT change.
>
> GIM>> Please check if the following update is acceptable
>
> OLD TEXT
>
> The following sections are meant to replace the corresponding sections in
> the base specification
>
> NEW TEXT
>
> The following sections are meant to replace the corresponding sections in
> the base specification [RFC5880]
>
> in support of BFD for multipoint networks while not changing processing
> for point-to-point BFD.
>
> <RR> Ack.
>
>
>
> - 4.13.1. Add reference to [RFC5880] before mentioning section 6.7, e.g
> “under of rules of section 6.7 of [RFC5880]”
>
> GIM>> Done on two occurences
>
> - 4.13.2 P14. If the State field is Init and bfd.SessionType is not
> PointToPoint. Instead of checking “is not PointToPoint” should we check “is
> MultipointTail”? Otherwise this has an impact on S-BFD?
>
> GIM>> I agree. Should we get WG confirmation as for technical update or it
> is editorial?
>
> <RR> WG confirmation would be good.
>
> - 7 Security Considerations. s/ex:/e.g./
>
> GIM>> Done
>
> - 7 Security Considerations. Should we add at the beginning “The same
> security considerations as those described in [RFC5880] apply to this
> document. Additionally …”?
>
> GIM>> Agreed and done
>
>
>
> On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>; wrote:
>
> Hi,
>
>
>
> I forgot to mention that last week I did the shepherd write-up for both
> drafts.
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
> shepherdwriteup/
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-
> active-tail/shepherdwriteup/
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Tuesday, January 16, 2018 at 11:01 PM
>
>
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> sorry for my sloppiness. Fixed.
>
>
>
> Regards, Greg
>
>
>
> On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> wrote:
>
> Hi Greg,
>
>
>
> In 4.4.1 of MP, “A number values of the state variable are added to the…”,
> looks like there is a missing “of”?
>
>
>
> For the active-tail draft I haven’t completed my review of -06 yet: there
> are parts which aren’t clear to me and I don’t know yet if this is because
> there’s something missing in the document or whether it’s just lack of
> understanding on my part.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Tuesday, January 16, 2018 at 9:25 PM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad, et. al,
>
> the attached are diff to highlight updates to BFD in Multipoint Network
> and the working copy of Active Tails. After checking through the Active
> Tails draft, I've found no additional changes to make resulting from
> removing all references to bfd.SilentTail from BFD in Multipoint Networks
> draft. Your review and comments are most welcome.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky <gregimirsky@gmail.com>;
> wrote:
>
> Hi Reshad,
>
> thank you. I'll add it into the working version to others updates. I
> believe changes to active tails be more extensive as now it must introduce
> the bfd.SilentTail variable, not just its new state. Will work on that now.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>; wrote:
>
> Hi Greg,
>
>
>
> I am fine with the change below.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Tuesday, January 16, 2018 at 2:20 PM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
>
>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> I think this is very good idea. Then in section 4.13.3 Transmitting BFD
> Packets of BFD for Multipoint Networks should be edited. Perhaps the
> following be acceptable:
>
> OLD TEXT
>
>    A system MUST NOT transmit any BFD Control packets if bfd.SilentTail
>
>    is 1.
>
> NEW TEXT
>
>    A system MUST NOT transmit any BFD Control packets if bfd.SessionType is
>
>    MultipointTail.
>
> Will look into related changes in active tails if others agree with the proposal in general.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) <
> rrahman@cisco.com>; wrote:
>
> Regarding bfd.SilentTail, I am wondering if instead it should be removed
> from MP draft  (always 1 in there) and kept as new state variable in
> active-tail?
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Date: *Tuesday, January 16, 2018 at 9:32 AM
> *To: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;, Greg Mirsky <
> gregimirsky@gmail.com>;
> *Cc: *Jeffrey Haas <jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
>
>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Greg,
>
>
>
> The changes for bfd.SessionType (in both drafts) look good.
>
>
>
> bfd.SilentTail is fine in multipoint but in active-tail it is in the New
> State Variables section.  It should be in 3.3.2 instead and there should be
> a reference to the multipoint draft.
>
>
>
> Also, I am in the process of doing the shepherd write-up. So you don’t
> have to push these changes immediately, you can wait for the review, up to
> you.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>;
> *Date: *Tuesday, January 16, 2018 at 1:47 AM
> *To: *Greg Mirsky <gregimirsky@gmail.com>;
> *Cc: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;, Jeffrey Haas <
> jhaas@pfrc.org>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Looks good to me, Greg. Thanks.
>
> Thumb typed by Carlos Pignataro.
>
> Excuze typofraphicak errows
>
>
> On Jan 16, 2018, at 15:32, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>
> Hi Reshad and Carlos,
>
> thank you for your suggestions. Please check the diffs with proposed
> changes to BFD Multipoint and BFD Multipoint with active tails drafts
> (attached).
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com>; wrote:
>
> Reshad, Greg,
>
>
>
> Indeed, it seems the content of the section is updated, but the title is
> misleading. The same applies to the active-tail doc:
>
>
>
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-
> active-tail-06#section-3.3.1
>
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1
>
>
>
> Thanks,
>
>
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>
> On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) <rrahman@cisco.com>;
> wrote:
>
>
>
> Hi Greg,
>
>
>
> Section 4.4.1 still says “New state variables” for bfd.SessionType and the
> text still starts with “A number of state variables and their values are
> added…”, so I misinterpreted that as bfd.SessionType is being added as new
> state variable.
>
>
>
> Please consider splitting this section in 2 parts for clarification e.g.
> 4.4.1 for New State Variables (bfd.SilentTail) and 4.4.2 for New State
> Variable Values (bfd.SessionType).
>
>
>
> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-12#section-4.4.1
>
>
>
> Regards,
>
> Reshad.
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Monday, January 15, 2018 at 6:17 PM
> *To: *"Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> *Cc: *Jeffrey Haas <jhaas@pfrc.org>;, "Carlos Pignataro (cpignata)" <
> cpignata@cisco.com>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
>
>
> Hi Reshad,
>
> I thought I've addressed them as per Carlos suggestion. Have I missed
> anything?
>
>
>
> Regards, Greg
>
>
>
> On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" <rrahman@cisco.com>;
> wrote:
>
> The changes for bfd.SessionType (it’s not a new state variable but uses
> what’s defined in RFC7880) weren’t made in the latest revision.
>
> Greg, do you plan on addressing this soon? Or there’s no consensus on this
> topic yet?
>
> Regards,
> Reshad.
>
> On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" <
> rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org>; wrote:
>
>     Greg,
>
>     On Tue, Dec 19, 2017 at 02:17:02PM -0800, Greg Mirsky wrote:
>     > Hi Carlos and Jeff,
>     > thank you for responding so expediently. I think we've reached the
> rough
>     > consensus. Attached are the diffs for both BFD documents and the
> updated
>     > copies. Please let me know if the changes being made have addressed
> all the
>     > comments received during the WGLC. I'll then upload new versions.
>
>     I believe this covers all points I've seen on the mailing list to date.
>
>     Please push the updates.
>
>     We'll have further discussion about the need for a registry in
> conjunction
>     with the Yang module implications discussion.
>
>     -- Jeff
>
>     > On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <jhaas@pfrc.org>;
> wrote:
>     [...]
>     > > At this point it is also worth noting that the session type has no
>     > > centralized location covering their enumerations.  This leads to
> two
>     > > interesting observations:
>     > > - We could have an IANA registry for such things.  However, I'm
> not sure
>     > >   this is really need.  But this also means:
>     > > - Here's another case why some pieces of the BFD yang module
> likely shoudl
>     > >   be IANA maintained.  In this case, the bfd-path-type identity as
> the
>     > >   relevant example.
>
>
>
>
>
> <Diff_ draft-ietf-bfd-multipoint-active-tail-06.txt -
> draft-ietf-bfd-multipoint-active-tail-07.txt.html>
>
> <Diff_ draft-ietf-bfd-multipoint-12.txt - draft-ietf-bfd-multipoint-13.
> txt.html>
>
>
>
>
>
>
>
>
>
>
>
>
>