Re: WGLC for BFD Multipoint documents (last round)

[Greg Mirsky <[e-mail]>]

Hi Reshad,
thank you for your detailed review of
draft-ietf-bfd-multipoint-active-tail and comments. I have copied
parts of the review an i-lined my answers and notes tagged GIM>>.
I've attached the diff to highlight the update and the new working
version of the draft. Greatly appreciate your help.

Regards,
Greg

:(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>>  This draft is Informational while RFCs 5880 and 7880 are
Standard track. Would an Informational track document be updating
Standard? Please confirm.

- General. There are a few instances where singular is used instead of
plural (e.g. for session, tail) 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 Introduction “path as is
feasible.)”. I have not called out all of them, search for “.)”
GIM>> I think I've hunted down them all down.

- 1 Introduction. s/which allows tail/which allows tails/
- 1 Introduction. Clarifications/explanations are desirable on “it is
preferable if unicast paths share as little fate with the multipoint
path as is feasible.)”
GIM>> Please consider the following text update:
OLD TEXT
and in fact it is preferable if unicast paths share as little fate
with the multipoint path as is feasible
NEW TEXT
and in fact it is preferable if unicast paths share as little fate
with the multipoint path as is feasible, so to increase probability of
delivering the notification from the tail to the head)

- 1 Introduction. s/Goal of this application/The goal of this application/
GIM>> Done
- 1 Introduction mentions “…state implosion towards the head”. Not
sure implosion is the right term there, if it is the right term then
clarification is needed.
GIM>> Agree. I think that 'state explosion' is what we're concerned
with.Would s/implosion/explosion/ be acceptable?

- 2 Overview. Change “Head may wish” to “A head may wish” or “Heads may wish”
GIM>> Used the former.
- 2 Overview. “…the head can direct the tails to transmit…”: add
reference or explanation on how the head does that. Also
s/direct/request/?
GIM>> Controlling Multipoint BFD Options section provides the details.
Will add reference ', as described in Section 3.4' Would that address
this comment?

- 2 Overview. 1st paragraph, I know it’s obvious when you read the
draft but might be good to have 1 sentence to explain why this is
unreliable.
GIM>> Section 5.2 gives good explanation of what is being considered
unreliable. I' agree that using different shades of reliable
notification to the head is not the best terminology but I don't have
better to offer. Would reference to section 5.2 be acceptable? Do we
want to characterize the level of guaranteed notification to the head
otherwise than 'notification reliability'?
- 2 Overview. 3rd paragraph: s/as a unicast to the tail/as a unicast
to that tail/?
GIM>> Done
- 2 Overview. 3rd paragraph: “or the single reply thereto is lost”,
rephrase that sentence e.g. to “or the single reply os also lost”?
GIM>> "..  or the single reply also lost ..."
- 2 Overview. “If some tails are more equal than others…”. I know what
you mean but plus change the wording.
GIM>> Proposed update:
OLD TEXT
If some tails are more equal than others, ...
NEW TEXT
If the awareness of the state of some nodes is more important for the head, ...

- 3 Protocol Details. s/This section is update/This section is an update/
- 3.2 Multipoint Client Session Failure. s/know the tail state/know
the tail’s state/
GIM>> Done and done.

- 3.3 State Variables. As discussed, bfd.SessionType should be in “new
variable values” section and the others in “new variables” section.
- 3.3.1 New State Variables. The paragraph on bfd.ReportTailDown says
“If 0, the tail..”. Mention that the packets sent from the tail are in
response to the head’s periodic BFD control packets? Also when set to
1, how do the tails know from the head that they need to notify the
head? This paragraph needs some clarification.
3.3.2 State Variable Initialization and Maintenance. s/section 6.8.1
of the [RFC5880] needs/section 6.8.1 of [RFC5880] need/
- 3.4 Controlling Multipoint BFD Options. 2nd paragraph: add reference
to section 5.1?
GIM>> Agree
- 3.4. 3rd paragraph : add reference to section 5.3? Also do we need a
state variable which controls this behaviour (discovering tails)?
GIM>> In the reverse order.
Then the variable be per tail? What if number of tails is unknown to
the head? I'd rather not define that in the base specification.
Reference added.
- 3.4. Paragraph 5 should be after paragraph 3?
GIM>> I agree, makes the narrative more logical.
- 3.4. Paragraph 6, regarding “initial delay”, add a reference to
3.13.3 which describes the delay.
- 3.5 State Machine. s/State machine for/The state machine for/
GIM>> Done and done
- 3.8 Soliciting the Tails. “random delay”, add a reference to 3.13.3
which describes the delay.
- 3.13. “in the base specification” refers to base BFD or base BFD
multipoint? Add a reference.
GIM>> In fact it is both. Added references accordingly.
- 3.13.1. Should reception at head also be covered here? If not, add
“at tail” to the title
GIM>> You're right, the changes update processing at MultipointTail
but the base specification does not differentiate processing of the
received BFD control packet based on the bfd.SessionType. I propose to
have the text without update.
- 3.13.1. s/by head below procedure MUST be/by the head, the procedure
below MUST be/
GIM>> Agree. I think more changes can benefit the text:
OLD TEXT
In addition to that if tail tracking is desired by head below
procedure MUST be applied.
NEW TEXT
In addition to that, if tail tracking is desired by head, below
procedure MUST be applied.
Would you agree?

- 3.13.1 and 3.13.2. Both are adding to the procedures in
draft-ietf-bfd-multipoint, specify where the addition is taking place
(e.g. at the end).
GIM>>
- 7 Security Considerations. Should we add at the beginning “The same
security considerations as those described in [RFC5880] and
[I-D.ietf-bfd-multipoint] apply to this document.”?
GIM>> Agree.

On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman)
<[e-mail]> 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 <[e-mail]>
> Date: Tuesday, January 16, 2018 at 11:01 PM
>
>
> To: "Reshad Rahman (rrahman)" <[e-mail]>
> Cc: "Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas
> <[e-mail]>, "[e-mail]" <[e-mail]>
> 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)" <[e-mail]>
> 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 <[e-mail]>
> Date: Tuesday, January 16, 2018 at 9:25 PM
> To: "Reshad Rahman (rrahman)" <[e-mail]>
> Cc: "Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas
> <[e-mail]>, "[e-mail]" <[e-mail]>
> 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 <[e-mail]> 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) <[e-mail]>
> wrote:
>
> Hi Greg,
>
>
>
> I am fine with the change below.
>
>
>
> Regards,
>
> Reshad.
>
>
>
> From: Greg Mirsky <[e-mail]>
> Date: Tuesday, January 16, 2018 at 2:20 PM
> To: "Reshad Rahman (rrahman)" <[e-mail]>
> Cc: "Carlos Pignataro (cpignata)" <[e-mail]>, Jeffrey Haas
> <[e-mail]>, "[e-mail]" <[e-mail]>
>
>
> 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)
> <[e-mail]> 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)" <[e-mail]>
> Date: Tuesday, January 16, 2018 at 9:32 AM
> To: "Carlos Pignataro (cpignata)" <[e-mail]>, Greg Mirsky
> <[e-mail]>
> Cc: Jeffrey Haas <[e-mail]>, "[e-mail]" <[e-mail]>
>
>
> 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)" <[e-mail]>
> Date: Tuesday, January 16, 2018 at 1:47 AM
> To: Greg Mirsky <[e-mail]>
> Cc: "Reshad Rahman (rrahman)" <[e-mail]>, Jeffrey Haas
> <[e-mail]>, "[e-mail]" <[e-mail]>
> 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 <[e-mail]> 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)
> <[e-mail]> 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, [e-mail]
>
> “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) <[e-mail]>
> 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 <[e-mail]>
> Date: Monday, January 15, 2018 at 6:17 PM
> To: "Reshad Rahman (rrahman)" <[e-mail]>
> Cc: Jeffrey Haas <[e-mail]>, "Carlos Pignataro (cpignata)"
> <[e-mail]>, "[e-mail]" <[e-mail]>
> 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)" <[e-mail]>
> 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"
> <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> 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>
>
>
>
>
>
>