Subject: RE: A modest proposal: get rid of (*,*,RP) state

From: Billy Ng <[email-masked]>
Date: Mon, 12 Jun 2000 09:42:28 -0400

> 
>   Given this, we'd like to ask the following questions:
> 1) Does anyone handle receiving and propagating (*,*,RP) joins?

RiverDelta does not, but I know Nortel/Bay does :).

> 2) Does anyone implement the PMBR functionality that initiates
>    (*,*,RP) joins?

RiverDelta does not, but I know Nortel/Bay does :).

> 3) Most importantly, does anyone have any objections to eliminating
>    the (*,*,RP) functionality?
> 

No objections.  (don't think Nortel/Bay objects either :).

--Billy

---

From: Yunzhou Li <[email-masked]>
Date: Mon, 12 Jun 2000 11:31:08 -0400 (EDT)

Hi there,

I have an objection to eliminating the (*,*,RP) functionality:
(*,*,RP) state provides interoperability capability to PIM-SM
and DVMPR/PIM-DM; (*,*,RP) provides a better scalability to
high speed routers.

Thanks,
-yli

---

From: Yunzhou Li <[email-masked]>
Date: Mon, 12 Jun 2000 15:16:10 -0400 (EDT)

Hi All,

I should have explained my point in more detail:

A (*,*,RP) state is an aggregation of multiple (*,G/prefix)
states, or (*,*) state when the prefix length is 4 or less.
Each (*,G/prefix) state again is an aggregation of numerous
(*,G) and (S,G) states. With this interpretation, we don't 
have to do two lookups in the data forwarding plane. I think 
the new PIM-SM specification probably can reflect this fact.

A high speed router may not allow too much intelligence and 
it may not generate revenue per-flow (S,G) or (*,G). In 
stead, it may generate revenue per aggregated bandwidth or 
(*,G/prefix). In particular, we allow a (*,*,RP) generator 
to create a forwarding policy like "accept all but reject...".
This policy in turns can be propagated to all routers from 
the (*,*,RP) generator all the way to the RP. This is how 
we can benefit from (*,*,RP). At this point, I would think 
(*,*,RP) has a good match with BGMP (*,G/prefix) state.

Thanks,
-yli