Re: WGLC for BFD Multipoint documents (last round)

[Greg Mirsky <[e-mail]>]

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?

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

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

- 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?
GIM>> RE: reference to the active tails draft. As noted above, it will
introduce new informational reference. Any concern with that?
- 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?
- 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.
- 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 ..."?

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

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

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

- 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?
- 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) <[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>
>
>
>
>
>
>
>
>