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

From: [email-masked]
Date: Mon, 12 Jan 2015 01:05:57 -0800

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-05.txt
	Pages           : 18
	Date            : 2015-01-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-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-05

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, 12 Jan 2015 09:11:26 +0000

Hello All,
    A new version of BFD Multipoint draft is published. Below are the changes made. 

I have finished incorporating comments for BFD multipoint. I have done changes as below.
1.	Removing active tail.
2.	Adding more clarity about IP/MPLS demux.
3.	Packet consumption on tails.
4.	Desired echo interval setting. 
5.	Security concerns.

Please review this new version and let me know if any comments. 

Thanks
Santosh P K 

> -----Original Message-----
> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Monday, January 12, 2015 2:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-bfd-multipoint-05.txt
> 
>

---

From: Mingui Zhang <[email-masked]>
Date: Tue, 13 Jan 2015 02:13:15 +0000

Hi Santosh,

I have a concern with demux. In Section 4.7, a combination of (source address, My Discr, multipoint_tree_id) is used to demux at the tail. But, if we read the first 'if' branch in Section 4.13.2, we have
         "Select a session based on the source address and the My
         Discriminator field. "
The parameter "multipoint_tree_id" is missed here.

I understand the "multipoint_tree_id " is introduced to strengthen the security of the system based on a previous comment.
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01919.html
However, I advise we reconsider it. Let's use an example. Suppose the head uses My Discr = 100 on both tree1 and tree2. A tail can well demux these two sessions if the multipoint_tree_id is used for demux. If the tail replies to the head with YourDisc=100 and without the multipoint_tree_id, the head cannot tell whether the failed multipath is on tree1 or on tree2. Hence, the tail MUST carry the multipoint_tree_id in the unicast reply packet as well. But, does the unicast packet have the place to accommodate the multipoint_tree_id?

By the way, 
s/4.16. /4.13./

Thanks,
Mingui

>From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Santosh P K
>Sent: Monday, January 12, 2015 5:11 PM
>To: [email-masked]
>Subject: RE: I-D Action: draft-ietf-bfd-multipoint-05.txt
>
>Hello All,

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 13 Jan 2015 10:09:05 +0000

Hello Mingui,
   My understanding thus far on any BFD session type is that session discriminators are unique (leaving aside the more complex case of classical and SBFD supported on the same node). So, I am not sure why the demux needs to consider the case where the same discriminator is allocated to two different sessions tracking two different trees. Can you please let me know if I am missing something here?
Thanks
Prasad

-----Original Message-----
From: Rtg-bfd [mailto:[email-masked]] On Behalf Of Mingui Zhang
Sent: Tuesday, January 13, 2015 7:43 AM
To: Santosh P K; [email-masked]
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-05.txt

Hi Santosh,

By the way,
s/4.16. /4.13./

Thanks,
Mingui

>> From: Rtg-bfd [mailto:[email-masked]] On Behalf Of 
>> internet- [email-masked]
>> 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: Santosh P K <[email-masked]>
Date: Tue, 13 Jan 2015 14:47:29 +0000

Mingui,
    Thanks for your comments. Please see my inline comments.

> I have a concern with demux. In Section 4.7, a combination of (source
> address, My Discr, multipoint_tree_id) is used to demux at the tail. But, if we
> read the first 'if' branch in Section 4.13.2, we have

Thanks for point it out. I think I missed this and I need to add this :). 

> I understand the "multipoint_tree_id " is introduced to strengthen the
> security of the system based on a previous comment.
> However, I advise we reconsider it. Let's use an example. Suppose the head
> uses My Discr = 100 on both tree1 and tree2. A tail can well demux these two
> sessions if the multipoint_tree_id is used for demux. If the tail replies to the
> head with YourDisc=100 and without the multipoint_tree_id, the head
> cannot tell whether the failed multipath is on tree1 or on tree2. Hence, the
> tail MUST carry the multipoint_tree_id in the unicast reply packet as well.
> But, does the unicast packet have the place to accommodate the
> multipoint_tree_id?

This is a good point but I think this suggestion is more for Head de-multiplexing packets received from tail on reverse unicast path right? The new multipoint document has no text for active tail. This means this section is applicable only for tail de-multiplexing packets received over multipoint tree. This text is also under IF condition which says if M bit is set right. This can only happen if you are tail. 

In active tail document this is a problem as head will receive packets over reverse unicast path and head will not get multicast tree id. So it has to use combo of Your_disc and srouce address and not include multicast tree id in that. Is that ok? 

Thanks
Santosh P K

> From: Mingui Zhang [mailto:[email-masked]]
> I have a concern with demux. In Section 4.7, a combination of (source
> address, My Discr, multipoint_tree_id) is used to demux at the tail. But, if we
> read the first 'if' branch in Section 4.13.2, we have
> I understand the "multipoint_tree_id " is introduced to strengthen the
> security of the system based on a previous comment.
> However, I advise we reconsider it. Let's use an example. Suppose the head
> uses My Discr = 100 on both tree1 and tree2. A tail can well demux these two
> sessions if the multipoint_tree_id is used for demux. If the tail replies to the
> head with YourDisc=100 and without the multipoint_tree_id, the head
> cannot tell whether the failed multipath is on tree1 or on tree2. Hence, the
> tail MUST carry the multipoint_tree_id in the unicast reply packet as well.
> But, does the unicast packet have the place to accommodate the
> multipoint_tree_id?
> 
> By the way,
> s/4.16. /4.13./
> 
> Thanks,
> Mingui
>

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 14 Jan 2015 03:14:43 +0000

Hi Santosh,

Thanks for your response. 

>In active tail document this is a problem as head will receive packets over
>reverse unicast path and head will not get multicast tree id. 

Yes, that was exactly what I wanted to explain.

>So it has to use
>combo of Your_disc and source address and not include multicast tree id in that.
>Is that ok?

I think this is the simplest way to solve the problem. 

Thanks,
Mingui

>From: Santosh P K [mailto:[email-masked]]
>Sent: Tuesday, January 13, 2015 10:47 PM
>To: Mingui Zhang; [email-masked]
>This is a good point but I think this suggestion is more for Head de-multiplexing
>packets received from tail on reverse unicast path right? The new multipoint
>document has no text for active tail. This means this section is applicable only
>for tail de-multiplexing packets received over multipoint tree. This text is also
>under IF condition which says if M bit is set right. This can only happen if you are
>tail.
>
>In active tail document this is a problem as head will receive packets over
>reverse unicast path and head will not get multicast tree id. So it has to use
>combo of Your_disc and srouce address and not include multicast tree id in that.
>Is that ok?
>
>Thanks
>Santosh P K
>
>

---

From: Mingui Zhang <[email-masked]>
Date: Wed, 14 Jan 2015 03:22:57 +0000

Hi Prasad,

It could happen if the tree_id is used as a factor for demux. 
Since Santosh has explained this issue in an email afterward. Let's discussion this issue over there.

Thanks,
Mingui

>From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]]
>Sent: Tuesday, January 13, 2015 6:09 PM
>To: Mingui Zhang; Santosh P K; [email-masked]
>   My understanding thus far on any BFD session type is that session
>discriminators are unique (leaving aside the more complex case of classical and
>SBFD supported on the same node). So, I am not sure why the demux needs to
>consider the case where the same discriminator is allocated to two different
>sessions tracking two different trees. Can you please let me know if I am missing
>something here?
>Thanks
>Prasad
>
>I have a concern with demux. In Section 4.7, a combination of (source address,
>My Discr, multipoint_tree_id) is used to demux at the tail. But, if we read the
>first 'if' branch in Section 4.13.2, we have
>I understand the "multipoint_tree_id " is introduced to strengthen the security
>of the system based on a previous comment.
>head with YourDisc=100 and without the multipoint_tree_id, the head cannot
>tell whether the failed multipath is on tree1 or on tree2. Hence, the tail MUST
>carry the multipoint_tree_id in the unicast reply packet as well. But, does the
>unicast packet have the place to accommodate the multipoint_tree_id?
>
>By the way,
>s/4.16. /4.13./
>
>Thanks,
>Mingui
>