Re: WGLC for BFD Multipoint documents (last round)

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 29 January 2018 13:54 UTC

Return-Path: <rrahman@cisco.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 030011318D4 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Jan 2018 05:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NqgNYtxnH-y4 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Jan 2018 05:54:51 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087321318F9 for <rtg-bfd@ietf.org>; Mon, 29 Jan 2018 05:52:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=163204; q=dns/txt; s=iport; t=1517233962; x=1518443562; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6w5b0pYnQruLdMs0YHsKgXE4cxweQbhn36zEOzt2FXw=; b=IgRfwoB/1WjuDW7z1jnDMi8g05Ck7lB9u8WtsdIacG0PRiMZYXIYrAkI 26VDIYe9KZVfwIBn6qS9PzqaOV++TU9nbSASqHVAX6iHILFTV1iTV9OUN 7zISM9NN8w+F2lS9lkcro0ETyhbDHLUqkoTDceF3W1136b5qrqWU41RT+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAwCwJm9a/5RdJa1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSkcELWZ1KAqDFEKZDYICiROOMRWCAgolhRYCGoIbVhYBAQE?= =?us-ascii?q?BAQEBAQJrKIUjAQEBAwEMDgEICkECAgEGBQsCAQYCEQMBAgEgAQYDAgICHxEUC?= =?us-ascii?q?QgCBA4FiVFMAw0IEIgQnXGCJyaHDQ2DEwEBAQEBAQEBAQEBAQEBAQEBAQEBARg?= =?us-ascii?q?FhFSCFYFXgWcBKYMFgmtEAQECAQGBQxImCQkGEAKCXzGCFCAFi2uOEReJRD0Ci?= =?us-ascii?q?BaISYUGghuGIYVWhEGBVosBgmFGiQ0CERkBgTsBJgIwJYErcBUZJCoBgW8BDwm?= =?us-ascii?q?CTByBCgECeAF4AQGNfQGBFgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.46,431,1511827200"; d="scan'208,217"; a="62597288"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2018 13:52:40 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w0TDqeMa019750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Jan 2018 13:52:40 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 29 Jan 2018 07:52:39 -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.1320.000; Mon, 29 Jan 2018 07:52:39 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.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)
Thread-Topic: WGLC for BFD Multipoint documents (last round)
Thread-Index: AQHTdDbMQKkp4UZhy0e3Kn8Lrj3T1qNFVBAAgABtnICAASUEgIADdUKAgADmoICAAGfFAIABPX0AgCk9u4CAAASiAIAAK1EAgAAqqgCAACNngIAABGqAgACB1oCAAEjuAIAAB2UAgAAsZQCAAA7FAIAAO8sAgAALOICAAA9fAIAMOY6AgAGCuACAASTJgIAAntGAgAGyGYCAACIhAIACLSSA
Date: Mon, 29 Jan 2018 13:52:39 +0000
Message-ID: <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>
In-Reply-To: <CA+RyBmVNU6bt2KVw+=xsFU0J3fmoBNX9QP8GF+eCbPzbyWTSjg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.65]
Content-Type: multipart/alternative; boundary="_000_7F1C8A9518DE42D09DF5A6920ED4029Fciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/u0zXXFTyJTaDZ5YfTkBoLSUvGoc>
X-Mailman-Approved-At: Mon, 29 Jan 2018 05:56:44 -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 13:54:58 -0000

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<mailto:rrahman@cisco.com>> wrote:
Thanks Greg. PSI <RR2>.

I think we’ve closed on these comments.

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Friday, January 26, 2018 at 7:42 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:gregimirsky@gmail.com>>
Date: Thursday, January 25, 2018 at 4:46 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:gregimirsky@gmail.com>>
Date: Tuesday, January 16, 2018 at 11:01 PM

To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:gregimirsky@gmail.com>>
Date: Tuesday, January 16, 2018 at 9:25 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:rrahman@cisco.com>> wrote:
Hi Greg,

I am fine with the change below.

Regards,
Reshad.

From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Tuesday, January 16, 2018 at 2:20 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:rrahman@cisco.com>>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto:cpignata@cisco.com>>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:gregimirsky@gmail.com>>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Cc: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:rtg-bfd-bounces@ietf.org> on behalf of jhaas@pfrc.org<mailto: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<mailto: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>