Subject: [pim] Simple join failure notification for PIM-SM multicast routing

From: [email-masked]
Date: Thu, 15 Jun 2006 10:44:36 +0200

Hello,

A new internet-draft is available in the ietf repository :

http://www.ietf.org/internet-drafts/draft-hoerdt-pim-group-unreachable-00.txt

Title :
"Simple join failure notification for PIM-SM multicast routing"
 
Abstract:

"Currently, PIM-SM is the most widely deployed multicast routing
protocol in the Internet. However in IPv6 this multicast protocol
lacks a simple connectivity debugging tool, making it difficult to
identify multicast routing problems.  When a host wants to receive a
multicast group or channel, if the corresponding  PIM-Join message
cannot be propagated in the network, nothing exists to inform the
receiver or the network about this failure. We propose a simple error
notification message based on ICMP/ICMP6 which is able to indicate
where and why the error happened in the network without using a
multicast traceroute mechanism."

We would like to present this work in the PIM working group at the
66th IETF/Montreal PIM. Before that, we would like to get comments and
engage discussion with the PIM and MBONED working groups in the
mailing lists.

thanks,

Hoerdt Mickael

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Jerome Durand <[email-masked]>
Date: Thu, 15 Jun 2006 16:28:28 +0200

Hi!

I read your doc, nice contribution indeed. IMHO, we should move forward 
this proposal quickly. We agreed in Dallas to have monitoring/management 
included in MBoned charter and your doc comes at the perfect time.

Thanks

Jerome

---

From: Pekka Savola <[email-masked]>
Date: Thu, 15 Jun 2006 18:30:45 +0300 (EEST)

On Thu, 15 Jun 2006, Jerome Durand wrote:
> I read your doc, nice contribution indeed. IMHO, we should move forward this 
> proposal quickly. We agreed in Dallas to have monitoring/management included 
> in MBoned charter and your doc comes at the perfect time.

I agree that usability and reliability improvements would be useful. 
The more generic issue how how to make PIM more reliable is undoubtely 
a topic for PIM WG rechartering discussion (as well as MBONED WG for 
making requirements on manageability in general).

I've read the draft in question, and have written up a number of 
mostly editorial comments, but I think there are a couple of high 
level issues first:

  - what is it what we really want?
   a) reporting to PIM routers on the path on observed failures?
   b) reporting to the receiver hosts on observed failures?
   c) receiver-side DoS attack mitigation so that (S,G) joins can be
      pruned off if S does not exist? [see
      draft-ietf-mboned-mroutesec-04.txt]

   First of all, the current mechanism is only reporting a subset of
   failures, i.e., those where it gets an indication that a failure
   occurred.  There is no way to detect e.g., packet getting silently
   dropped (for any number of reasons) as joins are not acked [*].
   I wonder whether there are many of these 'packet discarded'
   scenarios, e.g., non-existing source but which matches a discard
   default route.

   Personally, I'd be most interested in a) and c), because I fear b)
   is very difficult because the hosts would need extra intelligence
   to actually parse this stuff, and if we wanted to primarily report
   to the hosts, we'd have to assume all the routers in the path
   support this (which is not necessarily the case)

   It seems that we might actually want two things, improve
   manageability of both PIM _and_ IGMP/MLD plus security of PIM-SM.

  - it seems that ICMP error message is an odd choice for this 
protocol, given that almost all the traffic is really hop-by-hop 
between PIM routers.  Did you consider using PIM messaging for this? 
This approach is outlined in Appendix B of 
draft-ietf-mboned-mroutesec.  The only part where ICMP might make 
sense is DR-to-host reporting, but even that should probably better be 
a new MLD/IGMP message.

  - the protocol appears to send group unreachability reports 
immediately.
[*] An interesting related problem is whether a PIM join should be 
retransmitted before doing so (but AFAICS, current specs do not do 
such retransmissions, so a PIM join can be dropped for any number of 
reasons)

  - you do not spell out that every router on the path is required to 
support this in order for the unreachability report to get back. 
This lessens the value of the mechanism.  It might be possible to 
achieve similar effects (possibly with lesser amount of failure 
reporting, not sure) using existing PIM prune signalling.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Beau Williamson <[email-masked]>
Date: Thu, 15 Jun 2006 14:10:11 -0500

Hoerdt, et al,

I did a quick review of the draft as well as reading some of Pekka's and 
Toerless' comments.

It seems to me that what you are calling for would best be served by a 
PIM-NACK message.  We've talked about doing PIM-ACK's to do reliable PIM 
signalling for years but most of this has centered on the use of PIM-ACK 
messages.

While I like the fundament concept of being able to signal tree failure, I 
would agree with Pekka and Toerless that we have a ways to go to put all 
the items in place to do this and make it effective.

For example, let's say that there is a temporary outage or topology change 
that results in a Periodic Join failing to be processed. If we send this 
PIM-NACK message down the tree, is the last hop router supposed to send a 
Prune and delete the mroute state in order to tear down the now useless 
tree?  What if the outage has been rectified a short time later.  How does 
the last hop router know to "try again".

Having said the above, I don't want to discourage you from pursuing this. 
All I wanted to point out is that it seems to me that a new PIM control 
packet would be better served to accomplish this.  Ergo, the PIM-NACK that 
is propagated down the tree. That and (like Toerless) I'm not sure exactly 
how existing hosts and networks would make use of this information.

Beau Williamson

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Jun 2006 21:46:22 -0700

>> multicast traceroute mechanism."

    IP multicast scales well today because no where in the network state is
    maintained per receiver. This is an important scalability principle I
    would like to see not change.

    What happens if a link goes down where it affects 1000s of receivers.
    The router on the downstream side of the failure would 1) have to track
    the receivers and 2) send a message to each of them. This can't possibly
    be workable. 

    This should be solved and there are cases where it has been solved by
    doing beaconing at the application layer.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Jun 2006 23:40:35 -0700

>> The unreachability message is sent to downstream routers,
>> using outgoing interfaces in the group/channel entry of the TIB (that is 
>> the same interfaces
>> it would send a data packet)

    Still too much state and too much messaging. 

Dino

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Fri, 16 Jun 2006 08:36:32 +0200

>     the receivers and 2) send a message to each of them. This can't possibly
this is not at all what we propose. No information on  receivers is 
maintained.
The unreachability message is sent to downstream routers,
using outgoing interfaces in the group/channel entry of the TIB (that is 
the same interfaces
it would send a data packet)

Jean-Jacques

---

From: John Zwiebel <[email-masked]>
Date: Fri, 16 Jun 2006 12:53:59 -0700

2cents:

-- GU messages received by an RP should stop there unless the RP
	has (S,G) state with an OIF-list.  Sending a GU down a
	shared-tree doesn't tell us anything.  If it is important
	to know that a specific source is missing, I'd say that
	the receiver should have been using SSM.  (another point for
	my "dump ASM" campaign.
-- in 2.2 you state that the GUs are sent to the DRs, but its only
	the DR on the fist-hop that this applies to.  Intermediate
	routers may or may not be a DR on any interface.
-- It was suggested that the GU might be useful in getting a downstream
	router to recognize a upstream failure so it might join to
	a different path.  I see danger in this path.  It could interfere
	with the unicast routing protocol that PIM is dependent on.
-- the spec doesn't cover what a host might do with this information,
	if the user doesn't get the report and actually do something
	with it, then I don't see how it is useful.
-- Figure 3: I'd prefer it be called "source address" vs unicast address
-- I don't see the usefulness of the L flag.  If a downstream router  
never
	gets one does that mean anything?
-- R and S bits.  May not be necessary.  Sending S information down the 
	shared tree doesn't mean anything to me.  If the RPF to the
	source == RPF to the RP, receipt of a (*,G) GU means the same thing
	"you can't get there from here".
	ie, a Group Record with 0 source addresses means its an ASM group
	the last-hop router should never have been able to join to the SPT
	so receipt of a GU that tells it about a given source doesn't mean
	anything.  Even in the case where the (S,G) state is set up and then
	the share/SPT goes away at the same time, I think one could do away
	with having to specifically address the shortest path since they
	overlap and the last-hop knows that they overlap.

	in cases where the last-hop RPFs to the same spt/RPT router but
	above that point things diverge, what is the advantage of getting
	S info down the RPT?  Either data stops or it doesn't.  If it
	doesn't, you know the SPT is still up so you don't care about
	that.  But you don't know that the RPT is down, which becomes
	clear when you get the GU with the GR and 0 sources.

	ie, if you do decide to continue with this draft (whether it be in
	ICMP or PIM) as a last-hop I want to know that the (*,G) is down or
	the (S,G) is down.  If the (*,G) and (S,G) overlap to the point of
	failure, there is no additional information in separately specifying
	each (S,G).