Tom and I are using the following site to track pim wg drafts: http://www.employees.org/~mmcbride/pimwg/draft_status It will be kept current. Please ping us with additional details you may want to see. And please feel free to offer assistance to draft authors on open issues. thanks, mike
Below I am including few more comments regarding the PIM-SM spec. First I include few emails to the ML (items 1--3) from other folks that had raised some issues in the past. Some of those issues are probably related. The rest of the items are just editorial stuff. Pavlin =================================================================== 1) [An old email from "James Huang" <jhuang <at> zumanetworks.com> 11 Apr 2002]: After more thoughts on the issue that I raised in my previous emails, I still believe there is a problem with the (S,G) assert state-machine. The problem is as follows: Suppose initially the state-machine is in the NoInfo state and AssertTrackingDesired(S,G,I)== TRUE. When it receives a prefered (S,G) assert message with RPT clear from intf I, it will transition to the AssertLoser state. Additionally, if (I == RPF_intf(S)), it will set SPTbit(S,G) to 1. Now if JoinDesired(S,G) is FALSE, we have created a bad (S,G) state where SPTbit(S,G) is set to 1 while JoinDesired(S,G) is FALSE. This bad state can prevent this router from forwarding future (S,G) traffic (see sec 4.2 Data Forwarding Rules). I think the fix is to set SPTbit(S,G) to 1 only if (I == RPF_intf(S)(Continue reading)
Hi all, I would like to have a clarfication regarding RP selection. For example if I have the following RP SET list: 239.1.1.0/24 10.10.1.3 (PRIORITY = 5) 10.10.1.2 (PRIORITY = 4) 10.10.1.1 (PRIORITY = 3) 239.1.0.0/16 10.10.1.2 (PRIORITY = 10) 10.10.1.3 (PRIORITY = 10) For the group 239.1.1.1 the longest match would be 239.1.1.0 and for group 239.1.2.1 it would match 239.1.0.0. According to rfc 2362: From the RPs with the highest priority (i.e. lowest `Priority' value), the candidate with the highest resulting value is then chosen as the RP for that group, and its identity and hash value are stored with the entry created. Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because it has the lowest priority, so the rfc statement doesn`t make sense to me. We have found an RP with the lowest priority so why is the second step required.I thought hash value is required only if(Continue reading)
> I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense > to me. We have found an RP with the lowest priority so why is the > second step required.I thought hash value is required only if > priorities are same (to resolve the tie). >(Continue reading)
On Fri, Apr 02, 2004 at 08:52:03AM -0500, aruts <at> excite.com wrote: > > Hi all, > > I would like to have a clarfication regarding RP selection. > > For example if I have the following RP SET list: > > 239.1.1.0/24 > 10.10.1.3 (PRIORITY = 5) > 10.10.1.2 (PRIORITY = 4) > 10.10.1.1 (PRIORITY = 3) > > > 239.1.0.0/16 > 10.10.1.2 (PRIORITY = 10) > 10.10.1.3 (PRIORITY = 10) > > For the group 239.1.1.1 the longest match would be 239.1.1.0 > and for group 239.1.2.1 it would match 239.1.0.0. > > According to rfc 2362: > > From the RPs with the highest priority (i.e. lowest > `Priority' value), the candidate with the highest resulting > value is then chosen as the RP for that group, and its identity > and hash value are stored with the entry created. > > Now for 239.1.1.1 10.10.1.1 should be selected as RP simply because > it has the lowest priority, so the rfc statement doesn`t make sense(Continue reading)
[Note: a reply to a 2 weeks old email] I will reply only to Issue 2 below. I will leave other folks to reply re. Issue 1. > Hi, > > (I read through the pim spec, and I'll be writing up my comments in a > couple of days .. but there's one biggest issue which I wanted to > raise immediately..) > > Section 4.7 defines the behaviour of PIM-SM router which is > interfacing a different multicast routing protocol, referring to RFC > 2715. > > Issue 1: the whole point may be moot because RFC 2715 is > Informational, and this is aimed aa Standards Track; there can be no > normative reference to it. > > Possible resolution: decrease the weight of RFC 2715 in this document, > and move RFC 2715 off to informative references. > > Issue 2: the wildcard receiver requirement (see below) is completely > unrealistic, could be an enermous DoS component, and is completely > inpractical -- not to mention failing to work with mechanisms like > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > not know about all the groups in a domain. Imagine a case where you > could associate with a PIM-SM router, and act as a wildcard receiver. > Instand multicast DoS as the PIM-SM router would have to join to every > source in the Internet!!!!(Continue reading)
On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > Issue 2: the wildcard receiver requirement (see below) is completely > > unrealistic, could be an enermous DoS component, and is completely > > inpractical -- not to mention failing to work with mechanisms like > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > not know about all the groups in a domain. Imagine a case where you > > could associate with a PIM-SM router, and act as a wildcard receiver. > > Instand multicast DoS as the PIM-SM router would have to join to every > > source in the Internet!!!! > > > > Suggestion: discuss this requirement. My feeling is that it should be > > deprecated (with caveats, and describing its limitations) or removed > > completely. > > > The (*,*,RP) Join is generated only by the border routers for the > RPs within their own domain. In other words, the (*,*,RP) Join is > not carried across domains. Hence, you cannot use it for > inter-domain DoS attacks. > > Within a domain, the assumption is that you trust your own routers > for the (*,*,RP) Join generation (among all other stuff), hence it > can't be used for intra-domain DoS attack either. How about SSM where you don't have any RPs and no (similar) multicast domain? The wildcard receiver argument applies equally to that as well, AFAICS. What about embedded-RP (or maybe also bidir-PIM, not sure), where the multicast domain practically includes all of the Internet?(Continue reading)
> On Tue, 6 Apr 2004, Pavlin Radoslavov wrote: > > > Issue 2: the wildcard receiver requirement (see below) is completely > > > unrealistic, could be an enermous DoS component, and is completely > > > inpractical -- not to mention failing to work with mechanisms like > > > SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does > > > not know about all the groups in a domain. Imagine a case where you > > > could associate with a PIM-SM router, and act as a wildcard receiver. > > > Instand multicast DoS as the PIM-SM router would have to join to every > > > source in the Internet!!!! > > > > > > Suggestion: discuss this requirement. My feeling is that it should be > > > deprecated (with caveats, and describing its limitations) or removed > > > completely. > > > > > > The (*,*,RP) Join is generated only by the border routers for the > > RPs within their own domain. In other words, the (*,*,RP) Join is > > not carried across domains. Hence, you cannot use it for > > inter-domain DoS attacks. > > > > Within a domain, the assumption is that you trust your own routers > > for the (*,*,RP) Join generation (among all other stuff), hence it > > can't be used for intra-domain DoS attack either. > > How about SSM where you don't have any RPs and no (similar) multicast > domain? The wildcard receiver argument applies equally to that as > well, AFAICS. The (*,*,RP) Joins don't apply for the SSM multicast address range simply because the RPs exclude that address range.(Continue reading)
On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > How about SSM where you don't have any RPs and no (similar) multicast > > domain? The wildcard receiver argument applies equally to that as > > well, AFAICS. > > The (*,*,RP) Joins don't apply for the SSM multicast address range > simply because the RPs exclude that address range. You miss the point. Are you saying that PIM-SSM does not need to interoperate with other multicast routing protocols, as described in section 4.7? This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as that is just a specification detail. I'm interested in more high-level issues. > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > multicast domain practically includes all of the Internet? > > > > (with multicast domain I refer to the area for which the group is > > active on under one RP or no RP at all (SSM).) > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > domain I mean entities as AS). Do you mean that such a join would be blocked at the border of the PIM domain (AFAIK not -- one only blocks BSR messages?), for example if the routers along the path were manually configured to use out-of-domain RP?(Continue reading)
> On Wed, 7 Apr 2004, Pavlin Radoslavov wrote: > > > How about SSM where you don't have any RPs and no (similar) multicast > > > domain? The wildcard receiver argument applies equally to that as > > > well, AFAICS. > > > > The (*,*,RP) Joins don't apply for the SSM multicast address range > > simply because the RPs exclude that address range. > > You miss the point. > > Are you saying that PIM-SSM does not need to interoperate with other > multicast routing protocols, as described in section 4.7? Yes. > This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as > that is just a specification detail. I'm interested in more > high-level issues. > > > > What about embedded-RP (or maybe also bidir-PIM, not sure), where the > > > multicast domain practically includes all of the Internet? > > > > > > (with multicast domain I refer to the area for which the group is > > > active on under one RP or no RP at all (SSM).) > > > > Still, the (*,*,RP) Joins don't cross domain boundaries (and here by > > domain I mean entities as AS). > > Do you mean that such a join would be blocked at the border of the PIM > domain (AFAIK not -- one only blocks BSR messages?), for example if(Continue reading)
RSS Feed40 | |
|---|---|
42 | |
34 | |
13 | |
16 | |
17 | |
6 | |
9 | |
13 | |
11 | |
6 | |
11 | |
8 | |
19 | |
24 | |
41 | |
12 | |
12 | |
1 | |
13 | |
32 | |
38 | |
18 | |
15 | |
30 | |
25 | |
36 | |
22 | |
107 | |
17 | |
24 | |
14 | |
10 | |
3 | |
25 | |
11 | |
12 | |
29 | |
24 | |
12 | |
6 | |
2 | |
7 | |
13 | |
16 | |
2 | |
20 | |
22 | |
11 | |
1 | |
5 | |
14 | |
6 | |
7 | |
15 | |
4 | |
15 | |
21 | |
17 | |
41 | |
22 | |
23 | |
11 | |
4 | |
17 | |
30 | |
3 | |
13 | |
15 | |
52 | |
17 | |
17 | |
22 | |
23 | |
8 | |
8 | |
15 | |
24 | |
7 | |
20 | |
35 | |
3 | |
24 | |
34 | |
22 | |
20 | |
74 | |
33 | |
39 | |
38 | |
15 | |
122 | |
65 | |
5 | |
33 | |
9 | |
3 | |
42 | |
40 | |
27 | |
11 | |
28 | |
7 | |
44 | |
52 | |
40 | |
11 | |
20 | |
15 | |
32 | |
28 | |
39 | |
19 | |
21 | |
4 | |
18 | |
40 | |
25 | |
8 | |
16 | |
14 | |
58 | |
19 | |
76 | |
30 | |
7 | |
28 | |
8 | |
25 | |
33 | |
18 | |
33 | |
26 | |
41 | |
27 | |
1 |
