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
- [pim] Simple join failure notification for PIM-SM… hoerdt
- Re: [pim] Simple join failure notification for PI… Jerome Durand
- Re: [pim] Simple join failure notification for PI… Pekka Savola
- Re: [pim] Simple join failure notification for PI… Beau Williamson
- Re: [pim] Simple join failure notification for PI… Dino Farinacci
- Re: [pim] Simple join failure notification for PI… Dino Farinacci
- Re: [pim] Simple join failure notification for PI… Jean-Jacques Pansiot
- Re: [pim] Simple join failure notification for PI… John Zwiebel
- [pim] Re: Simple join failure notification for PI… hoerdt