Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

From: Santosh P K <[email-masked]>
Date: Mon, 6 Oct 2014 12:51:42 +0000

Hello All,
   I am seeking comments on active tale section of this document. I spoke to few implementers and found that no one really finds use case for active tale. Does anyone on this forum feel that we might need active tale? If there are no uses cases then we can move active tale section to appendix? We would like to make all the changes before IETF 91 and push this for RFC. Any suggestions?

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, August 19, 2014 7:38 PM
To: [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

Note that this consists mostly of a re-publish with Santosh as the new editor.  (And moving from .nroff to .xml.)

In the next few weeks, Santosh will be working with known implementors to edit the document to match implementation.  Ideally these edits will be complete prior to the next IETF session in Honolulu.  This will put us a bit past our original milestone for publication, but still much better on track than many of our previous documents.

-- Jeff

On Mon, Aug 18, 2014 at 05:55:37PM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.
> 
>         Title           : BFD for Multipoint Networks
>         Authors         : Dave Katz
>                           Dave Ward
>                           Santosh Pallagatti
> 	Filename        : draft-ietf-bfd-multipoint-04.txt
> 	Pages           : 27
> 	Date            : 2014-08-12
> 
> Abstract:
>    This document describes extensions to the Bidirectional Forwarding
>    Detection (BFD) protocol for its use in multipoint and multicast
>    networks.  Comments on this draft should be directed to rtg-
>    [email-masked].
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-04
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Santosh P K <[email-masked]>
Date: Mon, 6 Oct 2014 13:27:01 +0000

Sorry for typo in my precious mail  "active tale" it is "active tail".

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:22 PM
To: Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello All,

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, August 19, 2014 7:38 PM
To: [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 9 Oct 2014 15:38:11 +0000

[With Chair Hat On]

Dear WG,

The topic of keeping or removing the active tail from draft-ietf-bfd-multipoint is one of the last couple of topics that we, as a WG, need to resolve for this document.

Whether or not we keep or remove the active tail, leaves will be able to detect the failure of the multicast tree, which allows protections such as live-live.

What is essentially different:

Keeping the active tail - Allows ingress/root to keep track of leaves.

Removing the active tail - Ingress/root will not be able to keep track of leaves.

If there's any requirements for the ingress/root to trigger some protections, then active tail becomes a requirement. If there is no such requirements, then the active tail is an unnecessary portion of this document.

It'll be beneficial to hear your thoughts/comments to help gauge where we are on this matter as a WG.

Comments/thoughts?

Thanks!

-Nobo

> Sent: Monday, October 06, 2014 9:27 AM
> To: Santosh P K; Jeffrey Haas; [email-masked]
>    I am seeking comments on active tale section of this document. I spoke to
> few implementers and found that no one really finds use case for active tale.
> Does anyone on this forum feel that we might need active tale? If there are
> no uses cases then we can move active tale section to appendix? We would
> like to make all the changes before IETF 91 and push this for RFC. Any
> suggestions?
> 
> Thanks
> Santosh P K
> 
> In the next few weeks, Santosh will be working with known implementors to
> edit the document to match implementation.  Ideally these edits will be
> complete prior to the next IETF session in Honolulu.  This will put us a bit
> past our original milestone for publication, but still much better on track
> than many of our previous documents.
> 
> -- Jeff
> 
> 
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 9 Oct 2014 18:58:36 +0000

In certain environment the tracking of the tails is happening by other
means. Example is Multicast VPN using MP-BGP.

On 09/10/14 17:38, "Nobo Akiya (nobo)" <[email-masked]> wrote:

>[With Chair Hat On]
>
>Dear WG,
>
>The topic of keeping or removing the active tail from
>draft-ietf-bfd-multipoint is one of the last couple of topics that we, as
>a WG, need to resolve for this document.
>
>Whether or not we keep or remove the active tail, leaves will be able to
>detect the failure of the multicast tree, which allows protections such
>as live-live.
>
>If there's any requirements for the ingress/root to trigger some
>protections, then active tail becomes a requirement. If there is no such
>requirements, then the active tail is an unnecessary portion of this
>document.
>
>> Note that this consists mostly of a re-publish with Santosh as the new
>>editor.
>> (And moving from .nroff to .xml.)
>>

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 10 Oct 2014 01:31:56 +0000

I think the "keeping the active tail" choice can help the ingress/root to perform global protection. Additionally, it's possible to achieve a more balanced load distribution among multiple trees (there might be more than two available trees) if the ingress/root has knowledge of the active tail. 

Thanks,
Mingui

>From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
>Sent: Thursday, October 09, 2014 11:38 PM
>The topic of keeping or removing the active tail from draft-ietf-bfd-multipoint is
>one of the last couple of topics that we, as a WG, need to resolve for this
>document.
>
>Whether or not we keep or remove the active tail, leaves will be able to detect
>the failure of the multicast tree, which allows protections such as live-live.
>
>If there's any requirements for the ingress/root to trigger some protections,
>then active tail becomes a requirement. If there is no such requirements, then
>the active tail is an unnecessary portion of this document.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Oct 2014 01:45:35 +0000

Hi Santosh,
thank you for taking on this task.
Perhaps just a technical question:
*       there many new protocol variables and states associated with the tail tracking functionality. Were you considering leaving them in the standard portion or moving into informational appendix along with the description of tail monitoring machinery?

        Regards,
                Greg

PS. I'll try to send my comments to the document by Monday.

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:27 AM
To: Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:22 PM
To: Jeffrey Haas; [email-masked]<mailto:[email-masked]>
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello All,

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, August 19, 2014 7:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

-- Jeff

On Mon, Aug 18, 2014 at 05:55:37PM -0700, [email-masked]<mailto:[email-masked]> wrote:
>    [email-masked]<mailto:[email-masked]>.
>
>
>

---

From: Santosh P K <[email-masked]>
Date: Fri, 10 Oct 2014 02:39:25 +0000

Thanks Hendreickx for your reply.

-----Original Message-----
From: Henderickx, Wim (Wim) [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 12:29 AM
To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

In certain environment the tracking of the tails is happening by other means. Example is Multicast VPN using MP-BGP.

On 09/10/14 17:38, "Nobo Akiya (nobo)" <[email-masked]> wrote:

>draft-ietf-bfd-multipoint is one of the last couple of topics that we, 
>as a WG, need to resolve for this document.
>
>Whether or not we keep or remove the active tail, leaves will be able 
>to detect the failure of the multicast tree, which allows protections 
>such as live-live.
>
>protections, then active tail becomes a requirement. If there is no 
>such requirements, then the active tail is an unnecessary portion of 
>this document.
>
>>    I am seeking comments on active tale section of this document. I 
>>spoke to  few implementers and found that no one really finds use case 
>>for active tale.
>> Does anyone on this forum feel that we might need active tale? If 
>>there are  no uses cases then we can move active tale section to 
>>appendix? We would  like to make all the changes before IETF 91 and 
>>push this for RFC. Any  suggestions?
>> 
>> Thanks
>> Santosh P K
>> 
>> Note that this consists mostly of a re-publish with Santosh as the 
>>new editor.
>> In the next few weeks, Santosh will be working with known 
>>implementors to  edit the document to match implementation.  Ideally 
>>these edits will be  complete prior to the next IETF session in 
>>Honolulu.  This will put us a bit  past our original milestone for 
>>publication, but still much better on track  than many of our previous 
>>documents.
>> 
>> -- Jeff
>> 
>> 
>> 
>> >  This draft is a work item of the Bidirectional Forwarding 
>> > Detection
>> Working Group of the IETF.
>> >

---

From: Santosh P K <[email-masked]>
Date: Fri, 10 Oct 2014 02:41:37 +0000

Mingui,
   Thanks a lot for your comments. Can you please tell me if there any application which is already doing it? Is there any other way of doing it without BFD like in case of MVPN?

Thanks
Santosh P K 

-----Original Message-----
From: Mingui Zhang [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 7:02 AM
To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Thanks,
Mingui

>to detect the failure of the multicast tree, which allows protections such as live-live.
>
>such requirements, then the active tail is an unnecessary portion of this document.
>
>> spoke to few implementers and found that no one really finds use case for active tale.
>> publication, but still much better on track than many of our previous documents.
>>
>> -- Jeff
>>
>>
>>

---

From: Santosh P K <[email-masked]>
Date: Fri, 10 Oct 2014 02:43:13 +0000

Hello Greg,
     Thanks for your comments. Leaving or moving to appendix is the question here. It depends on if we really find any use case scenario for active tail.

Thanks
Santosh P K

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, October 10, 2014 7:16 AM
To: Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hi Santosh,

        Regards,
                Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:27 AM
To: Santosh P K; Jeffrey Haas; [email-masked]<mailto:[email-masked]>
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:22 PM
To: Jeffrey Haas; [email-masked]<mailto:[email-masked]>
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello All,

Thanks
Santosh P K

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Tuesday, August 19, 2014 7:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt

-- Jeff

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 10 Oct 2014 03:21:24 +0000

Hi Santosh,

You are welcome. 
We intend to do so for TRILL Resilient Distribution Trees. 

Thanks,
Mingui

>From: Santosh P K [mailto:[email-masked]]
>Sent: Friday, October 10, 2014 10:42 AM
>To: Mingui Zhang; Nobo Akiya (nobo); Jeffrey Haas; [email-masked]
>   Thanks a lot for your comments. Can you please tell me if there any
>application which is already doing it? Is there any other way of doing it without
>BFD like in case of MVPN?
>
>Thanks
>Santosh P K
>
>I think the "keeping the active tail" choice can help the ingress/root to perform
>global protection. Additionally, it's possible to achieve a more balanced load
>distribution among multiple trees (there might be more than two available trees)
>if the ingress/root has knowledge of the active tail.
>
>Thanks,
>Mingui
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Oct 2014 10:13:44 -0400

>      Thanks for your comments. Leaving or moving to appendix is the question here. It depends on if we really find any use case scenario for active tail.

And one of the motivations for the solicication of comments is to figure out
what we RFC: Shipping features vs. optional but specified components.

For example, I don't think I've yet heard of a BFD implementation that
supports demand mode.  Echo mode is also incompletely supported across
vendor platforms.

While not a big deal - everyone supports async - such issues hinder
advancement of the RFC to full standard.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 10 Oct 2014 14:48:28 +0000

Santosh,

It will helpful to clarify exactly what you mean by "active tail".

- Do you intend to keep tail reporting of the failure (bfd.ReportTailDown=1)?
- Is it just unicast poll from head that is being questioned for removal?

Knowing exactly what aspect is being questioned for removal may provide a better base for good discussions.

Thanks!

-Nobo

> Sent: Thursday, October 09, 2014 10:39 PM
> To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg-
> [email-masked]

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 10 Oct 2014 14:50:33 +0000

Hello Santosh,
  Since the usage of activeTail is currently optional, there may be benefit in retaining the activeTail as part of the main specification. However we could improve the specification of the activeTail, please find the following observations in that context:
Section 1:
   This document effectively modifies and adds to the base BFD
   specification.  It is the intention of the authors to fold these
   extensions into the base specification at the appropriate time.
GVP1> Should we consider removing the second sentence of the last paragraph ? I assume that RFC 5880 would not change due to multi-point BFD gets standardized.

Section 2:
   A final goal is to integrate multipoint operation into the base
   specification in such a way as to make it relatively easy to support
   both multipoint and point-to-point operation in a single
   implementation.
GVP1> Should we consider removing this goal? I assume that RFC 5880 would not change due to multi-point BFD gets standardized.

Section 3:
In my understanding this section provides a lot of details in the way multipointTail sessions are bootstrapped and feedback on multipoint connectivity is provided back to the head. However it may be better to consider splitting this text into relevant sub-sections so important clauses needed for interoperability are not lost. In particular RFC 2119 verbs are not capitalized. I think it may be beneficial to explicitly capture the following aspects:
a/ Procedures  for bootstrapping and maintaining multipointTail sessions (already described in part in Sec 4.15.2)
b/ Procedures for generating unicast BFD packets (reflecting the connectivity state) from the tail nodes: It is my understanding that the tails do not initiate unicast packets until the head initiates the poll sequence for all tail nodes. If this is the case, we could consider adding explicit text to this effect. 
c/ Procedures for bootstrapping and maintaining multipointClient sessions:

There may be additional clarifications needed for the demux of BFD sessions at the tails especially when tracking P2MP MPLS LSPs. We could start a separate thread for those considerations.
	
Regards
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Thursday, October 09, 2014 9:08 PM
To: Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

[With Chair Hat On]

Dear WG,

Comments/thoughts?

Thanks!

-Nobo

> In the next few weeks, Santosh will be working with known implementors 
> to edit the document to match implementation.  Ideally these edits 
> will be complete prior to the next IETF session in Honolulu.  This 
> will put us a bit past our original milestone for publication, but 
> still much better on track than many of our previous documents.
> 
> -- Jeff
> 
> 
>

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 10 Oct 2014 16:28:49 +0000

Hi Nobo,
thank you for so precisely and eloquently formulating it:
      Knowing exactly what aspect is being questioned for removal may provide a better base for good discussions.
I see several possible scenarios:
*       keep the scope of the document as-is;
*       extract and move to an appendix as informational/historical description of tail monitoring but keep all new variables and states in standard part as currently defined (dormant but readily available);
*       rip off everything related to tail monitoring from the standard part (major, huge undertaking IMO).

Have I missed any other option?

        Regards,
                Greg

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Friday, October 10, 2014 7:48 AM
To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Santosh,

Thanks!

-Nobo

> [email-masked]<mailto:[email-masked]>
> To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]<mailto:[email-masked]>
> On 09/10/14 17:38, "Nobo Akiya (nobo)" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >[With Chair Hat On]
> >
> >Dear WG,
> >
> >draft-ietf-bfd-multipoint is one of the last couple of topics that
> >we, as a WG, need to resolve for this document.
> >
> >> > A New Internet-Draft is available from the on-line
> >> > Internet-Drafts
> >> directories.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 10 Oct 2014 12:48:03 -0400

> Have I missed any other option?

* Extract it to a new RFC extending the base multipoint draft; target it for
  experimental status.

-- Jeff

---

From: Santosh P K <[email-masked]>
Date: Tue, 14 Oct 2014 11:21:12 +0000

Hello All,
   Sorry for delay. I am trying to elaborate what I meant by "active tail". Please also comment on other two items that I have listed below which were raised by Prasad and Nobo in earlier discussions. 

Active tail:
------------
As per discussion with implementers it looks like we don't see any use case scenario for head tracking tail. Currently there are multiple options given in draft for head to track tail. 
	1.  Unreliable Head Notification as per section 6.2
		When tail detect timer expires it sends DOWN BFD packet to head on reverse unicast path. 
	2. Semi-reliable Head Notification and Tail Solicitation as per section 6.3
		A multipoint POLL with a combination of reverse unicast path FINAL will help head to know if tail has lost communication with head.
	3. Reliable Head Notification as per section 6.4
	 	A combination of multipoint POLL and unicast POLL will be used by head to detect tail going down. Tail will make use of reverse unicast path to send FINAL packet to head. 

We have below options:
	1. Go with simple "No Head Notification" as per section 6.1 in base draft and move rest of the sections to Appendix or move to separate draft?  In this case On MultipointHead bfd.ReportTailDown 
	     will be set to 0 and we might not even need MultipointClient as we are not going to receive any packets from tail. bfd.SilentTail will be set to 1 on MultipointTail
	2. Another option is to just keep "Unreliable Head Notification" as per section 6.2 and move/remove rest of mechanism through which Multipoint head can detect tail going down.
	     Meaning we need to move/remove Multicast POLL and unicast POLL from MultipointHead. 
	3. Jeff suggested that we move these sections to new draft with experimental status. 
	4.  Any other options? Please suggest.

Along with this I am also seeking comments on below two points.
Demux:
---------
This was brought up by Prasad in context of EVPN BFD draft that as per section 4.7 of this draft say

	" The minimum amount of a priori information required both on the head 
	    and tails is the binding to the multipoint path over which BFD is  running."

Above text is brief and draft is AF agnostic. Do we need to make text of Sec 4.7 and related sections more explicit? For example in case of EVPN tail nodes may use the P2MP label as the session demux key. Do we want to elaborate demux in base draft or it should be outside the scope of this document? 

Security consideration:
----------------------------
As per Nobo's comment on this draft long back.  We need to add some suggestion in security consideration. Mainly because MultipointTail session can be created dynamically.

Snippet from Nobo's mail. 

"MultipointTail sessions are dynamically created. If I had a way of getting around GTSM & Authentication (or lack of) and was aware of a source address that will pass the "check", then I could DoS this system with range of My Discriminator values to leaves, which will cause many instances of MultipointTail sessions to get created. Draft does say [create or discard] choice is outside the scope (in 4.16.2). But given the dynamic nature of session creation, it would be beneficial to highlight this point and provide suggestions in the "Security Consideration"."

Any suggestion on this?

Jeff and Nobo have already raised some concerns here. We might have to see how PIM is doing it today. 

Thanks
Santosh P K 

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 8:18 PM
To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Santosh,

Thanks!

-Nobo

---

From: Santosh P K <[email-masked]>
Date: Tue, 14 Oct 2014 11:24:03 +0000

Prasad,
  Thanks for your comments. I have raised the below point in my new mail. I have consolidated all three points of discussion in one mail. 

Thanks
Santosh P K

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 8:21 PM
To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

Hello Santosh,

Section 2:

Section 3:
In my understanding this section provides a lot of details in the way multipointTail sessions are bootstrapped and feedback on multipoint connectivity is provided back to the head. However it may be better to consider splitting this text into relevant sub-sections so important clauses needed for interoperability are not lost. In particular RFC 2119 verbs are not capitalized. I think it may be beneficial to explicitly capture the following aspects:
a/ Procedures  for bootstrapping and maintaining multipointTail sessions (already described in part in Sec 4.15.2) b/ Procedures for generating unicast BFD packets (reflecting the connectivity state) from the tail nodes: It is my understanding that the tails do not initiate unicast packets until the head initiates the poll sequence for all tail nodes. If this is the case, we could consider adding explicit text to this effect. 
c/ Procedures for bootstrapping and maintaining multipointClient sessions:

Regards
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: Thursday, October 09, 2014 9:08 PM
To: Santosh P K; Jeffrey Haas; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

[With Chair Hat On]

Dear WG,

Comments/thoughts?

Thanks!

-Nobo

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 14 Oct 2014 22:33:41 +0000

[With Chair Hat Off]

Hi Santosh,

Thank you for leading this effort!

Hopefully others can provide their comments to help close of last remaining points for the BFD multipoint document.

Please see my comments in-line.

> Sent: Tuesday, October 14, 2014 7:21 AM
> To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-
> [email-masked]
>    Sorry for delay. I am trying to elaborate what I meant by "active tail".
> Please also comment on other two items that I have listed below which
> were raised by Prasad and Nobo in earlier discussions.
> 
> Active tail:
> ------------
> As per discussion with implementers it looks like we don't see any use case
> scenario for head tracking tail. Currently there are multiple options given in
> draft for head to track tail.
> 		A multipoint POLL with a combination of reverse unicast
> path FINAL will help head to know if tail has lost communication with head.
> 	 	A combination of multipoint POLL and unicast POLL will be
> used by head to detect tail going down. Tail will make use of reverse unicast
> path to send FINAL packet to head.

One important characteristics is that:
(1) allows the head to be notified of _in-band_ failure by leaves.
(2) allows the head to poll leaves through _in-band_ packets.
(3) allows the head to poll leaves through _out-of-band_ unicast packets.

Going back to what Wim wrote (thanks for the comment Wim!):
[snip]
> Example is Multicast VPN using MP-BGP.
[snip]

True, in the scenario described, (3) adds very minimal value beyond running multi-hop BFD session between BGP peers.

On the other hand (1) and (2) are in-band, and can detect failures that other sessions like multi-hop BFD sessions cannot. It does look useful with technologies such as P2MP-TE where:

- leaves are constant
- has path-protection mechanism
 
> 
> We have below options:
> 	1. Go with simple "No Head Notification" as per section 6.1 in base
> draft and move rest of the sections to Appendix or move to separate draft?
> In this case On MultipointHead bfd.ReportTailDown
> 	     will be set to 0 and we might not even need MultipointClient as
> we are not going to receive any packets from tail. bfd.SilentTail will be set
> to 1 on MultipointTail
> 	2. Another option is to just keep "Unreliable Head Notification" as
> per section 6.2 and move/remove rest of mechanism through which
> Multipoint head can detect tail going down.

Another way to look at this is that:

(a) unicast DOWN notification from leaves.
(b) multicast Poll of leaves.
(c) unicast Poll of leaves.

If we want to keep the in-band mechanism and remove out-of-band mechanism, then preserve (a) and (b) but remove (c). And that would be my preference.

Mingui, for your "TRILL Resilient Distribution Trees", do you see the need for all [a-c] or just subsets?

> Above text is brief and draft is AF agnostic. Do we need to make text of Sec
> 4.7 and related sections more explicit? For example in case of EVPN tail
> nodes may use the P2MP label as the session demux key. Do we want to
> elaborate demux in base draft or it should be outside the scope of this
> document?

Demux procedures is one, UDP port is the other one (i.e. it is not specified in this document).

We need to either:
- Add details in this document, or
- Consider this document as multipoint base document, and roll out micro-documents describing demux/UDP-port details for various data planes.

Either will work, but the details are required somewhere to interoperate.

> As per Nobo's comment on this draft long back.  We need to add some
> suggestion in security consideration. Mainly because MultipointTail session
> can be created dynamically.
> 
> "MultipointTail sessions are dynamically created. If I had a way of getting
> around GTSM & Authentication (or lack of) and was aware of a source
> address that will pass the "check", then I could DoS this system with range
> of My Discriminator values to leaves, which will cause many instances of
> MultipointTail sessions to get created. Draft does say [create or discard]
> choice is outside the scope (in 4.16.2). But given the dynamic nature of
> session creation, it would be beneficial to highlight this point and provide
> suggestions in the "Security Consideration"."
> 
> Any suggestion on this?
> 

Right it would be a good idea how other multipoint/multicast protocols have addressed this.

Thanks!

-Nobo

---

From: Santosh P K <[email-masked]>
Date: Sat, 18 Oct 2014 13:33:48 +0000

Hello Nobo,
   Thanks again for your comments on this. Please see my comments. 

> Mingui, for your "TRILL Resilient Distribution Trees", do you see the need for all [a-c] or just subsets?

Does (a) alone not enough?  Want to know if there are any application which wants to track tail proactively? If so we can keep both (a) and (b). 

> Demux procedures is one, UDP port is the other one (i.e. it is not specified in this document).

Yes, UDP port is not specified in the document. We can add this info in base document itself? Every on ok with this? Any suggestions?  

Thanks
Santosh P K

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Wednesday, October 15, 2014 4:04 AM
To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]; Mingui Zhang
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

[With Chair Hat Off]

Hi Santosh,

> As per discussion with implementers it looks like we don't see any use 
> case scenario for head tracking tail. Currently there are multiple 
> options given in draft for head to track tail.
> 	2. Semi-reliable Head Notification and Tail Solicitation as per 
> section
> 6.3
> 		A multipoint POLL with a combination of reverse unicast path FINAL 
> will help head to know if tail has lost communication with head.
> 	 	A combination of multipoint POLL and unicast POLL will be used by 
> head to detect tail going down. Tail will make use of reverse unicast 

[snip]

- leaves are constant
 
> we are not going to receive any packets from tail. bfd.SilentTail will 
> be set to 1 on MultipointTail

> 4.7 and related sections more explicit? For example in case of EVPN 
> tail nodes may use the P2MP label as the session demux key. Do we want 
> to elaborate demux in base draft or it should be outside the scope of 
> this document?

We need to either:

> suggestion in security consideration. Mainly because MultipointTail 
> session can be created dynamically.
> 
> "MultipointTail sessions are dynamically created. If I had a way of 
> getting around GTSM & Authentication (or lack of) and was aware of a 
> source address that will pass the "check", then I could DoS this 
> system with range of My Discriminator values to leaves, which will 
> cause many instances of MultipointTail sessions to get created. Draft 
> does say [create or discard] choice is outside the scope (in 4.16.2). 
> But given the dynamic nature of session creation, it would be 
> beneficial to highlight this point and provide suggestions in the "Security Consideration"."
> 
> Any suggestion on this?
> 

Thanks!

-Nobo

> Knowing exactly what aspect is being questioned for removal may 
> provide a better base for good discussions.
> 
> Thanks!
> 
> -Nobo
> 
> > >Whether or not we keep or remove the active tail, leaves will be 
> > >able to detect the failure of the multicast tree, which allows 
> > >protections such as live-live.
> > >
> > >>    I am seeking comments on active tale section of this document. 
> > >>I spoke to  few implementers and found that no one really finds 
> > >>use case for active tale.
> > >>appendix? We would  like to make all the changes before IETF 91 
> > >>and push this for RFC. Any  suggestions?
> > >>
> > >> Thanks
> > >> Santosh P K
> > >>
> > >> Note that this consists mostly of a re-publish with Santosh as 
> > >>the new editor.
> > >>implementors to  edit the document to match implementation.  
> > >>Ideally these edits will be  complete prior to the next IETF 
> > >>session in Honolulu.  This will put us a bit  past our original 
> > >>milestone for publication, but still much better on track  than 
> > >>many of our previous documents.
> > >>
> > >> -- Jeff
> > >>
> > >>
> > >>
> > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, 
> > >>[email-masked]
> > >>wrote:
> > >> >
> > >> > Please note that it may take a couple of minutes from the time 
> > >> > of submission until the htmlized version and diff are available 
> > >> > at
> > >> tools.ietf.org.
> > >> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 21 Oct 2014 21:38:47 +0000

[With Chair Hat On]

WG,

I'd imagine many are busy ... being the last week before the cut-off and all ...

But it'll be very helpful if you can chime in to help Santosh to take BFD multipoint further.

[With Chair Hat Off]

Hi Santosh,

> Sent: Saturday, October 18, 2014 9:34 AM
> [email-masked]; Mingui Zhang
> > If we want to keep the in-band mechanism and remove out-of-band
> mechanism, then preserve (a) and (b) but remove (c). And that would be my
> preference.
> Does (a) alone not enough? 

Personally I think there's a value in leaving the option for the head to do in-band polling of leaves. In other words, if down notification from a leaf to the head, then there is no way for the head to find out that leaf is no longer receiving.

> Want to know if there are any application
> which wants to track tail proactively? If so we can keep both (a) and (b).

More comments from the WG will be very helpful. So far ...

- Mingui brought up "TRILL Resilient Distribution Trees".
- I brought up P2MP-TE Path Protection, which I think both (a) and (b) will be useful.

> Yes, UDP port is not specified in the document. We can add this info in base
> document itself? Every on ok with this? Any suggestions?

Demux procedures and UDP ports should go into the same document.

So it's either:

(a) put everything in draft-ietf-bfd-multipoint.

Or

(b) spin off draft-ietf-bfd-multipoint-<dataplane> document per data plane.

Thanks!

-Nobo

> > 		When tail detect timer expires it sends DOWN BFD packet to
> head on
> > reverse unicast path.
> path FINAL
> used by
> On the other hand (1) and (2) are in-band, and can detect failures that other
> sessions like multi-hop BFD sessions cannot. It does look useful with
> technologies such as P2MP-TE where:
> 
> - leaves are constant
> > 	     Meaning we need to move/remove Multicast POLL and unicast
> POLL
> > from MultipointHead.
> 
> If we want to keep the in-band mechanism and remove out-of-band
> mechanism, then preserve (a) and (b) but remove (c). And that would be my
> preference.
> 
> - Consider this document as multipoint base document, and roll out micro-
> documents describing demux/UDP-port details for various data planes.
>

---

From: Santosh P K <[email-masked]>
Date: Wed, 22 Oct 2014 02:12:57 +0000

Nobo,
  Thanks for your comments. It is more clear now. I will wait for other to comment on these points as well. 

Thanks
Santosh P K 

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2014 3:09 AM
To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; [email-masked]; Mingui Zhang
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt

[With Chair Hat On]

WG,

[With Chair Hat Off]

Hi Santosh,

> mechanism, then preserve (a) and (b) but remove (c). And that would be 
> my preference.
> > Mingui, for your "TRILL Resilient Distribution Trees", do you see 
> > the need
> for all [a-c] or just subsets?
> 

> Want to know if there are any application which wants to track tail 
> proactively? If so we can keep both (a) and (b).

> 
> > Demux procedures is one, UDP port is the other one (i.e. it is not 
> > specified
> in this document).
> 
> Yes, UDP port is not specified in the document. We can add this info 
> in base document itself? Every on ok with this? Any suggestions?

So it's either:

Or

Thanks!

-Nobo

> Hopefully others can provide their comments to help close of last 
> remaining points for the BFD multipoint document.
> 
> > Please also comment on other two items that I have listed below 
> > which were raised by Prasad and Nobo in earlier discussions.
> >
> > Active tail:
> > ------------
> > As per discussion with implementers it looks like we don't see any 
> > use case scenario for head tracking tail. Currently there are 
> > multiple options given in draft for head to track tail.
> > head to detect tail going down. Tail will make use of reverse 
> > unicast path to send FINAL packet to head.
> 
> True, in the scenario described, (3) adds very minimal value beyond 
> running multi-hop BFD session between BGP peers.
> 
> On the other hand (1) and (2) are in-band, and can detect failures 
> that other sessions like multi-hop BFD sessions cannot. It does look 
> useful with technologies such as P2MP-TE where:
> 
> - leaves are constant
> > 	     will be set to 0 and we might not even need MultipointClient 
> > as we are not going to receive any packets from tail. bfd.SilentTail 
> > will be set to 1 on MultipointTail
> mechanism, then preserve (a) and (b) but remove (c). And that would be 
> my preference.
> 
> > tail nodes may use the P2MP label as the session demux key. Do we 
> > want to elaborate demux in base draft or it should be outside the 
> > scope of this document?
> 
> - Consider this document as multipoint base document, and roll out 
> micro- documents describing demux/UDP-port details for various data planes.
> 
> > cause many instances of MultipointTail sessions to get created. 
> > Draft does say [create or discard] choice is outside the scope (in 4.16.2).
> > beneficial to highlight this point and provide suggestions in the 
> > "Security
> Consideration"."
> >
> > Any suggestion on this?
> >
> > > >draft-ietf-bfd-multipoint is one of the last couple of topics 
> > > >that we, as a WG, need to resolve for this document.
> > > >
> > > >protections, then active tail becomes a requirement. If there is 
> > > >no such requirements, then the active tail is an unnecessary 
> > > >portion of this document.
> > > >
> > > >> Does anyone on this forum feel that we might need active tale? 
> > > >>If there are  no uses cases then we can move active tale section 
> > > >>to appendix? We would  like to make all the changes before IETF 
> > > >>91 and push this for RFC. Any  suggestions?
> > > >>
> > > >> Thanks
> > > >> Santosh P K
> > > >>
> > > >> > Please note that it may take a couple of minutes from the 
> > > >> > time of submission until the htmlized version and diff are 
> > > >> > available at
> > > >> tools.ietf.org.
> > > >> >