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

From: Jeffrey Haas <[email-masked]>
Date: Wed, 3 Jan 2018 10:43:23 -0500

Working Group,

Last call has concluded on the multipoint documents.

We have one lingering item to be discussed with our AD regarding the
registry for session types prior to shipping this document to the IESG.

Thank you for your efforts!

Reshad will be taking on the role of document shepherd for these documents.

-- Jeff

On Wed, Dec 13, 2017 at 12:24:43PM -0500, Jeffrey Haas wrote:
> Working Group,
> 
> In an attempt to give our AD a holiday gift, we're at the point where we may
> now work to conclude WGLC on the BFD multipoint documents.  We did one pass
> of last call June-July of this year, and held off approval pending review
> from ALU who has an implementation of the base spec.  ALU has since
> responded that they're fine with the contents.
> 
> To provide the working group one last opportunity to review the documents,
> we're running a final last call and will send off the changes to our AD
> afterward.
> 
> The prior WGLC thread is here:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/yDOFOpd9BIIKtLniDGdqPioSt_w/?qid=2d0831389d19508c66f9a387096250e6
> 
> The documents are here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/
> 
> The intent is to conclude this WGLC at end of year.
> 
> -- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 15 Jan 2018 23:00:53 +0000

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.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Jan 2018 15:17:32 -0800

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)" <[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.
>
> On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Greg,
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Jan 2018 01:52:36 +0000

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 <[email-masked]>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, "[email-masked]" <[email-masked]>
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)" <[email-masked]<mailto:[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.

Regards,
Reshad.

On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Greg,

    Please push the updates.

    -- Jeff

    > On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
    [...]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Jan 2018 04:25:16 +0000

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]<mailto:[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]<mailto:[email-masked]>> wrote:

Hi Greg,

Regards,
Reshad.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 15, 2018 at 6:17 PM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Jan 2018 06:47:47 +0000

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]<mailto:[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]<mailto:[email-masked]>> wrote:
Reshad, Greg,

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]
    > >   be IANA maintained.  In this case, the bfd-path-type identity as the

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Jan 2018 22:31:59 -0800

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:
>
> 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).
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, January 15, 2018 at 6:17 PM
> *To: *"Reshad Rahman (rrahman)" <[email-masked]>
> *Cc: *Jeffrey Haas <[email-masked]>, "Carlos Pignataro (cpignata)" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: WGLC for BFD Multipoint documents (last round)
>
> Hi Reshad,

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Jan 2018 14:32:28 +0000

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)" <[email-masked]>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Jan 2018 18:53:28 +0000

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]>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jan 2018 11:19:58 -0800

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) <[email-masked]

> 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]>
>
> 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 <
> [email-masked]>, "[email-masked]" <[email-masked]>
> On Jan 16, 2018, at 15:32, Greg Mirsky <[email-masked]> wrote:
>
> Hi Reshad and Carlos,
>
> <Diff_ draft-ietf-bfd-multipoint-active-tail-06.txt -
> draft-ietf-bfd-multipoint-active-tail-07.txt.html>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 16 Jan 2018 21:58:53 +0000

Hi Greg,

I am fine with the change below.

Regards,
Reshad.

From: Greg Mirsky <[email-masked]>
Date: Tuesday, January 16, 2018 at 2:20 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,
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

   is 1.
NEW TEXT

   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) <[email-masked]<mailto:[email-masked]>> 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)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 16, 2018 at 9:32 AM
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Greg,

Regards,
Reshad.

From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 16, 2018 at 1:47 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jan 2018 14:51:44 -0800

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:

> *Date: *Tuesday, January 16, 2018 at 2:20 PM
> *Cc: *"Carlos Pignataro (cpignata)" <[email-masked]>, Jeffrey Haas <
> On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) <
> [email-masked]> wrote:
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jan 2018 18:25:44 -0800

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:

> On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) <
>> *Cc: *Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]
>> >
>>
>>
>> *“Sometimes I use big words that I do not fully understand, to make
>> myself sound more photosynthesis."*
>>
>>
>>
>> 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.
>>
>>
>>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 17 Jan 2018 03:05:54 +0000

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]<mailto:[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]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Reshad.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 16, 2018 at 2:20 PM
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]>>

Hi Reshad,

   is 1.
NEW TEXT

   MultipointTail.

Regards,

Greg

Regards,
Reshad.

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Jan 2018 20:00:54 -0800

Hi Reshad,
sorry for my sloppiness. Fixed.

Regards, Greg

On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <[email-masked]>
wrote:

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 24 Jan 2018 22:42:02 +0000

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

Hi Reshad,

Regards, Greg

On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Reshad.

Hi Reshad, et. al,

Regards,
Greg

Regards,
Greg

Regards,
Reshad.

Hi Reshad,

   is 1.
NEW TEXT

   MultipointTail.

Regards,

Greg

Regards,
Reshad.

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Jan 2018 10:28:04 -0500

Thanks, Reshad.

Since the majority of the content is nits, Greg can simply address them as
Editor.

The Security Considerations issues raised in the base spec may deserve a bit
more explicit Working Group discussion:

: The shepherd has concerns wrt security: 
: 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 multipoint tree with a
: different discriminator?

-- Jef

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Jan 2018 13:46:08 -0800

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) <[email-masked]>
wrote:

> shepherdwriteup/
> *Date: *Tuesday, January 16, 2018 at 11:01 PM
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Jan 2018 15:06:04 -0800

Hi Jeff, Reshad, et. al,
I agree that the Security Considerations section will benefit from clearer
description of the need to limit resources that may be allocated for p2mp
BFD sessions on MultipointTail nodes. Perhaps we can use wording close to
Security Consideration section in RFC 7726:
   BFD sessions, naturally, use system
   and network resources.  More BFD sessions means more resources will
   be used.  It is highly important to ensure that only a minimum number
   of BFD sessions are provisioned per MultipointHead and that bootstrapped
BFD
   sessions are properly deleted when they are no longer required.

Regards,
Greg

On Thu, Jan 25, 2018 at 7:28 AM, Jeffrey Haas <[email-masked]> wrote:

> > Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, Jeffrey Haas <
> > 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.
> >
> > Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:cpi
> [email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:rtg-
> [email-masked]>>
> [email-masked]<mailto:[email-masked]>> wrote:
> > Hi Greg,
> >
> > Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:cpi
> [email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:rtg-
> [email-masked]>>
> >
> [email-masked]<mailto:[email-masked]>> wrote:
> > To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:cpi
> [email-masked]>>, Greg Mirsky <[email-masked]<mailto:
> [email-masked]>>
> > Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:rtg-
> [email-masked]>>
> >
> > Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:rrah
> [email-masked]>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:rtg-
> [email-masked]>>
> [email-masked]<mailto:[email-masked]>> wrote:
> > Reshad, Greg,
> >
> > Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>, "Carlos
> Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:rtg-
> [email-masked]>>
> [email-masked]<mailto:[email-masked]> on behalf of
> [email-masked]<mailto:[email-masked]>> wrote:
> >
> >     Greg,
> >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 26 Jan 2018 15:14:14 +0000

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”)
  *   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, “ .
  *   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…”
  *   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/

Please see inline <RR>.

Regards,
Reshad.

Date: Thursday, January 25, 2018 at 4:46 PM

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.

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.

<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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

Hi Reshad, et. al,

Regards,
Greg

Regards,
Greg

Regards,
Reshad.

Hi Reshad,

   is 1.
NEW TEXT

   MultipointTail.

Regards,

Greg

Regards,
Reshad.

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 26 Jan 2018 15:29:37 +0000

Hi Greg,

The proposal below addresses some of the concerns. But I would also like to see some wording/procedure to protect the tail in the 2 cases mentioned.

Regards,
Reshad.

From: Greg Mirsky <[email-masked]>
Date: Thursday, January 25, 2018 at 6:06 PM
To: Jeffrey Haas <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "Carlos Pignataro (cpignata)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WGLC for BFD Multipoint documents (last round)

Hi Jeff, Reshad, et. al,
I agree that the Security Considerations section will benefit from clearer description of the need to limit resources that may be allocated for p2mp BFD sessions on MultipointTail nodes. Perhaps we can use wording close to Security Consideration section in RFC 7726:
   BFD sessions, naturally, use system
   and network resources.  More BFD sessions means more resources will
   be used.  It is highly important to ensure that only a minimum number
   of BFD sessions are provisioned per MultipointHead and that bootstrapped BFD
   sessions are properly deleted when they are no longer required.

Regards,
Greg

On Thu, Jan 25, 2018 at 7:28 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Reshad.

-- Jef

On Wed, Jan 24, 2018 at 10:42:02PM +0000, Reshad Rahman (rrahman) wrote:
> On Jan 16, 2018 7:05 PM, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Greg,
>
> From: Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> On Tue, Jan 16, 2018 at 2:51 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Reshad,
> On Tue, Jan 16, 2018 at 1:58 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Greg,
>
> From: Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>
> On Tue, Jan 16, 2018 at 10:53 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> From: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>
> From: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> On Jan 16, 2018, at 15:32, Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi Reshad and Carlos,
> On Mon, Jan 15, 2018 at 8:25 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Reshad, Greg,
>
> Carlos Pignataro, [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
> On Jan 16, 2018, at 10:52 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> Hi Greg,
>
> From: Greg Mirsky <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> On Jan 15, 2018 3:00 PM, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Greg,
>
>     > On Tue, Dec 19, 2017 at 8:05 AM, Jeffrey Haas <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>     [...]

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Jan 2018 16:42:29 -0800

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) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> Thank you for the prompt response. The changes look good. Some nits I may
> missed during my review and nits on new rev:
>
>    - 3 Overview. s/Details of how head keeps track/Details of how heads
>    keep track/ (or if singular “of how a head keeps track”)
>
> GIM2>> I think that singular is consistent with the preceding sentence 'A
head may wish to be alerted to the tails' connectivity (or lack thereof).'
And because there's 'a head' should the next reference be 'the head', thus
making 'Details of how the head keeps track ...'?

>
>    -
>    - 4.2 Session Model. References to Section 4.4.1 were added but
>    consider making a change e.g adding () around the reference or “, as
>    defined in Section 4.4.1, “ .
>
> GIM2>> Done

>
>    -
>    - 4.4.1 New State Variable Values. First paragraph starts “A number
>    values of the state variable are added to the base BFD…”. Should be “A
>    number of values…”? Or reword that paragraph to something along the lines
>    of “A number of values are added to some existing state variables defined
>    in the base BFD…”
>
> GIM2>> Used the former 'A number of values ...'

>
>    -
>    - 4.10 Timer Manipulation. s/However to indicate a change in the
>    packets MultipointHead session MUST send packets with P bit set.
>    MultipointTail session/However to indicate a change in the packets,
>    MultipointHead sessions MUST send packets with the P bit set.
>    MultipointTail sessions/
>
> GIM2>> Or should it be 'However, to indicate a change in the packets,
MultipointHead MUST send packets with the P bit set.'?

>    -
> *Date: *Thursday, January 25, 2018 at 4:46 PM
> 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.
>
>
>
> <RR> I am fine with something along the lines of "Another goal is for the
> mechanism to work on any multicast technology."
>
>
>
> - 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
>
> 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.
>
>
>
> On Wed, Jan 24, 2018 at 2:42 PM, Reshad Rahman (rrahman) <

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 28 Jan 2018 02:36:26 +0000

Thanks Greg. PSI <RR2>.

I think we’ve closed on these comments.

Regards,
Reshad.

Date: Friday, January 26, 2018 at 7:42 PM

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

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

  *

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

Hi Reshad,

Acceptable?
<RR> Yes.

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

Hi Reshad, et. al,

Regards,
Greg

Regards,
Greg

Regards,
Reshad.

Hi Reshad,

   is 1.
NEW TEXT

   MultipointTail.

Regards,

Greg

Regards,
Reshad.

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 27 Jan 2018 20:38:20 -0800

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) <[email-masked]>
wrote:

> *Date: *Friday, January 26, 2018 at 7:42 PM
> On Fri, Jan 26, 2018 at 7:14 AM, Reshad Rahman (rrahman) <
> document.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 29 Jan 2018 13:52:39 +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.

Date: Saturday, January 27, 2018 at 11:38 PM

Hi Reshad,
many thanks for your guidance and support. Should I upload the new version of the draft?

Kind regards,
Greg

On Sat, Jan 27, 2018 at 6:36 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg. PSI <RR2>.

Regards,
Reshad.

Hi Reshad, et. al,

Kind regards,
Greg

  *

  *

  *

  *

Please see inline <RR>.

Regards,
Reshad.

Hi Reshad,

Acceptable?
<RR> Yes.

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

Hi Reshad, et. al,

Regards,
Greg

Regards,
Greg

Regards,
Reshad.

Hi Reshad,

   is 1.
NEW TEXT

   MultipointTail.

Regards,

Greg

Regards,
Reshad.

Hi Greg,

Regards,
Reshad.

Regards,
Greg

Thanks,

—

Hi Greg,

Regards,
Reshad.

Hi Reshad,

Regards, Greg

Regards,
Reshad.

    Greg,

    Please push the updates.

    -- Jeff

    [...]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 29 Jan 2018 19:47:22 +0000

Greg, these changes are good with me.

Regards,
Reshad.

Date: Monday, January 29, 2018 at 1:04 PM

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]<mailto:[email-masked]>> wrote:
Hi Greg,

Regards,
Reshad.

<snip>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Jan 2018 10:04:01 -0800

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.
>
>
>
> *Date: *Saturday, January 27, 2018 at 11:38 PM
>
> On Sat, Jan 27, 2018 at 6:36 PM, Reshad Rahman (rrahman) <

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jan 2018 19:23:44 -0800

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:
> Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, Jeffrey Haas
> <[email-masked]>, "[email-masked]" <[email-masked]>
> 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: Greg Mirsky <[email-masked]>
Date: Tue, 30 Jan 2018 19:47:31 -0800

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)
<[email-masked]> wrote:
> 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 10:53 AM, Reshad Rahman (rrahman)
> 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.
>
>
>
> Cc: "Reshad Rahman (rrahman)" <[email-masked]>, Jeffrey Haas
> 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,
>
>
>
> Cc: Jeffrey Haas <[email-masked]>, "Carlos Pignataro (cpignata)"
> <[email-masked]>, "[email-masked]" <[email-masked]>
> On 2017-12-20, 12:09 PM, "Rtg-bfd on behalf of Jeffrey Haas"
> <[email-masked] on behalf of [email-masked]> wrote:
>
>     Greg,
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 31 Jan 2018 14:44:35 +0000

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.

: based on source address and the identify of the of the multipoint tree with a

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,

    
    Abstract:

    

    
    Regards,
    Greg

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 1 Feb 2018 00:51:01 +0000

Hi Greg,

Please see inline <RR>.

Regards,
Reshad.

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

    Hi Reshad,
    
    Regards,
    Greg
    
<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.

    

<RR> Reference to 5.2 is good enough.

    
    
<RR> No, the variable would be on the head for all tails. 

    Reference added.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 31 Jan 2018 17:41:06 -0800

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