Subject: Re: WGLC for BFD Multipoint documents (last round)

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Feb 2018 19:23:27 -0800

Hi Reshad,
thank you for your patience and support.
To address your questions a) and b) we may recommend that an implementation
creates MultipointTail session only if provisioned with My Discriminator
value for the given pair of MultipointHead and multicast tree via
out-of-band control or management plane. Discussion of exact mechanisms is
outside the scope of this document. And then the text will continue to
discuss measures for implementations that create MultipointTail session
dynamically for any known combination of head and multicast tree that has
Multipoint BFD enabled.

Regards,
Greg

On Wed, Jan 31, 2018 at 6:44 AM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi Greg,
>
> Thanks for addressing the changes so promptly. I’d like to hear from the
> WG on the 2 security concerns below, i.e. whether they need to be addressed
> and if yes, then how. I believe if we address a) below we also address b)?
>
> Regards,
> Reshad.
>
> : a) We should have the ability, e.g. via configuration, to prevent the
> number
> : of MultipointTail sessions from exceeding the number of expected streams.
> : Otherwise 1 misbehaving head could use up all the MultipointTail session
> : resources on a tail.
> : b) A misbehaving head which changes My Discriminator for a MultipointHead
> : session will cause tails to create many MultipointTail sessions
> (4.13.2). We
> : should consider adding a check to see if we have a MultipointTail session
> : based on source address and the identify of the of the multipoint tree
> with a
> : different discriminator?
>
> 7.  Security Considerations
>
>    The same security considerations as those described in [RFC5880]
>    apply to this document.  Additionally, implementations that create
>    MultpointTail sessions dynamically upon receipt of Multipoint BFD
>    Control packets MUST implement protective measures to prevent
>    infinite number of MultipointTail sessions being created.  Below are
>    listed some points to be considered in such implementations.
>
>       If a Multipoint BFD Control packet did not arrive on a multicast
>       tree (e.g. on expected interface, with expected MPLS label, etc),
>       then a MultipointTail session should not be created.
>
>       If redundant streams are expected for a given multicast stream,
>       then the implementations should not create more MultipointTail
>       sessions than the number of streams.  Additionally, when the
>       number of MultipointTail sessions exceeds the number of expected
>       streams, then the implementation should generate an alarm to users
>       to indicate the anomaly.
>
>
>
> Katz, et al.             Expires August 3, 2018                [Page 16]
>
>
> Internet-Draft         BFD for Multipoint Networks          January 2018
>
>
>       The implementation should have a reasonable upper bound on the
>       number of MultipointTail sessions that can be created, with the
>       upper bound potentially being computed based on the number of
>       multicast streams that the system is expecting.
>
> On 2018-01-30, 10:23 PM, "Greg Mirsky" <[email-masked]> wrote:
>
>     Hi Reshad, et.al,
>     I've uploaded the new version of the draft:
>
>     A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>     This draft is a work item of the Bidirectional Forwarding Detection WG
>     of the IETF.
>
>             Title           : BFD for Multipoint Networks
>             Authors         : Dave Katz
>                               Dave Ward
>                               Santosh Pallagatti
>                               Greg Mirsky
>             Filename        : draft-ietf-bfd-multipoint-13.txt
>             Pages           : 18
>             Date            : 2018-01-30
>
>     Abstract:
>        This document describes extensions to the Bidirectional Forwarding
>        Detection (BFD) protocol for its use in multipoint and multicast
>        networks.
>
>
>
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
>
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-bfd-multipoint-13
>     https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-13
>
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-13
>
>     Will respond to your comments on the Active Tails shortly.
>
>     Regards,
>     Greg
>
>
>     On Mon, Jan 29, 2018 at 11:47 AM, Reshad Rahman (rrahman)
>     <[email-masked]> wrote:
>     > Greg, these changes are good with me.
>     >
>     >
>     >
>     > Regards,
>     >
>     > Reshad.
>     >
>     >
>     >
>     > From: Greg Mirsky <[email-masked]>
>     > Date: Monday, January 29, 2018 at 1:04 PM
>     > To: "Reshad Rahman (rrahman)" <[email-masked]>
>     > Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, Jeffrey Haas
>     > <[email-masked]>, "[email-masked]" <[email-masked]>
>     > Subject: Re: WGLC for BFD Multipoint documents (last round)
>     >
>     >
>     >
>     > 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) <
> [email-masked]>
>     > 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.
>     >
>     >
>     >
>     > <snip>
>     >
>     >
>
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sat, 3 Feb 2018 18:01:14 +0000

Hi Greg,

While OOB mechanism would improve security, my personal opinion is that we should try to improve security without requiring an OOB mechanism. I think we can add text to the security considerations to address the concerns below, e.g. A tail SHOULD prevent the number of MultipointTail sessions from exceeding the number of expected streams.  The concern expressed in b) cannot be fixed by what I proposed because of multiple streams.  So just preventing the number of MultipointTail sessions from exceeding the number of expected streams should be good enough.

Regards,
Reshad.

From: Rtg-bfd <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Thursday, February 1, 2018 at 10:23 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,
thank you for your patience and support.
To address your questions a) and b) we may recommend that an implementation creates MultipointTail session only if provisioned with My Discriminator value for the given pair of MultipointHead and multicast tree via out-of-band control or management plane. Discussion of exact mechanisms is outside the scope of this document. And then the text will continue to discuss measures for implementations that create MultipointTail session dynamically for any known combination of head and multicast tree that has Multipoint BFD enabled.

Regards,
Greg

On Wed, Jan 31, 2018 at 6:44 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks for addressing the changes so promptly. I’d like to hear from the WG on the 2 security concerns below, i.e. whether they need to be addressed and if yes, then how. I believe if we address a) below we also address b)?

Regards,
Reshad.

: a) We should have the ability, e.g. via configuration, to prevent the number
: of MultipointTail sessions from exceeding the number of expected streams.
: Otherwise 1 misbehaving head could use up all the MultipointTail session
: resources on a tail.
: b) A misbehaving head which changes My Discriminator for a MultipointHead
: session will cause tails to create many MultipointTail sessions (4.13.2). We
: should consider adding a check to see if we have a MultipointTail session
: based on source address and the identify of the of the multipoint tree with a
: different discriminator?

On 2018-01-30, 10:23 PM, "Greg Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi Reshad, et.al<http://et.al>,
    I've uploaded the new version of the draft:

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Bidirectional Forwarding Detection WG
    of the IETF.

    Abstract:

    Regards,
    Greg

    On Mon, Jan 29, 2018 at 11:47 AM, Reshad Rahman (rrahman)
    <[email-masked]<mailto:[email-masked]>> wrote:
    > From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
    > To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
    > Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas
    > <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
    > A number of new values of the state variable bfd.SessionType are added to
    > the base BFD…
    >
    > On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>
    > 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
    > Section 4.10. “MUST send packets with P bit set.”. Did we agree on “MUST

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sat, 3 Feb 2018 20:27:43 +0000

Hi Greg,

The question about whether we need a new variable wasn’t referring to MultipointClient state (I agree this is well explained). Since I mentioned “state variable” I realize the confusion…

The question was whether we need a new state variable (not for the MultipointClient state) to control the behavior explained in this paragraph, e.g the new state variable could be called bfd.TrackTails.

   If the head wishes to know the identity of the tails, it sends
   multipoint Polls as needed.  Previously known tails that don't
   respond to the Polls will be detected.

Regards,
Reshad.

On 2018-01-31, 8:41 PM, "Greg Mirsky" <[email-masked]> wrote:

    Hi Reshad,
    thank you for your expedient response to the proposed update. I'll
    mark the draft as potentially updating RFCs 5880 and 7880. I'm glad
    that you consider acceptable almost all proposed changes. I think that
    the one open questions is:
        - 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.
    <RR> No, the variable would be on the head for all tails.
    Let me try to construct already defined variables:
    - section New State Variable Value has defined MultipointClient as the
    new state of bfd.SessionType:
    MultipointClient:  A session on the head that tracks the state of an
    individual tail, when desirable.
    That is how MultipointClient use explained in section Multipoint
    Client Session. I think that the text in the remainder of the
    Controlling Multipoint BFD Options does provide reasonable explanation
    of use of MultipointClient state. What do you think?
    
    Regards,
    Greg
    
    On Wed, Jan 31, 2018 at 4:51 PM, Reshad Rahman (rrahman)
    <[email-masked]> wrote:
    > Hi Greg,
    >
    > Please see inline <RR>.
    >
    > Regards,
    > Reshad.
    >
    >
    > On 2018-01-30, 10:47 PM, "Greg Mirsky" <[email-masked]> wrote:
    >
    >     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.
    > <RR> This draft was experimental at a certain point but got changed to Standards Track because AFAIR of a normative reference from the TRILL P2MP BFD.
    >
    >     - 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)
    > <RR> Ack.
    >
    >     - 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?
    > <RR> Ack.
    >
    >     - 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?
    > <RR> Yes.
    >
    >     - 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'?
    > <RR> Reference to 5.2 is good enough.
    >
    >     - 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 ..."
    > <RR> Ack.
    >
    >     - 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, ...
    > <RR> Ack.
    >
    >     - 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.
    > <RR> No, the variable would be on the head for all tails.
    >
    >     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?
    > <RR> Ack.
    >
    >     - 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)
    >     > 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.
    >     >
    >     >
    >     >
    >     > Date: Tuesday, January 16, 2018 at 11:01 PM
    >     >
    >     >
    >     > sorry for my sloppiness. Fixed.
    >     >
    >     >
    >     >
    >     > Regards, Greg
    >     >
    >     >
    >     >
    >     > On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <[email-masked]>
    >     > 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.
    >     >
    >     >
    >     >
    >     > Date: Tuesday, January 16, 2018 at 9:25 PM
    >     > 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 <[email-masked]> 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) <[email-masked]>
    >     > wrote:
    >     >
    >     > Hi Greg,
    >     >
    >     >
    >     >
    >     > I am fine with the change below.
    >     >
    >     >
    >     >
    >     > Regards,
    >     >
    >     > Reshad.
    >     >
    >     >
    >     >
    >     > Date: Tuesday, January 16, 2018 at 2:20 PM
    >     > 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)
    >     > 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)" <[email-masked]>
    >     > Date: Tuesday, January 16, 2018 at 9:32 AM
    >     > To: "Carlos Pignataro (cpignata)" <[email-masked]>, Greg Mirsky
    >     > <[email-masked]>
    >     > Cc: Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]>
    >     >
    >     >
    >     > 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)" <[email-masked]>
    >     > Date: Tuesday, January 16, 2018 at 1:47 AM
    >     > To: Greg Mirsky <[email-masked]>
    >     > Cc: "Reshad Rahman (rrahman)" <[email-masked]>, Jeffrey Haas
    >     > Looks good to me, Greg. Thanks.
    >     >
    >     > Thumb typed by Carlos Pignataro.
    >     >
    >     > Excuze typofraphicak errows
    >     >
    >     >
    >     > On Jan 16, 2018, at 15:32, Greg Mirsky <[email-masked]> 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)
    >     > <[email-masked]> 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, [email-masked]
    >     >
    >     > “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) <[email-masked]>
    >     > 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.
    >     >
    >     >
    >     >
    >     > Date: Monday, January 15, 2018 at 6:17 PM
    >     > Cc: Jeffrey Haas <[email-masked]>, "Carlos Pignataro (cpignata)"
    >     > <[email-masked]>, "[email-masked]" <[email-masked]>
    >     > 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)" <[email-masked]>
    >     > 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"
    >     > <[email-masked] on behalf of [email-masked]> 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 <[email-masked]> 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>
    >     >
    >     >
    >     >
    >     >
    >     >
    >     >
    >
    >