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

Pekka Savola <pekkas@netcore.fi> Thu, 15 June 2006 15:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqto8-0005mS-42; Thu, 15 Jun 2006 11:30:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqto7-0005mN-6o for pim@ietf.org; Thu, 15 Jun 2006 11:30:55 -0400
Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqto6-0001vR-MK; Thu, 15 Jun 2006 11:30:55 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k5FFUkNh021308; Thu, 15 Jun 2006 18:30:46 +0300
Date: Thu, 15 Jun 2006 18:30:45 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: hoerdt@clarinet.u-strasbg.fr
Subject: Re: [pim] Simple join failure notification for PIM-SM multicast routing
In-Reply-To: <44916E8C.20300@renater.fr>
Message-ID: <Pine.LNX.4.64.0606151803010.20741@netcore.fi>
References: <20060615084436.GK16284@clarinet.u-strasbg.fr> <44916E8C.20300@renater.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: ClamAV 0.88.2/1539/Wed Jun 14 17:21:49 2006 on otso.netcore.fi
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2
X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi
X-Spam-Score: -2.8 (--)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: mboned@ietf.org, pim@ietf.org
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
Errors-To: pim-bounces@ietf.org

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

_______________________________________________
pim mailing list
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim