Re: WGLC for BFD Multipoint documents (last round)

Greg Mirsky <gregimirsky@gmail.com> Sat, 27 January 2018 00:42 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 149B112D7F0 for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Jan 2018 16:42:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 lwsW-ppqr9gu for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Jan 2018 16:42:33 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 97D4F12AF84 for <rtg-bfd@ietf.org>; Fri, 26 Jan 2018 16:42:32 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id o89so2738482lfg.10 for <rtg-bfd@ietf.org>; Fri, 26 Jan 2018 16:42:32 -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=uBkY/aT77vDCawi6aaDnNeoGn0fBYrmjCtr4HsjxVj8=; b=VYAlclKjof1sitVNoajf6XMLogiTRHwGhFR2G/3gdzs84pMKbrkSDV4Cg9+YoJC8I9 YgjCMwS2Pp8EUr7kecAg9Der+uTBiScCTnwGRdvX+VtKTrmN8jewDeqv0jdz27LeTwhZ 2DnCZP2Bi4lWAmKdrUtrSkFQt61a0BrWjN8h1rNeYEXHKO7shPG+7QbINGHR0GHLYwWy SWJ1SJMW793fVyaSKImXBAU+wJF5XOsw+TdB5LesYAVleEYMal0IhOFDZLd/4CiSrtHE efd7nd4T1kIERttpNteskxnuO3eoLPMI6OyzI7kXfoAuMjxvbS2LYndSieewCmI9rZqD FJsw==
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=uBkY/aT77vDCawi6aaDnNeoGn0fBYrmjCtr4HsjxVj8=; b=oRccWhlnJC4sTFydFFHT53mpPmVul/ylseHGkweu95s4XSv9xGaIEMgIwzJPAuBjgf 0NHA3zZx01S5EGHCqB4P+7y2Tp88SiDo0/SlJc0G6UQ3nfx/9knZXZNua7JQWEGSQrtz ng7B+Zu0DjT50LZpaTsBAQZZ8LsyaaqxTnYn+x+ckRAqPBWJqGsoakWNqW8ctC00t44Z HIfKZsyxZ/TaZevI0ePichptHTWkS+dGOuhfakM5Xhy+wB4IunirWy4vnz5zR7ydrUPs lDyTf03NGYWLmmdcnlT/HPPgE5/1B7blJDyxqXKNARfc6IAwuy5iv6b9Sf1kpxSdr9jm CCuA==
X-Gm-Message-State: AKwxytcXQCdOAj3kWsfv4A6ZGw2uRyMEjAPl1KEECn4AHBM7tj/v1OEp jh44IcSB5O2WsHgR+hAXkp2BeO8yiJuSPHI+Oh8=
X-Google-Smtp-Source: AH8x226Yw2IQFlBwdp5eZgXBQuELB/2s+hPThDYIsirs4TH1z3QQ1QvOWjuvWLQtAOns+ZBWFU9KG1QvX8GAR6K50IM=
X-Received: by 10.25.161.84 with SMTP id k81mr9589901lfe.127.1517013750536; Fri, 26 Jan 2018 16:42:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.21.94 with HTTP; Fri, 26 Jan 2018 16:42:29 -0800 (PST)
In-Reply-To: <28FBFF19-27FD-41DB-A0CF-29DC3CED119A@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>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 26 Jan 2018 16:42:29 -0800
Message-ID: <CA+RyBmVh_uKZ8rT+03YhhF4W6qiDBRmeK9BtbUEo_ZuTdzkfBw@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="001a114104f0b8639f0563b74924"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/LVVCMB3FS_YCGIx8P_Zjt3XK1X0>
X-Mailman-Approved-At: Fri, 26 Jan 2018 18:31:45 -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: Sat, 27 Jan 2018 00:42:38 -0000

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 ...'?

>
>    -
>    - 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 ...'

>
>    -
>    - 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.'?

>
>    -
>
>
>
> 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>
>
>
>
>
>
>
>
>
>