Subject: FW: PIM-SM source aggregation

From: Sudhir Cheruathur <[email-masked]>
Date: Tue, 12 Oct 1999 15:13:31 -0700

-----Original Message-----
From: Liming Wei [mailto:[email-masked]] 
Sent: Tuesday, October 12, 1999 11:42 AM
To: [email-masked]
Subject: Re: PIM-SM source aggregation

Sudhir,

If it is ok with you, please forward this message to the WG mailing
list.

The issue of source address aggregation is still a work-in-progress
subject. Although the packet format allows source masks, no mechanism
is put in place to utilize it yet. And there is not a known design
to do source aggregation well, without side effects or showstoppers.

That does not mean a truely simple yet effective way does not
exist for source aggregation. It does require non-trivial design
work. You are welcome to propose such a mechanism to the PIM working
group, with the understanding that the discussions on it may
generate more issues.

If you like, I can put down 10 minutes for you to talk about this
in the DC working group meeting.

-Liming

> From: Sudhir Cheruathur <[email-masked]>
> 
> Hi Liming Wei,
> 
> 
> I posted this question on the mailing list but I did not get any reply.
> I hope it is ok to ask you directly. If it is inconvenient, my apologies. 
> 
> 
>  My question is related to source aggregation in PIM-SM.
> 
> 
> Consider the following network.
> 
>     R1----------------------R2------s1,s2
>      |                         |
>      |                         |
>     R4----------------------R3
>      |
>     G
> 
>   (in case the above figure is unreadable)
>   R1 is connected to R2 and R4. 
>   R2 is connected to R3 and R1 
>   R3 is connected to R2 and R4
>   R4 is connected to R1 and R3
>  
> 
> 
>   Let R1 be the RP.
>  
>   Let sources 1.1.1.1(s1) and 1.1.1.2(s2) be connected 
>   to R2 on another interface.
> 
>   A host on R4 wants to recv packets to group G.
> 
>   When source S1 starts to send packets to G, At
>   R2 (S,G) created is (1.1.1.0,G). 
>   (I am assuming that it is ok to aggregate S in this way.)
>   
>   When source S2 starts to send packets to G. The above
>   (1.1.1.0,G) is used to send packets to the RP.
> 
>   Traffic starts to flow via RPT between R2 and R4 via the RP (R1).  
> 
>   Now R4 initiates SPT towards S1. However the (S,G)
>   created here is (1.1.1.1,G),
>  
>   R4 sends a (1.1.1.1, G) join towards R2 via R3
>   R3 creates (1.1.1.1,G) sends a join to R2.
> 
>   Now does R2 create (1.1.1.1,G) or use the already existing
>   (1.1.1.0,G) to join the SPT ? 
> 
>   If it does  i.e. use the existing aggregated entry, won't the 
>   following happen ?
>        
>       At R4  (1.1.1.1,G) upstream R3.
>       At R3  (1.1.1.1,G) upstream R2.
>       At R2  (1.1.1.0,G) upstream local interface.
> 
>       Because of these states traffic from S2 (1.1.1.2) starts flowing 
>       down the SPT tree (towards R3). But will get dropped at R3.
> 
> 
> 
> Is it required that all routers use  fully qualified source
> addresses for (S,G) ?  
> 
> When looking up an existing (S,G)state while processing (S,G)
joins/prunes, 
> should S's match exactly or should one use the longest match ?
> 
> The J/P packets contain the netmask so intermediate routers 
> can have same (S,G) as the one who initiates the joins. 
> But what happens at the sender's/receiver's end, is it a policy decision ?
> 
> Thanks a bunch.
> 
> Regds
> Sudhir C
>

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Tue, 12 Oct 1999 15:59:57 -0700

> >   (1.1.1.0,G) to join the SPT ? 

If we assume that the router lookup supports longest prefix match,
then R2 should create (1.1.1.1/32,G) with oif=(1.1.1.0/24,G)oifs+oif
toward R3, and at the same time it should keep the existing
(1.1.1.0/24,G). 

On the other side, if the s2 bw is low and if the overhead of
sending it over R2-R3 is tolerable, then no need to add
(1.1.1.1/32,G); instead, you should just add the R2-R3 oif to
(1.1.1.0/24,G). However, this technique should be used more
carefully than the first one.

If the router doesn't support longest prefix match, then it either
should split the aggregate (1.1.1.0/24,G) after the first (S,G) join
is received (actually, it can delete the (1.1.1.0/24,G) and later
will create "on demand" the (S,G)s for all active sources), or
should use the second technique above (again, only if the total bw
overhead is tolerable).

There is nothing PIM-SM specific here, and it is router
implementation issue.

Could you tell me why are you concerned about the states in R2? It
is quite likely that R2 will be an edge router, with relatively
limited number of active senders, so it will have relatively small
number of states. R1 (the RP) should be ot major concern, because it
will have much larger number of states.

Pavlin